Launch (Start)

Was macht Launch (Start)?

Launch ist die Auslieferungs-Routine der Shipyard: von der Missionsübersicht bis zur ausgelieferten, verifizierten Änderung. Sie steht an der Verifizierbarkeitsgrenze – Agenten führen kontinuierlich alles Wiederholbare und durch Beweise Akzeptierbare aus; Menschen entscheiden über Dinge, die das System nicht beurteilen kann oder die teuer falsch sein können. Das Ziel ist nicht maximale Automatisierung – es ist die maximale Delegation verifizierbarer Arbeit, sodass die Zeit des Menschen nur für die Entscheidungen aufgewendet wird, die nur ein Mensch treffen kann.

Der Verifizierbarkeitstest, angewendet auf jeden Schritt: Wenn dies falsch gemacht wird, kann das System es erkennen? Kann es automatisch wiederholen oder zurückrollen? Beides ja → Agent. Keine eindeutige Antwort, System kann nicht beurteilen oder teuer falsch → Mensch.

Launch setzt voraus, dass die Shipyard existiert – und weigert sich zu laufen, wenn dies nicht der Fall ist. Das Yard-Tor ist die erste Aktion jedes Aufrufs, vor der Dokumenten-Sprachauflösung und vor dem Lesen einer gelieferten Spezifikation:

• Führen Sie das vollständige Drydock --check-Audit aus – fehlende Oberflächen, ein fehlendes oder ungültiges CONTEXT.md-Frontmatter documentLanguage, tote Pfade, im Code ungenutzte Glossarbegriffe, nie referenzierte Standards. Dies ist das einzige Kriterium: Launch führt keine separate eigene Facility-Inventur durch.
• Handlungsrelevante / hochvertrauenswürdige Befunde blockieren den Lauf hart: Listen Sie jeden solchen Befund wörtlich auf, verweisen Sie auf /oh-my-claudecode:drydock, geben Sie an, dass der Lauf nie gestartet wurde und keine Artefakte erzeugt wurden, und stoppen Sie. Behandeln Sie ohne explizite Überschreibung jeden Befund als blockierend.
• Enge Überschreibung (nur explizite Absicht): Befunde mit geringem Vertrauen, Befunde, die im Drydock-Bericht explizit als False Positives eingestuft wurden, oder ein explizit vom Benutzer deklariertes Scratch-/Wegwerf-Repository dürfen nur mit bewusster, pro-Aufruf-Benutzerabsicht überschrieben werden – die Überschreibung muss den/die Befund(e) oder den Wegwerf-Bereich nennen und darf niemals einen hochvertrauenswürdigen, handlungsrelevanten Befund stillschweigend verschlucken. Kein allgemeines Umgehungs-Flag.
• Aktuelle Audit-Einschränkung: Heute ist --check eine Skill-Anweisungs-Checkliste ohne maschinenlesbaren Befund-/Schweregrad-Vertrag oder ausführbare Datei – die Schweregradklassifizierung verlässt sich auf die Formulierung des Drydock-Berichts, bis ein strukturierter Vertrag existiert. Ein maschinenlesbarer Befund-/Schweregrad-Exit-Vertrag ist das beabsichtigte Folge-Up; die Tor-Formulierung bleibt ehrlich darüber, worauf sie sich mechanisch verlassen kann und worauf nicht.
• Ein sauberes Audit (oder ein explizit überschriebener Low-Confidence/False-Positive/Scratch-Bereich) lässt den Lauf zu. Jeder Papierpfad-Slot (CONTEXT.md, docs/adr/, docs/business/) und jede Facility-Oberfläche existiert zu diesem Zeitpunkt bereits; Launch füllt den Papierpfad, sobald Entscheidungen getroffen werden, erstellt aber niemals die Slots.
• Die Regeldatei ist CLAUDE.md – die Shipyard-Karte erkennt keinen Ersatz an.

Die Grenze

