32 Releases 32 Tags

RSS Feed

• v4.3.3 b1883befc7

  Compare

  v4.3.3 Stable

  torben released this 2026-09-03 19:33:51 +00:00 | 73 commits to main since this release

  4.3.3 - 2026-09-03 - Modellwahl nach Pruefbarkeit statt nach Aufgabenname; stack-dev bricht an den Phasenwechseln fuer den Model-Switch

  Author: Torben Nehmer

  instructions/claude-code-model-selection.md routete bisher nach Skill: eine Zeile "Stack
  development -> Opus/high" fuer alles, was tools/, types/ oder instructions/ anfasst. Das ist
  zu grob in beide Richtungen - es verteuert die lange, mechanische Mitte einer Stack-Sitzung, und es
  sagt nichts darueber, dass Anfang und Ende derselben Sitzung anders zu behandeln sind.

  Die neue Achse ist "was faengt hier einen Fehler ab". Wo ein Check in Code steht - pytest,
  docs verify, instructions verify, CI, die Gates - kostet der Fehler eines schwaecheren Modells
  eine Runde und faellt auf. Wo die einzige Durchsetzung eine Sitzung ist, die Prosa liest, faellt
  derselbe Fehler gar nicht auf: er wird ausgeliefert und bleibt stehen. Das ist dasselbe Argument,
  das docs/why-gates-are-code.md fuer Gates fuehrt, angewandt auf die Modellwahl.

  Stack-Entwicklung ist damit nicht mehr eine Zeile, sondern drei:

  Phase	Was einen Fehler faengt	Modell
  Design, Versionsstelle, Grenzuebertritts-Urteil	nichts	Opus/high
  Code, Tests, mechanische Doku-Synchronisation	pytest, CI, docs verify	Sonnet/high
  Issue-Abschluss, docs/-Veralterung, Changelog-Prosa	nichts, per Konstruktion	Opus/high

  Die Mitte ist die lange Phase und die mit den Checks - dort liegt die Ersparnis. Die beiden
  Raender sind kurz (Minuten, nicht Stunden), haben aber keinen maschinellen Waechter: wikitool
  kennt den Issue-Tracker bewusst nicht, und eine docs/-Seite traegt keinen normativen Satz, also
  gibt es dort nichts zu verifizieren. Sie oben zu lassen ist billig und schuetzt genau die Arbeit,
  die still scheitert.

  Zwei Praezisierungen dazu: Effort ist der billigere Hebel als das Modell - medium steht fuer
  Stack-Arbeit bewusst in keiner Zeile, weil Mehrdatei-Konsistenz das ist, was ein reduzierter
  Effort zuerst aufgibt; high ist die Untergrenze, sobald mehr als eine Datei oder ein Contract
  betroffen ist. Und die Asymmetrie ist benannt: eine unnoetige Opus-Phase kostet einmal Geld, eine
  ungepruefte Sonnet-Phase kann etwas ausliefern, das nie wieder jemand ansieht.

  Damit die Tabelle ueberhaupt wirksam wird, braucht sie Haltepunkte. Eine Sitzung kann ihr
  eigenes Modell nicht wechseln - das ist /model und gehoert dem Nutzer. Eine Empfehlung, die
  niemand zum richtigen Zeitpunkt ausspricht, aendert nichts. instructions/dev/stack-dev/SKILL.md
  bekommt deshalb zwei ausdrueckliche Breaks:

  • Neuer Schritt 3 - "Settle the design before building", mit dem Angebot zum Wechsel nach
    unten, sobald der Plan steht und die Arbeit mechanisch wird. Einmal aussprechen, dann so oder
    so weiterarbeiten.
  • Schritt 6 (Abschluss) bricht in die Gegenrichtung - ab dort greift wieder kein Check. Mit
    der ausdruecklichen Auflage, die Arbeit unabhaengig von der Antwort zu tun: nach dem Publish
    auf einen Modellwechsel zu blockieren wuerde genau den Zustand hinterlassen, den Schritt 6
    verhindern soll. Lief die Phase auf dem billigeren Modell, gehoert das in die Uebergabe statt
    ins Schweigen.

  Ein auftauchender Grenzuebertritt ist unter den Decision points ebenfalls als Anlass zum Wechsel
  nach oben benannt: docs verify prueft, dass ein Uebertritt sich dokumentiert, nie dass die
  Stelle richtig gewaehlt war.

  Die uebrigen Schritte sind unveraendert und nur umnummeriert (alt 3-5 -> neu 4-6).

  Downloads

  • chemenu-stack-4.3.3.tar.gz
    476 KiB

    2026-09-03 19:33:51 +00:00
  • chemenu-stack-4.3.3.tar.gz.sha256
    93 B

    2026-09-03 19:33:51 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)