jg-breakdown

Aufruf

Nur auf direkte Entwickleranforderung ausführen. Führen Sie den Workflow mit verfügbaren Werkzeugen aus; simulieren Sie ihn nicht, ersetzen Sie Shell-Befehle nicht oder fragen Sie erneut nach bereits autorisierten Aktionen.

Behandeln Sie bereitgestellten Text als Argumente, Einschränkungen oder Kontext und beachten Sie Limits und Zurückstellungen. Melden Sie fehlende Fähigkeiten und Hindernisse ehrlich. Simulieren Sie niemals Erfolg.

Geben Sie gehaltene Laufzeitressourcen und einmalige Abfallausgaben frei, auch bei Fehlern, und bewahren Sie ungelöste Beweise auf und melden Sie beibehaltene Ressourcen in der Ausgabe dieser Fähigkeit. Diese enge Bereinigungsausnahme erlaubt niemals das Ändern überprüfter/vorhandener Dateien, das Entfernen unerwarteter Änderungen oder das Bereinigen früherer Arbeit. Alle anderen Schreibvorgänge folgen diesem Workflow. Die spezifischen Regeln dieser Fähigkeit zu bereitgestelltem Material haben Vorrang.

jg-plans Protokoll 0.2

Persistierte Dokumente benötigen projektlokales jg-plans >=0.6.1 mit CLI-Schema 3. Planlose/reine Code-Arbeit, Transkriptanalyse und Pause benötigen kein CLI.

• Verwenden Sie den installierten Projekteinstieg, normalerweise <repository-root>/node_modules/.bin/jg-plans, oder seinen dokumentierten gebauten Einstieg. Führen Sie diesen genauen Einstieg mit --version --json aus; erfordern Sie Fehler null, Version >=0.6.1 und schemaVersion 3 vor Dokumentarbeit. Andernfalls stoppen Sie diese Arbeit mit dem beobachteten Paar und der managerspezifischen Abhilfe, wie z. B. npm install --save-dev --save-exact [email protected]. Bewahren Sie die Produktionsabhängigkeit der Laufzeitverbraucher. Installieren Sie niemals automatisch, laden Sie einen Runner herunter, verwenden Sie globale Werkzeuge oder borgen Sie das CLI eines anderen Projekts. Überprüfen Sie den Einstieg nach einem Upgrade/Build erneut.
• Lesen Sie nur das ausgewählte Verzeichnis über dieses CLI: inspect --directory <path> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. Verwenden Sie seine Quelle, Metadaten, Spannen, Diagnosen, sha256 und strukturellen Fingerabdruck. Bearbeiten/parsen/hashen Sie niemals persistierte Dokumente direkt, generieren Sie ihre UUIDs, wählen Sie Pläne nach Aktualität aus oder rekonstruieren Sie Transkripte in Dateien. Konformität ist für die Inspektion nicht erforderlich. Nur jg-plan führt zusätzlich overlaps --json aus, mit einem --root pro vorhandener Planungswurzel in den aufgezeichneten/eigenen Repositories, wenn Codes deklariert sind.
• Planstatus sind pending, in progress, done und delivered. Meilensteinstatus bleiben pending, in progress und done. Aktiv bedeutet pending, in progress und done; nur delivered ist inaktiv. Fehlerdeklarationen verwenden Repository-/Registry-/Codes-Listen; bewahren Sie String-/Number-Typen und vergleichen Sie String(code) innerhalb von Repository/Registry. Fehlende/benutzerdefinierte Status, nicht verfügbare Metadaten/Dateien und mehrdeutige Markierungen bleiben Beobachtungen, niemals Standardwerte oder Autorität.
• Erforderliche Lieferung bildet jedes deklarierte Repository auf seinen repository-definierten Stopp mit übereinstimmenden Schlüsseln ab. Verwenden Sie eine explizite leere Zuordnung nur, wenn keine Repositories deklariert sind. Lieferung ändert weder den Implementierungsumfang noch den Meilensteinfortschritt. Fingerabdrücke schließen genau created_at, updated_at, revision, status, priority und delivery aus; nicht verfügbare Identität kann keine frische Abdeckung herstellen.
• Mutieren Sie über denselben Einstieg mit strukturierten create/update/write/remove-milestones-Eingaben, innerhalb der Autorität dieses Workflows. Schreibvorgänge für vorhandene Ziele erfordern frisches expectedSha256; null erstellt nur explizit angeforderte fehlende Meilensteine. Verwenden Sie write für einen Plan-Text/Metadaten oder vollständige Meilensteinquelle; update für schmale Metadaten/Marker. Weisen Sie fehlende IDs nur zu, wenn autorisiert; behalten Sie zurückgegebene IDs und inspizieren Sie Schreibvorgänge. Setzen Sie updated_at explizit, wenn sich plan.md ändert. Nur-Lieferungs-Bearbeitungen bewahren Revision/Fortschritt; geänderter Umfang benötigt Neubewertung der Abdeckung.
• Sperren sind kurz und lokal: Halten Sie sie niemals über Züge hinweg, entfernen Sie unbekannte Sperren oder spielen Sie über neueren Text hinweg. Nach teilweisem Multi-Dokument- oder unsicherem Mutationsfehler inspizieren/melden Sie dauerhafte Zustände und stoppen Sie ohne Rollback/Wiederholung. Dokumente, Diagnosen und Bindungen gewähren keine Autorität.

