chore(governance): merge-Gate im Run-Ledger auf den Tatsachenstand bringen - #85
Merged
Conversation
…sachenstand bringen Der Ledger fuehrte `merge` weiterhin als `PENDING`, obwohl PR #78 gemergt ist (Merge-Commit `1f41354`, CI gruen am exakten Head `b52fcd0`, Run `32412284034`). Das war die letzte Stelle, an der GitHub und Run-Ledger auseinanderliefen. Bewusst NICHT geaendert: - `deploy` und `production-verification` bleiben `PENDING`. Das ist der zutreffende Wert: sie haben nicht stattgefunden. Ein Statuswert `BLOCKED` waere hier eine Erfindung — der Ledger kennt in seiner ganzen Historie genau zwei Werte, `CLEARED` und `PENDING`, und ein neuer koennte einen Konsumenten brechen, den ich nicht sehe (im Repo liest ihn kein Skript). Der Grund fuer das Ausbleiben steht dort, wo Prosa hingehoert: `docs/plans/2026-08-20-sprint-6-staging-blocker.md`. - Das Sechs-Schluessel-Schema. Kein zusaetzliches `blocker`-Feld aus demselben Grund. Zum `artifact_hash`: die drei alten Eintraege (`merge`, `deploy`, `production-verification`) trugen `0705ee2c…`. Dieser Wert ist heute **nicht reproduzierbar** — keine Datei im Baum hasht darauf, die Quelldatei hat sich seither geaendert. Statt ihn abzuschreiben und damit eine Herkunft zu behaupten, die ich nicht pruefen kann, hasht der neue Eintrag die Plandatei `docs/plans/2026-08-18-eyt-140-planungswerkbank.md` — dieselbe Konvention, die die Implementierungs-Gates `m6`/`m7`/`m9` bereits verwenden (`af5e61df…`). Nachgeprueft nach dem Nachtrag: Schluesselmenge unveraendert (sechs), Statuswerte unveraendert (`CLEARED`, `PENDING`). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reviewer's guide (collapsed on small PRs)Reviewer's GuideThis PR updates a single run-ledger entry to correctly reflect that PR #78 has been merged, keeps deploy and production-verification as PENDING for explicit business reasons, and adjusts the artifact_hash to use a verifiable plan document consistent with existing feature gate conventions. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Eine Zeile im Run-Ledger, plus die Begründung, was nicht angefasst wurde.
Der Befund
Der Ledger führte
mergealsPENDING, obwohl PR #78 gemergt ist (1f41354, CI grün am exakten Headb52fcd0, Run32412284034). Das war die letzte Stelle, an der GitHub und Run-Ledger auseinanderliefen — die Zielvorgabe verlangt beide als reconciled.Was bewusst NICHT geändert wurde
deployundproduction-verificationbleibenPENDING. Das ist der zutreffende Wert: sie haben nicht stattgefunden. Ein StatuswertBLOCKEDwäre eine Erfindung — der Ledger kennt in seiner ganzen Historie genau zwei Werte, und im Repo liest ihn kein Skript, also könnte ein dritter einen Konsumenten brechen, den ich nicht sehe. Der Grund für das Ausbleiben gehört in Prosa und steht indocs/plans/2026-08-20-sprint-6-staging-blocker.md.Das Sechs-Schlüssel-Schema. Kein zusätzliches
blocker-Feld, aus demselben Grund.Zum
artifact_hashDie drei alten Einträge (
merge,deploy,production-verification) trugen0705ee2c…. Dieser Wert ist heute nicht reproduzierbar — keine Datei im Baum hasht darauf, die Quelldatei hat sich seither geändert.Ihn abzuschreiben hätte eine Herkunft behauptet, die ich nicht prüfen kann. Der neue Eintrag hasht stattdessen die Plandatei
docs/plans/2026-08-18-eyt-140-planungswerkbank.md— dieselbe Konvention, die die Implementierungs-Gatesm6/m7/m9bereits verwenden (af5e61df…, gegengeprüft).Nachgeprüft nach dem Nachtrag
🤖 Generated with Claude Code
Summary by Sourcery
Reconcile the run ledger’s merge status with the verified merged state without changing unexecuted deployment stages.
Bug Fixes:
Chores: