Der Modellwechsel-Break hält nicht an - er ist konstruktionsbedingt eine Mitteilung, keine Entscheidungsstelle #50
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-devSchritt 3 undstack-closeSchritt 1 bieten je einen Modellwechsel an. Beide sind ausdrücklich nicht blockierend formuliert:Damit ist der Break strukturell keine Entscheidungsstelle, sondern eine Zeile im Ausgabestrom. Die Sitzung spricht das Angebot aus und arbeitet in derselben Antwort weiter. Der Betreiber müsste in genau diesem Moment mitlesen und mit Ctrl+C unterbrechen, damit ein Wechsel überhaupt zustande kommt. Passiert das nicht — der Normalfall —, ist der Punkt vorbei, bevor jemand ihn als Punkt wahrnehmen konnte.
Ein Angebot, das niemand annehmen kann, ohne die laufende Ausführung abzubrechen, ist kein Angebot.
Beleg: die erste kalte Sitzung, die
stack-closebenutzt hat#47 hat sich das selbst ins Handover geschrieben:
Die Sitzung vom 2026-09-04 zu #43/#48/#49 (Auslieferung
4.7.0/4.7.1) war dieser Datenpunkt. Das Ergebnis ist geteilt, und beide Hälften gehören ins Protokoll:Was gehalten hat — der Skill-Schnitt aus #47 Vorschlag E.
stack-devendete am Publish, diepublish-Notiz kam,stack-closewurde aufgerufen, die Schlussphase lief vollständig. Sie hat dabei zwei echte Lücken gefunden, die kein Check fängt: dielint-Zeile intools/CONTRACT.md, die den neuen Befund nicht kannte, und — schwerwiegender — dass die naheliegende Reparatur des neuen Lint-Befundsxref removegewesen wäre, das beidseitig abräumt und die spezifische Kante mitgelöscht hätte. Beides ist als4.7.1nachgezogen worden. Der Schnitt funktioniert.Was nicht gehalten hat — der Wechsel selbst. Beide Breaks wurden wörtlich ausgesprochen. Gewechselt wurde nie, und zwar nicht, weil der Betreiber abgelehnt hätte, sondern weil es keinen Moment gab, in dem eine Antwort erwartet wurde. Alle drei Phasen liefen auf Opus.
Die gemessene Fehlerkosten dieser Sitzung sind gering und zeigen die Asymmetrie. Design- und Schlussphase liefen auf dem richtigen Modell — zufällig, weil der Betreiber die Sitzung dort gestartet hatte. Bezahlt wurde nur die mechanische Mitte (Katalog-Prosa, zwei Contracts, Lint-Code, sechs Tests, Bump) auf dem teureren Modell. Der umgekehrte Fall ist der teure, und er ist genauso wahrscheinlich: eine auf Sonnet gestartete Sitzung durchläuft Design und Abschluss auf dem billigen Modell, weil derselbe Break in beide Richtungen nicht anhält — und genau das sind die beiden Phasen, für die
claude-code-model-selection.md„nothing, by construction" als Absicherung notiert.Zweiter Beleg: Sitzung zu #81, 2026-09-10 — erste kalte Sitzung nach Anlage dieses Issues
Anders als der erste Beleg oben (der noch am Gründungstag dieses Issues entstand und die Ausgangslage belegt) ist dies die erste Sitzung, die auf
stack-devlief, nachdem #50 bereits offen auf dem Board stand — also der Test, ob das Wissen um den Befund allein etwas ändert.Gegenstand war #81 (CLAUDE.md-Importkette). Ablauf:
/model sonnetbei Efforthigh."AGENTS.md/CLAUDE.md/USER.md/SOUL.md-Edits, neuedocs/-Seite, Versionsbump,pytest, Publish) lief auf demselben Modell wie die Designphase — kein Wechsel fand statt.stack-close(dieser Kommentar) läuft ebenfalls auf demselben Modell.Alle drei Phasen liefen auf Opus. Zweiter Datenpunkt, gleiches Ergebnis wie der erste: Angebot ausgesprochen, Wechsel null Mal — diesmal sogar mit einer inhaltlichen Antwort direkt im Anschluss an das Angebot, die es dennoch nicht aufgriff. Das stützt eher Weg 2 (Entscheidung an den Sitzungsanfang ziehen) als Weg 1 (
AskUserQuestion): der Betreiber hat hier nicht abgelehnt oder übersehen, sondern schlicht auf den fachlichen Teil der Antwort reagiert, weil der Modell-Absatz nicht als eigene, getrennte Frage im Raum stand.Kumulierter Stand: zwei kalte Sitzungen, zwei Angebote je Sitzung (wo beide Skills durchlaufen wurden) bzw. eines (wo nur
stack-devbis zum Publish lief), null Wechsel.Was zu entscheiden ist
Drei Wege, sie schließen sich aus.
1 — Einmal wirklich fragen, mit
AskUserQuestion. Claude Code hat einen blockierenden Frage-Mechanismus, den beide Skills nicht benutzen. Die genannte Begründung fürs Nicht-Blockieren („a session that argues about its own model") spricht gegen eine Debatte, nicht gegen eine einzelne Frage mit zwei Optionen. Kosten: ein Roundtrip pro Break, zweimal pro Sitzung. Einwand:AskUserQuestiongibt es nur in Claude Code, und beide Skills werden lokal auch nach.agents/skills/publiziert, wo Codex, Copilot und Vibe sie lesen — dieselbe Portabilitätsfrage, die in #47 den Agenten-Zuschnitt erledigt hat, hier aber schwächer, weil ein fehlender Mechanismus nur auf die heutige Prosa zurückfällt.2 — Die Entscheidung an den Sitzungsanfang ziehen. Der Wechsel ist mitten im Fluss teuer und am Anfang gratis:
/stack-devwird vom Betreiber aufgerufen, und da liest er. Der Skill würde eröffnen mit „diese Sitzung hat die Phasen Design / Mechanik / Abschluss — Modell jetzt wählen", statt zweimal mittendrin etwas anzubieten. Verliert die Phasengenauigkeit, gewinnt eine Stelle, an der eine Entscheidung real möglich ist. Denkbar auch als Kombination mit 1: einmal fragen am Anfang, danach gar nicht mehr. Durch den zweiten Beleg oben leicht gestärkt: das Problem war hier nicht Unaufmerksamkeit, sondern dass der Break im Fließtext einer inhaltlichen Antwort unterging — ein Mechanismus, der vor jeder inhaltlichen Reaktion steht, umgeht genau das.3 — Akzeptieren und die Prosa ehrlich machen. Wenn der Wechsel praktisch nie stattfindet, sollen die Skills aufhören, ihn als Entscheidungsstelle zu beschreiben. Dann bleibt die Handover-Pflicht aus #47 Vorschlag D als das, was tatsächlich wirkt: die Nennung aller drei Phasen macht sichtbar, was gelaufen ist, ohne so zu tun, als hätte jemand steuern können. Das ist die Variante, die nichts baut und die bestehende Lage korrekt beschreibt — dieselbe Bewegung, die
stack-closein 4.6.1 mit seinem eigenen Schnitt schon gemacht hat.Was hier ausdrücklich nicht wieder aufgemacht wird
Der Skill-Schnitt (#47 E), die Handover-Pflicht (D) und die ehrlichere Schritt-3-Formulierung (C) stehen und haben ihren ersten kalten Lauf bestanden. Dieses Issue betrifft allein das dritte Kettenglied, das #47 schon als verbleibende Selbstdisziplin benannt hatte — nur mit dem Zusatz, dass es keine Disziplinfrage ist: die Anweisung verbietet das Anhalten aktiv.
Akzeptanzkriterien
stack-devSchritt 3 undstack-closeSchritt 1 sagen dasselbe wiedocs/model-and-effort-selection.md(verschoben ausinstructions/claude-code-model-selection.mdin #81) — heute beschreiben alle drei einen Wechsel, den keiner ermöglichtstack-dev-Sitzung als Beleg im Body nachgetragen — hat der Wechsel stattgefunden, ja oder nein (Sitzung zu #81, 2026-09-10: nein, zweiter Datenpunkt oben)Vorgeschichte
Nachfolger von #47 (geschlossen 2026-09-04), das die zwei Breakpoints aus 4.3.3 überarbeitet, den Skill-Schnitt gebaut und sich den fehlenden Wirksamkeitsbeleg selbst notiert hat. Der Beleg liegt jetzt zweifach vor: Sitzung vom 2026-09-04 zu #43/#48/#49, Auslieferung
4.7.0(3916cb9) und4.7.1(24593c5); Sitzung vom 2026-09-10 zu #81, Auslieferung5.0.0-beta.8(f8111d0). Angebot vier Mal ausgesprochen (zwei Sitzungen × bis zu zwei Breaks), Wechsel null mal.Changelog: Zweiten Beleg nachgetragen — Sitzung zu #81, 2026-09-10, die erste
stack-dev-Sitzung seit Anlage dieses Issues. Ergebnis identisch zum ersten Beleg: Angebot ausgesprochen, kein Wechsel, alle drei Phasen auf demselben Modell. Neu diesmal: der Betreiber reagierte direkt im Anschluss an das Angebot inhaltlich auf den Plan, ging aber nicht auf die Modellfrage ein — das stützt Weg 2 (Entscheidung an den Sitzungsanfang ziehen) leicht stärker als vorher. Akzeptanzkriterium 5 abgehakt; ein neues Kriterium 6 vermerkt, dass eine dritte Sitzung bestätigend, aber nicht mehr entscheidungsnotwendig wäre. Die Entscheidung zwischen den drei Wegen bleibt offen.