Umgesetzt und veröffentlicht als 2cce979 (v7.0.0-beta.13, --patch). Entschieden am
2026-09-22: Variante 2 - die Beförderung nach raw/ steht künftig hinter der
Verpflichtungsentscheidung -, mit Teilentscheidung A für den Übergang nach ingest-large-tree.
Hervorgegangen aus einer offen gebliebenen Teilfrage von #132.
Warum Variante 2
Die Regel „die Verpflichtungsseite wird zuerst gesetzt, damit ein Fehlschlag nichts Verwaistes auf
der Wissensseite hinterlässt" stand im Baum bereits an drei Stellen. raw accept war die einzige,
an der sie brach:
Dazu der Befund, der die Frage entschied: docs/knowledge-and-commitment.md (§ „Status has
exactly one home") behauptete die Eigenschaft schon vor dieser Änderung als Tatsache - „a failure
creating the item leaves no page and no promoted source material behind it". Geschrieben in cfbe3ea, im #132-Commit selbst. Der Baum beschrieb ein Design, das es noch nicht gab. Variante 1
wäre damit nicht „nichts tun" gewesen, sondern „diesen Satz zurücknehmen"; die docs/-Seite war
die bessere Beschreibung.
Befund zum alten Akzeptanzkriterium 2 - geprüft, nicht angenommen
Genau ein Schritt zwischen „lesen" und „befördern" setzte raw/ voraus: der Abzweig bei
Übergröße nach ingest-large-tree.md, dessen Schritt 2 work new --input <pfad> ist. work new
verweigert jeden Pfad außerhalb raw/ (tools/chemenu/commands/work_cmd.py:173), weil der
Run-Key aus dem Pfad unterhalb raw/ abgeleitet wird. Alles andere - Lesen, Metadatenextraktion, search, task new - brauchte raw/ nicht; capture-session schreibt ohnehin direkt nach raw/notes/ und überspringt den Schritt vollständig.
Teilentscheidung A - umgesetzt
Greift die Größenprüfung, wird vor dem Wechsel nach ingest-large-tree befördert. Die
hergestellte Eigenschaft gilt für den Standard-Ingest, nicht für den large-tree-Lauf - der ist
per Konstruktion kein atomarer Vorgang, publiziert unit-weise über Tage und stellt seine eigene
Verpflichtungsfrage erst in dessen Schritt 5d je Unit. docs/knowledge-and-commitment.md benennt
diese Ausnahme jetzt explizit, statt die Eigenschaft unbedingt zu behaupten.
Verworfen wie geplant: work new für incoming/-Pfade öffnen (zu teuer für den Gewinn, siehe
frühere Fassung dieses Bodys).
Was tatsächlich geändert wurde
instructions/wiki-ingest/SKILL.mds Schritte 1-5 neu geordnet: lesen → Metadaten → search →
Diskussion inkl. Verpflichtung und task new → raw accept. Schritte 6-12 behalten ihre Nummern
unverändert.
Zwei Stellen verschärft, nicht nur verschoben:
Die fidelity/authority-Frage (jetzt Schritt 5) benennt ausdrücklich, dass die Datei zu
diesem Zeitpunkt schon vollständig gelesen ist - der Moment, in dem die Versuchung, den Wert aus
dem Inhalt zu erschließen statt ihn zu erfragen, am größten ist.
Derselbe Schritt benennt, dass seine Kollisionsverweigerung jetzt später fällt, nach Lesen,
Diskussion und möglicherweise bereits angelegtem Tracker-Posten - kein neuer Fehlerzustand,
sondern derselbe von sources coverage/lint gemeldete, nur mit längerer Standzeit.
Nachgezogen: instructions/ingest-queue.md (die fidelity/authority-Referenz auf „step 1" →
„step 5"; die beiden anderen „step 1"-Stellen sind generische Einstiegspunkte und blieben korrekt
stehen), instructions/ingest-large-tree.md (Schritt 5d: „steps 5-10" → „steps 4-10", mit
Begründung, warum Schritt 5 dort ein No-op ist), instructions/CONTRACT.md (die
Once-Test-Referenz „step 1 and again in step 6" → „step 5"), docs/knowledge-and-commitment.md
(die Tatsachenbehauptung wird zutreffend, plus die Ausnahme für den large-tree-Fall benannt), README.mds Skill-Tabellenzeile.
tools/wikitool version bump --patch (7.0.0-beta.12 → 7.0.0-beta.13); die dabei gemeldete
„crosses a compatibility boundary"-Warnung stammt vom bereits offenen Kandidaten (#119/#133/ #135), nicht von dieser Änderung - kein --breaking gesetzt, keine neue Breaking-Change-Zeile
hinzugekommen
pytest in tools/: 1429 grün, keiner der bestehenden Tests prüft eine konkrete Schrittnummer,
also keine Kollisionen mit der Umnummerierung
Geänderte Dateien (git diff --stat vor dem Publish) decken sich exakt mit der ursprünglich
genannten Nachzieh-Liste: README.md, docs/knowledge-and-commitment.md, instructions/CONTRACT.md, instructions/ingest-large-tree.md, instructions/ingest-queue.md, instructions/wiki-ingest/SKILL.md
Veröffentlicht als 2cce979.
Nicht in diesem Paket
Beim Durchsehen der Naht zwischen Wissen und Verpflichtungen sind drei Dinge aufgefallen, die #132 verursacht oder freigelegt hat und die nicht zur Reihenfolge im Ingest gehören: #137 (Defekt: gtd-weekly-review kennt task new nicht) und #138 (Entscheidung: soll der Weekly Review task new anbieten). Beide offen, unabhängig von diesem Issue.
Modell-Herkunft
Gesamte Sitzung - Bewertung des Ingest-Prozesses, die Entscheidung Variante 2 + A, die
Umsetzung (Schrittumsortierung, Nachzug, Version-Bump, Publish) und dieser Abschluss - lief auf
Opus 5. Der Wechsel auf Sonnet bei Effort high wurde vor der Umsetzung angeboten; der Nutzer hat
ihn nicht gezogen.
Abhängigkeiten
Keine. #132 ist geschlossen und ausgeliefert; an dessen Kommando hat sich nichts geändert, nur an
der Schrittfolge des Ingest-Skills und an einem Satz in docs/.
Umgesetzt und veröffentlicht als `2cce979` (`v7.0.0-beta.13`, `--patch`). Entschieden am
2026-09-22: **Variante 2** - die Beförderung nach `raw/` steht künftig hinter der
Verpflichtungsentscheidung -, mit **Teilentscheidung A** für den Übergang nach
`ingest-large-tree`.
Hervorgegangen aus einer offen gebliebenen Teilfrage von #132.
## Warum Variante 2
Die Regel „die Verpflichtungsseite wird zuerst gesetzt, damit ein Fehlschlag nichts Verwaistes auf
der Wissensseite hinterlässt" stand im Baum bereits an drei Stellen. `raw accept` war die einzige,
an der sie brach:
| Ort | Reihenfolge | Durchgesetzt durch |
|---|---|---|
| `new project` | Tracker-Projekt → `kb/gtd/`-Seite | Code, ein Kommando |
| `wiki-ingest` 5→6 | `task new` → Quellenseite | Instruction (#132) |
| `capture-session` 4→5 | offene Fäden → Issues, dann Ingest | Instruction |
| `raw accept` | Beförderung vor allem anderen | **der Bruch, jetzt behoben** |
Dazu der Befund, der die Frage entschied: `docs/knowledge-and-commitment.md` (§ „Status has
exactly one home") behauptete die Eigenschaft schon vor dieser Änderung als Tatsache - „a failure
creating the item leaves no page and no promoted source material behind it". Geschrieben in
`cfbe3ea`, im #132-Commit selbst. Der Baum beschrieb ein Design, das es noch nicht gab. Variante 1
wäre damit nicht „nichts tun" gewesen, sondern „diesen Satz zurücknehmen"; die `docs/`-Seite war
die bessere Beschreibung.
## Befund zum alten Akzeptanzkriterium 2 - geprüft, nicht angenommen
Genau ein Schritt zwischen „lesen" und „befördern" setzte `raw/` voraus: der Abzweig bei
Übergröße nach `ingest-large-tree.md`, dessen Schritt 2 `work new --input <pfad>` ist. `work new`
verweigert jeden Pfad außerhalb `raw/` (`tools/chemenu/commands/work_cmd.py:173`), weil der
Run-Key aus dem Pfad unterhalb `raw/` abgeleitet wird. Alles andere - Lesen, Metadatenextraktion,
`search`, `task new` - brauchte `raw/` nicht; `capture-session` schreibt ohnehin direkt nach
`raw/notes/` und überspringt den Schritt vollständig.
## Teilentscheidung A - umgesetzt
Greift die Größenprüfung, wird **vor** dem Wechsel nach `ingest-large-tree` befördert. Die
hergestellte Eigenschaft gilt für den **Standard-Ingest**, nicht für den large-tree-Lauf - der ist
per Konstruktion kein atomarer Vorgang, publiziert unit-weise über Tage und stellt seine eigene
Verpflichtungsfrage erst in dessen Schritt 5d je Unit. `docs/knowledge-and-commitment.md` benennt
diese Ausnahme jetzt explizit, statt die Eigenschaft unbedingt zu behaupten.
Verworfen wie geplant: `work new` für `incoming/`-Pfade öffnen (zu teuer für den Gewinn, siehe
frühere Fassung dieses Bodys).
## Was tatsächlich geändert wurde
`instructions/wiki-ingest/SKILL.md`s Schritte 1-5 neu geordnet: lesen → Metadaten → `search` →
Diskussion inkl. Verpflichtung und `task new` → `raw accept`. Schritte 6-12 behalten ihre Nummern
unverändert.
Zwei Stellen verschärft, nicht nur verschoben:
- Die `fidelity`/`authority`-Frage (jetzt Schritt 5) benennt ausdrücklich, dass die Datei zu
diesem Zeitpunkt schon vollständig gelesen ist - der Moment, in dem die Versuchung, den Wert aus
dem Inhalt zu erschließen statt ihn zu erfragen, am größten ist.
- Derselbe Schritt benennt, dass seine Kollisionsverweigerung jetzt später fällt, nach Lesen,
Diskussion und möglicherweise bereits angelegtem Tracker-Posten - kein neuer Fehlerzustand,
sondern derselbe von `sources coverage`/`lint` gemeldete, nur mit längerer Standzeit.
Nachgezogen: `instructions/ingest-queue.md` (die `fidelity`/`authority`-Referenz auf „step 1" →
„step 5"; die beiden anderen „step 1"-Stellen sind generische Einstiegspunkte und blieben korrekt
stehen), `instructions/ingest-large-tree.md` (Schritt 5d: „steps 5-10" → „steps 4-10", mit
Begründung, warum Schritt 5 dort ein No-op ist), `instructions/CONTRACT.md` (die
Once-Test-Referenz „step 1 and again in step 6" → „step 5"), `docs/knowledge-and-commitment.md`
(die Tatsachenbehauptung wird zutreffend, plus die Ausnahme für den large-tree-Fall benannt),
`README.md`s Skill-Tabellenzeile.
## Verifiziert
- `tools/wikitool instructions verify` grün (nach `instructions sync`)
- `tools/wikitool docs verify` grün
- `tools/wikitool version bump --patch` (`7.0.0-beta.12` → `7.0.0-beta.13`); die dabei gemeldete
„crosses a compatibility boundary"-Warnung stammt vom bereits offenen Kandidaten (#119/#133/
#135), nicht von dieser Änderung - kein `--breaking` gesetzt, keine neue Breaking-Change-Zeile
hinzugekommen
- `pytest` in `tools/`: 1429 grün, keiner der bestehenden Tests prüft eine konkrete Schrittnummer,
also keine Kollisionen mit der Umnummerierung
- Geänderte Dateien (`git diff --stat` vor dem Publish) decken sich exakt mit der ursprünglich
genannten Nachzieh-Liste: `README.md`, `docs/knowledge-and-commitment.md`,
`instructions/CONTRACT.md`, `instructions/ingest-large-tree.md`, `instructions/ingest-queue.md`,
`instructions/wiki-ingest/SKILL.md`
Veröffentlicht als `2cce979`.
## Nicht in diesem Paket
Beim Durchsehen der Naht zwischen Wissen und Verpflichtungen sind drei Dinge aufgefallen, die
#132 verursacht oder freigelegt hat und die nicht zur Reihenfolge im Ingest gehören: #137 (Defekt:
`gtd-weekly-review` kennt `task new` nicht) und #138 (Entscheidung: soll der Weekly Review
`task new` anbieten). Beide offen, unabhängig von diesem Issue.
## Modell-Herkunft
Gesamte Sitzung - Bewertung des Ingest-Prozesses, die Entscheidung Variante 2 + A, die
Umsetzung (Schrittumsortierung, Nachzug, Version-Bump, Publish) und dieser Abschluss - lief auf
Opus 5. Der Wechsel auf Sonnet bei Effort `high` wurde vor der Umsetzung angeboten; der Nutzer hat
ihn nicht gezogen.
## Abhängigkeiten
Keine. #132 ist geschlossen und ausgeliefert; an dessen Kommando hat sich nichts geändert, nur an
der Schrittfolge des Ingest-Skills und an einem Satz in `docs/`.
torben
changed title from Soll `raw accept` im Ingest hinter die Verpflichtungsentscheidung rücken? to `raw accept` rückt im Ingest hinter die Verpflichtungsentscheidung2026-09-22 17:35:52 +00:00
Changelog: Entscheidung getroffen (Variante 2 + Teilentscheidung A), Body von der
Entscheidungsvorlage zur Umsetzungsspezifikation umgeschrieben, Titel von der Frage auf die
Arbeit umgestellt, kind/decision → kind/build.
Neu im Body: der Befund, dass docs/knowledge-and-commitment.md die Eigenschaft seit cfbe3ea
bereits als Tatsache behauptet (macht Variante 1 zu „Satz zurücknehmen" statt „nichts tun"); das
Prüfergebnis zum alten Kriterium 2 - genau ein Schritt setzt raw/ voraus, der large-tree-Abzweig
über work new (work_cmd.py:173); die neue Schrittfolge samt der Feststellung, dass 6-12 ihre
Nummern behalten; drei Bauanforderungen, die über reines Verschieben hinausgehen; die
Nachzieh-Liste mit sechs Fundstellen.
Gestrichen: der Abschnitt „Was zu entscheiden ist" (erledigt) und die alten vier
Akzeptanzkriterien, ersetzt durch sechs prüfbare Eigenschaften.
Abgespalten: #137 (Defekt - gtd-weekly-review nennt zweimal „die einzigen zwei GTD-Kommandos"
und zeigt für die Begründung auf zwei Dateien, die sie nicht tragen) und #138 (Entscheidung -
soll der Weekly Review task new anbieten, mit den beiden Kontextpunkten „Ingest kann
Verpflichtungen nicht schließen" und „large-tree fragt pro Unit").
**Changelog:** Entscheidung getroffen (Variante 2 + Teilentscheidung A), Body von der
Entscheidungsvorlage zur Umsetzungsspezifikation umgeschrieben, Titel von der Frage auf die
Arbeit umgestellt, `kind/decision` → `kind/build`.
Neu im Body: der Befund, dass `docs/knowledge-and-commitment.md` die Eigenschaft seit `cfbe3ea`
bereits als Tatsache behauptet (macht Variante 1 zu „Satz zurücknehmen" statt „nichts tun"); das
Prüfergebnis zum alten Kriterium 2 - genau ein Schritt setzt `raw/` voraus, der large-tree-Abzweig
über `work new` (`work_cmd.py:173`); die neue Schrittfolge samt der Feststellung, dass 6-12 ihre
Nummern behalten; drei Bauanforderungen, die über reines Verschieben hinausgehen; die
Nachzieh-Liste mit sechs Fundstellen.
Gestrichen: der Abschnitt „Was zu entscheiden ist" (erledigt) und die alten vier
Akzeptanzkriterien, ersetzt durch sechs prüfbare Eigenschaften.
Abgespalten: #137 (Defekt - `gtd-weekly-review` nennt zweimal „die einzigen zwei GTD-Kommandos"
und zeigt für die Begründung auf zwei Dateien, die sie nicht tragen) und #138 (Entscheidung -
soll der Weekly Review `task new` anbieten, mit den beiden Kontextpunkten „Ingest kann
Verpflichtungen nicht schließen" und „large-tree fragt pro Unit").
Changelog: Body auf den finalen Stand gebracht - „Umgesetzt und veröffentlicht als 2cce979"
ersetzt die Umsetzungsspezifikation, alle sechs Akzeptanzkriterien durch „Verifiziert"
ersetzt mit den tatsächlichen Befunden (Testzahl, docs verify/instructions verify-Ergebnis,
Deckung der geänderten Dateien mit der Nachzieh-Liste), Bauanforderungen durch „Was tatsächlich
geändert wurde" ersetzt. Neu: Abschnitt „Modell-Herkunft". Schließe das Issue.
**Changelog:** Body auf den finalen Stand gebracht - „Umgesetzt und veröffentlicht als `2cce979`"
ersetzt die Umsetzungsspezifikation, alle sechs Akzeptanzkriterien durch „Verifiziert"
ersetzt mit den tatsächlichen Befunden (Testzahl, `docs verify`/`instructions verify`-Ergebnis,
Deckung der geänderten Dateien mit der Nachzieh-Liste), Bauanforderungen durch „Was tatsächlich
geändert wurde" ersetzt. Neu: Abschnitt „Modell-Herkunft". Schließe das Issue.
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.
Umgesetzt und veröffentlicht als
2cce979(v7.0.0-beta.13,--patch). Entschieden am2026-09-22: Variante 2 - die Beförderung nach
raw/steht künftig hinter derVerpflichtungsentscheidung -, mit Teilentscheidung A für den Übergang nach
ingest-large-tree.Hervorgegangen aus einer offen gebliebenen Teilfrage von #132.
Warum Variante 2
Die Regel „die Verpflichtungsseite wird zuerst gesetzt, damit ein Fehlschlag nichts Verwaistes auf
der Wissensseite hinterlässt" stand im Baum bereits an drei Stellen.
raw acceptwar die einzige,an der sie brach:
new projectkb/gtd/-Seitewiki-ingest5→6task new→ Quellenseitecapture-session4→5raw acceptDazu der Befund, der die Frage entschied:
docs/knowledge-and-commitment.md(§ „Status hasexactly one home") behauptete die Eigenschaft schon vor dieser Änderung als Tatsache - „a failure
creating the item leaves no page and no promoted source material behind it". Geschrieben in
cfbe3ea, im #132-Commit selbst. Der Baum beschrieb ein Design, das es noch nicht gab. Variante 1wäre damit nicht „nichts tun" gewesen, sondern „diesen Satz zurücknehmen"; die
docs/-Seite wardie bessere Beschreibung.
Befund zum alten Akzeptanzkriterium 2 - geprüft, nicht angenommen
Genau ein Schritt zwischen „lesen" und „befördern" setzte
raw/voraus: der Abzweig beiÜbergröße nach
ingest-large-tree.md, dessen Schritt 2work new --input <pfad>ist.work newverweigert jeden Pfad außerhalb
raw/(tools/chemenu/commands/work_cmd.py:173), weil derRun-Key aus dem Pfad unterhalb
raw/abgeleitet wird. Alles andere - Lesen, Metadatenextraktion,search,task new- brauchteraw/nicht;capture-sessionschreibt ohnehin direkt nachraw/notes/und überspringt den Schritt vollständig.Teilentscheidung A - umgesetzt
Greift die Größenprüfung, wird vor dem Wechsel nach
ingest-large-treebefördert. Diehergestellte Eigenschaft gilt für den Standard-Ingest, nicht für den large-tree-Lauf - der ist
per Konstruktion kein atomarer Vorgang, publiziert unit-weise über Tage und stellt seine eigene
Verpflichtungsfrage erst in dessen Schritt 5d je Unit.
docs/knowledge-and-commitment.mdbenenntdiese Ausnahme jetzt explizit, statt die Eigenschaft unbedingt zu behaupten.
Verworfen wie geplant:
work newfürincoming/-Pfade öffnen (zu teuer für den Gewinn, siehefrühere Fassung dieses Bodys).
Was tatsächlich geändert wurde
instructions/wiki-ingest/SKILL.mds Schritte 1-5 neu geordnet: lesen → Metadaten →search→Diskussion inkl. Verpflichtung und
task new→raw accept. Schritte 6-12 behalten ihre Nummernunverändert.
Zwei Stellen verschärft, nicht nur verschoben:
fidelity/authority-Frage (jetzt Schritt 5) benennt ausdrücklich, dass die Datei zudiesem Zeitpunkt schon vollständig gelesen ist - der Moment, in dem die Versuchung, den Wert aus
dem Inhalt zu erschließen statt ihn zu erfragen, am größten ist.
Diskussion und möglicherweise bereits angelegtem Tracker-Posten - kein neuer Fehlerzustand,
sondern derselbe von
sources coverage/lintgemeldete, nur mit längerer Standzeit.Nachgezogen:
instructions/ingest-queue.md(diefidelity/authority-Referenz auf „step 1" →„step 5"; die beiden anderen „step 1"-Stellen sind generische Einstiegspunkte und blieben korrekt
stehen),
instructions/ingest-large-tree.md(Schritt 5d: „steps 5-10" → „steps 4-10", mitBegründung, warum Schritt 5 dort ein No-op ist),
instructions/CONTRACT.md(dieOnce-Test-Referenz „step 1 and again in step 6" → „step 5"),
docs/knowledge-and-commitment.md(die Tatsachenbehauptung wird zutreffend, plus die Ausnahme für den large-tree-Fall benannt),
README.mds Skill-Tabellenzeile.Verifiziert
tools/wikitool instructions verifygrün (nachinstructions sync)tools/wikitool docs verifygrüntools/wikitool version bump --patch(7.0.0-beta.12→7.0.0-beta.13); die dabei gemeldete„crosses a compatibility boundary"-Warnung stammt vom bereits offenen Kandidaten (#119/#133/
#135), nicht von dieser Änderung - kein
--breakinggesetzt, keine neue Breaking-Change-Zeilehinzugekommen
pytestintools/: 1429 grün, keiner der bestehenden Tests prüft eine konkrete Schrittnummer,also keine Kollisionen mit der Umnummerierung
git diff --statvor dem Publish) decken sich exakt mit der ursprünglichgenannten Nachzieh-Liste:
README.md,docs/knowledge-and-commitment.md,instructions/CONTRACT.md,instructions/ingest-large-tree.md,instructions/ingest-queue.md,instructions/wiki-ingest/SKILL.mdVeröffentlicht als
2cce979.Nicht in diesem Paket
Beim Durchsehen der Naht zwischen Wissen und Verpflichtungen sind drei Dinge aufgefallen, die
#132 verursacht oder freigelegt hat und die nicht zur Reihenfolge im Ingest gehören: #137 (Defekt:
gtd-weekly-reviewkennttask newnicht) und #138 (Entscheidung: soll der Weekly Reviewtask newanbieten). Beide offen, unabhängig von diesem Issue.Modell-Herkunft
Gesamte Sitzung - Bewertung des Ingest-Prozesses, die Entscheidung Variante 2 + A, die
Umsetzung (Schrittumsortierung, Nachzug, Version-Bump, Publish) und dieser Abschluss - lief auf
Opus 5. Der Wechsel auf Sonnet bei Effort
highwurde vor der Umsetzung angeboten; der Nutzer hatihn nicht gezogen.
Abhängigkeiten
Keine. #132 ist geschlossen und ausgeliefert; an dessen Kommando hat sich nichts geändert, nur an
der Schrittfolge des Ingest-Skills und an einem Satz in
docs/.Soll `raw accept` im Ingest hinter die Verpflichtungsentscheidung rücken?to `raw accept` rückt im Ingest hinter die VerpflichtungsentscheidungChangelog: Entscheidung getroffen (Variante 2 + Teilentscheidung A), Body von der
Entscheidungsvorlage zur Umsetzungsspezifikation umgeschrieben, Titel von der Frage auf die
Arbeit umgestellt,
kind/decision→kind/build.Neu im Body: der Befund, dass
docs/knowledge-and-commitment.mddie Eigenschaft seitcfbe3eabereits als Tatsache behauptet (macht Variante 1 zu „Satz zurücknehmen" statt „nichts tun"); das
Prüfergebnis zum alten Kriterium 2 - genau ein Schritt setzt
raw/voraus, der large-tree-Abzweigüber
work new(work_cmd.py:173); die neue Schrittfolge samt der Feststellung, dass 6-12 ihreNummern behalten; drei Bauanforderungen, die über reines Verschieben hinausgehen; die
Nachzieh-Liste mit sechs Fundstellen.
Gestrichen: der Abschnitt „Was zu entscheiden ist" (erledigt) und die alten vier
Akzeptanzkriterien, ersetzt durch sechs prüfbare Eigenschaften.
Abgespalten: #137 (Defekt -
gtd-weekly-reviewnennt zweimal „die einzigen zwei GTD-Kommandos"und zeigt für die Begründung auf zwei Dateien, die sie nicht tragen) und #138 (Entscheidung -
soll der Weekly Review
task newanbieten, mit den beiden Kontextpunkten „Ingest kannVerpflichtungen nicht schließen" und „large-tree fragt pro Unit").
Changelog: Body auf den finalen Stand gebracht - „Umgesetzt und veröffentlicht als
2cce979"ersetzt die Umsetzungsspezifikation, alle sechs Akzeptanzkriterien durch „Verifiziert"
ersetzt mit den tatsächlichen Befunden (Testzahl,
docs verify/instructions verify-Ergebnis,Deckung der geänderten Dateien mit der Nachzieh-Liste), Bauanforderungen durch „Was tatsächlich
geändert wurde" ersetzt. Neu: Abschnitt „Modell-Herkunft". Schließe das Issue.