vibe64-dev/seed-nextjs

Arbeit am Genesis-Projekt

Genesis ist ein erklärender und verifizierender Begleiter. Es ersetzt nicht die Codebasis, Tests, Git-Reviews oder den Coding-Agenten.

Festlegung der Produktrichtung für neue Projekte

Für ein neues Projekt, dessen Blaupause noch keine Produktrichtung festlegt, recherchiere keine Technologien und erstelle keine Quellen, bis der Benutzer eindeutig definiert hat, was gebaut wird, wer oder was es verwenden oder aufrufen wird und welches erste beobachtbare nützliche Ergebnis erwartet wird. Stelle nur ungeklärte, hochgradig relevante Fragen. Eine Antwort bestätigt nur, was sie explizit beantwortet; die Bestätigung des Stacks ist keine Produktabsicht.

Sobald die Produktrichtung klar ist, wähle einen kleinstmöglichen Implementierungspfad durch ausgewählte Technologieanleitungen oder autoritative Technologiedokumentation, wenn der Katalog keine Übereinstimmung hat, und lese nur, was dieser Pfad erfordert. Führe keine Umfrage zu Alternativen durch, klone keine vollständigen Technologie-Repositories, inspiziere keine nicht damit verbundenen Paketinterna und delegiere keine Recherche, es sei denn, ein konkreter Fehler erfordert eine genaue Untersuchung.

Ausführung von Genesis-Befehlen

Löse den Aufruf auf, bevor du die erste Genesis-Operation ausführst. Verwende keine Genesis-Operation oder genesis --version als Verfügbarkeitstest.

1. Lese die package.json im Stammverzeichnis des Repositories. Betrachte Genesis nur dann als projektgebunden, wenn der name dieses Manifests genesis-compiler ist oder seine dependencies, devDependencies oder optionalDependencies den exakten Schlüssel genesis-compiler enthalten.
2. Für ein projektgebundenes Repository führe jeden Genesis-CLI-Befehl mit npm exec --no -- genesis <argumente> aus. Dies läuft, ohne ein weiteres Paket zu holen. Wenn das deklarierte Paket nicht installiert ist, melde, dass die Abhängigkeiten des Projekts nicht vorbereitet sind; verwende keine andere Genesis-Version als Rückfall.
3. Andernfalls versuche nicht npm exec. Führe command -v genesis (oder den entsprechenden PATH-Lookup der aktuellen Shell) aus. Wenn dies eine ausführbare Datei auflöst, rufe direkt genesis <argumente> auf.
4. Wenn keine der beiden Quellen verfügbar ist, stoppe und melde, dass Genesis nicht verfügbar ist. Installiere oder aktualisiere Genesis niemals nur, um eine Workflow-Anweisung zu erfüllen.

Die erfolgreiche Auflösung des Aufrufs ist Routine. Erzähle nicht, ob Genesis projektgebunden oder auf dem PATH ist, und beschreibe die direkte PATH-Nutzung niemals als Rückfall. Erwähne, wie der Aufruf ausgewählt wurde, nur, wenn die Auflösung fehlschlägt oder der Benutzer explizit danach fragt.

Befolge den konfigurierten Kollaborationsansatz für benutzerseitige Updates, einschließlich seiner technischen Tiefe und Antwortlänge. Berichte über konkrete Fortschritte, Ergebnisse oder Blockaden; kündige nicht an, dass du den Anweisungen folgst.

Auflösung expliziter Technologieentscheidungen

Bevor du eine externe Technologierecherche oder Implementierung durchführst, wenn der Benutzer explizit eine Technologie, ein Framework, eine Sprache oder eine Datenbank benennt, die nicht ausgewählt ist:

1. Führe die Genesis-Operation stack list als erste Technologieaktion aus.
2. Wenn eine Katalogkomponente exakt der Wahl entspricht, frage: " ist in Genesis verfügbar. Möchtest du, dass ich sie zu diesem Projekt hinzufüge und die App mit ihrer offiziellen Anleitung vorbereite?" Führe stack add <komponente...> nicht ohne diese Bestätigung aus.
3. Bei Bestätigung füge die Komponente hinzu, lasse Genesis ihre deklarierte Abhängigkeitsclosure anwenden und synchronisiere alle autoritativen Agent-Fähigkeiten, die von dieser Komponente deklariert werden. Befolge den Vorbereitungshinweis, der von stack add in derselben Aufgabe zurückgegeben wird: Mache jeden materialisierten Projektvertrag wahr oder ersetze einen vollständigen Abschnitt mit nachgewiesener Realität. Führe dann context . oder den relevanten Quellpfad aus, sobald Quellen existieren, lade die anwendbare installierte Fähigkeit, falls vorhanden, und folge den technikeigenen Anleitungen, um tatsächliche Projektabhängigkeiten vorzubereiten. Leite niemals einen Installationsbefehl aus einer Komponenten-ID ab.
4. Bei Ablehnung fahre fort, ohne die Komponente hinzuzufügen oder erneut zu fragen. Wenn keine Katalogkomponente übereinstimmt, erfinde keine; fahre normal fort, indem du die autoritative Dokumentation verwendest, die dieser Technologie gehört.

