torben/chemenu
1
1 Fork 0
Code Issues 40 Pull Requests Actions Packages Releases 41 Wiki Activity

Ketten von Paketen: stack-dev schreibt ## Kette, stack-close nennt am Ende das nächste Glied #205

New Issue
Closed
opened 2026-10-09 21:38:25 +00:00 by torben · 3 comments
torben commented 2026-10-09 21:38:25 +00:00
Owner
Copy link
Copy source

Angelegt am 2026-10-09 in der Design-Sitzung zu #87/#200 (Stand 9.0.0, 7cfafd7). Auf Wunsch des Betreibers erinnert stack-close ihn immer an das nächste Paket. Erweitert am 2026-10-10: Damit das „immer“ trägt, muss auch stack-dev den Abschnitt immer schreiben. Gebaut und geschlossen am 2026-10-10.

Problem

Mehrere Pakete, die nacheinander gebaut werden sollen, verloren beim Schließen den Faden. stack-close endete mit dem Schließen (instructions/dev/stack-close/SKILL.md Schritt 4). Welches Issue als Nächstes dran war, stand höchstens in einem Body, den nach dem Schließen niemand mehr las. Die Erinnerung kann nur so zuverlässig sein wie der Abschnitt, den sie liest. Den schrieb keine Prozedur vor, die Kette „Beschaffung und Konfiguration“ war von Hand entstanden.

Entwurf (umgesetzt)

  1. Konvention in instructions/dev/issue-tracking.md: neuer Abschnitt § Chains (englisch). Ein Paket, das Teil einer geordneten Folge ist, trägt im Body einen Abschnitt mit der festen Überschrift ## Kette, in genau dieser Form, als letzter Abschnitt des Bodys: 
    ## Kette

Kette „<Name>“
- Vorgänger: #A        (oder: keiner - erstes Glied)
- Nachfolger: #C       (oder: keiner - letztes Glied)
    • Die Überschrift und die Zeilenanfänge sind zitiertes Vokabular und bleiben deutsch, wie die Bodies.
    • Keine Liste aller Glieder im Abschnitt: Eine eingefügte oder entfernte Kettenstelle berührt nur die zwei Nachbarn, nicht jeden Body der Kette. Die ganze Folge ergibt sich durch Ablaufen.
    • Die Reihenfolge ist eine Planungsentscheidung, keine Abhängigkeit: Eine echte Abhängigkeit trägt weiterhin status/blocked und steht im Body als Blocker. Die Zeile status/blocked in der Statustabelle verweist darauf.
  2. stack-dev schreibt den Abschnitt: Schritt 3 verlangt ## Kette bei mehr als einem geordneten Paket und das Nachziehen der Nachbarn beim Einfügen, Herausnehmen oder Umstellen (der Changelog-Kommentar nennt es). Schritt 5 prüft vor dem Ende der Phase bei jedem berührten Glied, dass Vorgänger und Nachfolger gegenseitig aufeinander zeigen.
  3. stack-close Schritt 5 nach dem Schließen liest ## Kette und gibt genau eine feste Schlusszeile aus: Nachfolger offen und bereit (kind/build, weder status/incoming noch status/unconfirmed) → /stack-build #M; offen, nicht bereit → /stack-dev #M; schon geschlossen → der Kette bis zum ersten offenen Glied folgen; kein offenes Glied → „Chain … is complete“; kein Abschnitt → keine Zeile. Abweichung vom ersten Entwurf: Die Schlusszeilen stehen in der Anweisung englisch, weil die Kontrollebene englisch ist; der Agent spricht sie in der KB-Sprache (AGENTS.md § File naming, wie bei den Schlusszeilen von stack-dev und stack-build). Zusätzlich ein Decision point: zeigt der Abschnitt auf einen Nachfolger, der nicht zurückzeigt, oder auf ein nicht existierendes Issue, nennt stack-close das statt eines geratenen Nachfolgers und überlässt die Reparatur /stack-dev.
  4. status/blocked am Nachfolger: Nennt der Body des Nachfolgers dieses Issue als einzigen offenen Blocker, nimmt stack-close dort status/blocked ab und kommentiert das (issue-tracking.md Schritt 6). Hat er weitere offene Blocker, bleibt das Label.
  5. Kein Skill startet die nächste Phase selbst, stack-close nennt sie nur - dieselbe Regel wie in instructions/dev/stack-mode.md § The three phases. Die Tabelle dort nennt für Phase 1 ## Kette und für Phase 3 das nächste Glied.

Betroffene Dateien

  • instructions/dev/issue-tracking.md: neuer Abschnitt § Chains, Eintrag in „When to run“, Hinweis in der Statustabelle, TOC per tools/wikitool docs toc --apply
  • instructions/dev/stack-dev/SKILL.md: Schritt 3 und Schritt 5
  • instructions/dev/stack-close/SKILL.md: Schritt 5 und eine Zeile unter Decision points
  • instructions/dev/stack-mode.md: Tabellenzeilen Phase 1 und 3
  • docs/dev/development.md § Stack development as a session type of its own: ein Halbsatz, dass stack-close das nächste Glied nennt (Nachzug in der Schließphase)
  • Generiert, nicht von Hand: .claude/skills/, .agents/skills/ per tools/wikitool instructions sync

Akzeptanzkriterien

  • issue-tracking.md beschreibt den Abschnitt ## Kette mit der festen Form aus Entwurf 1, ohne Liste aller Glieder, und grenzt Reihenfolge gegen status/blocked ab.
  • stack-dev/SKILL.md verlangt den Abschnitt bei mehr als einem geordneten Paket, das Nachziehen der Nachbarn beim Einfügen oder Entfernen und die gegenseitige Prüfung vor dem Ende der Phase.
  • stack-close/SKILL.md Schritt 5 nennt die fünf Fälle aus Entwurf 3 mit ihrer jeweiligen Schlusszeile und die Regel aus Entwurf 4.
  • instructions verify, docs verify und pytest sind grün (lokal: 2714 passed, 3 skipped); CI ist grün auf dem publizierten Commit: Läufe 639 (verify und pwsh) und 640 sind success.
  • Selbsttest: Die stack-close-Sitzung, die dieses Issue geschlossen hat, hat ## Kette gelesen, bei #206 die Rückverweisung (Vorgänger #205) und die Bereitschaft (kind/build, kein status/incoming/status/unconfirmed, kein status/blocked) geprüft und die Schlusszeile mit /stack-build #206 ausgegeben.

Versionsteil

--patch. instructions/dev/ wird von dist export nicht ausgeliefert. Eine Instanz merkt also nichts, und der Drop-in-Test gilt in beide Richtungen. Den Bump braucht es nur, weil der Version-Gate der CI auf instructions/ schaut. Der Nachzug in docs/dev/ liegt außerhalb dieses Gates und brauchte keinen eigenen Bump.

Stand

Abgeschlossen. Veröffentlicht als 9.0.1-beta.1 in 3c80262 (2026-10-10), --impact low im laufenden Kandidaten, verifiziert durch die CI-Läufe 639 und 640. Der Nachzug in docs/dev/development.md ging als 88788d6 hinaus. Vorher waren docs verify und instructions verify lokal grün, danach CI-Lauf 641 (verify und pwsh). Weitere docs/-Seiten, Contracts und Installationsanleitungen berührt die Änderung nicht. docs/explanation/model-and-effort-selection.md und docs/explanation/architecture.md nennen die drei Phasen nur, ohne Schlussverhalten.

Kette

Kette „Beschaffung und Konfiguration“

> Angelegt am 2026-10-09 in der Design-Sitzung zu #87/#200 (Stand `9.0.0`, `7cfafd7`). Auf Wunsch des Betreibers erinnert `stack-close` ihn immer an das nächste Paket. Erweitert am 2026-10-10: Damit das „immer“ trägt, muss auch `stack-dev` den Abschnitt immer schreiben. Gebaut und geschlossen am 2026-10-10. ## Problem Mehrere Pakete, die nacheinander gebaut werden sollen, verloren beim Schließen den Faden. `stack-close` endete mit dem Schließen (`instructions/dev/stack-close/SKILL.md` Schritt 4). Welches Issue als Nächstes dran war, stand höchstens in einem Body, den nach dem Schließen niemand mehr las. Die Erinnerung kann nur so zuverlässig sein wie der Abschnitt, den sie liest. Den schrieb keine Prozedur vor, die Kette „Beschaffung und Konfiguration“ war von Hand entstanden. ## Entwurf (umgesetzt) 1. **Konvention in `instructions/dev/issue-tracking.md`:** neuer Abschnitt § Chains (englisch). Ein Paket, das Teil einer geordneten Folge ist, trägt im Body einen Abschnitt mit der festen Überschrift `## Kette`, in genau dieser Form, als letzter Abschnitt des Bodys: ``` ## Kette Kette „<Name>“ - Vorgänger: #A (oder: keiner - erstes Glied) - Nachfolger: #C (oder: keiner - letztes Glied) ``` - Die Überschrift und die Zeilenanfänge sind zitiertes Vokabular und bleiben deutsch, wie die Bodies. - **Keine Liste aller Glieder** im Abschnitt: Eine eingefügte oder entfernte Kettenstelle berührt nur die zwei Nachbarn, nicht jeden Body der Kette. Die ganze Folge ergibt sich durch Ablaufen. - Die Reihenfolge ist eine Planungsentscheidung, keine Abhängigkeit: Eine echte Abhängigkeit trägt weiterhin `status/blocked` und steht im Body als Blocker. Die Zeile `status/blocked` in der Statustabelle verweist darauf. 2. **`stack-dev` schreibt den Abschnitt:** Schritt 3 verlangt `## Kette` bei mehr als einem geordneten Paket und das Nachziehen der Nachbarn beim Einfügen, Herausnehmen oder Umstellen (der Changelog-Kommentar nennt es). Schritt 5 prüft vor dem Ende der Phase bei jedem berührten Glied, dass Vorgänger und Nachfolger gegenseitig aufeinander zeigen. 3. **`stack-close` Schritt 5 nach dem Schließen** liest `## Kette` und gibt genau eine feste Schlusszeile aus: Nachfolger offen und bereit (`kind/build`, weder `status/incoming` noch `status/unconfirmed`) → `/stack-build #M`; offen, nicht bereit → `/stack-dev #M`; schon geschlossen → der Kette bis zum ersten offenen Glied folgen; kein offenes Glied → „Chain … is complete“; kein Abschnitt → keine Zeile. **Abweichung vom ersten Entwurf:** Die Schlusszeilen stehen in der Anweisung englisch, weil die Kontrollebene englisch ist; der Agent spricht sie in der KB-Sprache (`AGENTS.md` § File naming, wie bei den Schlusszeilen von `stack-dev` und `stack-build`). Zusätzlich ein Decision point: zeigt der Abschnitt auf einen Nachfolger, der nicht zurückzeigt, oder auf ein nicht existierendes Issue, nennt `stack-close` das statt eines geratenen Nachfolgers und überlässt die Reparatur `/stack-dev`. 4. **`status/blocked` am Nachfolger:** Nennt der Body des Nachfolgers dieses Issue als einzigen offenen Blocker, nimmt `stack-close` dort `status/blocked` ab und kommentiert das (`issue-tracking.md` Schritt 6). Hat er weitere offene Blocker, bleibt das Label. 5. **Kein Skill startet die nächste Phase selbst**, `stack-close` nennt sie nur - dieselbe Regel wie in `instructions/dev/stack-mode.md` § The three phases. Die Tabelle dort nennt für Phase 1 `## Kette` und für Phase 3 das nächste Glied. ## Betroffene Dateien - `instructions/dev/issue-tracking.md`: neuer Abschnitt § Chains, Eintrag in „When to run“, Hinweis in der Statustabelle, TOC per `tools/wikitool docs toc --apply` - `instructions/dev/stack-dev/SKILL.md`: Schritt 3 und Schritt 5 - `instructions/dev/stack-close/SKILL.md`: Schritt 5 und eine Zeile unter Decision points - `instructions/dev/stack-mode.md`: Tabellenzeilen Phase 1 und 3 - `docs/dev/development.md` § Stack development as a session type of its own: ein Halbsatz, dass `stack-close` das nächste Glied nennt (Nachzug in der Schließphase) - Generiert, nicht von Hand: `.claude/skills/`, `.agents/skills/` per `tools/wikitool instructions sync` ## Akzeptanzkriterien - [x] `issue-tracking.md` beschreibt den Abschnitt `## Kette` mit der festen Form aus Entwurf 1, ohne Liste aller Glieder, und grenzt Reihenfolge gegen `status/blocked` ab. - [x] `stack-dev/SKILL.md` verlangt den Abschnitt bei mehr als einem geordneten Paket, das Nachziehen der Nachbarn beim Einfügen oder Entfernen und die gegenseitige Prüfung vor dem Ende der Phase. - [x] `stack-close/SKILL.md` Schritt 5 nennt die fünf Fälle aus Entwurf 3 mit ihrer jeweiligen Schlusszeile und die Regel aus Entwurf 4. - [x] `instructions verify`, `docs verify` und `pytest` sind grün (lokal: 2714 passed, 3 skipped); CI ist grün auf dem publizierten Commit: Läufe 639 (`verify` und `pwsh`) und 640 sind `success`. - [x] **Selbsttest:** Die `stack-close`-Sitzung, die dieses Issue geschlossen hat, hat `## Kette` gelesen, bei #206 die Rückverweisung (Vorgänger #205) und die Bereitschaft (`kind/build`, kein `status/incoming`/`status/unconfirmed`, kein `status/blocked`) geprüft und die Schlusszeile mit `/stack-build #206` ausgegeben. ## Versionsteil **`--patch`.** `instructions/dev/` wird von `dist export` nicht ausgeliefert. Eine Instanz merkt also nichts, und der Drop-in-Test gilt in beide Richtungen. Den Bump braucht es nur, weil der Version-Gate der CI auf `instructions/` schaut. Der Nachzug in `docs/dev/` liegt außerhalb dieses Gates und brauchte keinen eigenen Bump. ## Stand Abgeschlossen. Veröffentlicht als `9.0.1-beta.1` in `3c80262` (2026-10-10), `--impact low` im laufenden Kandidaten, verifiziert durch die CI-Läufe 639 und 640. Der Nachzug in `docs/dev/development.md` ging als `88788d6` hinaus. Vorher waren `docs verify` und `instructions verify` lokal grün, danach CI-Lauf 641 (`verify` und `pwsh`). Weitere `docs/`-Seiten, Contracts und Installationsanleitungen berührt die Änderung nicht. `docs/explanation/model-and-effort-selection.md` und `docs/explanation/architecture.md` nennen die drei Phasen nur, ohne Schlussverhalten. ## Kette Kette „Beschaffung und Konfiguration“ - Vorgänger: keiner - erstes Glied - Nachfolger: #206
torben added the prio/plannedsize/Sarea/processkind/build labels 2026-10-09 21:38:25 +00:00
torben changed title from stack-close nennt am Ende das nächste Paket einer Kette to Ketten von Paketen: stack-dev schreibt `## Kette`, stack-close nennt am Ende das nächste Glied 2026-10-10 06:14:49 +00:00
torben commented 2026-10-10 06:18:11 +00:00
Author
Owner
Copy link
Copy source

Changelog: Erweitert (2026-10-10, Frage des Betreibers „weiß stack-dev auch davon?“): Auch stack-dev schreibt ## Kette und zieht beim Einfügen oder Entfernen die Nachbarn nach. Vor dem Ende der Phase prüft es, dass die Glieder gegenseitig aufeinander zeigen. Die Kettenzeile listet nicht mehr alle Glieder, damit ein Einfügen nur die zwei Nachbarn berührt. Anlass war das Einfügen von #210, das sonst acht Bodies berührt hätte. Titel angepasst.

**Changelog:** Erweitert (2026-10-10, Frage des Betreibers „weiß stack-dev auch davon?“): Auch `stack-dev` schreibt `## Kette` und zieht beim Einfügen oder Entfernen die Nachbarn nach. Vor dem Ende der Phase prüft es, dass die Glieder gegenseitig aufeinander zeigen. Die Kettenzeile listet nicht mehr alle Glieder, damit ein Einfügen nur die zwei Nachbarn berührt. Anlass war das Einfügen von #210, das sonst acht Bodies berührt hätte. Titel angepasst.
torben commented 2026-10-10 07:01:08 +00:00
Author
Owner
Copy link
Copy source

Changelog: Gebaut und als 9.0.1-beta.1 in 3c80262 veröffentlicht, CI-Läufe 639 und 640 grün. Drei Kriterien abgehakt, nur der Selbsttest beim Schließen ist offen. Abweichung vom Entwurf: Die Schlusszeilen stehen in der Anweisung englisch (Kontrollebene), der Agent spricht sie in der KB-Sprache. Neu gegenüber dem Entwurf: ein Decision point in stack-close für einen kaputten Kettenzeiger und ein Hinweis in der status/blocked-Zeile der Statustabelle.

