Erledigt. Ausgeliefert in 8.0.0-beta.24, Commit d8224ee; Docs-Nachzug aus dem Abschluss als c0f324f. Geprüft lokal mit docs verify, instructions verify, pytest (2059 passed, 3 skipped) und in CI: #499 und #500 auf d8224ee, #501 auf c0f324f, alle grün. #50 ist mit diesem Issue geschlossen. Der Abschluss lief bereits nach dem neuen stack-close.
Befund
Der bisherige Ablauf hatte zwei Skills, aber drei Phasen, und koppelte Phasenwechsel an Modellwechsel innerhalb einer Session:
stack-dev umfasste Design und Bau. Schritt 3 bot am Übergang /model sonnet an.
stack-close umfasste CI-Warten, Issue-Abschluss, docs/-Staleness und Handover. Schritt 1 bot /model opus an.
Das hielt aus drei Gründen nicht:
Der Modellwechsel mitten in der Session fand nicht statt.#50 hat vier Angebote in zwei kalten Sessions dokumentiert und null Wechsel.
Er ist auch nicht wünschenswert. Ein Wechsel verwirft den Prompt-Cache. Sonnet ist auf 200k Kontext beschränkt, und die Bauphase läuft dort reproduzierbar über (#151 B).
CI-Warten saß in der falschen Phase. Ein roter Lauf machte die Abschlussphase wieder zur Bauphase.
Dazu blieb der Issue-Body in der Praxis bis stack-close unverändert, weil den Skills feste Stellen für die Pflege fehlten.
Lösung (umgesetzt)
Skill und Session sind getrennt. Die Phasen übergeben über Zustände im Tracker; jeder Phasenwechsel geht in derselben Session oder nach /clear, das Modell wird pro Session gewählt. Die Phasentabelle steht in instructions/dev/stack-mode.md § The three phases.
Phase
Skill
Aufruf
Endet mit (Übergabepunkt)
Was einen Fehler fängt
1 Design/Triage
stack-dev
automatisch und /stack-dev
Body ist ready
nichts
2 Bau
stack-build (neu)
nur/stack-build #N
grüner CI-Lauf auf dem publizierten Commit, Body aktuell
pytest, docs verify, instructions verify, CI
3 Abschluss
stack-close
nur/stack-close
Body im Endzustand, Issue geschlossen
nichts
Entscheidungen
stack-dev bleibt der Einstieg und ist jetzt der Design-Skill (Mode-Wechsel, Triage von status/incoming, Auffrischen einer Spec, Fehleranalyse). Die Trigger-Beschreibung bleibt, ergänzt um Triage/Ausarbeitung.
stack-build und stack-close tragen disable-model-invocation: true. Phase 1 endet mit einer festen Zeile, die /stack-build #N nennt; Phase 2 mit einer, die /stack-close nennt. Das Risiko aus #47, den Abschluss zu vergessen, liegt damit beim Betreiber; zweites Signal bleiben die Publish-Notiz und ein offenes Issue mit abgehakten Kriterien und grünem CI. Die Sperre gilt nur in Claude Code (bestätigt: nach dem Sync bot der Harness nur noch stack-dev als aufrufbar an); für Codex, Copilot und Vibe bleibt die Prosa.
Session-Schnitt 1 → 2: lange Design-Session → /clear + /stack-build #N; kurze → direkt weiter.
Session-Schnitt 2 → 3: Bau auf Opus/high → Abschluss in derselben Session; sonst /clear und neue Session auf Opus/high, die aus Body und Diff arbeitet.
Modell in Phase 2: bewusst offen gelassen; die Antwort liefern die Handover-Tabellen der geschlossenen Pakete (Kandidaten: Opus/high Standard, Opus/medium bei size/S, Sonnet/high nur mit Schnitt vor Phase 3). docs/model-and-effort-selection.md führt die Zeile als „Opus (open)“.
/effort mitten in der Session: Laut Anthropics Doku zum Prompt-Caching invalidiert jede Änderung des Effort-Werts immer den Message-Cache (Tools/System je nach Modell). Also gilt dieselbe Regel wie bei Sonnet: Opus/medium (Bau) → Opus/high (Abschluss) wird vor Phase 3 geschnitten, nicht umgeschaltet. Steht in docs/model-and-effort-selection.md § Model per session, not per phase.
Abschluss immer auf Opus/high.
Gemeinsame Teile sind eigene Instruktionen (Invariante 8):
instructions/dev/stack-mode.md: Mode-Regeln, Phasentabelle, Katalog der Dev-Verfahren (vorher stack-dev Schritt 2), Modell pro Session
instructions/dev/publish-and-ci.md: lokale Checks, publish, CI-Warten (MCP statt curl, ~4/5 Min., Abbruch nach 15 Min., Schleife bricht beim ersten Fehler ab), roter Lauf = zurück in den Bau
Definition „ready“ (Übergabe 1 → 2)
Steht in instructions/dev/issue-tracking.md § Ready to build. Beim Bau gegenüber dem Design erweitert:
vierter Punkt: die betroffenen Dateien/Oberflächen sind benannt (verlangt issue-tracking.md Schritt 1 ohnehin)
eine nicht blockierende offene Frage darf bleiben, wenn sie so markiert ist und die Folge beider Antworten nennt – so sah #168 selbst aus, als es als ready galt
Body-Pflege in Phase 2 (feste Stellen)
stack-build Schritt 3 (Abweichung → sofort in den Body) und Schritt 6 (nach dem Publish: Kriterien, Version, Commit; CI grün: Lauf nennen), plus ein Changelog-Kommentar pro Session; Verweis auf issue-tracking.md Schritt 2/3 statt Wiederholung.
stack-close (Abweichung von der Design-Fassung)
Schritt 1 prüft die Übergabe (grünes CI im Body, sonst zurück zu /stack-build) und nennt einmal, falls nicht Opus/high, ohne Wechsel anzubieten. Schritt 2 prüft den Endzustand des Bodys. Schritt 3 Staleness, ein eigener Nachzug mit Bump + publish-and-ci.md. Geschlossen wird erst in Schritt 4, nach dem Handover im Schließkommentar – nicht in Schritt 2, weil ein Nachzug in Schritt 3 noch publizieren und auf CI warten kann. Genau das ist beim Abschluss dieses Issues passiert (c0f324f, #501).
Erweitertes Handover (stack-close Schritt 4)
Tabelle pro Phase: Modell, Effort, eigene Session ja/nein, Kontext übergelaufen/kompaktiert ja/nein; dazu size/.
instructions/dev/issue-tracking.md (§ Ready to build)
tools/chemenu/commands/git_publish.py (STACK_MACHINERY_NOTE: „CI on the pushed commit is the last mechanical check still to come…“) + test_git_publish.py; test_instructions_cmd.py (drei Skills, Flag nur auf build/close)
docs/model-and-effort-selection.md – im Abschluss nachgezogen (c0f324f): der Satz über die Handover-Tabellen der Work Packages beschreibt nur dieses Repo und steht jetzt in einem dist:strip-Block, dazu ein Zeilenumbruch
Patch-Bump → 8.0.0-beta.24 (der Docs-Nachzug liegt außerhalb des Versions-Gates und brauchte keinen)
Akzeptanzkriterien
Drei Skills existieren. stack-build und stack-close tragen in Quelle und in den publizierten Kopien unter .claude/skills/ und .agents/skills/disable-model-invocation: true; stack-dev trägt es nicht (Test test_only_the_operator_starts_the_build_and_close_phases, Drift-Check in instructions verify)
Kein Skill und keine Instruktion fordert noch einen /model-Wechsel innerhalb einer Session (Grep unter instructions/: nur Treffer, die einen Wechsel ausschließen)
Kein Skill-Text weist den Agenten an, stack-build oder stack-close selbst aufzurufen; die Übergänge nennen das Slash-Kommando für den Betreiber
Die Definition „ready“ steht an genau einer Stelle; stack-dev verweist am Ende darauf, stack-build prüft sie als ersten Schritt
Das CI-Warteverfahren steht an genau einer Stelle; stack-close enthält es nicht mehr, sondern verweist nur noch für den Fall eines eigenen Docs-Nachzugs darauf
Die Mode-Regeln stehen an genau einer Stelle und sind von allen drei Skills verlinkt
stack-build nennt die drei festen Stellen der Body-Pflege und verlinkt issue-tracking.md Schritt 2, ohne die Regel zu wiederholen
stack-close Schritt 4 verlangt Modell, Effort, Session-Grenze und Überlauf pro Phase sowie size/
STACK_MACHINERY_NOTE behauptet nicht mehr, dass direkt nach dem Publish die ungeprüfte Phase beginnt; der Test ist angepasst (test_stack_machinery_note_puts_ci_before_the_unchecked_phase)
docs/model-and-effort-selection.md beschreibt die Modellwahl pro Session und nennt Sonnet nicht mehr als Standard für die Bauphase
Alle oben gelisteten Verweise nennen die drei Skills richtig (Grep nach stack-dev/stack-close außerhalb von instructions/dev/stack-* geprüft; Code-Kommentare, die nur „dist export prunes the stack-dev skill“ sagen, bleiben – weiterhin wahr)
docs verify, instructions verify, pytest und CI sind grün (lokal vor jedem Publish; CI #499/#500 auf d8224ee, #501 auf c0f324f)
Sitzungen 2026-10-02: Design mit Betreiber und Opus 5.5 in eigener Sitzung; Bau und Abschluss gemeinsam in einer zweiten Sitzung auf Opus 5.5 (Handover-Tabelle im Schließkommentar)
## Stand
**Erledigt.** Ausgeliefert in `8.0.0-beta.24`, Commit `d8224ee`; Docs-Nachzug aus dem Abschluss als `c0f324f`. Geprüft lokal mit `docs verify`, `instructions verify`, `pytest` (2059 passed, 3 skipped) und in CI: [#499](https://gitea.nehmer.net/torben/chemenu/actions/runs/499) und [#500](https://gitea.nehmer.net/torben/chemenu/actions/runs/500) auf `d8224ee`, [#501](https://gitea.nehmer.net/torben/chemenu/actions/runs/501) auf `c0f324f`, alle grün. #50 ist mit diesem Issue geschlossen. Der Abschluss lief bereits nach dem neuen `stack-close`.
## Befund
Der bisherige Ablauf hatte zwei Skills, aber drei Phasen, und koppelte Phasenwechsel an Modellwechsel *innerhalb* einer Session:
- `stack-dev` umfasste Design **und** Bau. Schritt 3 bot am Übergang `/model sonnet` an.
- `stack-close` umfasste CI-Warten, Issue-Abschluss, `docs/`-Staleness und Handover. Schritt 1 bot `/model opus` an.
Das hielt aus drei Gründen nicht:
1. **Der Modellwechsel mitten in der Session fand nicht statt.** #50 hat vier Angebote in zwei kalten Sessions dokumentiert und null Wechsel.
2. **Er ist auch nicht wünschenswert.** Ein Wechsel verwirft den Prompt-Cache. Sonnet ist auf 200k Kontext beschränkt, und die Bauphase läuft dort reproduzierbar über (#151 B).
3. **CI-Warten saß in der falschen Phase.** Ein roter Lauf machte die Abschlussphase wieder zur Bauphase.
Dazu blieb der Issue-Body in der Praxis bis `stack-close` unverändert, weil den Skills feste Stellen für die Pflege fehlten.
## Lösung (umgesetzt)
**Skill und Session sind getrennt.** Die Phasen übergeben über **Zustände im Tracker**; jeder Phasenwechsel geht in derselben Session oder nach `/clear`, das Modell wird pro Session gewählt. Die Phasentabelle steht in `instructions/dev/stack-mode.md` § The three phases.
| Phase | Skill | Aufruf | Endet mit (Übergabepunkt) | Was einen Fehler fängt |
|---|---|---|---|---|
| 1 Design/Triage | `stack-dev` | automatisch und `/stack-dev` | Body ist **ready** | nichts |
| 2 Bau | `stack-build` (neu) | **nur** `/stack-build #N` | **grüner CI-Lauf** auf dem publizierten Commit, Body aktuell | pytest, `docs verify`, `instructions verify`, CI |
| 3 Abschluss | `stack-close` | **nur** `/stack-close` | Body im Endzustand, Issue geschlossen | nichts |
### Entscheidungen
- **`stack-dev` bleibt der Einstieg und ist jetzt der Design-Skill** (Mode-Wechsel, Triage von `status/incoming`, Auffrischen einer Spec, Fehleranalyse). Die Trigger-Beschreibung bleibt, ergänzt um Triage/Ausarbeitung.
- **`stack-build` und `stack-close` tragen `disable-model-invocation: true`.** Phase 1 endet mit einer festen Zeile, die `/stack-build #N` nennt; Phase 2 mit einer, die `/stack-close` nennt. Das Risiko aus #47, den Abschluss zu vergessen, liegt damit beim Betreiber; zweites Signal bleiben die Publish-Notiz und ein offenes Issue mit abgehakten Kriterien und grünem CI. Die Sperre gilt nur in Claude Code (bestätigt: nach dem Sync bot der Harness nur noch `stack-dev` als aufrufbar an); für Codex, Copilot und Vibe bleibt die Prosa.
- **Session-Schnitt 1 → 2:** lange Design-Session → `/clear` + `/stack-build #N`; kurze → direkt weiter.
- **Session-Schnitt 2 → 3:** Bau auf Opus/high → Abschluss in derselben Session; sonst `/clear` und neue Session auf Opus/high, die aus Body und Diff arbeitet.
- **Modell in Phase 2:** bewusst offen gelassen; die Antwort liefern die Handover-Tabellen der geschlossenen Pakete (Kandidaten: Opus/high Standard, Opus/medium bei `size/S`, Sonnet/high nur mit Schnitt vor Phase 3). `docs/model-and-effort-selection.md` führt die Zeile als „Opus (open)“.
- **`/effort` mitten in der Session:** Laut Anthropics Doku zum Prompt-Caching invalidiert jede Änderung des Effort-Werts immer den Message-Cache (Tools/System je nach Modell). Also gilt dieselbe Regel wie bei Sonnet: Opus/medium (Bau) → Opus/high (Abschluss) wird vor Phase 3 geschnitten, nicht umgeschaltet. Steht in `docs/model-and-effort-selection.md` § Model per session, not per phase.
- **Abschluss immer auf Opus/high.**
- **Gemeinsame Teile sind eigene Instruktionen** (Invariante 8):
- `instructions/dev/stack-mode.md`: Mode-Regeln, Phasentabelle, Katalog der Dev-Verfahren (vorher `stack-dev` Schritt 2), Modell pro Session
- `instructions/dev/publish-and-ci.md`: lokale Checks, `publish`, CI-Warten (MCP statt `curl`, ~4/5 Min., Abbruch nach 15 Min., Schleife bricht beim ersten Fehler ab), roter Lauf = zurück in den Bau
### Definition „ready“ (Übergabe 1 → 2)
Steht in `instructions/dev/issue-tracking.md` § Ready to build. **Beim Bau gegenüber dem Design erweitert:**
- vierter Punkt: die betroffenen Dateien/Oberflächen sind benannt (verlangt `issue-tracking.md` Schritt 1 ohnehin)
- eine **nicht blockierende** offene Frage darf bleiben, wenn sie so markiert ist und die Folge beider Antworten nennt – so sah #168 selbst aus, als es als ready galt
### Body-Pflege in Phase 2 (feste Stellen)
`stack-build` Schritt 3 (Abweichung → sofort in den Body) und Schritt 6 (nach dem Publish: Kriterien, Version, Commit; CI grün: Lauf nennen), plus ein Changelog-Kommentar pro Session; Verweis auf `issue-tracking.md` Schritt 2/3 statt Wiederholung.
### `stack-close` (Abweichung von der Design-Fassung)
Schritt 1 prüft die Übergabe (grünes CI im Body, sonst zurück zu `/stack-build`) und nennt einmal, falls nicht Opus/high, ohne Wechsel anzubieten. Schritt 2 prüft den Endzustand des Bodys. Schritt 3 Staleness, ein eigener Nachzug mit Bump + `publish-and-ci.md`. **Geschlossen wird erst in Schritt 4**, nach dem Handover im Schließkommentar – nicht in Schritt 2, weil ein Nachzug in Schritt 3 noch publizieren und auf CI warten kann. Genau das ist beim Abschluss dieses Issues passiert (`c0f324f`, #501).
### Erweitertes Handover (`stack-close` Schritt 4)
Tabelle pro Phase: Modell, Effort, eigene Session ja/nein, Kontext übergelaufen/kompaktiert ja/nein; dazu `size/`.
## Betroffene Dateien
- `instructions/dev/stack-dev/SKILL.md`, `stack-build/SKILL.md` (neu), `stack-close/SKILL.md`
- `instructions/dev/stack-mode.md`, `instructions/dev/publish-and-ci.md` (neu)
- `instructions/dev/issue-tracking.md` (§ Ready to build)
- `tools/chemenu/commands/git_publish.py` (`STACK_MACHINERY_NOTE`: „CI on the pushed commit is the last mechanical check still to come…“) + `test_git_publish.py`; `test_instructions_cmd.py` (drei Skills, Flag nur auf build/close)
- `docs/model-and-effort-selection.md` – im Abschluss nachgezogen (`c0f324f`): der Satz über die Handover-Tabellen der Work Packages beschreibt nur dieses Repo und steht jetzt in einem `dist:strip`-Block, dazu ein Zeilenumbruch
- Verweise: `instructions/CONTRACT.md`, `doc-pull-through.md`, `version-parts.md`, `testing-conventions.md`, `dev-setup.md`, `commonplace-kb.md`, `DEVELOPMENT.md`, `AGENTS.md` § Developing this stack, `README.md`
- Patch-Bump → `8.0.0-beta.24` (der Docs-Nachzug liegt außerhalb des Versions-Gates und brauchte keinen)
## Akzeptanzkriterien
- [x] Drei Skills existieren. `stack-build` und `stack-close` tragen in Quelle **und** in den publizierten Kopien unter `.claude/skills/` und `.agents/skills/` `disable-model-invocation: true`; `stack-dev` trägt es nicht (Test `test_only_the_operator_starts_the_build_and_close_phases`, Drift-Check in `instructions verify`)
- [x] Kein Skill und keine Instruktion fordert noch einen `/model`-Wechsel innerhalb einer Session (Grep unter `instructions/`: nur Treffer, die einen Wechsel ausschließen)
- [x] Kein Skill-Text weist den Agenten an, `stack-build` oder `stack-close` selbst aufzurufen; die Übergänge nennen das Slash-Kommando für den Betreiber
- [x] Die Definition „ready“ steht an genau einer Stelle; `stack-dev` verweist am Ende darauf, `stack-build` prüft sie als ersten Schritt
- [x] Das CI-Warteverfahren steht an genau einer Stelle; `stack-close` enthält es nicht mehr, sondern verweist nur noch für den Fall eines eigenen Docs-Nachzugs darauf
- [x] Die Mode-Regeln stehen an genau einer Stelle und sind von allen drei Skills verlinkt
- [x] `stack-build` nennt die drei festen Stellen der Body-Pflege und verlinkt `issue-tracking.md` Schritt 2, ohne die Regel zu wiederholen
- [x] `stack-close` Schritt 4 verlangt Modell, Effort, Session-Grenze und Überlauf pro Phase sowie `size/`
- [x] `STACK_MACHINERY_NOTE` behauptet nicht mehr, dass direkt nach dem Publish die ungeprüfte Phase beginnt; der Test ist angepasst (`test_stack_machinery_note_puts_ci_before_the_unchecked_phase`)
- [x] `docs/model-and-effort-selection.md` beschreibt die Modellwahl pro Session und nennt Sonnet nicht mehr als Standard für die Bauphase
- [x] Alle oben gelisteten Verweise nennen die drei Skills richtig (Grep nach `stack-dev`/`stack-close` außerhalb von `instructions/dev/stack-*` geprüft; Code-Kommentare, die nur „`dist export` prunes the `stack-dev` skill“ sagen, bleiben – weiterhin wahr)
- [x] `docs verify`, `instructions verify`, `pytest` und CI sind grün (lokal vor jedem Publish; CI #499/#500 auf `d8224ee`, #501 auf `c0f324f`)
- [x] #50 ist mit Verweis auf dieses Issue geschlossen
## Vorgeschichte
- **#47:** der Skill-Schnitt `stack-dev`/`stack-close`
- **#50:** der Modellwechsel-Break hält nicht an; durch dieses Issue entschieden und mit ihm geschlossen
- **#151 B:** Sonnet-Kontext übergelaufen
- **Sitzungen 2026-10-02:** Design mit Betreiber und Opus 5.5 in eigener Sitzung; Bau und Abschluss gemeinsam in einer zweiten Sitzung auf Opus 5.5 (Handover-Tabelle im Schließkommentar)
Changelog (Bau-Session): Gebaut und publiziert als 8.0.0-beta.24 (d8224ee), CI #499/#500 grün, #50 geschlossen; alle Kriterien abgehakt. Abweichungen vom Design: „ready“ um benannte Dateien und markierte nicht blockierende Fragen erweitert; stack-close schließt erst in Schritt 4 statt 2. Offene Frage zu /effort geklärt (invalidiert den Message-Cache → Schnitt vor Phase 3), Abschnitt „Offen“ entfällt. Neu: Abschnitt „Stand“.
**Changelog (Bau-Session):** Gebaut und publiziert als `8.0.0-beta.24` (`d8224ee`), CI #499/#500 grün, #50 geschlossen; alle Kriterien abgehakt. Abweichungen vom Design: „ready“ um benannte Dateien und markierte nicht blockierende Fragen erweitert; `stack-close` schließt erst in Schritt 4 statt 2. Offene Frage zu `/effort` geklärt (invalidiert den Message-Cache → Schnitt vor Phase 3), Abschnitt „Offen“ entfällt. Neu: Abschnitt „Stand“.
Changelog (Abschluss): Body in den Endzustand gebracht: „Stand“ auf erledigt; Docs-Nachzug c0f324f mit CI #501 aufgenommen. Der Nachzug verschiebt in docs/model-and-effort-selection.md einen Satz, der nur dieses Repo beschreibt, in einen dist:strip-Block. Weitere Prüfung auf veraltete Prosa ohne Befund: tools/CONTRACT.md beschreibt die Publish-Notiz nicht, README.md/DEVELOPMENT.md/AGENTS.md sind im Bau nachgezogen, und es wurde keine Installationsinstruktion berührt.
Handover
Phase
Modell
Effort
Eigene Session?
Kontext übergelaufen/kompaktiert?
1 Design (stack-dev)
Opus 5.5
unbekannt (nicht im Record)
ja
unbekannt (nicht im Record)
2 Bau (stack-build, lief noch nach altem stack-dev-Text)
Opus 5.5
als Stufe für die Session nicht sichtbar
nein – mit Phase 3 geteilt, nach /clear getrennt von Phase 1
nein
3 Abschluss (stack-close)
Opus 5.5
als Stufe für die Session nicht sichtbar
nein – mit Phase 2 geteilt
nein
size/M. Für die offene Modellfrage in Phase 2 ist das der erste Datenpunkt: Ein size/M-Bau auf Opus hielt einschließlich Abschluss ohne Kompaktierung in einer Sitzung. Die Effort-Spalte bleibt so lange eine Lücke, bis die Sitzung ihre Stufe sieht; sonst muss der Betreiber sie nachtragen.
**Changelog (Abschluss):** Body in den Endzustand gebracht: „Stand“ auf erledigt; Docs-Nachzug `c0f324f` mit CI #501 aufgenommen. Der Nachzug verschiebt in `docs/model-and-effort-selection.md` einen Satz, der nur dieses Repo beschreibt, in einen `dist:strip`-Block. Weitere Prüfung auf veraltete Prosa ohne Befund: `tools/CONTRACT.md` beschreibt die Publish-Notiz nicht, `README.md`/`DEVELOPMENT.md`/`AGENTS.md` sind im Bau nachgezogen, und es wurde keine Installationsinstruktion berührt.
**Handover**
| Phase | Modell | Effort | Eigene Session? | Kontext übergelaufen/kompaktiert? |
|---|---|---|---|---|
| 1 Design (`stack-dev`) | Opus 5.5 | unbekannt (nicht im Record) | ja | unbekannt (nicht im Record) |
| 2 Bau (`stack-build`, lief noch nach altem `stack-dev`-Text) | Opus 5.5 | als Stufe für die Session nicht sichtbar | nein – mit Phase 3 geteilt, nach `/clear` getrennt von Phase 1 | nein |
| 3 Abschluss (`stack-close`) | Opus 5.5 | als Stufe für die Session nicht sichtbar | nein – mit Phase 2 geteilt | nein |
`size/M`. Für die offene Modellfrage in Phase 2 ist das der erste Datenpunkt: Ein `size/M`-Bau auf Opus hielt einschließlich Abschluss ohne Kompaktierung in einer Sitzung. Die Effort-Spalte bleibt so lange eine Lücke, bis die Sitzung ihre Stufe sieht; sonst muss der Betreiber sie nachtragen.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Stand
Erledigt. Ausgeliefert in
8.0.0-beta.24, Commitd8224ee; Docs-Nachzug aus dem Abschluss alsc0f324f. Geprüft lokal mitdocs verify,instructions verify,pytest(2059 passed, 3 skipped) und in CI: #499 und #500 aufd8224ee, #501 aufc0f324f, alle grün. #50 ist mit diesem Issue geschlossen. Der Abschluss lief bereits nach dem neuenstack-close.Befund
Der bisherige Ablauf hatte zwei Skills, aber drei Phasen, und koppelte Phasenwechsel an Modellwechsel innerhalb einer Session:
stack-devumfasste Design und Bau. Schritt 3 bot am Übergang/model sonnetan.stack-closeumfasste CI-Warten, Issue-Abschluss,docs/-Staleness und Handover. Schritt 1 bot/model opusan.Das hielt aus drei Gründen nicht:
Dazu blieb der Issue-Body in der Praxis bis
stack-closeunverändert, weil den Skills feste Stellen für die Pflege fehlten.Lösung (umgesetzt)
Skill und Session sind getrennt. Die Phasen übergeben über Zustände im Tracker; jeder Phasenwechsel geht in derselben Session oder nach
/clear, das Modell wird pro Session gewählt. Die Phasentabelle steht ininstructions/dev/stack-mode.md§ The three phases.stack-dev/stack-devstack-build(neu)/stack-build #Ndocs verify,instructions verify, CIstack-close/stack-closeEntscheidungen
stack-devbleibt der Einstieg und ist jetzt der Design-Skill (Mode-Wechsel, Triage vonstatus/incoming, Auffrischen einer Spec, Fehleranalyse). Die Trigger-Beschreibung bleibt, ergänzt um Triage/Ausarbeitung.stack-buildundstack-closetragendisable-model-invocation: true. Phase 1 endet mit einer festen Zeile, die/stack-build #Nnennt; Phase 2 mit einer, die/stack-closenennt. Das Risiko aus #47, den Abschluss zu vergessen, liegt damit beim Betreiber; zweites Signal bleiben die Publish-Notiz und ein offenes Issue mit abgehakten Kriterien und grünem CI. Die Sperre gilt nur in Claude Code (bestätigt: nach dem Sync bot der Harness nur nochstack-devals aufrufbar an); für Codex, Copilot und Vibe bleibt die Prosa./clear+/stack-build #N; kurze → direkt weiter./clearund neue Session auf Opus/high, die aus Body und Diff arbeitet.size/S, Sonnet/high nur mit Schnitt vor Phase 3).docs/model-and-effort-selection.mdführt die Zeile als „Opus (open)“./effortmitten in der Session: Laut Anthropics Doku zum Prompt-Caching invalidiert jede Änderung des Effort-Werts immer den Message-Cache (Tools/System je nach Modell). Also gilt dieselbe Regel wie bei Sonnet: Opus/medium (Bau) → Opus/high (Abschluss) wird vor Phase 3 geschnitten, nicht umgeschaltet. Steht indocs/model-and-effort-selection.md§ Model per session, not per phase.instructions/dev/stack-mode.md: Mode-Regeln, Phasentabelle, Katalog der Dev-Verfahren (vorherstack-devSchritt 2), Modell pro Sessioninstructions/dev/publish-and-ci.md: lokale Checks,publish, CI-Warten (MCP stattcurl, ~4/5 Min., Abbruch nach 15 Min., Schleife bricht beim ersten Fehler ab), roter Lauf = zurück in den BauDefinition „ready“ (Übergabe 1 → 2)
Steht in
instructions/dev/issue-tracking.md§ Ready to build. Beim Bau gegenüber dem Design erweitert:issue-tracking.mdSchritt 1 ohnehin)Body-Pflege in Phase 2 (feste Stellen)
stack-buildSchritt 3 (Abweichung → sofort in den Body) und Schritt 6 (nach dem Publish: Kriterien, Version, Commit; CI grün: Lauf nennen), plus ein Changelog-Kommentar pro Session; Verweis aufissue-tracking.mdSchritt 2/3 statt Wiederholung.stack-close(Abweichung von der Design-Fassung)Schritt 1 prüft die Übergabe (grünes CI im Body, sonst zurück zu
/stack-build) und nennt einmal, falls nicht Opus/high, ohne Wechsel anzubieten. Schritt 2 prüft den Endzustand des Bodys. Schritt 3 Staleness, ein eigener Nachzug mit Bump +publish-and-ci.md. Geschlossen wird erst in Schritt 4, nach dem Handover im Schließkommentar – nicht in Schritt 2, weil ein Nachzug in Schritt 3 noch publizieren und auf CI warten kann. Genau das ist beim Abschluss dieses Issues passiert (c0f324f, #501).Erweitertes Handover (
stack-closeSchritt 4)Tabelle pro Phase: Modell, Effort, eigene Session ja/nein, Kontext übergelaufen/kompaktiert ja/nein; dazu
size/.Betroffene Dateien
instructions/dev/stack-dev/SKILL.md,stack-build/SKILL.md(neu),stack-close/SKILL.mdinstructions/dev/stack-mode.md,instructions/dev/publish-and-ci.md(neu)instructions/dev/issue-tracking.md(§ Ready to build)tools/chemenu/commands/git_publish.py(STACK_MACHINERY_NOTE: „CI on the pushed commit is the last mechanical check still to come…“) +test_git_publish.py;test_instructions_cmd.py(drei Skills, Flag nur auf build/close)docs/model-and-effort-selection.md– im Abschluss nachgezogen (c0f324f): der Satz über die Handover-Tabellen der Work Packages beschreibt nur dieses Repo und steht jetzt in einemdist:strip-Block, dazu ein Zeilenumbruchinstructions/CONTRACT.md,doc-pull-through.md,version-parts.md,testing-conventions.md,dev-setup.md,commonplace-kb.md,DEVELOPMENT.md,AGENTS.md§ Developing this stack,README.md8.0.0-beta.24(der Docs-Nachzug liegt außerhalb des Versions-Gates und brauchte keinen)Akzeptanzkriterien
stack-buildundstack-closetragen in Quelle und in den publizierten Kopien unter.claude/skills/und.agents/skills/disable-model-invocation: true;stack-devträgt es nicht (Testtest_only_the_operator_starts_the_build_and_close_phases, Drift-Check ininstructions verify)/model-Wechsel innerhalb einer Session (Grep unterinstructions/: nur Treffer, die einen Wechsel ausschließen)stack-buildoderstack-closeselbst aufzurufen; die Übergänge nennen das Slash-Kommando für den Betreiberstack-devverweist am Ende darauf,stack-buildprüft sie als ersten Schrittstack-closeenthält es nicht mehr, sondern verweist nur noch für den Fall eines eigenen Docs-Nachzugs daraufstack-buildnennt die drei festen Stellen der Body-Pflege und verlinktissue-tracking.mdSchritt 2, ohne die Regel zu wiederholenstack-closeSchritt 4 verlangt Modell, Effort, Session-Grenze und Überlauf pro Phase sowiesize/STACK_MACHINERY_NOTEbehauptet nicht mehr, dass direkt nach dem Publish die ungeprüfte Phase beginnt; der Test ist angepasst (test_stack_machinery_note_puts_ci_before_the_unchecked_phase)docs/model-and-effort-selection.mdbeschreibt die Modellwahl pro Session und nennt Sonnet nicht mehr als Standard für die Bauphasestack-dev/stack-closeaußerhalb voninstructions/dev/stack-*geprüft; Code-Kommentare, die nur „dist exportprunes thestack-devskill“ sagen, bleiben – weiterhin wahr)docs verify,instructions verify,pytestund CI sind grün (lokal vor jedem Publish; CI #499/#500 aufd8224ee, #501 aufc0f324f)Vorgeschichte
stack-dev/stack-closeChangelog (Bau-Session): Gebaut und publiziert als
8.0.0-beta.24(d8224ee), CI #499/#500 grün, #50 geschlossen; alle Kriterien abgehakt. Abweichungen vom Design: „ready“ um benannte Dateien und markierte nicht blockierende Fragen erweitert;stack-closeschließt erst in Schritt 4 statt 2. Offene Frage zu/effortgeklärt (invalidiert den Message-Cache → Schnitt vor Phase 3), Abschnitt „Offen“ entfällt. Neu: Abschnitt „Stand“.Changelog (Abschluss): Body in den Endzustand gebracht: „Stand“ auf erledigt; Docs-Nachzug
c0f324fmit CI #501 aufgenommen. Der Nachzug verschiebt indocs/model-and-effort-selection.mdeinen Satz, der nur dieses Repo beschreibt, in einendist:strip-Block. Weitere Prüfung auf veraltete Prosa ohne Befund:tools/CONTRACT.mdbeschreibt die Publish-Notiz nicht,README.md/DEVELOPMENT.md/AGENTS.mdsind im Bau nachgezogen, und es wurde keine Installationsinstruktion berührt.Handover
stack-dev)stack-build, lief noch nach altemstack-dev-Text)/cleargetrennt von Phase 1stack-close)size/M. Für die offene Modellfrage in Phase 2 ist das der erste Datenpunkt: Einsize/M-Bau auf Opus hielt einschließlich Abschluss ohne Kompaktierung in einer Sitzung. Die Effort-Spalte bleibt so lange eine Lücke, bis die Sitzung ihre Stufe sieht; sonst muss der Betreiber sie nachtragen.