Repository navigation
docs(w4-02): finalize the 27-row M4 acceptance matrix - #48
Conversation
No-Test: documentation-only acceptance contract
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
No-Test: documentation-only plan status update
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Die Entscheidungsregel erzeugt eine widersprüchliche Abhängigkeit zwischen W4-02, W4-03 und der späteren M4-Abnahme.
Review effort: Balanced
Findings: 1
What changed in this PR
Die PR ergänzt die verbindliche 27-zeilige M4-Abnahmematrix für Continuous Mode.
Changes:
- Definiert Nachweise und Status für 27 Abnahmepunkte.
- Hält Continuous Mode bis zur Abnahme fail-closed.
- Ein Widerspruch in der Reihenfolge von W4-02 und W4-03 muss behoben werden.
| File | Description |
|---|---|
.pa/continuous_acceptance_matrix.md |
Dokumentiert den M4-Abnahmevertrag. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| W4-02 ist vollständig, wenn jede Zeile genau einen dauerhaft auffindbaren | ||
| Laufzeitbeleg oder einen dokumentierten Nutzer-/PC-Beleg referenziert. `blocked`, | ||
| `unavailable`, `not_reported`, `unverified` und fehlende Belege zählen nicht als | ||
| Bestanden. W4-03 darf die Aktivierung erst nach dieser Prüfung und der | ||
| Entscheidung aus Zeile 27 umsetzen. |
|
Queued — the merge queue status continues in this comment ↓. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 82db9a1900
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Bestanden. W4-03 darf die Aktivierung erst nach dieser Prüfung und der | ||
| Entscheidung aus Zeile 27 umsetzen. |
There was a problem hiding this comment.
Entkopple W4-02 von den W4-03-Belegen
Wenn die verbindliche M4-Reihenfolge eingehalten wird, erzeugt diese Regel einen Deadlock: docs/PLAN.md plant W4-03 ausdrücklich erst nach W4-02, während Zeile 27 bereits ein Audit mit releaseEligible: true verlangt; im geprüften Commit setzt scripts/continuous-audit.mjs jedoch continuousExecutionEnabled und stablePromotionAuthorized bis zur späteren Aktivierungsarbeit fest auf false. Damit kann W4-02 nie „vollständig“ werden und W4-03 folglich nie beginnen. W4-02 sollte nur die fertig definierte Matrix bzw. ihre vorgesehenen Belegarten verlangen; das Bestehen aller 27 Zeilen gehört zur anschließenden M4-Abnahme.
AGENTS.md reference: AGENTS.md:L52-L53
Useful? React with 👍 / 👎.
| | 13 | Launch, Prozessidentität und Exit werden reconciled. | Crash-, normaler Exit- und verlorene-Response-Lauf; unbekannte Prozesse führen zu `reconciling` und sperren Neudispatch. | Laufzeit | offen | | ||
| | 14 | Checkpoints und Fortschritt sind strukturiert, idempotent und an den Run gebunden. | Wiederholung, stale revision und fehlende Evidence werden mit stabiler Ablehnung bzw. unveränderter Wiederholung beobachtet. | Laufzeit | offen | | ||
| | 15 | Candidate und Evidence sind unveränderlich an Commit, Run und Policy gebunden. | Laufzeitbeleg für Bindung, Idempotenz, Leseberechtigung und Ablehnung fremder oder stale Evidence. | Laufzeit | offen | | ||
| | 16 | Reviews sind unabhängig vom Implementierer und an denselben Candidate gebunden. | Review-Lauf mit anderer Modellfamilie; Self-review und unverified Providervergleich bleiben nicht abnahmefähig. | Nutzer-Gate | offen | |
There was a problem hiding this comment.
Verlange zwei unabhängige Tier-A-Reviewer
Bei einem Candidate mit Nahtstellen-, Security-, Concurrency-, PTY- oder Datenbankänderungen kann diese Zeile bereits durch einen einzelnen Review-Lauf einer anderen Modellfamilie als bestanden gelten. Für Tier A sind jedoch zwei Reviewer von anderen Anbietern vorgeschrieben; „andere Modellfamilie“ belegt weder die erforderliche Anzahl noch die Anbieterunabhängigkeit. Dadurch könnte die Matrix eine risikoreiche Änderung mit zu schwachem Review für Delivery und Release freigeben. Der Nachweis muss die Risikostufe sowie Anzahl und Anbieter der Reviewer festhalten.
AGENTS.md reference: AGENTS.md:L26-L30
Useful? React with 👍 / 👎.
| | 23 | Updater und Recovery behandeln aktive Sitzungen, Fehler und Rollback sichtbar. | Installierter Update-Drill mit erfolgreichem, abgebrochenem und fehlgeschlagenem Übergang; kein unbefristetes stilles Warten. | Nutzer-Gate | offen | | ||
| | 24 | Der Benchmark misst Qualität vor Optimierung und bindet jeden Fall an Run und Evidence. | Fünf freigegebene Aufgaben aus W4-01 (oder der vom Nutzer bestätigte Umfang) mit Tokens, Zeit, Rejection, Rework und Regression; Zielwerte gelten erst nach Qualitätsgate. | Nutzer-Gate | offen | | ||
| | 25 | Singleton, Mehrfachstart und Recovery sind als installierte PC-Drills bestanden. | Nutzer führt die drei Drills aus; alte Instanz scheitert kontrolliert, Nutzersitzungen bleiben erhalten, Ergebnis wird abgelegt. | Nutzer-Gate | offen | | ||
| | 26 | Die vollständige Abnahme ist auf den vorgesehenen Plattformen und Gates reproduziert. | `prepush`, Linux-/Windows-Lane sowie dokumentierte Windows-/Linux-Einschränkungen sind mit Commit und Exit-Code festgehalten. | Nutzer-Gate | offen | |
There was a problem hiding this comment.
Verlange einen echten Windows-Lauf
Wenn dieser Nachweis aus einem gewöhnlichen PR übernommen wird, kann gates (windows) erfolgreich sein, obwohl kein Windows-Code kompiliert oder getestet wurde: Dieser Job ist dort nur ein Ubuntu-Stub. Die aktuelle Formulierung lässt damit eine vollständige Plattformabnahme allein anhand des grünen Jobnamens und dokumentierter Einschränkungen zu. Verlange stattdessen ausdrücklich den vollständigen Windows-Lauf aus der Merge Queue oder einem workflow_dispatch, gebunden an denselben Candidate-Commit.
AGENTS.md reference: AGENTS.md:L222-L230
Useful? React with 👍 / 👎.
| | 10 | Globale und projektbezogene Kapazitäts- und RAM-Grenzen werden eingehalten. | Ressourcendruck-Test zeigt die begrenzte Claim-Anzahl, die Speicheranpassung und eine unveränderte Sperre bei unbekannter Messung. | Laufzeit | offen | | ||
| | 11 | Provider, Modell, Transport und beobachtete Ausführungsidentität stimmen mit der Route überein. | Je freigegebenem Adapter ein echter PC-Lauf mit beobachteter Identität; unbekannte oder stale Zustände blockieren. | Nutzer-Gate | offen | | ||
| | 12 | Billing- und Usage-Angaben sind getrennt, quellengebunden und nicht erfunden. | Providerbeleg mit Quelle und Beobachtungszeit; fehlende Collector liefern `not_reported` statt geschätzter Tokens oder Guthaben. | Nutzer-Gate | offen | | ||
| | 13 | Launch, Prozessidentität und Exit werden reconciled. | Crash-, normaler Exit- und verlorene-Response-Lauf; unbekannte Prozesse führen zu `reconciling` und sperren Neudispatch. | Laufzeit | offen | |
There was a problem hiding this comment.
Prüfe den Lease-Ablauf ohne Rückforderung
Wenn die Lease eines noch laufenden Workers abläuft, decken die genannten Crash-, Normal-Exit- und Response-Verlust-Fälle nicht ab, dass Claim und Kapazität unverändert gehalten werden und kein Ersatz-Worker startet. Eine Implementierung könnte daher den Lease-Ablauf als Prozessende behandeln, einen zweiten Worker dispatchen und diese Zeile dennoch bestehen; selbst ein später abgewiesener stale write verhindert die doppelte Ausführung nicht. Ergänze einen expliziten Lease-Expiry-Drill, der unveränderten Claim, belegten Prozesszustand und ausbleibenden Neudispatch prüft.
AGENTS.md reference: AGENTS.md:L124-L126
Useful? React with 👍 / 👎.
| | 20 | Der globale Not-Aus stoppt die gesamte Ausführung innerhalb von 10 Sekunden. | PC-Drill misst den Zeitraum vom Auslösen bis zum bestätigten Stillstand aller betroffenen Worker und dokumentiert Restprozesse. | Nutzer-Gate | offen | | ||
| | 21 | Crash und Power-Loss lassen keine unklaren Claims oder stillen Zustandswechsel zurück. | Wiederanlauf-Drill an jeder kritischen Transition; Recovery bleibt blockiert, bis Prozess- und DB-Zustand reconciled sind. | Nutzer-Gate | offen | | ||
| | 22 | Backup und Wartung bilden einen kohärenten, wiederherstellbaren SQLite-Zustand. | Backup-Drill einschließlich WAL, Restore und Integritätsprüfung vor Wartung; Snapshot und Ergebnis sind referenziert. | Nutzer-Gate | offen | | ||
| | 23 | Updater und Recovery behandeln aktive Sitzungen, Fehler und Rollback sichtbar. | Installierter Update-Drill mit erfolgreichem, abgebrochenem und fehlgeschlagenem Übergang; kein unbefristetes stilles Warten. | Nutzer-Gate | offen | |
There was a problem hiding this comment.
Prüfe Fehler nach der Wiederaufnahme von Schreibzugriffen
Bei einem Updatefehler, der erst nach Wiederaufnahme der Schreibzugriffe und nach neuen Nutzerdaten eintritt, verlangen die drei aufgeführten Übergänge nicht, dass ein Rollback auf die alte Datenbank verweigert wird. Der Drill könnte somit trotz Datenverlust durch Wiederherstellung des alten Snapshots bestehen. Ergänze einen Post-Resume-Fehlerfall, der zunächst einen neuen Write bestätigt und anschließend belegt, dass Recovery den neuen Zustand nur bewahrt bzw. quarantänisiert und niemals die alte Datenbank einspielt.
AGENTS.md reference: AGENTS.md:L125-L127
Useful? React with 👍 / 👎.
|
@Mergifyio queue |
Merge Queue Status
This pull request spent 12 minutes 28 seconds in the queue, with no time running CI. ReasonThe pull request conflicts with the base branch The pull request was held in the queue, conflicting with at least one of 2 pull requests ahead of it. The conflict became a base branch one after #52, #54 merged. HintYou should update or rebase your pull request. If you want to requeue this pull request, you can post a Requeued — the merge queue status continues in this comment ↓. |
|
@Mergifyio queue |
Merge Queue Status
This pull request spent 13 minutes 16 seconds in the queue, including 12 minutes 57 seconds running CI. Required conditions to merge
|