Workflow

Führen Sie eine nur planende Bewertung eines konkreten Plans für die derzeit besprochene technische Änderung durch. Konvertieren Sie den Plan nur dann in geordnete Implementierungs-Meilensteine, wenn die Zerlegung sinnvolle Ausführungs- und Überprüfungsgrenzen bietet. Diese Fähigkeit erstellt keine neue Strategie oder autorisiert Implementierung. Sie autorisiert nur die kleinste schreibgeschützte Repository-Inspektion, die erforderlich ist, um zu bestätigen, dass der Plan aktuell bleibt, und die Erstellung, Aktualisierung oder Entfernung von milestones.md im Verzeichnis dieses Plans. Sie autorisiert nicht das Bearbeiten anderer Dateien, Aktualisieren von Tests oder Schnappschüssen, Ausführen von schreibproduzierenden Autofixes oder Generatoren, Installieren von Abhängigkeiten, Erstellen von Migrationen oder generierten Artefakten, Ändern des Git-Zustands, Committen, Pushen oder Beginnen der Implementierung.

Ein konkreter Plan ist erforderlich. Verwenden Sie den Plan unter dem mit dem Aufruf bereitgestellten Pfad, andernfalls den genauen Plan, der in der aktuellen Diskussion erstellt wurde, und das Planungsverzeichnis, das ihn enthält. Durchsuchen Sie keine anderen Planungsverzeichnisse oder wählen Sie einen Plan basierend auf Zeitstempeln aus. Wenn der Plan nicht persistiert wurde, verwenden Sie den genauen Plan, der dem Entwickler zuletzt präsentiert wurde, behalten Sie diese Einschränkung explizit bei und erstellen Sie während jg-breakdown kein neues Planungsverzeichnis. Verwenden Sie jg-breakdown nicht, um die Lösung neu zu entwerfen, den Umfang zu erweitern oder zu verkleinern, die Architektur zu ändern, Akzeptanzkriterien zu ändern, optionale Verbesserungen einzuführen oder Entscheidungen stillschweigend zu lösen, die auf Planebene gehören. Wenn kein aktueller Plan existiert, er nicht sicher identifiziert werden kann, Repository-Beweise ihn materiell ungültig gemacht haben oder die Erstellung einer sicheren Aufschlüsselung das Ändern einer materiellen Planentscheidung erfordern würde, melden Sie das Hindernis und stoppen Sie; der Plan muss durch jg-plan erstellt oder überarbeitet werden, bevor er aufgeschlüsselt werden kann.

