Genesis Blueprint und Program
Blueprint und Programm sind gepflegte Erläuterungen, kein Nachweis, Eigentum oder ein vollständiges semantisches Modell.
Blueprint
genesis/blueprint.md ist eine kurze, kohärente, nicht-technische Beschreibung dessen, was das Produkt tun soll. Bevorzuge explizite Benutzerabsichten. Erwähne keine Frameworks, Pakete, Routenschreibweisen, Schemata, Quelldateien, Implementierungspläne, Tests oder private Architektur.
Aktualisiere das Blueprint nach der Implementierung nur dann, wenn die Änderung bewusst beobachtbares Produktverhalten hinzufügt, entfernt oder verändert. Verwandle niemals einen Unfall, einen Fehler, eine private Designentscheidung oder Mehrdeutigkeit in eine Produktabsicht.
Program
Organisiere das Programm in lesbaren Verzeichnissen; die Mitgliedschaft wird nur in genesis/subsystems.md deklariert, unabhängig von Verzeichnisnamen:
genesis/program/billing/invoices.md
genesis/program/authentication/sessions.md
Erstelle ein Modul für jede sinnvolle öffentliche Operation, die von einem Subsystem bereitgestellt wird, unabhängig von Sprache oder Quellayout. Öffentliche Operationen umfassen exportierte Funktionen oder Methoden, API-Aktionen, Befehle, UI-Operationen und andere beobachtbare Einstiegspunkte. Bilde keine Quelldateien ab und dokumentiere nicht jede Hilfsfunktion.
Jedes Modul enthält:
# Lesbarer Grenzname
Eine kurze Erklärung, warum die Grenze existiert.
## Quellen
- Hauptquelle: `genauer/erstellter/hauptquellpfad`
- `genauer/erstellter/unterstützender/quellpfad`
## Öffentlicher Vertrag
Bedeutungsvolle Eingaben, Ausgaben, Effekte, Fehler und Garantien.
Jedes Modul benötigt genau einen - Hauptquelle:-Bullet-Punkt. Wähle die Hauptquelle explizit als den Ort, an dem man mit dem Lesen der Implementierung beginnen sollte; es muss kein ausführbarer Einstiegspunkt sein. Es muss zum besitzenden Subsystem des Moduls gehören, unter Berücksichtigung spezifischerer verschachtelter Verzeichnisbesitzer. Andere Quellen können gemeinsam genutzte Bibliotheken in anderen Subsystemen zitieren. Leite die Hauptdatei niemals aus der Reihenfolge der Quellenliste, Importen oder Dateinamen ab. Wenn ältere Module abgeglichen werden, überprüfe die Quelle und markiere den Anker explizit; die Indizierung weist keinen für dich zu.
Ein optionaler ## Implementierungslandkarte darf nur private Hilfsfunktionen oder Nähte benennen, die einem zukünftigen Agenten wesentlich helfen, die Operation zu ändern, zu verfolgen oder zu debuggen. Er ist informativ, keine öffentliche Garantie. Tests sind Beweise und niemals Implementierungsquellen.
Bevorzuge weniger, klarere Module. Entferne veraltete und doppelte Erläuterungen. Eine Quelle kann mehrere Operationen unterstützen; Hilfs- und Klebedateien können in keinem Programmmodul vorkommen.
Aufgabenabgrenzungen
Der Aufrufer bestimmt, ob es sich um eine Erstbeschreibung, vollständiges Program-Refresh, fokussierte Nach-Implementierungs-Abstimmung, reine Blueprint-Arbeit oder eine schreibgeschützte Überprüfung handelt. Respektiere die Bearbeitungsgrenzen des Aufrufers. Melde Mehrdeutigkeiten, statt Absichten zu erfinden.
Subsysteme
Pflege genesis/subsystems.md zusammen mit dem Programm bei Beschreibungs- und Aktualisierungsarbeiten. Reine Blueprint-Arbeit ändert die Karte nicht; die Überprüfung bleibt schreibgeschützt. Die Karte ist die autorisierte Assoziationsautorität, aber Verantwortlichkeiten und Tabellenverweise bleiben fehlbare Erläuterungen von Anwendungsquellcode und Schema.
Verwende diese exakte Version-Null-Grammatik:
# Subsysteme
## `forms` Formulare
Besitzt wiederverwendbares Formular-Rendering, Validierung und Erfassung von Übermittlungen.
### Quelle
- Verzeichnis `packages/forms`
### Programm
- `genesis/program/forms/render.md`
### Eigene Daten
- Tabelle `database` `default` `form_definitions`
### Verwendete Daten
- Nichts.
Verwende eine stabile kleingeschriebene, mit Bindestrich getrennte ID und einen menschenlesbaren Titel pro Subsystem. Jeder Eintrag benötigt einen Verantwortlichkeits-Text sowie die Abschnitte Programm, Eigene Daten und Verwendete Daten. Der Verantwortlichkeits-Text ist die vollständige Erläuterung des Subsystems, keine Kartenbeschriftung. Erkläre seinen Zweck, Umfang, wichtige Teile und die Zusammenarbeit mit anderen Besitzern. Bewahre substanzielle vorhandene Beschreibungen; ersetze sie nicht durch einzeilige Etiketten, um eine Visualisierung zu ermöglichen. Ein Konsument kann die angezeigte Vorschau verkürzen. Einfache Unterstützungsverzeichnisse benötigen möglicherweise nur eine kurze Erklärung. Der erforderliche Quellabschnitt enthält genau einen - Verzeichnis-Eintrag mit einem Backtick-Pfad: ein kanonisches projektrelevantes Verzeichnis, wobei . für das Projektstammverzeichnis zulässig ist. Jedes Subsystem hat ein Verzeichnisstammverzeichnis; deklariere niemals verstreute oder mehrere Stammverzeichnisse. Stapel-übergeordnete Verzeichnisregeln entdecken Standard-Subsystemstämme, sind aber nicht erschöpfend. Ein Agent kann einen anderen Stamm anhand tatsächlicher Verantwortlichkeit und Quellnachweise erkennen und deklarieren. Die erstellte Deklaration bleibt bei gewöhnlicher Indizierung erhalten. Die erstellte Karte ist nach der Fertigstellung die kanonische Besitzerliste; Stapel-Stämme sind Übernahmehinweise und schaffen niemals zusätzliche Besitzer oder teilen eine erstellte Grenze. Decke jeden indizierten Quellcode ab, falls nötig mit einem Projektstammbesitzer für verbleibende Unterstützungsdateien. UI-Komponenten und Engine-Code können einen Stamm teilen; UI-Projektion ändert nicht das Eigentum. Leere Abschnitte sagen - Nichts.; eine neue leere Karte enthält nur # Subsysteme und - Nichts.. Jedes Programmmodul gehört zu genau einem Subsystem. Programmverzeichnisnamen weisen kein Eigentum zu. Quellen können auf die Bibliotheken eines anderen Subsystems verweisen, ohne der Operation oder Implementierung zwei Besitzer zu geben. Verwende keine Globber, keine doppelten Operationen oder doppelten Tabellenbesitzer.
Beim Neugenerieren oder bewussten Aufteilen der Karte gleiche die Erläuterungen mit den neuen Verzeichnisbesitzern ab. Übertrage die zutreffenden Verantwortlichkeits- und expliziten Programmzuweisungen gemeinsam, wobei stabile IDs erhalten bleiben, wenn die Grenze unverändert ist. Überprüfe die erforderliche Hauptquelle jedes Programms gegen seinen aktuellen Besitzer, einschließlich verschachtelter Besitzer; Bibliotheksverweise behalten ihr eigenes Eigentum. Verwende die aktuellen Deklarationen und nicht die fest codierten Namen, das Verzeichnislayout oder die zwischengespeicherte Liste eines früheren Konsumenten. Überprüfe Subsysteme und Programm und behebe fehlende/doppelte Mitgliedschaften und ungültige Hauptanker, bevor du die Fertigstellung behauptest.
Eine Tabellenidentität besteht aus drei separaten exakten Backtick-Werten: der deklarierten Stack-Ressourcen-ID, dem Schema und der Tabelle. default bedeutet das Standardschema der Ressource; verwende ein explizites Schema, wo zutreffend. Zeichne niemals einen Host-Datenbanknamen, Anmeldedaten, SQL-Ausdruck oder Umgebungswert auf. Verwendete Daten verweisen auf eine Tabelle, die einem anderen deklarierten Subsystem gehört. Ein Subsystem kann Daten ohne Programmoperationen besitzen oder Operationen ohne Daten. Lies das echte Schema/die echten Migrationen, bevor du Eigentum zuweist; melde Unsicherheit, anstatt Assoziationen zu erfinden.
Pflege genesis/subsystems.md im selben Implementierungsdurchlauf, wenn eine Änderung eine Subsystemverantwortlichkeit, Programmmigliedschaft oder Dateneigentum/-nutzung hinzufügt, entfernt oder ändert. Lies die Karte, bevor du zugehörigen Code änderst. Verwende vorhandene Subsysteme wieder, es sei denn, eine eigenständige Verantwortlichkeit ist nachgewiesen. Deklariere jedes Programmmodul genau einmal; Ordner bestimmen nicht die Mitgliedschaft. Halte Tabellenverweise in Schema/Migrationen verankert; Genesis überprüft keine Datenbanken. Private Hilfsfunktionsänderungen benötigen keine Kartenbearbeitung, wenn diese Assoziationen unverändert bleiben.
Wenn genesis/subsystems.md fehlt oder in einer vorhandenen erklärten Anwendung leer ist, erstelle sie aus dem tatsächlichen Quellcode, Schema und vorhandenen Programm vor der Implementierung. Dies ist eine gewöhnliche erklärende Übernahme, kein Blocker oder Grund, erneut um Erlaubnis zu fragen. Bewahre das vorhandene Programm und den Quellcode; überprüfe die relevanten Verantwortlichkeiten und vervollständige die kleinste wahrheitsgemäße Karte. Die Initialisierung kann die leere Datei erstellen, aber nur der Agent schreibt ihre Bedeutung fest.