Menschliche Checkpunkte (die kritischen 20 %)	Kontinuierlicher Agentenlauf (die mechanischen 80 %)
C1: Missionsübersicht verfassen (Ziel + Umfang)	Faktenfindung und Repo-Exploration, selbstbedient
C2: Abnahmekriterien + Testnaht-Liste genehmigen	Interviewvorbereitung: Grenzfragen gebündelt mit empfohlenen Antworten
C3: Ticketzerlegung genehmigen (Granularität, blockierende Kanten)	Spezifikations- und Ticketentwurf, mechanische Validierung (Unabhängigkeit, Demonstrierbarkeit, passt in einen Kontext)
C4: Unumkehrbare Entscheidungen, die während des Laufs auftauchen, beantworten (gebündelt, asynchron)	TDD-Implementierung an vereinbarten Nähten, Builds, Tests, Regressionen
C5: Abschlussbericht akzeptieren; Veto über Offene Annahmen und die pro-Zeile Sedimentliste	Code-Review, Überprüfung über die gesamte Änderung, Team-Frontier-Terminplanung, der gesamte Papierpfad

Zwischen den Checkpunkten läuft die Pipeline nie im Leerlauf: Agenten arbeiten kontinuierlich an jedem Frontier-Ticket, das nicht von einer ausstehenden menschlichen Antwort abhängt.

Lebenszyklus-Haltung

Launch ist eine zustandslose Komposition über dem bestehenden OMC-Lebenszyklus – es besitzt keinen eigenen Laufzeitzustandsautomaten:

• Das Team besitzt Aufgabenstatus, Übergänge, Abbruch und Laufzeitbereinigung; Launch verändert sie niemals außerhalb des Team-Vertrags.
• Die kanonischen plan → execute → review → verify-Oberflächen besitzen ihr bestehendes Lebenszyklusverhalten. Launch-erstellte Artefakte sind beschränkt auf .omc/specs/<feature-slug>/, CONTEXT.md, docs/adr/ und docs/business/ – plus, nur nach C5-Freigabe, die Sediment-Slots, die in der Tabelle von Phase 5 genannt werden.
• Launch hat keine automatische Wiederaufnahme. Nach einer Unterbrechung lesen Sie die Artefakte und den aktuellen Team-Status erneut, setzen Sie aber nur durch einen neuen expliziten Launch-Aufruf fort, nachdem der besitzende Team-Lebenszyklus eine unterstützte terminale/bereinigte Grenze erreicht hat. Leiten Sie niemals eine menschliche Genehmigung ab oder wiederholen Sie eine in_progress-Aufgabe.
• Neblige Vorhaben fallen in die Zuständigkeit des Navigators: Wenn das Nebeltor zu /oh-my-claudecode:ask-navigator leitet, wurde der Lauf nie gestartet – keine Artefakte, kein partieller Zustand. Die Karte des Navigators ist der einzige Träger über Sitzungen hinweg; Launch setzt nur von der Missionsübersicht fort, die er zurückgibt.
• Launch fügt keine eigene Genehmigungsquittung, Revisionszähler, Wiederholungsprotokoll, Abbruchpfad, Rollback-Mechanismus oder Bereinigungslebenszyklus hinzu.

Jede Haltbarkeitsbehauptung in diesem Skill ist eine Behauptung über die Dateien auf der Festplatte, nicht über eine versteckte Laufzeit.

Phase 0 — Eintritt