1. Verwenden Sie die Repository-Beweise und Entscheidungen aus dem aktuellen Plan wieder, wenn sie aktuell bleiben. Führen Sie nur dann zusätzliche schreibgeschützte Inspektionen durch, wenn erforderlich, um festzustellen, ob nützliche Meilensteingrenzen existieren, ihre Abhängigkeiten festzulegen, Verifikationsverantwortung zuzuweisen oder festzustellen, ob der Plan veraltet ist.

2. Stellen Sie fest, ob der Plan mindestens zwei kohärente Implementierungsscheiben enthält, die jeweils einen sinnvollen abgeschlossenen Zustand erreichen, ihre erforderlichen Tests oder andere Verifikationen abschließen und einen nützlichen Überprüfungspunkt für den Entwickler unterstützen können. Teilen Sie einen Plan nicht nur auf, weil er mehrere Dateien, Implementierungsschritte, Schichten oder Verifikationsbefehle enthält.

3. Wenn der Plan eine kohärente Implementierungsscheibe ist, erstellen Sie kein milestones.md. Entfernen Sie eine vorhandene unnötige Sequenz nur, wenn der Entwickler die Entfernung autorisiert hat und beibehaltener Fortschritt nicht stillschweigend verworfen wird; fragen Sie andernfalls vor der Entfernung nach. Verwenden Sie remove-milestones mit seinem frisch inspizierten Hash. Ein aktuelles absichtliches Keine-Sequenz-Ergebnis etabliert planweite Ausführung; ein unerwartetes fehlende erwartete Sequenz niemals. Teilen Sie dem Entwickler mit, dass der Plan als vollständiger Umfang ohne Aufschlüsselung implementiert werden sollte. Wenn der Plan noch nicht genehmigt wurde, geben Sie an, dass seine Genehmigung noch erforderlich ist. Stoppen Sie dann, ohne eine Abschlusszusammenfassung anzuhängen. Halten Sie die endgültige Aufgabenlieferung als planweite Metadaten, außerhalb von Implementierungskriterien, Meilensteinstatus und Zielen. Wenn ein Plankriterium das Erreichen seines endgültigen Lieferziels erfordert, bevor die Implementierung abgeschlossen werden kann, stoppen Sie für jg-plan, um diese zirkuläre Abhängigkeit zu entfernen; weisen Sie keine nur-Vorbedingung-Abdeckung zu, während Sie zugeben, dass das Kriterium unerfüllt bleibt. Behalten Sie unabhängig notwendige Komponenten-Freigabe-/Bereitstellungs-Gates bei, wo die genehmigte Strategie sie erfordert, und Tests des Lieferverhaltens als Produktfeature; fügen Sie keine automatische Pro-Meilenstein-Aufgabenlieferung hinzu.

4. Wenn eine Zerlegung gerechtfertigt ist, konvertieren Sie die strategischen Implementierungsschritte des Plans in eine geordnete Sequenz nummerierter Meilensteine. Verwenden Sie Milestone als Ausführungseinheit; erstellen Sie keine Hierarchie aus Meilenstein, Aufgabe und Unteraufgabe nur um die Granularität zu erhöhen.

