torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity

status/incoming: menschliche Stubs sind keine Work Packages und dürfen nicht so umgesetzt werden #62

New Issue
Closed
opened 2026-09-04 19:53:23 +00:00 by torben · 1 comment
torben commented 2026-09-04 19:53:23 +00:00
Owner
Copy Link
Copy Source

Erledigt in 4.7.5-beta.1, Commit 4ab358f.

Was das Problem war

Das Label status/incoming wurde am 2026-09-04 in Gitea angelegt ("Vom
Menschen angelegte Anforderung, unvollständig, muss durch den Stack
komplettiert werden"), und zwei Issues trugen es bereits: #60 und #61. Beide
sind zwei bis drei Sätze Prosa, ohne Akzeptanzkriterium, ohne die vier
Pflichtachsen, teils Vermutung statt Feststellung.

instructions/dev/issue-tracking.md beschrieb das Label nicht. Eine Sitzung,
die #60 aufnimmt, sieht ein offenes Issue mit einem Body — und der Body ist
nach Schritt 2 genau das, was eine Sitzung als Spec glaubt. Zusätzlich verlangt
Schritt 4 alle vier Pflichtlabel "always", was ein status/incoming-Issue
legitim verletzt, ohne dass irgendwo stand, dass das in Ordnung ist.

Was umgesetzt wurde

Reine Instruction-Änderung, kein Tool-Code. wikitool kennt den Tracker
weiterhin nicht und soll ihn nicht kennenlernen (§ "What no tool checks").

In instructions/dev/issue-tracking.md:

  • Neuer Abschnitt § Incoming stubs, nach dem Muster von § Renames — ein
    Ablauf, der nicht in den nummerierten Fluss gehört. Erster Satz ist das
    Verbot: "A status/incoming issue is never implemented as it stands."
    Darunter die Begründung (der Tracker ist auch der Eingang des Menschen; Stub
    und Schritt-1-Body haben unterschiedliche Eintrittskosten) und die
    Ausarbeitung als sechs Schritte: Wortlaut als Absichtserklärung lesen, gegen
    den Baum prüfen, Originaltext wörtlich in den Kommentar retten, bevor der
    Rewrite ihn überschreibt, offene Fragen benennen statt beantworten
    (kind/decision), erst dann Schritt 4, dann Flag entfernen. Zwei Ausgänge
    wie bei status/unconfirmed.
  • Schritt 5 hat die dritte Tabellenzeile und den Absatz dazu: dieses Flag
    setzt Schritt 4 aus, statt ihn zu qualifizieren — die vier Achsen fehlen
    nicht, sie sind noch nicht fällig. Außerdem das einzige Flag, das eine
    Sitzung nie selbst vergibt.
  • § When to run und § Decision points nennen den Fall je einmal; der
    Decision Point adressiert den gefährlichen Fall "sieht trivial umsetzbar aus".
  • § What no tool checks listet den implementierten Stub als vierten Fall,
    den nichts meldet.
  • Frontmatter description: nennt drei status/-Flags und das Verbot.

In instructions/dev/stack-dev/SKILL.md: die Routing-Zeile zu
issue-tracking.md nennt status/incoming als Ausnahme zu allem davor.

Entscheidungen

Kein neuer nummerierter Schritt. stack-close/SKILL.md (Zeile 69) und
mehrere CHANGES.md-Einträge verweisen namentlich auf "Schritte 2-3 und 7".
Eine Umnummerierung hätte diese Verweise still falsch gemacht — genau der
Zerfall, den dieselbe Datei in § Renames beschreibt. Die Prozedur bekam
stattdessen einen eigenen Abschnitt, was ohnehin die passendere Form ist: die
Ausarbeitung eines Stubs ist kein Schritt im gewöhnlichen Ablauf, sondern ein
davorliegender Vorgang.

PATCH, nicht MINOR. dist export schließt instructions/dev/ aus; eine
ausgelieferte Instanz sieht von der Änderung nichts. Nach
version-parts.md § Decision points ("The break only affects this repository")
ist das kein Stack-Break, und der Drop-in-Test ist trivial erfüllt.

Akzeptanzkriterien

  • status/incoming in Schritt 5s Tabelle, mit ausdrücklichem Absatz, dass
    die vier Pflichtlabel unter diesem Flag noch nicht fällig sind
  • Eigener Abschnitt mit der Prozedur, Verbot als erste Aussage
  • § When to run und § Decision points nennen den Fall je einmal
  • Schrittnummerierung 1-7 unverändert — verifiziert per
    grep -n "^[0-9]\. \*\*" instructions/dev/issue-tracking.md (Schritte auf
    Zeile 45/70/127/143/191/213/218) und
    grep -n "steps 2-3 and 7" instructions/dev/stack-close/SKILL.md
  • Frontmatter description: nennt drei status/-Flags
  • tools/wikitool instructions verify (20 Instructions, 7 Skills,
    14 publizierte Kopien identisch) und docs verify (50 Kommandos,
    CHANGES.md dokumentiert 4.7.5-beta.1) grün
  • tools/.venv/bin/python -m pytest -q: 976 passed
  • version bump --patch auf 4.7.5-beta.1, CHANGES.md-Eintrag mit Prosa

Nachgelagert

  • #63 — kb/concepts/Issue Label Scheme.md beschreibt weiter nur zwei
    status/-Flags und behauptet 16 Labels statt 17. kb/-Inhalt, braucht eine
    Quelle nach Invariante 3, also eine eigene wiki-manage-Sitzung.
  • #60 und #61 bleiben unausgearbeitet offen. Das ist die erste Anwendung
    der Regel, nicht ihre Einführung.

Nicht verifiziert

Der Nutzen der Regel selbst — dass eine Sitzung, die #60 aufnimmt, tatsächlich
ausarbeitet statt zu bauen. Nichts Maschinelles prüft das (§ What no tool
checks); der Beleg wäre die Ausarbeitung von #60/#61 und liegt außerhalb dieses
Pakets. Der Kandidat 4.7.5-beta.1 ist noch offen und nicht per
version release fixiert.

**Erledigt in `4.7.5-beta.1`, Commit `4ab358f`.** ## Was das Problem war Das Label `status/incoming` wurde am 2026-09-04 in Gitea angelegt ("Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden"), und zwei Issues trugen es bereits: #60 und #61. Beide sind zwei bis drei Sätze Prosa, ohne Akzeptanzkriterium, ohne die vier Pflichtachsen, teils Vermutung statt Feststellung. `instructions/dev/issue-tracking.md` beschrieb das Label nicht. Eine Sitzung, die #60 aufnimmt, sieht ein offenes Issue mit einem Body — und der Body ist nach Schritt 2 genau das, was eine Sitzung als Spec glaubt. Zusätzlich verlangt Schritt 4 alle vier Pflichtlabel "always", was ein `status/incoming`-Issue legitim verletzt, ohne dass irgendwo stand, dass das in Ordnung ist. ## Was umgesetzt wurde Reine Instruction-Änderung, kein Tool-Code. `wikitool` kennt den Tracker weiterhin nicht und soll ihn nicht kennenlernen (§ "What no tool checks"). In `instructions/dev/issue-tracking.md`: - **Neuer Abschnitt § Incoming stubs**, nach dem Muster von § Renames — ein Ablauf, der nicht in den nummerierten Fluss gehört. Erster Satz ist das Verbot: *"A `status/incoming` issue is never implemented as it stands."* Darunter die Begründung (der Tracker ist auch der Eingang des Menschen; Stub und Schritt-1-Body haben unterschiedliche Eintrittskosten) und die Ausarbeitung als sechs Schritte: Wortlaut als Absichtserklärung lesen, gegen den Baum prüfen, Originaltext wörtlich in den Kommentar retten, bevor der Rewrite ihn überschreibt, offene Fragen benennen statt beantworten (`kind/decision`), erst dann Schritt 4, dann Flag entfernen. Zwei Ausgänge wie bei `status/unconfirmed`. - **Schritt 5** hat die dritte Tabellenzeile und den Absatz dazu: dieses Flag *setzt Schritt 4 aus*, statt ihn zu qualifizieren — die vier Achsen fehlen nicht, sie sind noch nicht fällig. Außerdem das einzige Flag, das eine Sitzung nie selbst vergibt. - **§ When to run** und **§ Decision points** nennen den Fall je einmal; der Decision Point adressiert den gefährlichen Fall "sieht trivial umsetzbar aus". - **§ What no tool checks** listet den implementierten Stub als vierten Fall, den nichts meldet. - **Frontmatter `description:`** nennt drei `status/`-Flags und das Verbot. In `instructions/dev/stack-dev/SKILL.md`: die Routing-Zeile zu `issue-tracking.md` nennt `status/incoming` als Ausnahme zu allem davor. ## Entscheidungen **Kein neuer nummerierter Schritt.** `stack-close/SKILL.md` (Zeile 69) und mehrere `CHANGES.md`-Einträge verweisen namentlich auf "Schritte 2-3 und 7". Eine Umnummerierung hätte diese Verweise still falsch gemacht — genau der Zerfall, den dieselbe Datei in § Renames beschreibt. Die Prozedur bekam stattdessen einen eigenen Abschnitt, was ohnehin die passendere Form ist: die Ausarbeitung eines Stubs ist kein Schritt im gewöhnlichen Ablauf, sondern ein davorliegender Vorgang. **PATCH, nicht MINOR.** `dist export` schließt `instructions/dev/` aus; eine ausgelieferte Instanz sieht von der Änderung nichts. Nach `version-parts.md` § Decision points ("The break only affects this repository") ist das kein Stack-Break, und der Drop-in-Test ist trivial erfüllt. ## Akzeptanzkriterien - [x] `status/incoming` in Schritt 5s Tabelle, mit ausdrücklichem Absatz, dass die vier Pflichtlabel unter diesem Flag noch nicht fällig sind - [x] Eigener Abschnitt mit der Prozedur, Verbot als erste Aussage - [x] § When to run und § Decision points nennen den Fall je einmal - [x] Schrittnummerierung 1-7 unverändert — verifiziert per `grep -n "^[0-9]\. \*\*" instructions/dev/issue-tracking.md` (Schritte auf Zeile 45/70/127/143/191/213/218) und `grep -n "steps 2-3 and 7" instructions/dev/stack-close/SKILL.md` - [x] Frontmatter `description:` nennt drei `status/`-Flags - [x] `tools/wikitool instructions verify` (20 Instructions, 7 Skills, 14 publizierte Kopien identisch) und `docs verify` (50 Kommandos, CHANGES.md dokumentiert 4.7.5-beta.1) grün - [x] `tools/.venv/bin/python -m pytest -q`: 976 passed - [x] `version bump --patch` auf `4.7.5-beta.1`, `CHANGES.md`-Eintrag mit Prosa ## Nachgelagert - **#63** — `kb/concepts/Issue Label Scheme.md` beschreibt weiter nur zwei `status/`-Flags und behauptet 16 Labels statt 17. `kb/`-Inhalt, braucht eine Quelle nach Invariante 3, also eine eigene `wiki-manage`-Sitzung. - **#60 und #61** bleiben unausgearbeitet offen. Das ist die erste Anwendung der Regel, nicht ihre Einführung. ## Nicht verifiziert Der Nutzen der Regel selbst — dass eine Sitzung, die #60 aufnimmt, tatsächlich ausarbeitet statt zu bauen. Nichts Maschinelles prüft das (§ What no tool checks); der Beleg wäre die Ausarbeitung von #60/#61 und liegt außerhalb dieses Pakets. Der Kandidat `4.7.5-beta.1` ist noch offen und nicht per `version release` fixiert.
torben added the prio/blockingsize/Sarea/processkind/build labels 2026-09-04 19:53:23 +00:00
torben commented 2026-09-04 19:57:03 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: Body auf den Endstand umgeschrieben und geschlossen. Alle sieben Akzeptanzkriterien abgehakt, jeweils mit dem Kommando bzw. Ergebnis, das sie belegt. Neu: Abschnitt "Entscheidungen" (warum kein neuer Schritt, warum PATCH) und "Nicht verifiziert" (der Nutzen der Regel ist maschinell nicht prüfbar, der Beleg wäre die Ausarbeitung von #60/#61). Der Punkt "kb/concepts/Issue Label Scheme.md" ist aus "Nicht in diesem Paket" nach "Nachgelagert" gewandert und liegt jetzt als #63 auf dem Board.

**Changelog:** Body auf den Endstand umgeschrieben und geschlossen. Alle sieben Akzeptanzkriterien abgehakt, jeweils mit dem Kommando bzw. Ergebnis, das sie belegt. Neu: Abschnitt "Entscheidungen" (warum kein neuer Schritt, warum PATCH) und "Nicht verifiziert" (der Nutzen der Regel ist maschinell nicht prüfbar, der Beleg wäre die Ausarbeitung von #60/#61). Der Punkt "`kb/concepts/Issue Label Scheme.md`" ist aus "Nicht in diesem Paket" nach "Nachgelagert" gewandert und liegt jetzt als #63 auf dem Board.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 Label area/process kind/build prio/blocking 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#62
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?