21 KiB
title, type, created, status, baseline_commit, review_loop_iteration, context
| title | type | created | status | baseline_commit | review_loop_iteration | context | |
|---|---|---|---|---|---|---|---|
| Story 3.10 — Inkrementelle Update- und Synthese-Erhaltung absichern | feature | 2026-08-21 | done | 8c43d3a09c |
0 |
|
Intent
Problem: §5.9 (Erweitern/Präzisieren/Korrigieren/No-Op, Story 3.1/3.3), §5.10 (Synthese, Story 3.4) und §5.15 (Routing-Tabelle, Story 3.9) verankern die Update-/Synthese-Mechanik und die Routing-Entscheidung — aber die Erhaltungs-Absicherung im laufenden, gemischten Run fehlt als geschlossene Klammer: (a) die CONFIRMING-Grenze ist offen — eine neue Source, die eine bestehende Aussage unabhängig bestätigt, trägt einen neuen Evidenzanker und darf nicht in den §5.9-No-Op („Evidenz bereits vollständig enthalten") fallen (AC-4 vs. AC-6); (b) Korrigieren dokumentiert die ersetzte Aussage samt Source-Basis noch nicht im Run-Receipt (AC-2); (c) der Provenienz-/Link-Selbsttest erwartet Deltas aus historischen, fest codierten Commits/Zählwerten statt aus dem aktuellen Run (AC-7); (d) der Hold-Ausbau ist auf „Home Story 3.10" delegiert (§5.15 Zelle 3 + Scope-Präzisierung „post-Reconcile-Orphan, Mehrziel", §5.10-Pkt.-8-/§5.14-Pkt.-5-Reconcile-Orphan-Regel): post-Reconcile-Orphan über volle Stufen b/c (nicht nur Stufe-a), Mehrziel-Auflösung (D-8-Mehrfach-Term-Vereinigung), und klassifikationspflichtige/widersprüchliche Evidenz muss bis Epic 4 ohne Wissensmutation in einem benannten Hold erhalten bleiben, mit beiden Evidenzpfaden im Run-Receipt (AC-8, NFR-7).
Approach: Neue Sektion §5.16 „Inkrementelle Update- & Synthese-Erhaltung + Hold-Ausbau (Story 3.10)" (nach §5.15, vor §6): (1) Kontinuitäts-Garantie — Update/Synthese mutiert im bestehenden Pfad, kein thematisches Duplikat, Identität + Index-Link erhalten (AC-1); (2) Korrigieren mit Run-Receipt-Trace — ersetzte Wortlautfolge + Source-Basis im Run-Receipt (außerhalb Bundles, §5.14 Pkt. 2); mehrdeutige Korrektur → benannter Hold (Epic 4) (AC-2); (3) Schutzbestandteile & Byte-Identität — geschützte Bestandteile (gültige belegte Aussagen, §5.5-Inline-Verweise, sources gültiger Belege, §5.6-Links, human-verified) bleiben bei jedem Update/Synthese; nicht betroffene Concepts byte-identisch (AC-3); (4) CONFIRMING-Konsolidierung — bestätigende neue Source: Aussage genau einmal, alle Evidenzanker via §5.5-Multi-Beleg, sources-Zuwachs, generated.at-Bump, kein NO_OP (AC-4); (5) gemeinsame Wissensrepräsentation — §5.10 Pkt. 2/3/5 als Synthese-Erhaltung (Update auf bestehendes Concept = Erweiterung, keine Neuschreibung) (AC-5); (6) byte-erhaltender NO_OP — identische Evidenz samt vollständiger Evidenzanker-Menge → NO_OP; fehlender Anker → Pkt. 4 (AC-6); (7) Provenienz- & Link-Selbsttest aus aktuellem Run — Baseline = aktuelles <Baseline-Commit>, erwartete Deltas = Kandidatenliste ∪ Neu-Anlage ∪ log.md ∪ nachgeführte index.md; kein historischer Commit/globaler Zählwert normativ (AC-7); (8) benannter Hold — post-Reconcile-Orphan über alle Stufen (a/b/c), Mehrziel-Auflösung (Konsolidierung auf primäre Ziel-Repräsentation; sonst Hold), widersprüchliche/klassifikationspflichtige Evidenz ohne Wissensmutation, beide Evidenzpfade im Run-Receipt (AC-8).
Boundaries & Constraints
Always:
- Nur
schema/compiler.mdmutiert (neue §5.16 + §7-Bullet-Erweiterung der Story-3.10-Verankerung + §8-Revisionslog Revision 3.5 + Hold-Home-Nachführungen: §5.15-Zelle-3-Zeile + §5.15-Scope-Präzisierung, §5.10-Pkt.-8-/§5.14-Pkt.-5-Verweis).schema/validator.md,schema/wiki-compiler.md,adapters/,raw/read-only (AD-3);schema/canonical-terms.mdbleibt append-only-Registry (keine Bestandsedits). - Referenz statt Re-Negotiation: bestehende §5.9/§5.10/§5.15-Mechaniken bleiben textuell unverändert — §5.16 definiert die operationelle Erhaltungs-Ebene (CONFIRMING-Grenze, Schutzbestandteile, aktueller-Run-Selbsttest, Hold-Ausbau) darüber; die §5.9-Abgrenzungs-Reihenfolge
Korrigieren → Präzisieren → Erweitern → No-Opbleibt die einzige Form-Wahl, synthese- und update-seitig unverändert. - Kein neues Prädikat, keine neue §7-Invaliditätsklasse, keine fünfte Update-Form, kein neuer Frontmatter-/Format-Key; AD-16-Klassifikation/semantische Auflösung bleibt Epic 4;
raw/unangetastet (AD-3). - Sandbox-Nachweis re-executierbar (Muster sandbox-3-9, Exit 0), harte PASS/FAIL-Assertionen, kein Berührung des realen Ist-Baums.
Ask First:
- Umlaut-vs-Transkription-Divergenz im Match-Pfad schließen (bleibt benannter Defer — kein neuer Normalisierungs-Operand, append-only).
- Verhalten des
generated.at(A0-20: einmaligeat-Festlegung pro Run) ändern — bleibt unverändert bindend. - Veränderung am §5.9-No-Op-Regeltext selbst (frozen, Story 3.1) — §5.16 ergänzt nur die operationelle CONFIRMING-Abgrenzung, kein Rework des frozen Textes.
Never:
- Nie Wissensmutation bei Orphan/Hold; nie stilles Löschen von Evidenz, Provenienz oder geschützten Bestandteilen; nie „Regenerate Everything" (AD-5/FR-12); nie hart kodierte erwartete Pläne/Concept-Bodies/Zählwerte als Beweis (AC-7, §5.14 Pkt. 2); nie Standalone/Eigene Runtime (D-3, AD-11); nie textueller Auto-Merge (AD-17c).
I/O & Edge-Case Matrix
| Scenario | Input / State | Expected Output / Behavior | Error Handling |
|---|---|---|---|
| KONTINUITAET | neue Erkenntnis auf bestehenden Concept-Pfad | in-place Update/Synthese, kein Duplikat, Identität + Index-Link erhalten (AC-1) | kein Overwrite, kein neuer Link ohne echte Beziehung |
| KORRIGIEREN_RECEIPT | eindeutige aktuelle Evidenz ersetzt eine Aussage | in-place Korrektur; ersetzte Wortlautfolge + Source-Basis im Run-Receipt (§5.14 Pkt. 2) (AC-2) | mehrdeutig → benannter Hold, keine Mutation |
| GESCHUETZTE_BESTANDTEILE | Update/Synthese auf Concept mit gültigen Aussagen+Provenienz | geschützte Bestandteile erhalten; nicht betroffene Concepts byte-identisch (AC-3) | Verstoß = textuell benannt (NFR-4), Ghost-Diff-Rollback (§5.9 Pkt. 5) |
| CONFIRMING | neue Source bestätigt bestehende Aussage unabhängig | Aussage genau einmal, alle beitragenden Evidenzanker (§5.5-Multi-Beleg), sources-Zuwachs, at-Bump — kein NO_OP (AC-4) |
kein Duplikat der Aussage, kein stiller Anker-Verlust |
| SYNTHESE_ERHALTUNG | mehrere redundante/ergänzende Sources | eine gemeinsame Wissensrepräsentation, claim-granulare gemischte Provenienz, keine Quelle-A/B-Aneinanderreihung (AC-5) | §5.10-Pkt.-5-Reflektiertheits-Selbsttest |
| NO_OP_BYTE_ERHALTEND | identische Evidenz samt vollständiger Evidenzanker im Body | byte-erhaltender NO_OP — keine Mutation, kein at-Bump, kein sources-Zusatz, kein log.md-Eintrag (AC-6) |
fehlender Anker → CONFIRMING (Pkt. 4), nicht NO_OP |
| SELBSTTEST_AKTUELLER_RUN | Provenienz-/Link-Selbsttest bei Update/Synthese | Baseline = aktuelles <Baseline-Commit>; erwartete Deltas = Kandidatenliste ∪ Neu-Anlage ∪ log.md ∪ index.md (AC-7) |
kein historischer Commit/Zählwert normativ; Abweichung = textuell benannt |
| ORPHAN_HOLD_VOLLE_STUFEN | unzugeordnete Evidenz, erkannt über Stufe a/b/c | benannter Hold ohne Wissensmutation, datumsgruppierter log.md-Eintrag (<Baseline-Commit>), beide Evidenzpfade im Run-Receipt (AC-8) |
kein Banner, keine stille Bearbeitung, keine eigenständige Anlage |
| MEHRZIEL | eine Einheit löst über mehrere Terme auf mehrere Ziele auf | Konsolidierung auf primäre Ziel-Repräsentation; kein Duplikat; ohne dominantes Ziel → benannter Hold (AC-8) | mehrdeutig → fail-closed (Hold), beide Pfade im Receipt |
Code Map
schema/compiler.md— primär mutiert (D-3): neue Sektion §5.16 „Inkrementelle Update- & Synthese-Erhaltung + Hold-Ausbau (Story 3.10)" (nach §5.15 Z. 398, vor §6 Z. 402; Pkt. 1–8) — alle Zellen referenzieren die bestehenden Mechaniken Wortlaut-unverändert; Hold-Home-Nachführungen: §5.15-Zelle-3-Zeile (Z. 391 „Hold-Ausbau Home Story 3.10") und §5.15-Scope-Präzisierung (Z. 400 „Der Hold-Ausbau (post-Reconcile-Orphan, Mehrziel) verbleibt Story 3.10") → „in §5.16 verankert (Story 3.10)"; §5.10-Pkt.-8-D-4-Bullet (Z. 302 „hat seinen Home in Story 3.10") → §5.16-Verankerung; §7-Bullet-Erweiterung (Story-3.10-Verankerung, analog §5.15-Ergänzung); §8-Revisionslog Revision 3.5. Bestehende §5.9/§5.10/§5.15-Mechaniken bleiben textuell unverändert (Referenz statt Re-Negotiation)._bmad-output/implementation-artifacts/sandbox-3-10/run-sandbox.sh— neu (re-executierbar, Mustersandbox-3-9/run-sandbox.sh, Exit 0): Szenarien E-1..E-9 (Matrix-Zeilen als harte Assertionen; CONFIRMING ≠ NO_OP mit Byte-Vergleich; NO_OP byte-erhaltend; Korrigieren-Receipt-Trace; aktueller-Run-Selbsttest; Orphan über Stufe-a/b/c; Mehrziel; Zwei-Run-Identität)._bmad-output/implementation-artifacts/sprint-status.yaml— mutiert: Key3-10-inkrementelle-update-und-synthese-erhaltung-absichernbacklog→review(Implementierungs-Commit; finalerdone-Flip im Step-05-Status-Sync nach konvergiertem Review-Loop);last_updated(FormatMM-DD-YYYY HH:MM)._bmad-output/implementation-artifacts/deferred-work.md— append: Defer „Orphan voller Stufen b/c + Mehrziel" (Hold-Home Story 3.10) → aufgegriffen/geschlossen; Umlaut-Defer bleibt offen (wie notiert, kein Instruktions-Defekt).wiki/log.md— append (Vertrag §5, bestehende Bullets unverändert): Story-3.10-Eintrag (Verankerung §5.16, Sandbox-Nachweis E-1..E-9, Status-Flip, Validator-Verdikt)._bmad-output/implementation-artifacts/epic-3-context.md— mutiert (gemäß genehmigtem Sprint-Change-Proposal 2026-08-20; Header „Edit freely"): Technical Decision Z. 39 „Deterministische Relevanz & Routing" um §5.16-/Story-3.10-Ist ergänzt (Erhaltungs-Absicherung + Hold-Ausbau verankert).
Read-only evidence (AD-3): schema/validator.md (Rev 9), schema/wiki-compiler.md, adapters/, raw/ (z. B. raw/architecture-spine/architecture-spine-2026-08-14.md AD-4/AD-5/AD-16; raw/epics/epics-2026-08-14.md FR-4/FR-6/FR-7/FR-12, NFR-7). schema/canonical-terms.md append-only unangetastet.
Tasks & Acceptance
Execution:
schema/compiler.md— §5.16 einfügen (nach §5.15, vor §6): Pkt. 1–8 gemäß Intent; keine neuen Prädikate/§7-Klassen/Keys; Hartung der CONFIRMING-vs-NO_OP-Grenze; §7-Bullet und §8-Revisionslog Revision 3.5 nachführen; Hold-Home-Nachführungen §5.15-Zelle-3/Scope-Präzisierung, §5.10-Pkt.-8-D-4_bmad-output/implementation-artifacts/sandbox-3-10/run-sandbox.sh— E-1..E-9, harte PASS/FAIL, CONFIRMING ≠ NO_OP byte-bewiesen, Zwei-Run nicht-vakuum, Exit 0_bmad-output/implementation-artifacts/sprint-status.yaml— Key 3-10 →review(Impl-Commit; finalerdone-Flip Step-05);deferred-work.md— Orphan-voller-Stufen/Mehrziel-Defer aufgegriffen;wiki/log.md— Story-3.10-Eintrag (Verankerung, Sandbox, Validator-Verdikt)_bmad-output/implementation-artifacts/epic-3-context.md— Technical Decision Z. 39 um §5.16-Ist ergänzt
Acceptance Criteria:
- Given eine passende neue Erkenntnis zu einem bestehenden Concept, when der Run sie verarbeitet, then wird das bestehende Concept in-place erweitert oder präzisiert und kein thematisches Duplikat angelegt (AC-1).
- Given explizite aktuelle Evidenz, die eine bestehende Aussage eindeutig korrigiert, ohne dass zwischen weiterhin gültigen Sources ein Widerspruch verbleibt, when der Run sie verarbeitet, then wird das bestehende Concept in-place korrigiert und die ersetzte Aussage samt Source-Basis bleibt im Run-Receipt nachvollziehbar; mehrdeutige Fälle gehen in den Hold für Epic 4 (AC-2).
- Given ein betroffenes Concept mit weiterhin gültigen Aussagen und Provenienz, when es aktualisiert wird, then bleiben diese geschützten Bestandteile erhalten; nicht betroffene Concepts bleiben byte-identisch (AC-3).
- Given eine neue Source, die eine bestehende Aussage unabhängig bestätigt, when synthetisiert wird, then erscheint die Aussage genau einmal und trägt alle beitragenden Evidenzanker; die neue Source ist kein
NO_OP(AC-4). - Given mehrere Sources mit redundanten und ergänzenden Aussagen, when der Run synthetisiert, then entsteht eine gemeinsame Wissensrepräsentation mit claim-granularer gemischter Provenienz — keine Source-A/Source-B-Aneinanderreihung (AC-5).
- Given eine bereits vollständig repräsentierte identische Source samt Evidenzanker, when sie erneut verarbeitet wird, then ist der Run für dieses Wissen byte-erhaltend (
NO_OP) (AC-6). - Given der Provenienz- und Link-Selbsttest, when erwartete Deltas bestimmt werden, then stammen Baseline und Erwartung aus dem aktuellen Run; kein historischer, fest codierter Commit oder globaler Zählwert ist normativ (AC-7).
- Given klassifikationspflichtige oder widersprüchliche Evidenz, when der Run sie erreicht, then wird sie bis Epic 4 ohne Wissensmutation in einem benannten Hold erhalten; beide Evidenzpfade bleiben im Run-Receipt nachvollziehbar (NFR-7) — der post-Reconcile-Orphan wird über alle Erhebungs-Stufen (a/b/c) geschlossen und Mehrziel-Einheiten werden konsolidiert oder gehalten (AC-8).
Spec Change Log
- Draft (2026-08-21, Step-02-Plan): Erstentwurf gemäß bmad-build-Workflow für Story 3.10 — Erhaltungs-Absicherung (AC-1..AC-7) + Hold-Ausbau (AC-8, Hold-Home aus §5.15-Zelle-3/Scope-Präzisierung und §5.10-Pkt.-8-D-4). Noch keine Review-Loop-Einträge;
status: draft, Review-Loop-Iteration 0.
Design Notes
Warum §5.16 als eigene Sektion, nicht §5.9/§5.10-Umbau? §5.9 (frozen, Story 3.1/3.3) und §5.10 (Story 3.4) sind textuell verankerte Mechaniken; §5.15 (Story 3.9) schließt die Routing-Ebene. §5.16 ist die Erhaltungs-Klammer darüber — dieselbe Fugen-Identitäts-Präzedenz wie §5.14/§5.15: die operationelle Ebene und der Hold-Ausbau werden als neue Sektion verankert, bestehende Regeltexte Wortlaut-unverändert referenziert (Re-Negotiation-Vermeidung).
CONFIRMING ≠ NO_OP (AC-4/AC-6-Grenze ist der Kernfnd der Erhaltung). Der §5.9-No-Op („engere Auslegung: trifft nur, wenn die neue Evidenz keine Aussage trägt, die im Body nicht bereits als belegte Aussage vorhanden ist — Term-/Stellen-Abgleich mit §5.5-Inline-Verweisen") muss operationell gegen den zunächst verblüffend ähnlichen CONFIRMING-Fall abgegrenzt werden: Eine bestätigende Source trägt denselben Inhalt, aber einen neuen Evidenzanker (anderer raw/-Pfad/-Stelle). Der Stellen-Abgleich schlägt also auf den Anker, nicht auf den Inhalt: ein fehlender Anker = echter neuer Beleg → Konsolidierungs-Update (Pkt. 4), kein NO_OP. NO_OP bleibt AC-6 vorbehalten: vollständige Evidenzanker-Menge bereits im Body präsent. Diese Abgrenzung ist rein operationell (neue §5.16-Ebene) — der frozen §5.9-Regeltext bleibt unverändert.
Run-Receipt trägt die Korrektur-/Hold-Spur (AC-2/AC-8). Der §5.14-Pkt.-2-Run-Receipt liegt außerhalb des Bundles und ist damit der korrekte Ort für ersetzte Wortlautfolgen (Korrigieren) und die beiden Evidenzpfade eines Holds (ursprünglicher + widersprechender) — das Bundle selbst enthält laut AD-16-Default beide Behauptungen, ohne Korrektur-Klassifikation (Epic 4). NFR-7 („ohne künstliche Gewissheit") wird damit mechanisch nachvollziehbar: Der Hold ist ein benannter, im log.md datumsgruppierter Eintrag + Receipt-Führung, nie eine stille Löschung oder eigenständige Concept-Anlage.
Aktueller-Run-Selbsttest (AC-7) löst die historischen Fixwerte auf. Die §5.6-Formeln 1–4 tragen historische Zählwerte/Baselines als dokumentarische Pins (Story 2.3/2.4). AC-7 macht für die Erhaltungs-Probe die Relativ-Ableitung normativ: Baseline = <Baseline-Commit> des aktuellen Runs (dynamische Extraktion), erwartete Delta-Menge = Kandidatenliste ∪ Neu-Anlage ∪ log.md ∪ nachgeführte index.md — kein globaler Zählwert liefert noch eine normative Erwartung mit.
Hold-Ausbau = post-Reconcile-Orphan über volle Stufen + Mehrziel. §5.15 Zelle 3 ist der Routing-Anker (fail-closed, raw/ unangetastet); §5.10 Pkt. 8 ist die deterministische Reconcile-Orphan-Regel (log.md-verwaist-Eintrag). §5.16 Pkt. 8 schließt die von §5.15/§5.14 offen gelassenen Fälle: (a) Orphan-Erkennung über alle drei Erhebungs-Stufen (§3.2 a/b/c — die Story-3.9-Sandbox übte nur Stufe-a), (b) Mehrziel aus der D-8-Mehrfach-Term-Vereinigung (Eine Einheit → mehrere gleichgewichtige Ziele: Konsolidierung auf eine primäre Ziel-Repräsentation, nie Duplikat-Inhalt in mehreren Concepts; ohne dominantes Ziel → fail-closed Hold), (c) benannter Hold mit beiden Evidenzpfaden im Receipt.
Verification
Commands (re-executierbar, ab Workspace-Root):
bash _bmad-output/implementation-artifacts/sandbox-3-10/run-sandbox.sh— expected: E-1..E-9 harte PASS/FAIL, CONFIRMING ≠ NO_OP byte-bewiesen (Aussage genau einmal, neuer Anker zusätzlich, keinNO_OP-Pfad), NO_OP byte-erhaltend (vollständige Anker-Menge), Korrigieren-Receipt-Trace vorhanden, aktueller-Run-Selbsttest ohne hart kodierte Erwartung, Orphan über Stufe-a/b/c + Mehrziel-Hold, Zwei-Run-Identität nicht-vakuum, Exit 0.grep -n "§5.16\|Revision 3.5" schema/compiler.md— §5.16-Sektion + Revisionslog-Eintrag;grep -n "Inkrementelle Update- & Synthese-Erhaltung" schema/compiler.md— Überschrift wortgleich; Hold-Home-Nachführung:grep -n "in §5.16 verankert" schema/compiler.md.- Read-only (AD-3):
git status --porcelainzeigt keinen Change anschema/validator.md/schema/wiki-compiler.md/adapters//raw/;schema/canonical-terms.mdunverändert. - Validator-Lauf: alle
wiki/-Dateien SUCCESS (keine Inhalts-Mutation); aufwiki/begrenzt (git status --porcelain -- wiki/): ausschließlichwiki/log.md— Erhaltungs-Invariante §5.9 Pkt. 5 gewahrt.
Zu beachten (beim step-04-Review): (a) bestehende §5.9/§5.10/§5.15-Mechaniken textuell unverändert (Referenz statt Re-Negotiation — §5.16 verankert nur die Erhaltungs-/Hold-Ebene); (b) die vorhandene Revisionslog-Nummer ist 3.4 (Story 3.9) — Revision 3.5 ist für Story 3.10 frei; (c) Umlaut-vs-Transkription-Defer bleibt offen (kein stiller Abschluss); (d) §5.16 führt kein neues Prädikat/keine neue §7-Klasse/keinen neuen Key ein; (e) AD-16-Klassifikation bleibt Epic 4.
Suggested Review Order
Design-Intent & Einstieg
- Erhaltungs-Klammer als eigene Sektion (Story 3.10) — operationelle Ebene über textuell unveränderten §5.9/§5.10/§5.15-Mechaniken, kein Umbau.
compiler.md:402
Instruktions-Verankerung (§5.16)
- CONFIRMING ≠ NO_OP: neue Source mit neuem Evidenzanker = Konsolidierungs-Update, nie No-Op (AC-4).
compiler.md:402 - NO_OP byte-erhaltend nur bei vollständiger Anker-Menge (AC-6); Korrigieren mit Run-Receipt-Trace (AC-2); Schutzbestandteile & Byte-Identität (AC-3).
compiler.md:402 - Benannter Hold über Erhebungs-Stufen a/b/c + Mehrziel-D-8-Vereinigung, beide Evidenzpfade im Receipt (AC-8).
compiler.md:402 - Selbsttest aus aktuellem Run: Baseline =
<Baseline-Commit>, erwartete Deltas, keine historischen Zählwerte (AC-7).compiler.md:402
Anker-Synchronisierung
- Hold-Home-Nachführungen: §5.15 Zelle 3 + Scope-Präzisierung, §5.10 Pkt. 8 D-4-Bullet — „in §5.16 verankert, Story 3.10".
compiler.md:391 - §7-Bullet Story-3.10-Verankerung; §8-Revisionslog Revision 3.5 (2026-08-21, Story 3.10).
compiler.md:515
Verifikations-Nachweis (Test)
- Sandbox E-1..E-9 — re-executierbarer Erhaltungs-Nachweis; Stufen-Scans a/b/c + route_orphan/mehrziel_route (echte Mechanik, kein Fixture-Marker-Wiedergepen).
run-sandbox.sh:127 - E-4 CONFIRMING ≠ NO_OP byte-bewiesen (at-Bump aus aktuellem Run, A0-20); E-6 NO_OP byte-erhaltend auf Run-State-Ebene (git-Status leer).
run-sandbox.sh:356 - E-8 Orphan/Mehrziel-Hold (log.md statt Sidecar, nur-log.md-Delta) + E-9 at-Wanduhr-Gap-Exzeption real ausgeübt.
run-sandbox.sh:512
Peripherie (Status/Tracking)
- sprint-status.yaml Key 3-10 → review (finaler done-Flip nach Step-05-Status-Sync); deferred-work.md Aufgegriffen-/Defer-Einträge; wiki/log.md Story-3.10-Eintrag; epic-3-context Technical Decision Z. 39.
sprint-status.yaml:47