**Changelog:** Gebaut und als `9.0.1-beta.1` in `3c80262` veröffentlicht, CI-Läufe 639 und 640 grün. Drei Kriterien abgehakt, nur der Selbsttest beim Schließen ist offen. Abweichung vom Entwurf: Die Schlusszeilen stehen in der Anweisung englisch (Kontrollebene), der Agent spricht sie in der KB-Sprache. Neu gegenüber dem Entwurf: ein Decision point in `stack-close` für einen kaputten Kettenzeiger und ein Hinweis in der `status/blocked`-Zeile der Statustabelle.
torben commented 2026-10-10 07:20:00 +00:00
Author
Owner
Copy link
Copy source

Changelog: Geschlossen (2026-10-10). Body im Endzustand, Selbsttest erfüllt: stack-close hat ## Kette gelesen und nennt #206 als nächstes Glied (bereit, also /stack-build #206). Nachgezogen wurde ein Halbsatz in docs/dev/development.md (88788d6, CI-Lauf 641 grün). Sonst ist keine docs/-Seite und kein Contract veraltet.

**Changelog:** Geschlossen (2026-10-10). Body im Endzustand, Selbsttest erfüllt: `stack-close` hat `## Kette` gelesen und nennt #206 als nächstes Glied (bereit, also `/stack-build #206`). Nachgezogen wurde ein Halbsatz in `docs/dev/development.md` (`88788d6`, CI-Lauf 641 grün). Sonst ist keine `docs/`-Seite und kein Contract veraltet.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
area/corpus
Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
 area/distribution
Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
 area/kb
Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
 area/process
Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
 area/workflow
Betrifft Git, Merge, Branching, Publish, PRs
 kind/build
Spezifiziert, wartet nur noch auf Umsetzungszeit
 kind/decision
Wartet auf eine Betreiberentscheidung
 kind/defect
Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich
 prio/blocking
Blockiert oder beschaedigt laufende Arbeit - als naechstes
 prio/planned
Traegt bald Zinsen - eingeplant
 prio/waiting
Sinnvoll, wartet auf einen Ausloeser
 size/L
Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
 size/M
Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
 size/S
Eine Sitzung, ein Publish, klar umrissener Schnitt
 status/blocked
Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
 status/incoming
Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden.
 status/unconfirmed
Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig
No labels area/process kind/build prio/planned size/S
Milestone
No items
No Milestone
Assignees
Clear assignees
torben
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#205