stack-dev/stack-close skill split; publish stack-machinery note; model-selection fix (#47 Block 2)

Files changed:
- CHANGES.md
- VERSION
- instructions/claude-code-model-selection.md
- instructions/dev/stack-close/SKILL.md
- instructions/dev/stack-dev/SKILL.md
- tools/CONTRACT.md
- tools/chemenu/commands/git_publish.py
- tools/chemenu/tests/test_git_publish.py

CHANGES.md

@@ -35,6 +35,73 @@ dev-checkout concern - readable here, never shipped as something to parse.
 
 ---
 
+## 4.6.0 - 2026-09-04 - stack-dev/stack-close skill split, publish stack-machinery note, model-selection fix (#47 Block 2)
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+- stack-dev/stack-close skill split, publish stack-machinery note, model-selection fix (#47 Block 2)
+<!-- /wikitool:bumps -->
+
+Block 2 aus #47 (Vorschlag E, am 2026-09-04 entschieden): die ungeprüfte Schlussphase einer
+Stack-Sitzung - Issue-Body-Rewrite, `docs/`-Veralterung, Changelog-Prosa - hatte bisher keinen
+eigenen Haltepunkt, sondern einen Prosa-Break in `stack-dev` Schritt 6. Der ist zweimal
+hintereinander verschluckt worden (#42, #30), beide Male mit echtem Fund im nachgeholten
+Durchgang. Ein dritter Prosa-Haltepunkt hätte dieselbe Wette verloren, die
+`docs/why-gates-are-code.md` für Gates schon verliert - also keine Prosa-Lösung mehr, sondern ein
+struktureller Schnitt.
+
+**Neuer Skill `stack-close`**, dev-only wie `stack-dev`. `stack-dev` endet nach `tools/wikitool
+publish` mit einem Stop statt mit einem sechsten Schritt; die Schlussphase existiert nur noch als
+eigener Skill, den eine Sitzung aufrufen muss - es gibt keinen „nächsten Schritt" mehr, an dem
+vorbei sie rutschen könnte. `stack-close` trägt drei Dinge: den Modell-Rückwechsel-Hinweis (wie
+zuvor), die Body-Rewrite-Disziplin aus `issue-tracking.md` Schritte 2-3 und 7, und neu die
+**Handover-Pflicht über die ganze Sitzung**: benannt wird das Modell für Design/Versionsstelle
+(Schritt 3), für die mechanische Mitte, und für diese Schlussphase - alle drei, auch wenn sie
+identisch sind. Eine Handover-Zeile, die nur eine billige Schlussphase meldet, schweigt genau
+dann, wenn die ebenso ungeprüfte Design-Phase auch billig lief und niemand dort gewechselt hat.
+
+Ein Agenten-Zuschnitt (Schlussphase als eigener Subagent mit eigenem Modell) wurde geprüft und
+verworfen: ein Fork erbt in Claude Code zwingend das Elternmodell, ein frischer Subagent den
+Sitzungskontext nicht - die Kombination, die der Zuschnitt bräuchte, gibt es nicht, und selbst
+wenn: der Input der Schlussphase *ist* das akkumulierte Sitzungswissen, das ein kalter Agent aus
+Diff und Issue neu ableiten müsste. Volle Begründung im Body von #47.
+
+**`instructions/claude-code-model-selection.md` korrigiert**, im dist-strip-Block: die
+Übersicht „stack-dev Schritt 3 und 6" ist falsch geworden, seit Schritt 6 nicht mehr existiert.
+Sie benennt jetzt beide Haltepunkte an ihrem tatsächlichen Ort - Schritt 3 in `stack-dev`,
+der zweite am Anfang von `stack-close`.
+
+**`stack-dev` Schritt 3 ehrlicher formuliert** (Vorschlag C): nicht mehr „ab hier alles
+mechanisch", sondern mit benannter Ausnahme - Changelog-Prosa (Schritt 4), eine berührte
+`docs/`-Seite, neue Menschendoku, der Prosa-Anteil einer Instruction. Dazu die Einschränkung aus
+#30: „durch Tests abgedeckt" gilt nur für das, was die Tests *treffen* - zwei
+datenvernichtende Bugs in `upstream merge` liefen an einem grünen `pytest`/`docs
+verify`/`instructions verify`/CI vorbei, weil kein Test den Fall traf, nicht weil ein
+schwächeres Modell schlechteren Code für den getesteten Fall geschrieben hätte.
+
+**Neu: `tools/wikitool publish` selbst erinnert an die Phasengrenze.** Berührt das Changeset
+`tools/`, `types/`, `instructions/`, `AGENTS.md` oder ein `<stage>/CONTRACT.md` - derselbe
+Umfang, den ein Versions-Bump selbst abdeckt -, druckt `publish` nach der Erfolgsmeldung eine
+Zeile, dass die folgende Phase von keinem der drei Checks abgedeckt ist. Kein Gate, keine
+Änderung am Exit-Code, für eine gewöhnliche Content-Publish stumm; harness- und
+instanzneutral formuliert, ohne jede Erwähnung eines Trackers, weil `publish` von jedem
+Skill genutzt wird, nicht nur von `stack-dev`. `git_publish.touches_stack_machinery()` plus
+vier neue Tests (`test_git_publish.py`): zwei für die reine Klassifikationsfunktion
+(positiv/negativ), zwei Integrationstests gegen einen echten Publish - die Notiz erscheint genau
+einmal bei einer `instructions/`-Änderung und bleibt aus bei einer gewöhnlichen `kb/`-Änderung.
+`tools/CONTRACT.md`s `publish`-Zeile trägt die Kurzfassung, absichtlich ohne den Dateinamen
+`version-parts.md` zu nennen - die Datei liegt unter `instructions/dev/` und würde in einer
+ausgelieferten Instanz ins Leere zeigen, während `tools/CONTRACT.md` selbst ausgeliefert wird.
+
+Verifiziert: `tools/wikitool instructions sync` (7 Skills, `stack-close` neu), `tools/wikitool
+docs verify`, `tools/wikitool instructions verify`, `.venv/bin/python -m pytest -q` (967
+passed, 4 davon neu).
+
+#47 bleibt offen für Block 3 (`DEVELOPMENT.md` in `STAGE_READMES`, veraltete Release-Notes).
+
+---
+
 ## 4.5.1 - 2026-09-04 - issue-tracking - destructive-step invariants, comment-vs-body authority, rename sweep
 
 **Author:** Torben Nehmer