Ein Lauf erreicht diese Phase nur durch ein sauberes Yard-Tor. Bevor Sie eine gelieferte Spezifikation lesen oder Phase 1 betreten, lösen Sie die Dokumentsprache auf. Eine explizite menschliche Wahl im aktuellen Aufruf gewinnt; andernfalls lesen Sie ein gültiges BCP-47-Style-Tag aus dem CONTEXT.md-Frontmatter am exakten stabilen Schlüssel documentLanguage; andernfalls erfordern Sie einstimmige hochvertrauenswürdige Inferenz aus CLAUDE.md dann README.md. Ein persistiertes bare- oder region-nur chinesisches Tag ist skript-ambig und muss einmal auf dieser Autoritätsebene gefragt werden, niemals durch Inferenz umgangen. Fehlende, gemischte, widersprüchliche, niedrig vertrauenswürdige, ungültige explizite oder skript-ambigue chinesische Beweise erfordern eine gebündelte Sprachfrage; raten Sie nicht. Chinesisch muss zu einem expliziten zh-Hans- oder zh-Hant-Skript-Tag aufgelöst werden. zh-Hans-* wählt den vereinfachten Begleiter und zh-Hant-* wählt den traditionellen Begleiter, während das vollständig normalisierte Tag persistiert wird. Persistieren Sie das aufgelöste normalisierte Tag zurück in CONTEXT.md vor jedem Launch-erstellten Artefakt, damit ein frischer expliziter Aufruf es ohne verborgenen Konversationszustand lesen kann. Der Mensch liest und pflegt diese Artefakte; Agenten sind sprachunabhängig.

Lokalisieren Sie nur Prosa und menschenlesbare Bezeichnungen/lokalisierbare Skalarwerte. Pfade, Slash-Befehle, Flags, Code-Blöcke, Platzhalter, Frontmatter-Schlüssel und maschinensemantische Werte, YAML/JSON-Schlüssel, Lebenszyklus-Token (plan, execute, review, verify), Status-Enums (pending, in_progress, completed, failed, ready-for-agent), IDs, Ticket blockedBy, öffentliches Team blocked_by und alle Parser-/Steuerungstoken bleiben byte-für-byte stabil. Referenz-Sprachbegleiter schließen sich gegenseitig aus: emittieren Sie genau eine ausgewählte Darstellung, niemals zweisprachige doppelte Überschriften oder Bezeichnungen.

• Kurze Selbstprüfung vor allem anderen: Nennt die Übersicht ein Ziel, eine Umfangsgrenze und Nicht-Ziele? Fehlen zwei oder mehr, sagen Sie dies und bitten Sie um einen Schärfungsdurchlauf – die Pipeline auf einer weichen Übersicht auszuführen, wandelt Ambiguität in selbstbewusst aussehende Ausgabe um.
• Nebeltor: Nach dem Schärfungsdurchlauf wenden Sie den Nebeltest des Navigators an – F1: Kann das Ziel in einem Satz angegeben werden (die Spezifikation, Entscheidung oder Änderung, zu der dieses Vorhaben seinen Weg findet)? F2: Können die ersten drei Entscheidungen jetzt präzise angegeben werden, auch wenn noch keine beantwortet werden kann? Entweder Antwort nein → der Lauf startet nie: Geben Sie dies klar an, notieren Sie, dass keine Artefakte erzeugt wurden, empfehlen Sie /oh-my-claudecode:ask-navigator (der Navigator der Shipyard kartiert Nebel als eine Karte von Entscheidungs-Tickets und gibt eine Missionsübersicht zurück), und stoppen. Übergeben Sie die Restfragen und bereits geklärte Vokabeln, damit der Navigator sie in W1 nicht noch einmal stellt.
• Kartenprüfung: Bevor Sie eine gelieferte Spezifikation lesen oder Phase 1 betreten, suchen Sie nach einer offenen navigator:map (Tracker-Label oder unter .omc/wayfinder/). Eine existiert und dieser Aufruf liefert keine neue Übersicht → empfehlen Sie /oh-my-claudecode:ask-navigator, um die nächste Entscheidung auf dieser Karte zu bearbeiten, und stoppen. Eine existiert und eine neue Übersicht wird geliefert → stellen Sie eine Frage – mit der offenen Karte fortfahren oder ein neues Vorhaben starten – bevor Sie fortfahren.
• Spezifikationspfad geliefert → lesen Sie ihn, springen Sie zu Phase 2.
• Missionsübersicht → Phase 1.
• Einzelpunkt-Fix → an Ausführen übergeben, beenden.

Phase 1 — Konvergieren (Mensch entscheidet, Agent bereitet vor)

