tderoussel/overnight-build

Prompt für den Overnight-Build

Die vollständige Vorlage liegt in references/overnight-build-template.md. Lies sie, bevor du loslegst. Leite die Regeln nicht aus dem Gedächtnis ab – fülle die [Klammer-Abschnitte] mit den spezifischen Angaben des Benutzers und übernimm alle Änderungen, die der Benutzer in seiner eigenen Kopie gemacht hat.

Unverhandelbar

Jede Ausgabe muss Regel 8 (Nutzungslimits überstehen) und den Abschnitt LAUNCHER enthalten. Nur so bleibt der Build neustartbar; ein Prompt ohne diese Elemente beginnt nach dem ersten Zurücksetzen stillschweigend von vorne und verschwendet eine Nacht.

Erstellung

1. Lies die Vorlage. Wenn der Benutzer eine bearbeitete Kopie hat, hat diese Vorrang – übernimm seine Änderungen.
2. Fülle die Spezifikation – was gebaut werden soll, Kontext, Designanforderungen, technische Anforderungen, Features in Prioritätsreihenfolge, Seed-Daten, Bereitstellung, Erfolgskriterien. Hier liegt die ganze Kunst: Eine vage Spezifikation erzeugt eine vage Nacht.
3. Lege Phasen fest – 4–8, jede unabhängig abschließbar und verifizierbar, mit Zeitschätzungen, die in der Summe das Budget ergeben.
4. Fülle das Pivot-Playbook mit projektspezifischen Blockern, zusätzlich zu den standardmäßigen Blockern der Vorlage.
5. Frage einmal nach dem gewünschten Starter (A: OS-Scheduler · B: Bash-Schleife · C: Scheduled-Task MCP), falls die Anfrage dazu nichts sagt. Frage einmal – dann mache weiter.
6. Gib die Ausgabe als einzelnen kopierbaren Code-Block aus und erinnere den Benutzer daran, sie als overnight-build-prompt.txt im Projektstammverzeichnis zu speichern, bevor er startet.

Abschlusssignal

Der Prompt muss den Build anweisen, BUILD_COMPLETE als letzte Zeile auszugeben – der Bash-Schleifen-Starter sucht danach, um zu beenden. Mache im Prompt deutlich, dass das Weglassen von BUILD_COMPLETE korrekt ist, wenn ein P0-Kriterium tatsächlich nicht erfüllt ist. Ein Starter, der bei einem unvollendeten Build beendet, ist schlimmer als einer, der weiterläuft.

Leitplanken

Ein unbeaufsichtigter Agent hat niemanden zum Fragen, daher muss der Prompt seine eigenen Grenzen mitbringen.

Wenn das Ziel eine bestehende Produktionscodebasis ist, leite zuerst die Dateiverantwortlichkeiten und eine DO-NOT-Liste ab (das Skill fleet-brief erzeugt beides) und übernimm die projekteigenen Verifikationsprüfungen in die Testphase, damit „fertig“ verifiziert bedeutet und nicht nur zusammengeführt.

Erlaube einem Overnight-Prompt niemals, Datenbankmigrationen durchzuführen, ein Schema zu pushen, über ein Hosting-CLI bereitzustellen, Telefonnummern oder Domains zu kaufen oder freizugeben oder Nachrichten an echte Kontakte zu senden. Dafür muss ein Mensch wach sein. Füge die eigenen irreversiblen Aktionen des Projekts zu dieser Liste hinzu.

Vom Build zu schreibende Ergebnisse

• BUILD_LOG.md – Phaseneinträge, Entscheidungen, Kehrtwendungen, bekannte Probleme und ## CHECKPOINT — <ISO>-Blöcke mit dem genauen nächsten Schritt
• RESEARCH_NOTES.md – Forschungsergebnisse vor Beginn der Implementierung

Beim Wiederaufnehmen ist die erste Aktion des Builds wörtlich, BUILD_LOG.md von oben bis unten zu lesen und vom neuesten Checkpoint aus fortzufahren – niemals neu zu recherchieren, neu zu gerüsten oder neu zu starten.