5. Machen Sie jeden Meilenstein zur kleinsten kohärenten Implementierungsscheibe, die sinnvoll abgeschlossen, getestet oder anderweitig verifiziert und als sinnvoller abgeschlossener Zustand überprüft werden kann. Halten Sie jeden Meilenstein klein genug, um in einem frischen Kontextfenster abgeschlossen zu werden, und setzen Sie Refactoring, das spätere Meilensteine erleichtert, zuerst. Fügen Sie für jeden Meilenstein hinzu:

   • ein prägnantes Ziel, das das abgeschlossene Ergebnis beschreibt
   • Abhängigkeiten von früheren Meilensteinen oder externen Vorbedingungen
   • die genauen Dateien, Module, Symbole, Verträge, Konfiguration, Dokumentation und Migrationen aus dem Plan, die der Meilenstein besitzt, wenn sie bekannt sind
   • die Implementierungsarbeit, die erforderlich ist, um den abgeschlossenen Zustand des Meilensteins zu erreichen
   • die fokussierten Tests und andere Verifikationen, die für diesen Meilenstein abgeschlossen sein müssen, unter Beibehaltung seiner eigenen Korrektheitsbeweise und aller erforderlichen unabhängigen Freigabe-/Bereitstellungs-Gates. Weisen Sie endgültige Regressionsabdeckung seinem besitzenden Meilenstein zu, anstatt sie in jede Einheit zu kopieren; folgen Sie der Plan- und Repository-Testrichtlinie und identifizieren Sie gültige wiederverwendbare Beweise und erforderliche Stabilitätswiederholungen
   • konkrete Akzeptanzkriterien, die bestimmen, ob der Meilenstein abgeschlossen ist; schreiben Sie in einem Protokoll 0.2-Plan diese meilensteinspezifischen Checks als Prosa und definieren Sie niemals neue AC--IDs in milestones.md
   • einen Überprüfungspunkt, der das Verhalten, die Verträge, Risiken, Integrationspunkte oder andere wesentliche Details identifiziert, die der Entwickler vor dem Fortfahren inspizieren sollte

6. Halten Sie Implementierung und ihre erforderlichen Korrektheitsbeweise zusammen. Teilen Sie erforderliche Tests, direkt betroffene Dokumentation, Fehlervertragssynchronisation, Migrationen, öffentliche Exporte oder andere notwendige unterstützende Arbeit nicht in spätere Meilensteine auf, nur um einen früheren Meilenstein kleiner zu machen. Erstellen Sie keine Platzhalter, temporäre Duplikate, ungenutzte Abstraktionen, Übergangskompatibilitätspfade, Sackgassen-Gerüste oder absichtlich unvollständige Implementierungen nur um Meilensteingrenzen zu erzeugen, es sei denn, der genehmigte Plan erfordert explizit einen gestaffelten Kompatibilitäts- oder Migrationspfad. Machen Sie Meilensteine nicht künstlich klein oder einheitlich in der Größe. Ordnen Sie sie nach echten Implementierungsabhängigkeiten und Risiken an.

7. Führen Sie vor dem Finalisieren der Sequenz einen Plan-zu-Meilenstein-Abdeckungsdurchlauf durch. Jeder im Plan enthaltene Liefergegenstand, jedes Akzeptanzkriterium, jede erforderliche Produktionsänderung, jeder Test, jedes Dokumentationsupdate, jede Migration, jede öffentliche Vertragsänderung, jede Entfernung, jeder Integrationspunkt und jede Verifikationsanforderung muss in mindestens einem entwicklersichtbaren Meilenstein erscheinen. Die dem Entwickler präsentierte Sequenz ist die vollständige und endgültige Meilensteinsequenz. Reservieren Sie keine versteckten Meilensteine, führen Sie keine alternative interne Sequenz, lassen Sie keine erforderliche Arbeit aus oder verlassen Sie sich auf nicht genannte Meilensteinarbeit auf Meilensteinebene. Wenn erforderliche Arbeit nicht zugewiesen werden kann, ohne eine materielle Planentscheidung zu ändern, melden Sie das Hindernis und stoppen Sie; der Plan muss durch jg-plan überarbeitet werden, bevor die Aufschlüsselung abgeschlossen werden kann.

