Steuerung der ungeprueften Phasen: Model-Switch-Breaks, Issue-Body als Plan, Kommentar-Historie #47
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Befund
stack-devhatte seit 4.3.3 zwei Breakpoints für den Modellwechsel: Schritt 3 („Design steht, ab hier mechanisch", Richtung Sonnet) und Schritt 6 („Publish ist durch, ab hier greift kein Check mehr", zurück Richtung Opus). Zwei Dinge daran waren falsch.Erstens war der Schritt-3-Satz zu absolut.
instructions/claude-code-model-selection.mdstuft „closing an issue,docs/staleness, changelog prose" ausdrücklich als ungeprüft ein („nothing, by construction") — nur entsteht genau diese Prosa nicht erst nach Schritt 6, sondern mitten in der als mechanisch deklarierten Strecke: die Changelog-Prosa schreibtversion-parts.mdSchritt 8, also vor dem Publish;docs/-Seiten und neue Menschendoku entstehen im selben Zug; und der Prosa-Anteil einer Instruction wird voninstructions verifystrukturell, nie inhaltlich geprüft. Eine Sitzung, die den Satz wörtlich nahm, schrieb genau die Textsorten auf dem billigeren Modell, für die die Modellwahl-Tabelle das Gegenteil sagt.Zweitens war Schritt 6 ein Prosa-Haltepunkt an der schlechtestmöglichen Stelle — dort, wo eine Sitzung sich fertig anfühlt. Er ist zweimal hintereinander ausgefallen.
Belege: zwei Sitzungen, derselbe ausgelassene Break
#42 (2026-09-03,
4.4.0)Die Umsetzung lief durchgehend auf Sonnet. Der Schritt-3-Break kam korrekt; danach entstanden auf demselben Modell, ohne dass ein Break fällig geworden wäre: die Changelog-Prosa des
4.4.0-Eintrags, der neue Abschnitt indocs/version-model.md,DEVELOPMENT.mdvollständig (99 Zeilen), der Prosa-Anteil ininstructions/dev/version-parts.md. Der Schritt-6-Break wurde ganz ausgelassen, ebenso die Handover-Zeile — aufgefallen ist es dem Betreiber beim Lesen des Transkripts, nicht der Sitzung.Was der nachgeholte Durchgang fand (4.4.1-beta.1): einen Faktenfehler, doppelt ausgeliefert. Changelog und
docs/version-model.mdbehaupteten, unter dem alten Modell seien Nummern vergeben worden, die nie ausgeliefert wurden — im Changelog mit einer erfundenen Zahl. Tatsächlich wurde jeder Bump zu einem echten, getaggten Release. Durch pytest,docs verify,instructions verifyund CI glatt durchgelaufen, weil keiner davon Prosa liest.#30 (2026-09-04,
4.5.0-beta.1bis-beta.3) — dieselbe Stelle, zweites MalSchritt-3-Break kam korrekt. Schritt 6 kam wieder nicht als Break, sondern degradierte zu einer rückblickenden Zeile nachdem Issue-Body-Rewrite und Close bereits auf dem billigeren Modell gelaufen waren. Die Sitzung hat die Regel gekannt und trotzdem nicht als Haltepunkt ausgeführt.
Zwei Sitzungen hintereinander, gleiche Stelle, gleicher Ausgang — damit kein Ausführungs-Ausrutscher, sondern eine Konstruktionsschwäche: Schritt 6 verlangte einen Haltepunkt in dem Moment, in dem die Änderung veröffentlicht, CI grün und „nur noch" das Aufräumen offen ist. Dieselbe Wette, die
docs/why-gates-are-code.mdfür Gates verliert.Und der nachgeholte Review-Durchgang fand wieder etwas — diesmal im Code: zwei datenvernichtende Fehler (
shutil.rmtreeauf eine Content-Stage mit 497 gitignorierten Telemetrie-Traces; fehlenderMERGE_HEAD-Guard, der bei unverwandten Historienkb/CONTRACT.mdund alle Templates gelöscht hätte). Beide an einem grünen Lauf vorbei, weil kein Test die Fälle berührte. Das relativiert die Prämisse von Schritt 3 dauerhaft: „durch Tests abgedeckt" gilt nur für das, was die Tests treffen.Zwei weitere Steuerungsprobleme, die #30 sichtbar gemacht hat
1. Ein Issue-Body, der Mechanik vorschreibt, wird mitsamt seiner Fehler ausgeführt
Der #30-Body war die Sitzungs-Planvorlage, elf nummerierte Schritte. Schritt 6 lautete wörtlich: „Für jede Stage aus
CONTENT_STAGES[…]:git rm -rq --cached --ignore-unmatch <stage>, Arbeitsverzeichnis entfernen,git checkout HEAD -- <stage>." Genau das wurde gebaut —shutil.rmtree(stage_dir)— und genau das war der datenvernichtende Fehler, harmlos fürkb//raw/, nicht harmlos für das von demselben Issue neu aufgenommenereports/. Der Body hat den Bug vorgeschrieben, und die Umsetzung war ihm gegenüber loyal.Die Lehre ist die Gegenrichtung von „mehr Anweisung": eine vorgeschriebene Mechanik wird wörtlich genommen, eine benannte Invariante wird geprüft. Hätte dort „die Content-Stages müssen danach exakt
HEADentsprechen, ohne dass ungetrackte oder ignorierte Dateien angefasst werden" gestanden, wäre derselbe Satz Bauanleitung und Testkriterium gewesen. Trifft nicht die imperative Form als solche — die elf Schritte erzeugten einen korrekten Kontrollfluss — sondern destruktive Schritte ohne mitgelieferte Invariante.2. Die Kommentar-Historie widerspricht dem Body — und nichts sagte, wer gewinnt
issue-tracking.mdSchritt 2 sagte es aus Autorensicht schon richtig („Comments carry the history; the body carries the state"), für die Lesesicht stand nirgends etwas. Bei #30 empfahl Kommentar 480 das Gegenteil des späteren Body-Beschlusses (nurupstream verifystattmerge); eine Sitzung, die ihn für aktuell hält, baut das Gegenteil des Auftrags — mit einer plausiblen Begründung aus dem eigenen Repo.Zwei weitere Belege schärften die Regel: #10 (Body seit 2026-08-30 unverändert, behauptete „Coverage wurde nie gemessen", während drei Kommentare 86,9 % / 5105 Statements / CI-Lauf 87 trugen — hier wäre „Body schlägt Kommentar" die falsche Auflösung gewesen; dazu widersprechen sich 318 und 342 über ein Akzeptanzkriterium) und #23 (ein
_WIKITOOL_ENV-Auszug ohneCHEMENU_ROOT, an dem eine kalte Sitzung das Issue für erledigt halten konnte). Daraus wurden drei Klauseln statt einer.Entscheidungen
A — Dritter Break vor der Prosa. Verworfen. Zerhackt die Sitzung in drei Modellwechsel, der mittlere mitten in einen Ablauf, den
version-parts.mdals Einheit beschreibt. Durch E gegenstandslos.B — Prosa ans Ende ziehen. Verworfen: der Changelog-Eintrag muss vor dem Publish vollständig sein.
C — Schritt 3 ehrlicher formulieren. Umgesetzt in 4.6.0. Statt „ab hier alles mechanisch" jetzt mit benannter Ausnahme (Changelog-Prosa, berührte
docs/-Seite, neue Menschendoku, Prosa-Anteil einer Instruction), plus der Einschränkung aus #30, dass Tests nur decken, was sie treffen.D — Handover-Pflicht. Umgesetzt in 4.6.0. Die Schlussphase benennt das Modell für alle drei Phasen — Design/Versionsstelle, mechanische Mitte, Schluss —, auch wenn sie identisch sind. Eine Zeile, die nur eine billige Schlussphase meldet, schweigt genau dann, wenn die ebenso ungeprüfte Design-Phase auch billig lief.
E — Die Phasengrenze zur Werkzeuggrenze machen. Entschieden und umgesetzt in 4.6.0: zwei Skills, nicht zwei Agenten.
Der Agenten-Zuschnitt ist in Claude Code nicht baubar. Ein Fork (
subagent_type: "fork") erbt den vollen Sitzungskontext, läuft aber zwingend auf dem Elternmodell — einmodel:-Override wird ignoriert. Ein frischer Subagent bekommt ein eigenes Modell, startet aber kalt. Die Kombination, die E bräuchte, existiert nicht. Selbst wenn: der Input der Schlussphase ist das akkumulierte Sitzungswissen, das ein kalter Agent aus Diff und Issue neu ableiten müsste — also genau die ungeprüfte Urteilsarbeit, die der Schnitt schützen soll. Dazu Portabilität:Agent/model:gibt es nur in Claude Code,stack-devwird aber auch nach.agents/skills/publiziert.Der Skill-Schnitt:
stack-devendet nach Schritt 5 (Publish) mit einem Stop;instructions/dev/stack-close/SKILL.mdträgt Issue-Body-Rewrite,docs/-Veralterungs-Check und Handover.Was er ehrlicherweise kauft — in 4.6.1 nachgeschärft, weil die erste Fassung zu stark formuliert war. Kein Code-Gate:
wikitoolkennt diesen Tracker nicht und soll ihn nicht kennenlernen. Was sich ändert, ist, dass die Schlussprozedur nicht mehr als nächster Schritt im Kontext steht — sie existiert nur in einem Skill, den jemand aufrufen muss. Was sich nicht ändert, ist der Auslöser:stack-devs „invoke it now" ist weiterhin ein Satz, und diepublish-Notiz nennt den Skill bewusst nicht beim Namen. Zwei der drei Kettenglieder bleiben Selbstdisziplin. Der Schnitt verengt den Ausfall, er schließt ihn nicht — undstack-closesagt das seit 4.6.1 selbst.Der Code-Hebel, umgesetzt in 4.6.0:
tools/wikitool publishdruckt nach der Erfolgsmeldung eine Zeile, sobald das Changesettools/,types/,instructions/,AGENTS.mdoder einCONTRACT.mdberührt. Harness- und instanzneutral, ohne Erwähnung eines Trackers (git_publish.touches_stack_machinery, vier Tests). Am eigenen Block-2-Publish live beobachtet.F — Konventionen für den Issue-Body als Planvorlage. Umgesetzt in 4.5.1.
issue-tracking.mdSchritt 1 trägt beide Regeln: destruktive Schritte tragen ihre Invariante; ein Akzeptanzkriterium ist eine prüfbare Eigenschaft, keine Tätigkeit.G — Autorität von Body gegenüber Kommentaren, Lesesicht. Umgesetzt in 4.5.1.
issue-tracking.mdSchritt 2 trägt drei Klauseln: Body schlägt Kommentar; ein erkennbar veralteter Body wird richtiggestellt, nicht umgangen; widersprüchliche Kommentare werden nach Beleg aufgelöst, nicht nach Datum. Platziert als Fortsetzung von Schritt 2 statt als neuer Schritt, damit die Querverweise auf feste Schrittnummern nicht brechen.Umsetzung: drei Blöcke, alle abgeschlossen
Block 1 —
issue-tracking.md, gemeinsam mit #29.4.5.1, Commit87a47cc. F, G und #29s Rename-Absatz in einem Bump. F in Schritt 1, G in Schritt 2, der Rename-Absatz als neuer##-Abschnitt nach Schritt 7 plus Trigger in „When to run" — bewusst ohne neue nummerierte Schritte, damit die harten Querverweise (stack-dev→ Schritt 7,kb/concepts/Issue Label Scheme.md→ Schritt 2) gültig bleiben. Verifiziert:docs verify,instructions verify,pytest(963 passed).Block 2 — der Skill-Schnitt (C + D + E).
4.6.0, Commitsd34924dund91bd430. Neuer Skillstack-close;stack-devendet am Publish; Schritt 3 nach C neu formuliert;claude-code-model-selection.mdkorrigiert (die Zeile nannte „Schritte 3 und 6", Schritt 6 existiert nicht mehr);publish-Notiz mit vier Tests. Verifiziert:instructions sync(7 Skills),docs verify,instructions verify,pytest(967 passed). Nachtrag91bd430:DEVELOPMENT.mdbeschriebstack-devnoch als den Skill, der den Issue-Abschluss trägt — gefunden vonstack-closeSchritt 3 im ersten echten Lauf, ohne Bump korrigiert.Block 3 — die beiden Nebenbefunde plus drei Prosa-Korrekturen.
4.6.1, Commit72b2b44.DEVELOPMENT.mdindocs_verify.STAGE_READMES: ja. Das Gegenargument („die Liste führt nur ausgelieferte Dokumente") löst sich beim Hinsehen auf —check_readmes_have_no_command_tableüberspringt eine nicht existierende Datei, der Eintrag ist in einer ausgelieferten Instanz also wirkungslos und greift genau dort, wo die Datei existiert und driften kann. Zwei Tests, einer davon für den Instanz-Fall, an dem die Entscheidung hing.gitea-mcpnicht editieren kann und dessen Neuanlage die Tarball-Assets vernichten würde. Stattdessen eine Fußzeile inrelease.yml, die sagt, dass die Notiz ein Schnappschuss ist und wo die gepflegte Fassung liegt — aufv4.6.1live verifiziert. Inrelease.ymlstatt inversion notes, weil das Kommando ein allgemeiner Extraktor ist.4.6.0, gefunden bei einer Bewertung des eigenen Ergebnisses: der4.6.0-Eintrag und der Docstring behaupteten, das Prädikat prüfe „denselben Pfad-Umfang" wie CIs Versions-Gate — falsch, CI matcht[^/]+/CONTRACT\.md$, das Prädikat jede Tiefe. Folgenlos im Verhalten, aber eine behauptete Äquivalenz, die keine ist, geschrieben in genau der ungeprüften Phase, um die dieses Issue sich dreht. Docstring undtools/CONTRACT.mdbenennen die Differenz jetzt;stack-closenimmt die Überzeichnung seines eigenen Schnitts zurück (siehe E).Verifiziert für Block 3:
docs verify,instructions verify,pytest(969 passed),release.ymlgegen den YAML-Parser und das Heredoc als Trockenlauf. CI-Läufe 159 und 160 auf72b2b44grün, Releasev4.6.1getaggt.Akzeptanzkriterien
Block 1
issue-tracking.md: destruktive Schritte tragen ihre Invariante; Akzeptanzkriterien als prüfbare Eigenschaft (F).issue-tracking.md: Lesesicht ausgeschrieben — Vorrang des Bodys, Korrekturpflicht bei erkennbar veraltetem Body, widersprüchliche Kommentare nach Beleg (G).4.5.0→4.5.1gemeinsam mit #29s Regelabsatz.Block 2
stack-devSchritt 3 benennt die ungeprüften Prosa-Nester und die Test-Einschränkung (C).stack-devendet nach dem Publish mit einem Stop (E).claude-code-model-selection.mdund die beiden Skills widersprechen sich nicht mehr.publish-Schlussnotiz entschieden: ja, umgesetzt, mit Test, ohne Erwähnung eines Trackers.Block 3
DEVELOPMENT.mdindocs_verify.STAGE_READMESaufgenommen, mit zwei Tests.DEVELOPMENT.mdentfernt (4.4.1-beta.1).Handover: welches Modell welche Phase
stack-closebisher benutzt hat, ist die, die ihn geschrieben hat. Das ist Selbst-Test, kein Beweis: die Belegbasis für das Problem sind zwei Sitzungen, die für die Lösung ist null. Der erste echte Datenpunkt ist eine kalte Sitzung, die den Skill nicht geschrieben hat.Vorgeschichte
Die zwei Breakpoints stammen aus 4.3.3 (2026-09-03). Die Lücke fiel beim ersten vollen Durchlauf danach auf (#42,
4.4.0, derselbe Tag); der nachgeholte Prosa-Durchgang ist als 4.4.1-beta.1 dokumentiert. Am 2026-09-04 trat bei #30 (4.5.0-beta.1bis-beta.3) derselbe verschluckte Schritt-6-Break ein zweites Mal auf; derselbe Durchgang lieferte die beiden neuen Befunde und den Nebenbefund zu den Release-Notes. Die Triage-Sitzung desselben Tages trug die Belege #10 und #23 nach und schärfte Vorschlag G. Vorschlag E stammt vom Betreiber (2026-09-04) und wurde am selben Tag entschieden. Alle drei Blöcke gingen am 2026-09-04 hinaus:4.5.1(87a47cc),4.6.0(d34924d,91bd430),4.6.1(72b2b44).stack-dev: die ungepruefte Prosa zwischen den beiden Model-Switch-Breaks faellt durchto Steuerung der ungeprueften Phasen: Model-Switch-Breaks, Issue-Body als Plan, Kommentar-HistorieChangelog: Body auf den erweiterten Stand umgeschrieben, Titel entsprechend gefasst — das Issue trägt jetzt die Steuerung der ungeprüften Phasen insgesamt, nicht nur die Prosa-Lücke zwischen den Breaks.
Neu aufgenommen, alles belegt aus der #30-Sitzung vom 2026-09-04:
shutil.rmtreeund damit der datenvernichtende Fehler. Konsequenz ist nicht mehr Anweisung, sondern: destruktive Schritte tragen die Invariante, die sie nicht verletzen dürfen (Vorschlag F).verify, plus eigenes Demo-Repo). Vorschlag G.CHANGES.mderreicht die veröffentlichte Release-Seite nie — beiv4.4.0real eingetreten.gitea-mcpkennt kein Release-Edit, und Delete+Recreate würde die angehängten Tarball-Assets vernichten, auf dieINSTALL.md/version checkzeigen; Korrektur daher heute nur im Web-UI.Empfehlung im Body: C + D + F + G jetzt (alles wenige Sätze Text), E als Betreiberentscheidung, weil es als einziges die Struktur ändert und als einziges den zweimal verschluckten Break tatsächlich erzwingen würde.
Re-Labelling:
size/S→size/M. Auslöser ist der gewachsene Zuschnitt: aus einer Skill-Textänderung sind zwei Instructions (stack-dev,issue-tracking.md), zwei offene Entscheidungen (E,STAGE_READMES) und eine Konventionsänderung für Issue-Bodies geworden.prio/plannedundkind/defectbleiben.Re-Labelling:
prio/planned→prio/blocking(Triage-Sitzung 2026-09-04, Betreiberentscheidung).Begründung, nicht still: dieses Issue repariert die Regeln, unter denen jede folgende Sitzung an diesem Stack arbeitet. Solange es offen ist, zahlt jede Bau-Sitzung denselben Preis weiter — zweimal dokumentiert, beide Male mit echtem Fund im nachgeholten Durchgang (ein doppelt ausgelieferter Faktenfehler bei #42, zwei datenvernichtende Codefehler bei #30). Das ist die Definition von
prio/blocking: es beschädigt laufende Arbeit, nicht irgendwann, sondern in der jeweils nächsten Sitzung.area/process,kind/defect,size/Munverändert.Als Nächstes, gemeinsam mit #29 als ein Block. Beides ist Issue- und Instruction-Hygiene, beides ist die ungeprüfte Sorte Prosa-Arbeit, und beide schreiben in
instructions/dev/issue-tracking.md— #47 die Vorschläge F und G, #29 den Satz über Renames als Nachbedingung für offene Issues. Drei Änderungen in derselben Datei getrennt zu bumpen wäre Verschwendung.Belege für Befund 2, in dieser Sitzung nachgetragen und behoben:
total_count: 0bei abgeschlossenem Lauf), 342 erklärt es vier Tage später für erfüllt, ohne die Gegenprobe. Eine Sitzung, die 342 für den aktuellen Stand hält, hakt ein Kriterium ab, das nie geprüft wurde. Im Body jetzt zugunsten von 318 aufgelöst._WIKITOOL_ENV-Auszug ohneCHEMENU_ROOT. Eine kalte Sitzung konnte den Block gegenconftest.pyhalten und daraus schließen, der Eintrag fehle noch — also die falsche Aufgabe ableiten statt der eigentlichen (der Test, der die Vollständigkeit erzwingt).Beide stützen die Empfehlung G aus dem Body und schärfen sie: der Satz für die Lesesicht darf nicht nur sagen „Body schlägt Kommentar", sondern muss auch sagen, was zu tun ist, wenn der Body erkennbar veraltet ist — nämlich ihn richtigstellen, bevor gearbeitet wird, nicht sich auf die Kommentare stützen. Sonst löst die Regel den Widerspruch zugunsten eines Textes auf, der falsch ist.
Changelog: Vorschlag E entschieden, Body entsprechend umgeschrieben (Design-Sitzung 2026-09-04, vor der Übergabe an Sonnet).
model:-Override wird ignoriert), ein frischer Subagent bekommt ein eigenes Modell, aber keinen Sitzungskontext. Die Kombination, die E braucht, existiert nicht. Dazu zwei Gründe, die auch bei anderer Harness-Lage gälten: der Input der Schlussphase ist das Sitzungswissen, undAgent/model:gibt es nur in einem von vier unterstützten Harnesses, währendstack-devauch nach.agents/skills/publiziert wird.publishläuft exakt an der Phasengrenze und könnte dort eine harness-neutrale Schlussnotiz ausgeben — kein Gate, aber Werkzeugausgabe statt Prosa, und ohne ein Wort über einen Tracker (§ „What no tool checks" bleibt unberührt).Labels unverändert:
area/process,kind/defect,prio/blocking,size/M.kind/decisionwäre falsch — die Entscheidung ist gefallen, offen ist Bauarbeit.Changelog: Block 1 umgesetzt und veröffentlicht als 4.5.1 (Commit
87a47cc), Body entsprechend umgeschrieben.instructions/dev/issue-tracking.md- F in Schritt 1, G in Schritt 2, beide als Fortsetzung des bestehenden Listenelements statt als neuer nummerierter Schritt, damit die Querverweise auf feste Schrittnummern ausstack-dev/SKILL.md(→ Schritt 7) undkb/concepts/Issue Label Scheme.md(→ Schritt 2) nicht brechen.docs verify,instructions verify,pytest(963 passed) - alle grün, alle vor dem Publish gelaufen.STAGE_READMES, Release-Notes, sowie #29s Pfad-Durchgang - der war nie Teil des Auftrags für diesen Block).Labels unverändert:
area/process,kind/defect,prio/blocking,size/M.Changelog: Block 2 umgesetzt und veröffentlicht als 4.6.0 (Commits
d34924d,91bd430), Body entsprechend umgeschrieben.stack-closeist ein neuer dev-only Skill;stack-devendet nach Schritt 5 mit Stop statt Schritt 6.tools/wikitool publishdruckt jetzt eine Stack-Machinery-Notiz an der Phasengrenze, geprüft gegen denselben Pfad-Umfang wie CIs eigener Versions-Gate. Vier neue Tests. Am eigenen Block-2-Publish live beobachtet - die Notiz erschien unaufgefordert.stack-closeselbst gefunden, wasstack-closeSchritt 3 finden sollte:DEVELOPMENT.mdbeschriebstack-devnoch als den Skill, der Issue-Abschluss trägt - stale seit diesem Block. Korrigiert, separater Commit91bd430, kein Bump (Datei liegt außerhalb des CI-Versions-Gate-Pfadmusters).Re-Labelling:
prio/blocking→prio/planned. Der Grund fürblockingwar, dass jede folgende Stack-Sitzung denselben verschluckten Break riskierte - das strukturelle Risiko ist mit dem Skill-Schnitt behoben. Was bleibt (Block 3:STAGE_READMES, Release-Notes) sind zwei Entscheidungen ohne laufenden Schaden, keinprio/blockingmehr wert.area/process,kind/defect,size/Munverändert.Changelog: Block 3 umgesetzt als 4.6.1 (Commit
72b2b44), Body auf den Endstand geschrieben, Issue geschlossen.DEVELOPMENT.mdgehört indocs_verify.STAGE_READMES— das Gegenargument löst sich auf, weil der Check eine nicht existierende Datei überspringt, der Eintrag in einer ausgelieferten Instanz also wirkungslos ist. Zwei Tests, einer davon genau für diesen Instanz-Fall. Release-Notes bleiben ein Schnappschuss, sagen es aber jetzt selbst: Fußzeile inrelease.yml, aufv4.6.1live verifiziert.4.6.0, gefunden bei einer Bewertung des eigenen Ergebnisses: die behauptete Äquivalenz zwischentouches_stack_machineryund CIs Versions-Gate war keine (CI matcht eine Pfadebene, das Prädikat jede Tiefe), undstack-closehat seinen eigenen Schnitt zu stark beschrieben. Beides korrigiert — die zweite Korrektur nimmt eine Aussage zurück, die dieses Issue selbst produziert hat.stack-closebenutzt hat, ist die, die ihn geschrieben hat), und dass ein siebtes Skill-Description-Budget bewusst gebucht wurde.Was aus diesem Issue heraus offen bleibt, steht in #21 (nachgetragene Frage, wie der
stack-dev/stack-close-Schnitt für Harnesses ohne Modellwahl zu lesen ist). Der erste echte Test des Schnitts ist eine kalte Sitzung — der ist nicht planbar, nur abzuwarten.Nachtrag zum Handover, nicht zur Entscheidung. Der hier vermisste Wirksamkeitsbeleg liegt vor — die Sitzung vom 2026-09-04 zu #43/#48/#49 (
4.7.0=3916cb9,4.7.1=24593c5) war die erste kalte Sitzung, diestack-closebenutzt hat, ohne ihn geschrieben zu haben.Ergebnis geteilt: Vorschlag E hat gehalten —
stack-devendete am Publish, diepublish-Notiz kam,stack-closewurde aufgerufen, und die Schlussphase fand zwei echte Lücken, die kein Check fängt (dielint-Zeile intools/CONTRACT.md; diexref remove-Falle beim neuen Befund, deren naheliegende Reparatur die spezifische Kante mitgelöscht hätte). Beides als4.7.1nachgezogen.Der Modellwechsel hat nicht stattgefunden, zweimal angeboten, null mal vollzogen — nicht aus Disziplinlosigkeit, sondern weil beide Breaks ausdrücklich nicht blockieren und es damit keinen Moment gibt, in dem eine Antwort erwartet wird. Das ist als #50 aufgemacht; dieses Issue bleibt geschlossen, seine Entscheidungen A–G werden dort nicht wieder aufgemacht.