Aktivierungsvertrag
Wird geladen, wenn die Auslösebedingungen im Frontmatter auf einen Fehler-Workflow zutreffen.
Dieses Skill leitet die öffentliche Zusammenarbeit. Es verleiht keine Berechtigungen zur Issue-Freigabe, zum Setzen von Labels, zur Durchführung von Reviews, zur Erteilung von Ausnahmen oder zur Merge-Autorität.
Harte Regeln
- Review- und Urteilstag-Beweise sind ausschließlich für Reviews bestimmt. Pi erteilt niemals Bereitstellungsautorität: Normale Commits, Pushes, PRs und Releases folgen stets der Repository-Richtlinie, unabhängig vom RDD-Modus.
- Erfordere ein genehmigtes Issue (
status:approved) und eine saubere Reproduktion auf dem aktuellenmain, bevor die Implementierung beginnt. Überprüfe bestehende PRs auf Ersetzung oder Konflikte; stoppe oder schränke veraltete Ansprüche ein. - Gruppiere nach kausaler Autoritätsinvariante. Verwende ein Issue und einen PR oder eine explizite Kette pro unabhängiger Invariante und Rollback-Grenze. Trenne unabhängige Ursachen; führe niemals eine ersetzte oder widersprüchliche Autoritätslinie zusammen.
- Erfasse jeden vom Issue oder PR beanspruchten Operator-Durchlauf, einschließlich Einstieg, Modus, Umgebung, Erwartung und Negativkontrollen. Fordere einen wahrheitsgetreuen Black-Box-Benchmark-Ablauf pro CLI- oder Lebenszyklus-Durchlauf, oder einen tatsächlichen Laufzeit-E2E-Nachweis, wenn der Kern-Benchmark diesen nicht abbilden kann. Synthetische Proxy-Abdeckung beweist niemals eine andere Laufzeit.
- Verwende eine CodeGraph-zentrierte Auswirkungsanalyse, einen dedizierten Worktree und verhaltensorientierte Tests. Führe eine quellenverändernde Normalisierung vor dem Einfrieren des Kandidaten durch.
- Prognostiziere autorisierte Änderungen vor den eigentlichen Bearbeitungen. Die harte Grenze liegt bei 400 Additionen plus Löschungen; darüber wird gestoppt für eine Kette oder eine explizite, vom Maintainer genehmigte Ausnahme.
- Wenn RDD aktiviert ist, binde Review-Belege, Ableitung, Korrektur und Wiederherstellungsbeweise an den genauen Kandidaten. Halte begrenzte Review-Fehler in einer Korrekturtransaktion; behandle diese Beweise niemals als Bereitstellungsautorität.
- Erfordere eine unabhängige, schreibgeschützte Kandidatenvalidierung vor der Veröffentlichung. Die Validierung darf weder Quellcode noch Autorität bearbeiten; Ergebnisse erfordern einen neuen Kandidaten.
- Pflege eine menschenwürdige und belegbasierte Kommunikation. Repository-Labels und Workflow-Metadaten gehören dem Maintainer und sind niemals Beweise für ein Verschulden des Beitragenden.
Entscheidungsgatter
| Bedingung | Aktion |
|---|---|
| Beliebiger RDD-Modus | Überprüfungsbelege bleiben reine Überprüfungsbelege; normale Commits, Pushes, PRs und Releases folgen der Repository-Richtlinie ohne Pi-Bereitstellungsautorität. |
| Issue-Gatter oder Reproduktion schlägt fehl | Warten, anhalten oder mit Belegen eingrenzen. |
| Invariante oder Rollback ist unabhängig | Trennen in separates Issue und autoritative PR-Linie. |
| Kern-Benchmark passt / passt nicht | Benchmark-Ablauf / tatsächlicher Laufzeit-E2E; niemals Proxy. |
| Prognose übersteigt 400 Zeilen | Kette oder genehmigte Ausnahme vor Bearbeitungen. |
Ausführungsschritte
- Überprüfe Modus, Genehmigung, PR-Konflikte und Reproduktion auf dem aktuellen
main. - Benenne Invariante und Rollback; isoliere den Worktree; Kartiere Code, Tests, Belege, Dokumentation, Distribution und Registrierung mit CodeGraph.
- Erfasse Durchläufe und Kontrollen; füge fehlschlagende Tests und die kleinste Korrektur hinzu.
- Normalisiere, halte das Budget ein, führe Tests aus und zeichne für jeden Durchlauf den genauen Kandidaten, Befehl, Szenario und das Ergebnis auf.
- Friere ein, validiere schreibgeschützt und gib das Urteil, die Belege sowie einen menschenwürdigen nächsten Schritt aus.
Ausgabevertrag
Gib rdd_mode, issue_pr, causal_invariant, operator_flows, journey_runtime_evidence, changed_line_budget, tests, rollback und unresolved_authority_decisions zurück.
Identifiziere genehmigte und ersetzte/widersprüchliche Autoritätslinien; jeden Durchlauf, jede Negativkontrolle und jeden kandidatengebundenen Beweis; Additionen plus Löschungen sowie Kette/Ausnahme; Testergebnisse; unabhängiges Rollback; und ungelöste Entscheidungen des Maintainers.
Referenzen
Keine unterstützenden Dateien. Die aktuelle Repository-Richtlinie ist weiterhin maßgeblich.