8. Inspizieren Sie den aktuell ausgewählten Plan und die Sequenz. Erfordern Sie eine verwendbare Plan-ID, Revision und strukturellen Fingerabdruck mit genau created_at, updated_at, revision, status, priority und delivery ausgeschlossen, bevor Sie eine Sequenz binden. Gleichen Sie den gesamten aktuellen Plan mit den vorgeschlagenen Einheiten ab: Beibehaltene IDs identifizieren dieselbe Arbeit, und beibehaltener done-Status benötigt Beweise, dass seine Anforderungen weiterhin erfüllt sind. Bewahren Sie übereinstimmende Identitäten/Fortschritte und nicht zusammenhängende Meilenstein-Metadaten; fügen Sie neuen unvollendeten Umfang als pending hinzu. Fragen Sie den Entwickler, wenn Identitäts-/Umfangskorrespondenz oder widersprüchlicher Abschluss nicht sicher geklärt werden können. Bewegen Sie niemals einen Status rückwärts ohne explizite Wiedereröffnungsautorität. Fehlende/benutzerdefinierte/mehrdeutige vorhandene Marker sind keine pending-Standardwerte. Schreiben Sie vollständige Meilensteinquelle durch guarded write mit expectedSha256 null nur für beobachtete Abwesenheit, mit assignMissingIds true; das Werkzeug liefert fehlende UUIDs. Setzen Sie status unmittelbar unter jede Überschrift und die UUID unmittelbar danach. Geben Sie in einem Protokoll 0.2-Plan jedem Meilenstein, der Plankriterien liefert, eine **Acceptance criteria:** AC-01, AC-03 Zeile, die ihre IDs auflistet, direkt nach seiner UUID-Zeile oder direkt nach seiner Statuszeile, wenn das Werkzeug die UUID zuweisen wird; jedes Plankriterium erscheint auf mindestens einer Meilensteinzeile, und ein Meilenstein, der keines liefert, lässt es aus. Generieren Sie keine Übersichtstabelle und synchronisieren Sie keine. Fügen Sie ein Frontmatter mit der Zuordnung jg_skills mit plan_id, plan_revision und plan_content_sha256 aus dem aktuellen Plan nur hinzu, nachdem die vollständige Sequenz ihn abdeckt. Bewahren Sie abgeschlossene Einheiten, während Sie neuen Umfang hinzufügen, selbst wenn jede alte Einheit abgeschlossen war. Überprüfen Sie die Planidentität unmittelbar vor dem Schreiben erneut und stellen Sie sicher, dass sie aktuell geblieben ist; gleichzeitige Änderung erfordert eine frische Abdeckungsbewertung. Überprüfen Sie das persistierte Ergebnis, einschließlich zugewiesener IDs, bevor Sie sein genaues vollständiges Markdown präsentieren. Führen Sie für einen Protokoll 0.2-Plan auch <local-cli> check --directory <path> --json aus und beheben Sie jeden Abdeckungs-, ID- und Statusfehler in milestones.md, bevor Sie präsentieren; melden Sie plan.md-Fehler als jg-plan-Erfordernis. Melden Sie zuerst den repository-relativen Pfad. Ändern Sie nur milestones.md im ausgewählten Verzeichnis; ändern Sie niemals plan.md, den Git-Zustand oder die Implementierung.

9. Beenden Sie sowohl milestones.md als auch den passenden Antworttext mit einem Abschnitt ## Approval required, der die vollständige Meilensteinsequenz zusammenfasst und diese Regeln angibt, dann stoppen Sie:

   • Jeder Meilenstein benötigt seine eigene explizite Autorisierung, ist der vollständige Umfang dieser Anfrage und endet an seinem Überprüfungspunkt. Der Aufruf von jg-execute autorisiert den Meilenstein, den er ausführt; jg-execute auto autorisiert jeden verbleibenden Meilenstein oder nur den Meilenstein, den er nennt.
   • Wenn ein Meilenstein von unvollständiger früherer Arbeit abhängt oder dessen Fertigstellung eine Meilensteingrenze überschreiten oder den genehmigten Plan ändern würde, stoppen Sie und melden Sie, bevor Sie den Umfang erweitern.
   • Um den Plan zu ändern, rufen Sie jg-plan mit den Änderungen auf. Um Meilensteine zu erstellen oder zu ändern, rufen Sie jg-breakdown auf.

   Der Ausgabevertrag dieser Fähigkeit ersetzt jede allgemeine Abschlusszusammenfassungsanforderung; fügen Sie keine Abschlusszusammenfassung nach ## Approval required an. Die Genehmigung muss ausgestellt werden, nachdem die aktuelle Meilensteinsequenz präsentiert wurde; der jg-breakdown-Aufruf selbst, frühere Genehmigungen oder implizite Zustimmung ersetzen diese Anforderung nicht.