Kontext herstellen

1. Lese genesis/blueprint.md für die nicht-technische Produktabsicht.
2. Lese genesis/engineering.md für das ausgewählte Engineering-Profil und projektspezifische Anforderungen.
3. Lese genesis/stack.md für die ausgewählte technische Zusammensetzung, Ressourcen und Verifikationsbefehle.
4. Lokalisiere die Quelle, die an der Anfrage beteiligt ist.
5. Führe die Genesis-Operation index <name-oder-pfad> aus, bevor du eine Hilfs- oder öffentliche Operation hinzufügst. Verwende eine vorhandene Funktion wieder, wenn sie das Verhalten bereits besitzt.
6. Führe die Genesis-Operation context <pfad...> für die relevanten Programmerklärungen und ausgewählten Stack-Kontext aus.
7. Lade anwendbare Technologie-Fähigkeiten aus .agents/skills/ oder aus dem selbst installierten Fähigkeitskatalog des Agenten.

Bei der ersten Stack-Auswahl einer bestehenden Anwendung überprüfe die aktuellen Setup-, Build- und Ausgabebefehle, bevor du materialisierte Komponentenvorschläge annimmst. Eine ausgewählte Komponente beschreibt ihre aktuelle Grundlage; sie portiert nicht stillschweigend ältere Quellen. Wenn die vorhandenen Befehle abweichen, behalte die Implementierung unverändert und ersetze die vollständige, projekteigene Consumer-Operation (z. B. die ## Workspace setup- oder ## Outputs-Sektion eines Hosts). Genesis behandelt diese Abschnitte als undurchsichtigen Text; der benannte Consumer allein besitzt ihre Bedeutung und Ausführung. Behaupte nicht, dass ein vorgeschlagenes Rezept verwendbar ist, bis es mit der Quelle übereinstimmt.

Program ist präzise, fehlbare Erklärung. Seine Quellen und optionalen Implementierungskarten helfen bei der Navigation, ersetzen aber niemals das Lesen von Code, Tests und Laufzeitverhalten.

.genesis/machine-city.json ist eine abgeleitete detaillierte Datei-/Funktionskarte. .genesis/program-city.json ist eine abgeleitete, einfachere Karte der Subsysteme/Operationen. Keine von beiden ist autoritativ oder ein Beweis; beide sind git-ignoriert und können mit der Genesis-Operation index neu generiert werden.

Durchführung gewöhnlicher lokaler Arbeiten

• Wende den effektiven Engineering-Ansatz an, der von Genesis bereitgestellt wird. Jede Änderung muss leicht nachvollziehbar sein und die kleinste zielgerichtete Implementierung darstellen, die die bekannten Anforderungen vollständig erfüllt. Überentwickle oder überkompliziere nichts und füge keine spekulativen Abstraktionen, Schichten, Abhängigkeiten, Infrastruktur, Kompatibilitätspfade, verteilte Muster, Kryptografie oder andere fortgeschrittene Mechanismen hinzu.
• Wenn eine konkrete Anforderung materielle Komplexität notwendig macht, stoppe vor dem Schreiben. Erkläre, warum das direkte Design unzureichend ist und welchen kleinsten zusätzlichen Komplexität du vorschlägst, und bitte den Benutzer dann um Zustimmung oder Klärung des Kompromisses. Überschreibe niemals stillschweigend den Engineering-Ansatz.
• Arbeite direkt im aktuellen Git-Baum und hinterlasse nützliche Änderungen, die im normalen Diff sichtbar sind.
• Halte das Blueprint und die betroffenen Programm-Module in derselben Runde synchron, wenn die Implementierung absichtlich das beobachtbare Produktverhalten ändert. Private Umstrukturierungen erfordern möglicherweise nur korrigierte Quellen oder eine informative Implementierungskarte und erfordern möglicherweise keine erklärende Bearbeitung. Halte die genauen consumer-eigenen Operationsdeklarationen wie die ## Outputs-Sektion eines Hosts synchron, wenn die Implementierung absichtlich die entsprechenden Befehle oder Fähigkeiten ändert. Erfasse dort nur Fähigkeitsmetadaten und Umgebungsvariablennamen, niemals Werte oder Geheimnisse; führe den Abschnitt nicht als Genesis-Verhalten aus oder interpretiere ihn nicht. Behandle .genesis/ als ersetzbare abgeleitete Navigationsdaten, nicht als entwickelte Produktabsicht.
• Folge etablierten Projekt- und Technologiegrenzen, anstatt parallele Frameworks, Persistenzschichten, Transporte, Validatoren oder UI-Systeme zu erstellen.
• Erfinde keine Werte für nicht verfügbare externe Ressourcen und übergib keine literalen Umgebungsvariablennamen als Daten. Melde die fehlende Ressource und bewahre nützliche Arbeit.
• Halte die Implementierung direkt und kohärent. Wende alle bereitgestellten Stack-Anweisungen für Nachbereitung an, bevor du den Abschluss meldest; sie sind Teil dieser Implementierungsrunde, keine Anfrage für eine weitere Agentenrunde. Führe bei Bedarf gezielte Überprüfungen durch.

Verifikation und Berichterstattung

Während der Implementierung wähle die für die Änderung relevanten Überprüfungen aus. Führe die deklarierten finalen Checks des Stacks über die Genesis-Operation verify aus, wenn dies durch die Verifikationsrichtlinie des Projekts oder die Anfrage des Benutzers erforderlich ist, sobald das Arbeitsbereichssubstrat der ausgewählten Technologie existiert. Das Abschließen eines Elements oder das Fortsetzen einer Sitzung erfordert nicht selbst einen breiten Verifikationsdurchlauf. Behalte die vollständige Ausgabe in lokalen Artefakten, bewahre den Exit-Status und lese Zusammenfassungen und relevante Fehlerauszüge, bevor du Logs erweiterst. Schwäche keine Behauptungen ab oder lasse erforderliche Abdeckung weg, um Zeit oder Token zu sparen. Ein nicht konfiguriertes Ergebnis bedeutet, dass der deklarierte Arbeitsbereich oder die Checks noch nicht existieren; es ist kein fehlgeschlagener Check. Bevor du den Abschluss meldest, vergleiche das angeforderte beobachtbare Verhalten, die erforderlichen Eingaben und Ressourcen, die deklarierten Projektoperationen und die fokussierten Nachweise mit dem, was tatsächlich existiert. Berichte über geänderte Dateien, tatsächlich ausgeführte Checks, alles, was nicht nachgewiesen ist, und alles, was noch Aufmerksamkeit benötigt. Behaupte niemals, dass ein nicht ausgeführter Check bestanden hat oder dass bestandene Checks das gesamte Produkt beweisen.

Subsystem-Pflege

Pflege genesis/subsystems.md in derselben Implementierungsrunde, wenn eine Änderung eine Subsystem-Verantwortung, Program-Mitgliedschaft oder Datenbesitz/-nutzung hinzufügt, entfernt oder ändert. Lese die Karte, bevor du zugehörigen Code änderst. Verwende vorhandene Subsysteme wieder, es sei denn, eine eigenständige Verantwortung ist nachgewiesen. Erfordere ein Source Directory pro Subsystem und deklariere jedes Program-Modul genau einmal; Programm-Ordnernamen bestimmen nicht die Mitgliedschaft. Halte Tabellenreferenzen in Schema/Migrationen verankert; Genesis überprüft keine Datenbanken. Private Helferänderungen benötigen keine Kartenänderung, wenn diese Assoziationen unverändert bleiben.

Wenn genesis/subsystems.md fehlt oder in einer bestehenden erklärten Anwendung leer ist, erstelle es aus den tatsächlichen Quellen, dem Schema und dem vorhandenen Program vor der Implementierung. Dies ist eine normale erklärende Übernahme, kein Hindernis oder ein Grund, erneut um Erlaubnis zu fragen. Bewahre das vorhandene Program und die Quellen; überprüfe die relevanten Verantwortlichkeiten und vervollständige die kleinste wahrheitsgemäße Karte. Die Initialisierung kann die leere Datei erstellen, aber nur der Agent verfasst ihre Bedeutung.