Führen Sie das Interview mit dem Design-Tree-Protokoll durch: Kartieren Sie Entscheidungen und ihre Abhängigkeiten, arbeiten Sie dann in Frontier-Runden – bündeln Sie jede derzeit stellbare Frage in einer Runde, nummeriert, jede mit einer empfohlenen Antwort. Der Mensch antwortet; der Baum formt sich neu; berechnen Sie die Frontier neu. Fakten werden immer durch Sub-Agenten aus Repo-Beweisen selbst bedient – der Mensch wird nur nach dem gefragt, was keine noch so große Erkundung klären kann.

Papierpfad, geschrieben in dem Moment, in dem jedes Element geklärt ist:

• Domänenvokabular → CONTEXT.md im Repo-Root (ein Eintrag pro Begriff)
• Entscheidungen, die den ADR-Test bestehen (schwer umkehrbar, ohne Kontext überraschend, echter Tradeoff) → docs/adr/NNNN-<slug>.md
• Geschäftsregeln und Hintergrund, die während der Konvergenz entdeckt wurden → docs/business/ (ein Artikel pro Geschäftsfrage, einleitender Absatz sagt, warum es wichtig ist)

Nicht-Konvergenz ist hier normale Arbeit, kein Fehlschlag: Wenn die Frontier nicht leer wird, präsentieren Sie die verbleibenden Fragen, eingestuft – dies ist C2s Eingabe, kein Fehler. Wenn die verbleibenden Fragen selbst nicht präzise angegeben werden können (Nebeltest F2 schlägt fehl), ist das Ziel selbst ungeklärt und dies liegt außerhalb von C2s Autorität: stoppen, notieren Sie, was bereits geklärt wurde (Vokabular in CONTEXT.md, beantwortete Fragen), empfehlen Sie /oh-my-claudecode:ask-navigator, und beenden – die Pipeline erfindet niemals ein Ziel.

Loft-Umweg. Eine verbleibende Frage, die präzise ist, aber nicht in Prosa geklärt werden kann – sie muss gesehen oder angeklickt werden, nicht beschrieben (wie die UI aussehen sollte, ob ein Zustandsmodell sich richtig anfühlt) – wird mit einem Artefakt beantwortet, nicht mit weiteren Fragen: Rufen Sie das Skill-Tool mit "loft" auf, lassen Sie den Captain reagieren und falten Sie diese Reaktion zurück in das Interview. Das geloftete Artefakt ist C2s Eingabe; der Captain unterschreibt, was sie gesehen haben, nicht was ihnen erzählt wurde.

Harbor-Übersichten. Eine von /oh-my-claudecode:harbor übergebene Missionsübersicht enthält signierte Entscheidungen mit Links und anwendbaren Bedingungen: konsumieren Sie sie als bereits getroffen – stellen Sie keine unveränderten Geschäftsziele erneut in Frage. Wenn sich der Code seit der Beweiserhebung geändert hat (neuer HEAD, geänderte Basis), überprüfen Sie die betroffenen technischen Beweise erneut; neuer Implementierungsumfang, der über die signierte Übersicht hinausgeht, erhält dennoch seine eigene Genehmigung.

Phase 2 — Spezifikationssynthese (Agent entwirft → C2 genehmigt)

Synthetisieren Sie .omc/specs/<feature-slug>/spec.md:

# <Feature> Spezifikation
## Problem
## Lösung
## User Stories        (nummeriert, jede mit testbaren Abnahmekriterien)
## Implementierungsentscheidungen
## Testentscheidungen   (nur externes Verhalten)
## Nicht im Umfang

Entwerfen Sie alles, stoppen Sie dann bei C2: Präsentieren Sie die Abnahmekriterien und die Testnaht-Liste zur menschlichen Genehmigung. Nähte werden durch Repo-Beweise und die Tiefenmodul-Disziplin ausgewählt (öffentliche Schnittstellen, bestehende Testnähte, Tiefenanalyse); der Mensch bestätigt oder korrigiert die Liste – eine Naht, die der Mensch nicht genehmigt hat, erhält keine Tests.