Die M4-Abnahmematrix ist jetzt als verbindlicher Vertrag mit genau 27 Zeilen dokumentiert.
Jede Zeile verlangt einen beobachtbaren Laufzeitbeleg oder ein ausdrücklich benanntes Nutzer-/PC-Gate.
Continuous Mode bleibt bis zur vollständigen Abnahme und einer expliziten Nutzerentscheidung fail-closed.
Report
Was geändert wurde
.pa/continuous_acceptance_matrix.mdergänzt.offen.origin/maingelöst: die neueren PLAN-Fakten ausmainübernommen und die vollständige 27-Zeilen-Matrix erhalten.Warum
W4-02 verlangt die finale Abnahmematrix vor W4-03. Der öffentliche Snapshot enthielt die in historischen Statusdokumenten referenzierte Matrixdatei nicht; diese Änderung stellt den fehlenden, fail-closed formulierten Vertrag wieder her, ohne Runtime-Fähigkeiten zu behaupten.
Evidenz
awk -F'|' '/^\\|[[:space:]]*[0-9]+[[:space:]]*\\|/ {count++} END {print count+0}' .pa/continuous_acceptance_matrix.md: 27 Zeilen, Exit 0.git diff --check: Exit 0.bash scripts/ci/secret-scan.sh: Exit 0, keine Leaks.bash scripts/ci/gates.sh lane prepush: Exit 0; Frontend 342/342, HQ 460/460, Rust 1628/1628 (7 übersprungen).git merge origin/main: Konflikt indocs/PLAN.mdgelöst, Merge-Commitc826634705c09084a9ec0f6df1cc4bc42eac9b03.git push -u origin codex/w4-02-acceptance-matrix: Exit 0.git ls-remote origin refs/heads/codex/w4-02-acceptance-matrix: Exit 0, finaler SHAc826634705c09084a9ec0f6df1cc4bc42eac9b03.NICHT ABGEDECKT
#[cfg(windows)]-Tests und die Windows-Arme von Clippy wurden nicht ausgeführt (KI-7). Die Windows-Bahn läuft in der Merge-Queue.offen; diese Doku definiert ihre Nachweise, sie ersetzt keine Nutzer-/PC-Drills.Review-Disposition
Tier C (Doku): kein externer Review erforderlich; Gates und die 27-Zeilen-Prüfung sind die Abnahme.
Offene Punkte
W4-03, die Not-Aus-/Recovery-/Updater-Drills, Provider-/Billing-Belege und die explizite Nutzerentscheidung bleiben nachgelagerte Voraussetzungen.