Haltbarkeits-Gate (agentenerzwungen, keine Genehmigung erforderlich): Spezifikation und Tickets tragen Verträge, niemals Koordinaten – keine Dateipfade, keine Zeilennummern. Fragmente, die eine Entscheidung besser als Prosa kodieren (Zustandsmaschinen, Reducer, Schemata) sind die Ausnahme und geben ihre Herkunft an (normalerweise ein Loft).

Phase 3 — Ticketzerlegung (Agent entwirft → C3 genehmigt)

Aufteilen in vertikale Scheiben unter .omc/specs/<feature-slug>/tickets/:

• NN-slug.md, eine Datei pro Ticket, abhängigkeitsgeordnet, jede deklariert blockedBy: [ids]
• jedes Ticket durchquert jede Schicht, ist unabhängig demonstrierbar und passt in einen frischen Kontext
• Breite Refactorings gehen Expand-Contract: Neue Form hinzufügen, in Batches migrieren, alte entfernen – jeder Batch ein Ticket

Agentenseitige mechanische Validierung läuft zuerst (Unabhängigkeit, Demonstrierbarkeit, Kontextpassung). Dann C3: Präsentieren Sie Granularität, blockierende Kanten und vorgeschlagene Merges/Splits zur menschlichen Genehmigung. Iterieren Sie bis zur Genehmigung. Markieren Sie jedes Ticket ready-for-agent.

Integrations-Verdrahtungsregel: Jede vertikale Scheibe enthält ihre eigene Verdrahtung und eine Smoke-Assertion – eine Scheibe, deren Ausgabe nichts mountet, bedient oder importiert, ist nicht erledigt. Scheibenübergreifende Nähte, die keine einzelne Scheibe besitzt (Routen-Mounting, statisches Serving, Entry-Point-Verdrahtung), erhalten ein explizites Integrationsticket als letzten Frontier-Eintrag.

Phase 4 — Die Frontier ausführen

Die Frontier ist jedes Ticket, dessen Blocker alle abgeschlossen sind.

Parallel (Standard, 2+ Tickets). Übergeben Sie Tickets an das Team: Jedes Ticket wird zu einer Team-Aufgabe, blockedBy-Kanten werden übernommen – die Claim-Mechanik des Teams wählt nur Frontier-Aufgaben aus. Spawnen Sie N Worker. Jeder Worker implementiert mit der TDD-Disziplin an den in C2 genehmigten Nähten, wendet /oh-my-claudecode:minimal-code-discipline als Schreibzeit-Disziplin an (es bleibt opt-in); ein Ticket schließt nur, nachdem das Code-Review am Diff bestanden hat, deklariert vom Reviewer – der Implementierer genehmigt sich nie selbst.

Serial (einzelnes Ticket, oder --serial). Delegieren Sie ein Ticket nach dem anderen an einen Ausführungs-Subagenten; gleiches Review-Gate.

Zwei-Achsen-Review-Gate. Das abschließende Review läuft entlang zweier Achsen, parallel, getrennt berichtet – niemals zusammengeführt oder quer eingestuft, da eine Änderung eine Achse bestehen und die andere nicht bestehen kann (standardskonform aber falsches Verhalten; treu aber konventionsbrechend). Der Reviewer lässt das Ticket nicht bestehen, wenn eine der beiden Achsen nicht besteht:

• Standards-Achse – der Diff gegen den passenden docs/standards/-Band, plus eine reine Urteils-Baseline (ein dokumentierter Repo-Standard überschreibt die Baseline; alles, was Tooling bereits durchsetzt, wird übersprungen). Dies ist der stehende Konsument, der die Standards-Oberflächen referenziert hält.
• Spezifikations-Achse – der Diff gegen dieses Tickets Abnahmekriterien (die Spezifikation ist das gesamte Hauptbuch, aus dem die Tickets zerlegt wurden; es wird nur konsultiert, um nachzuvollziehen, woher ein Kriterium kam und um über eingeschmuggelten Umfang zu entscheiden – Verhalten, das kein Ticket

…

[abgeschnitten für Übersetzung]