Abgeschlossen. Der Entwurf ist vollstaendig umgesetzt (#122–#127), geprueft und ausgeliefert;
dieses Issue ist ab jetzt nur noch die Entscheidungsgeschichte, keine Spezifikation mehr.
Wer wissen will, wie die Schicht funktioniert, liest nicht hier: die Begruendung steht in docs/knowledge-and-commitment.md (ausgeliefert, erreicht jede Instanz), die verbindlichen
Regeln in tools/CONTRACT.md (review, new project, doctor), kb/CONTRACT.md und kb/gtd/COLLECTION.md, und die Bedienung in INSTALL.md § Konfiguration sowie im Skill weekly-review. Der noch offene zweite Provider ist #128 und steht seit 2026-09-20 auf
eigenen Beinen — mit eigener Spezifikation, ohne Rueckverweis auf dieses Issue, damit dieser
Entwurf nicht auf unbestimmte Zeit mitgeschleift wird.
Nicht gedeckt von irgendeiner mechanischen Pruefung war: dieser Entwurf selbst, die Wahl der
Versionsteile, und die Prosa jeder Instruction und jedes docs/-Textes, der daraus entstanden ist.
Ziel
Kleine Projekte jeder Art auf Chemenu verwalten: Projektbeschreibung, -status und -wissen,
beteiligte Personen, und die aktuell offenen Aufgaben (eigene und waiting-on), GTD-nah. Gesucht
war nicht ein Todo-Werkzeug, sondern die Verbindung zwischen Verpflichtungen und dem
Projektgedaechtnis in kb/. Erreicht.
ausgegliedert, eigenstaendig, prio/waiting — Ausloeser: die berufliche Instanz existiert
Pruefung des Ganzen (2026-09-20)
Alle sechs Umsetzungscommits wurden im vollen Diff gegen D1–D34 geprueft, zusammen mit
Testabdeckung, Doku-Pull-Through und Versionsteilen. Ergebnis: keine Befunde im Code - kein Bug,
keine fehlende Fehlerbehandlung, keine Invarianten-Verletzung. Jede im Body behauptete
Umsetzungskorrektur liess sich im tatsaechlichen Diff nachvollziehen (keine Fassaden-Doku), und
jeder der vier Umsetzungsbefunde (siehe unten) ist nicht nur dokumentiert, sondern getestet:
#125s Pruefung-1/4-Ueberlappung als ausdrueckliches Doppel-Finding
(test_cli_json_and_text_agree_on_findings), #126s Tracker-vor-Seite-Reihenfolge ueber einen
Fehlerpfad-Test, #127s Provider-Neutralitaet am echten Skill-Text
(test_weekly_review_skill_names_no_provider). Gelaufen und gruen: pytest (1383 Tests), tools/wikitool docs verify, tools/wikitool instructions verify.
Der einzige Befund lag in der Prosa, die keine Pruefung liest - und hat Zeile 7 ausgeloest. INSTALL.md § Konfiguration kannte .wikitool-tasks.json nicht (die Datei stand nur dort, wo ein
Agent nachschlaegt, nicht dort, wo ein Mensch die Form nachschlaegt); setup-instance.md bot den
Tracker nie an; upgrade-instance.md hatte keinen Pfad fuer ein neu ausgeliefertes .template -
genau den Fall, den der --major aus #123 erzwingt. Alle drei sind geschlossen. Dazu zwei docs/-
Seiten, deren Begruendung frueher verschoben worden war: why-gates-are-code.md kannte Exit 42 nur
als Gate (obwohl HumanInterventionRequired denselben Code verlaesst, ohne eine fuenfte Gate zu
sein), und ownership-and-templates.md beschrieb die .template-Kategorie nur fuer bereits
adoptierte Dateien. Und instructions/dev/doc-pull-through.md hat die zwei Tabellenzeilen bekommen,
deren Fehlen die Luecke ueberhaupt erst zugelassen hat.
Die vier Befunde aus der Umsetzung
Jeder ist im Entwurf unten an seiner Entscheidung vermerkt und im jeweiligen Issue ausgefuehrt:
#124: der Lesepfad fuer Super Productivity ist nicht db.json (die gibt es auf dem Desktop
nicht), sondern der jueingste periodische Backup-Schnappschuss.
#124: SPs lokale REST-API kann keine Projekte anlegen - daraus wurde HumanInterventionRequired/Exit 42 statt eines automatischen Schreibvorgangs.
#125: Pruefung 1 und 4 sind nicht disjunkt und melden fuer denselben Zustand beide. Keine
Dopplung, sondern zwei verschiedene Aussagen - so getestet.
#126: ein zustandsloser CLI-Prozess kann einen Tracker-Treffer nicht automatisch von einer
echten Namenskollision unterscheiden; statt eines automatischen verify()-Laufs entscheidet
das explizite --resume.
Nicht Teil davon:#117 (Seitenvorlage je Subtyp) — mit D17 verliess das Vorhaben den entity-Typ, das Issue steht auf eigenen Beinen. #118 (Beteiligungs-Label) ist entblockt — #123 hat die Collection gtd und ihren gtd:-outbound:-Block in kb/entities/COLLECTION.md
angelegt; mit D28 ist es ohnehin der Ausnahmefall.
Architektur
D1 — Bruchlinie: Wissen und Verpflichtung haben verschiedene Halbwertszeiten
kb/ ist ein Compiler fuer Dauerhaftes (immutable raw/, Quellenbindung, Titel-Identitaet,
generierte Indizes, Gates). Eine Next Action ist das Gegenteil: unbelegt, hochfrequent,
zustandsbehaftet, nur jetzt korrekt. Beides in einer Schicht erzeugt provenance: general
ueberall, ein kb/log.md voller „Task abgehakt", bedeutungslose Lint-Befunde und ein
Mass-Update-Gate bei jedem Wochenrueckblick. GTD zieht dieselbe Linie bereits: kb/ deckt
Allens zwei langsamste Zeilen ab (Project Support Material, Reference) und keine andere.
Ausgeliefert in docs/knowledge-and-commitment.md § "Different half-lives want different
machinery".
D2 — Muster 4: getrennte Zustaendigkeit ohne Sync
Verworfen: Export (im Tool abgehakt = Haken steht in der Ansicht, nicht in der Wahrheit),
Bidirektional (ID-Mapping, Konfliktaufloesung, Loesch-Semantik). Gewaehlt: Tracker besitzt die
Aufgaben, kb/ besitzt das Projektgedaechtnis, einziger Beruehrungspunkt ist ein Name.
Ausgeliefert in docs/knowledge-and-commitment.md § "Pattern 4: separate ownership, no
synchronization", samt der drei verworfenen Anordnungen.
D3 — Der Join passiert zur Lesezeit, nicht als Zustand
Der Review joint ueber den normalisierten Namen, gibt einen Bericht aus, speichert nichts.
Umgesetzt in #125:wikitool review speichert nichts, nicht einmal eine reports/-Datei — es
ist read-only und vom Iterationsbudget ausgenommen wie search. Ausgeliefert in docs/knowledge-and-commitment.md § "The join happens at read time, and stores nothing".
D4 — Ein Container pro Projekt; eine Aufgabe ist kein Identitaetstraeger
D5 — Keine GTD-Kontexte; Prioritaet und verfuegbare Zeit sind die Achsen
Von Allens vier Kriterien entfaellt der Kontext (ein Schreibtisch). Folge: jede Aufgabe braucht
eine Aufwandsschaetzung, und die pflegt per Hand niemand ohne Feedback — ein Werkzeug mit
Soll-Ist-Rueckmeldung ist kategorial besser, nicht nur bequemer. Topkriterium der Werkzeugwahl. Offen geblieben: der Rueckblick liest die Schaetzung bis heute nicht — ob er das soll, ist eine
Frage in #128.
D6 — Projektlose Sammelstelle: ein Inbox-Container im Tracker
D7 — Zwei Wahrheiten ueber „Status" sind verboten (Invariante 8)
kb/-Seite = dauerhafte Charakterisierung. Tracker = Momentzustand. Die Seite fasst die
Aufgabenliste nie zusammen. Folgewirkung: der Agent hat ausserhalb des Rueckblicks keinen
Anlass, Aufgaben zu lesen — davon lebt die kleine Kommandoflaeche in D31.
Ausgeliefert in docs/knowledge-and-commitment.md § "Status has exactly one home" - samt der
Folgewirkung auf die Kommandoflaeche, die dort der Grund fuer ihre Groesse ist.
D8 — Der Name erbt die Pflichten eines Identifiers
(1) Vor Anlage global case-normalisierte Eindeutigkeit erzwingen; (2) Rename ist explizit und
selten, mit Preflight, dann Tracker und kb/-Seite im selben Ablauf; (3) keine automatische
Ruecksynchronisierung, sondern periodischer Set-Vergleich der normalisierten Namen; (4) der
Review meldet beidseitig unmatched — erst dadurch wird ein Rename ein sichtbares Ereignis
statt eines stillen Datenverlusts; (5) bei Hierarchie global eindeutige Namen oder
menschenlesbarer Vollpfad.
Umgesetzt in #125:normalize_project_name (aus #124) treibt sowohl Pruefung 3 (Tracker ohne kb/-Seite) als auch Pruefung 4 (kb/-Seite ohne Tracker-Projekt) — der beidseitige
unmatched-Bericht steht. Ausgeliefert in docs/knowledge-and-commitment.md § "One name,
carrying the duties of an identifier".
D9/D30 — Waiting-For: Konvention, und nur zwei Teile davon maschinenlesbar
Nur org-mode bildet WAITING nativ ab; ueberall sonst definieren wir es selbst, was die
Werkzeugwahl entkoppelt. Maschinenlesbar sind ausschliesslich der WAITING-Status und follow_up_at (ein eigenes Datum, ausdruecklich nicht das Faelligkeitsdatum). Die
Person steht im Klartext im Aufgabentitel — Pruefung 2 braucht das Datum, nicht die Person,
und D28 hat fuer Personen ohnehin entschieden, dass eine Erwaehnung genuegt. Das haelt die
Adapterflaeche minimal und funktioniert in jedem Provider identisch. Preis: keine Auswertung
„worauf warte ich bei X?". Taskwarriors wait: ist semantisch ungeeignet.
Umgesetzt in #124: fuer Super Productivity ist WAITING eine Tag namens waiting
(case-insensitiv), follow_up_at die Aufgabe eigener Reminder-Zeitstempel (remindAt) —
ausdruecklich nicht dueDay/dueWithTime. Pruefung 2 in #125 liest das genau so. Diese
Regel bindet auch jeden kuenftigen Adapter und steht deshalb ausgeschrieben in #128.
D11 — Gitea bleibt fuer Stack-Arbeitspakete, nicht fuer persoenliche Verpflichtungen
Zwei Arbeitsklassen. Der Einwand aus instructions/dev/issue-tracking.md („eine Markdown-Datei
hat keinen Zustand und kostet einen Publish") hat allerdings den urspruenglichen Entwurf
gekippt, Verpflichtungen als Dateien im Repo zu halten.
D12 — Zielort: die private Arbeitsinstanz, nicht dieses Testbett
Maschinerie in den Stack (wandert per upstream merge), Inhalte mit echten Personen in den
Clone.
D13 — Nichts Aufgabenfoermiges wird gepublisht
D14 — Kein Verlauf noetig
Damit faellt das Kriterium, das das Feld sonst halbiert haette („Was war am 17. Juni offen?");
org-mode verliert seinen groessten Vorsprung.
D15 — Eine Instanz, ein Provider; keine Migration zwischen Providern
Folge, die mitentschieden ist: drei Kontexte heissen drei Instanzen — beruflich, privat,
spaeter ggf. Verein. Drei getrennte Wissensbasen, nicht eine mit drei Faechern. Das ist der Grund,
warum #128 auf die Existenz der beruflichen Instanz wartet und nicht auf Vorrat gebaut wird.
Typmodell
D16 — Der Stack kann einen Seitentyp nicht besitzen; er muss ihn fordern
Befund (im Baum geprueft):root: traegt zwei Bedeutungen zugleich — gegen welchen Root base_dir aufloest und wem der Typ gehoert. tools/chemenu/commands/dist_cmd.py:335: (frontmatter.get("root") or "kb") != "kb". root: kb → ships als .template → instanzeigen. Ein stack-eigener Seitentyp, der nach kb/ schreibt, ist nicht ausdrueckbar.
Antwort: fordern statt besitzen — das Idiom fuer source („There must be a type-spec
declaring name: source whose schema requires raw_files:", geprueft von docs verify).
Ebene
Was
Durchgesetzt von
Stack
Ein Typ dieses Namens muss existieren, sein Schema muss die Felder fuehren, auf die das Tooling verzweigt
docs verify (FAIL)
Instanz
Alles Weitere: zusaetzliche Felder, Template-Text, Sprache, Enum-Werte, base_dir
niemand
Custom Fields on top sind nativ moeglich (additionalProperties: false steht im Schema der Instanz). Verworfen: ein owner:-Feld, das Platzierung und Eigentum trennt;
Schema-Komposition aus stack-eigener Basis plus Instanz-Erweiterung.
Umgesetzt in #123:project/state: steht neben source/raw_files: in STACK_REQUIRED_TYPES. Anders als bei source (das die Forderung von Anfang an trug, vor jeder
Versionierung) war das hier ein nachtraeglicher Grenzuebertritt: eine Instanz, die die neue tools/-Fassung uebernimmt, ohne types/project.md.template zu adoptieren, faellt bei docs verify durch, wo sie vorher bestand. Deshalb --major statt der urspruenglich angenommenen --minor.
Nachtrag (Stack 7.0.0-beta.7/beta.8): dieser Grenzuebertritt hatte zunaechst keinen
Reparaturpfad in der Upgrade-Prozedur. upgrade-instance.md Schritt 5 sagte „new braucht keine
Entscheidung", und die Schritt-6-Tabelle sagt, instanzeigene Dateien koennten dort gar nicht
auftauchen - beides fuer sich richtig, zusammen irrefuehrend. Schritt 5 benennt die Ausnahme jetzt,
Schritt 9 traegt die Reparatur, und docs/ownership-and-templates.md nennt den Fall als die eine
Gestalt, in der „das Upgrade schreibt diese Datei nie" zu Arbeit wird.
D17 — Eigener Typ und eigene Collection, kein entity-Subtyp
Ein geforderter Typname spiegelt das source-Muster; eine Forderung nach einem Enum-Wert
in einem instanzeigenen Schema waere genau das, worauf man sich nicht verlassen kann.
D18 — entity_type: project meint etwas anderes: Homonyme, keine Dubletten
Die 11 Seiten unter kb/entities/projects/ sind Codebasen. Der neue Typ ist ein Vorhaben.
Niemand wartet auf BCDModule. Die Linie verlaeuft zwischen Artefakt („Chemenu",
„die Kueche") und Vorhaben (gtd: „Chemenu 7.0 ausliefern", „Kueche renovieren").
D19/D32 — project bleibt beim Vorhaben; der Entity-Subtyp heisst codebase
Betreiberentscheidung 2026-09-19: intuitiver schlaegt billiger. codebase steht bereits
woertlich im Collection-Contract („Codebases and initiatives"), deckt alle elf Seiten ab und
rutscht weder in tool noch in system.
Erwogen und verworfen: initiative — benennt ein Vorhaben und stuende damit auf derselben
Seite der Linie wie gtd/project; nebeneinander waeren beide nicht unterscheidbar, was den
Intuitionsgewinn aufzehrt. Das Generalitaets-Bedenken („in anderen Repos liegt hier auch
Nicht-Software") traegt nicht: der Enum gehoert der Instanz (D16), jede darf sich einen Subtyp
ergaenzen; ausgeliefert wird nur der Startwortschatz im .template. Geprueft wurde das an torben/nathan, wo unter projects/ ebenfalls ausnahmslos Software liegt.
Umgesetzt in #122:kb/entities/codebases/ mit elf Seiten, --minor, weil dist upgrade eine .template-basierte Datei nie schreibt und eine adoptierte Instanz ihren project-Wert damit
behaelt.
D20 — person wird nicht gespalten
duplicate_titles ist ein Lint-Befund ueber ganz kb/ (tools/chemenu/lint_core.py:247); ein gtd/person neben entity/person waere genau diese Kollision. Der Unterschied zu D18 liegt im
Referenten: bei project zwei Dinge, ein Wort (Homonym, also spalten); bei personderselbe
Referent — der Kollege, auf den du wartest, ist derselbe, der eine Quelle geschrieben hat.
D21 — Der Review braucht keinen Personentyp
Titelaufloesung genuegt. Die Stack-Forderung aus D16 bleibt damit auf genau einem Typ.
D22 — Die Collection gehoert der Instanz, der Typname dem Stack
base_dir: steht im instanzeigenen Type-Spec, und kb/CONTRACT.md leitet required_by_stack:
daraus ab. Diese Instanz waehlt kb/gtd/; eine andere darf kb/vorhaben/ waehlen. Damit
ist der Einwand entschaerft, eine Methodik in den Stack zu backen: „GTD" steht im
Verzeichnisnamen dieser Instanz, nicht in der Forderung.
D23 — Archivierung ist ein state:-Wert, kein Ortswechsel
Ein abgeschlossenes Vorhaben ist genau dann am wertvollsten; Wegsortieren wuerde es verstecken.
Der Review verzweigt ohnehin auf state:, und ein Verschieben wuerde die eine Area-Ebene
verbrauchen, die der Subtyp belegt.
Ausgeliefert in docs/knowledge-and-commitment.md § "A finished initiative is a state, not a
location", zusammen mit D24/D27s Begruendung fuer dormant.
dormant gegen stehengeblieben ist Zufall gegen Absicht: ohne diesen Wert meldet der
Rueckblick jede Woche dieselben bewusst pausierten Vorhaben als „stalled", und nach drei Wochen
liest niemand den Bericht mehr. completed gegen abandoned ist fuer den Review dasselbe,
fuer das Wissen das Gegenteil.
Die Werte sind englisch, weil Enum-Werte Identifier sind (types/type-spec.md). Die layout:-Titel bleiben Anzeigetext und deutsch.
Umgesetzt in #123:types/project.schema.yaml fuehrt state: genau so. Pruefung 1 in #125
liest genau diese vier Werte: nur active mahnt bei null offenen Posten, die anderen drei nie —
verifiziert per Fixture-Test je Wert.
D29 — Schubladen: responsibility: als Subtyp, ohne Bereichsseiten
Verantwortungsbereiche werden der Subtyp und ueber layout: zu Verzeichnissen (kb/gtd/haus/). Keine Area-of-Focus-Seiten — Betreiber-Nachtrag 2026-09-19, die Implikation war zu stark.
Damit entfaellt die Lint-Kopplung, die sonst noetig gewesen waere, um Verzeichnisname und
Bereichsseite synchron zu halten.
Das Feld heisst nicht area:. „Area" bedeutet in diesem Repo bereits eine Verzeichnisebene
innerhalb einer Collection (kb/CONTRACT.md); zwei Bedeutungen fuer ein Wort im selben Baum ist,
wie Missverstaendnisse anfangen. Bereichsseiten sind nicht verboten, nur nicht gefordert.
Umgesetzt in #123: Startwortschatz haus/finanzen/technik in types/project.mds layout:.
Der Wochenrueckblick
D10/D26 — Die Pruefliste
#
Pruefung
speist sich aus
1
Vorhaben ohne Next Action („stalled"), sofern state: active
Tracker-Projekt hat null offene Posten
2
Waiting-For aelter als n Tage
follow_up_at
3
Tracker-Projekt ohne kb/-Seite
Titelaufloesung + Altersschwelle
4
kb/-Seite active, aber keine offene Schleife
Join ueber den Namen + state:
5
Someday/Maybe seit n Monaten unberuehrt
Tracker-modified
—
Waiting-For nennt Person ohne kb/-Seite
fallengelassen, siehe D28
Rauschbremse fuer Pruefung 3: eine Altersschwelle, kein Marker im Tracker — ein Marker waere
ein zweites Vokabular in Pflege, und Muster 4 lebt davon, dass es genau eine Kopplung gibt.
Drei Schwellwerte sind Konfiguration, nicht Schema: n Tage (2), n Wochen (3), n Monate (5).
Umgesetzt in #124:.wikitool-tasks.jsons thresholds-Block
(stalled_waiting_days/unpaged_project_weeks/someday_stale_months) traegt genau diese drei;
seit Stack 7.0.0-beta.7 steht die vollstaendige Form der Datei in INSTALL.md § Konfiguration. Umgesetzt in #125:wikitool review fuehrt alle fuenf Pruefungen aus, mit Pruefung 3 und 4 als
den zwei Richtungen desselben Namensabgleichs (siehe D8). Umgesetzt in #127: instructions/weekly-review/SKILL.md fuehrt das Gespraech, das aus jeder der fuenf Pruefungen eine
Entscheidung macht — je Befund mindestens zwei Handlungsoptionen und ein Unterscheidungsmerkmal,
provider-neutral (D25).
D28 — Personen: Erwaehnung statt Seite
Die Projektseite traegt ## Beteiligte, wo eine Person mit ein bis zwei Zeilen charakterisiert
wird — ohne eigene Seite, ohne Wikilink. Eine eigene Seite bekommt jemand erst, wenn er fuer
das Wissen zaehlt; dann wird aus der Erwaehnung eine Kante mit dem Label aus #118. Bewusste
Ausnahme von kb/CONTRACT.md § „Every page should", gehalten von der Schreibdisziplin, nicht
von einem Pruefer.
Umgesetzt in #123:types/project.md und kb/gtd/COLLECTION.md nennen diese Ausnahme beide
explizit, mit Begruendung — sonst liest die naechste Session sie als Fehler.
Die Provider-Schicht
D25 — Zugriffsschicht: ausschliesslich die wikitool-CLI
Kein MCP fuer die Task-Schicht; der vorhandene Leseserver bekommt keine Task-Tools. Wird
spaeter ein entfernter Konsument gebraucht, wird es ein Tool auf dem vorhandenen Server,
gleicher Kern, gleicher Golden-Test.
Begruendung entlang INSTALL-MCP.md („ein zweiter Konsument desselben Kerns, nicht ein zweites
Programm"): die Achse ist nicht „CLI oder MCP", sondern welcher Konsument mit welchen
Faehigkeiten. Fuer eine lokale Session mit Checkout und Shell kostet MCP Komponierbarkeit (jeder
Aufruf eine Modellrunde) und eine zweite Flaeche. Dazu: die Gates sind Exit-Codes. Exit 42
wirkt, weil ein Prozess sich weigert — eine MCP-Schicht muesste das uebersetzen und schoebe ein
Gate zurueck Richtung Prosa, was docs/why-gates-are-code.md gerade vermeiden will. Nebenbefund: MCP mit verzoegertem Tool-Laden ist selective disclosure, nur vom Harness
ausgefuehrt statt im Prompt.
Umgesetzt in #124:chemenu.tasks.protocol/.superproductivity sind reine Bibliothek,
importiert von wikitool doctor; #125 liest sie ebenso als Bibliothek. Umgesetzt in #127: weekly-reviews Skill-Body nennt keinen Provider und keine Datei-/API-Form — ein Regressionstest
haelt das am echten Skill-Text fest. Ausgeliefert in docs/knowledge-and-commitment.md
§ "Which tracker is a decision the stack does not make".
Ein Lesekommando — der Bericht. Die Projektanlage reitet auf dem vorhandenen Seiten-Scaffold
mit: nach Eindeutigkeits-Preflight (D8) entstehen Seite und Tracker-Projekt gleichen Namens.
Ein Geburtsort, ein Name.
Tracker-zuerst-Projekte bleiben der Normalfall und laufen weiter ohne Seite — genau das mahnt
Pruefung 3 an. Ein voller Kommandobaum wurde verworfen: D7 nimmt dem Agenten den Anlass,
Aufgaben ausserhalb des Rueckblicks zu lesen, und Entdeckungskosten wachsen mit der Zahl der
Kommandos — der eine Nachteil, den D25 der CLI zugesteht.
Beide Haelften stehen (#125 bzw. #126). Praezisierungen aus der Umsetzung: fuer Super
Productivity ist die Tracker-Anlage kein Automatismus, weil dessen lokale REST-API keinen POST /projects hat (verifiziert gegen electron/local-rest-api-handler.service.ts,
2026-09-19) — sie wird zu einem verifizierten Mensch-in-der-Schleife-Schritt
(chemenu.errors.HumanInterventionRequired). Und statt eines automatischen verify()-Laufs
entscheidet ein explizites --resume, ob ein Tracker-Treffer als bestaetigte Fortsetzung gilt:
ein zustandsloser CLI-Prozess kann ihn nicht von einer echten Namenskollision unterscheiden. #127 fuegt der Kommandoflaeche bewusst nichts hinzu — jede aufgabenseitige Handlung bleibt
eine Handlung im Tracker selbst.
Konsequenzen fuer das Interface
Lese- und Schreibpfad duerfen verschiedene Transporte sein. SP: lesen aus dem
Backup-Schnappschuss (headless), schreiben ueber die lokale REST-API (Bearer-Token, App muss
laufen). Direktes Schreiben in db.json ist nicht vorgesehen.
Provider-Konfiguration in eigener Datei, nicht in ENVIRONMENT.md (keine Autoritaet,
keine Credentials). .wikitool-tasks.json, gitignored sofern Tokens darin liegen; nimmt auch
die drei Schwellwerte auf.
Faehigkeitsunterschiede nicht in der Instruction. Ein Provider, der etwas nicht kann,
scheitert nach dem Tool-Error-Contract mit Exit 1 — oder, wenn die fehlende Faehigkeit ein Mensch
ausgleichen kann, mit HumanInterventionRequired/Exit 42. Beides ist "die Instruction erfaehrt
nichts vom Provider" - der Unterschied ist nur, ob ein Mensch die Luecke schliessen kann.
Schema-Drift muss laut scheitern. SPs db.json hat kein versioniertes Public-Schema. Ein
Adapter, der still falsch parst, liefert einen Bericht, der plausibel aussieht und falsch ist.
Provider je Einsatzkontext
Kontext
Provider
Begruendung
Privat
Super Productivity
Beste Antwort auf die 40-Minuten-Frage. Kein zusaetzliches Hosting. Headless lesbar. Sync ueber SuperSync oder vorhandene Nextcloud
Beruflich
Azure DevOps
Gesetzt. Ein PC, 98 % der Wissensarbeit dort — umgesetzt in #128
Verein
vertagt (D33)
—
D33 — Der Verein wird vertagt
Kein dritter Adapter auf Vorrat. Wenn er kommt, wird der Verein eine eigene Instanz (D15). Und Incidents gehoeren nicht in diese Schicht: ein Incident wird gemeldet, triagiert,
geloest und wiederholt sich — eine andere Form als eine Verpflichtung. Eigene Designfrage.
D34 — iOS: Capture von Processing trennen
GTD trennt Erfassen von Verarbeiten; erfassen darf an vielen Orten passieren, verarbeitet wird
an einer Stelle. Unterwegs landet etwas in der vorhandenen Nextcloud, verarbeitet wird am
Schreibtisch in SP. Damit ist SPs schwache iOS-Seite kein Architekturproblem. Dasselbe Muster
faehrt dieser Stack fuer Wissen bereits: incoming/ plus raw promote, bzw. submit mit dem
Upload Review Gate. Optionale spaetere Ausbaustufe: der Rueckblick prueft, ob der
Capture-Eingang verstaubt.
Marktrecherche: die zwei Befunde, die zaehlen
Vollrecherche 2026-09-17 (Perplexity), rund 25 Kandidaten.
MCP-Asymmetrie. Bei dateibasierten Werkzeugen ist MCP Bequemlichkeit — stirbt er, liest der
Agent die Dateien. Bei dienstbasierten ist er der einzige Zugriffspfad — stirbt er, ist der
Review blind. Fast die gesamte gefundene Landschaft: Einzelmaintainer, 0–2 Stars,
One-shot-Releases. Mit D25 gegenstandslos.
Muster 4 verschiebt die Gewichte. Projektmetadaten im Tool: irrelevant. Projekt-CRUD:
nice-to-have, entscheidend ist Lesen. Stabiler Name: zentral. Zugriff ohne laufenden Dienst:
hoch. Schaetzung/Ist/Tagesplanung: Topkriterium.
Ausgeschieden: alles Proprietaere (Open Source und Self-Hosting sind hartes Kriterium);
Leantime und Vikunja privat an „keine weitere Webapp"; org-mode mit D14; Focalboard und Tracks
ueber zwoelf Monate ohne Release.
Verifikationspunkte — abgeschlossen
SPs lokale REST-API gegen die installierte Version — verifiziert 2026-09-19 gegen super-productivity/super-productivity (master): GET /projects existiert, POST /projects nicht.
Erzwingt SP eindeutige Projektnamen? Nein, wie vermutet → Preflight laeuft in SuperProductivityWriter.create_project; #126 nutzt denselben Preflight (find_project).
Hat SP einen Someday/Maybe-Container, oder ist das eine Tag-Konvention? Container: der
bestehende backlogTaskIds-Puffer je Projekt.
Azure DevOps: Rename-Stabilitaet, Feld fuer die Aufwandsschaetzung, Someday-Aequivalent → ausgegliedert nach #128, wo die drei Fragen als eigene „Vorher zu klaeren"-Liste stehen.
Kein offener Punkt dieses Issues mehr.
Versionsteile gegen instructions/dev/version-parts.md — fuer jedes Paket geklaert: #122 --minor, #123--major (abweichend von der urspruenglichen Annahme), #124/#125/#126/#127 --minor (plus ein --patch fuer einen Testnachtrag in #126), Doku-Nachzug --patch.
Nebenbefund ohne Folgen: SPs Integrations-Seite nennt Gitea unter den Issue-Trackern, die
Perplexity-Recherche nicht. Muster 4 braucht keinen Forge-Sync.
**Abgeschlossen.** Der Entwurf ist vollstaendig umgesetzt (#122–#127), geprueft und ausgeliefert;
dieses Issue ist ab jetzt nur noch die **Entscheidungsgeschichte**, keine Spezifikation mehr.
Wer wissen will, *wie* die Schicht funktioniert, liest nicht hier: die Begruendung steht in
**`docs/knowledge-and-commitment.md`** (ausgeliefert, erreicht jede Instanz), die verbindlichen
Regeln in **`tools/CONTRACT.md`** (`review`, `new project`, `doctor`), **`kb/CONTRACT.md`** und
`kb/gtd/COLLECTION.md`, und die Bedienung in **`INSTALL.md`** § Konfiguration sowie im Skill
`weekly-review`. Der noch offene zweite Provider ist **#128** und steht seit 2026-09-20 auf
eigenen Beinen — mit eigener Spezifikation, ohne Rueckverweis auf dieses Issue, damit dieser
Entwurf nicht auf unbestimmte Zeit mitgeschleift wird.
**Nicht gedeckt von irgendeiner mechanischen Pruefung war:** dieser Entwurf selbst, die Wahl der
Versionsteile, und die Prosa jeder Instruction und jedes `docs/`-Textes, der daraus entstanden ist.
## Ziel
Kleine Projekte jeder Art auf Chemenu verwalten: Projektbeschreibung, -status und -wissen,
beteiligte Personen, und die aktuell offenen Aufgaben (eigene und waiting-on), GTD-nah. Gesucht
war nicht ein Todo-Werkzeug, sondern die Verbindung zwischen Verpflichtungen und dem
Projektgedaechtnis in `kb/`. **Erreicht.**
## Umsetzung
| Reihenfolge | Issue | Inhalt | Zustand |
|---|---|---|---|
| 1 | **#122** | Entity-Subtyp `project` → `codebase` (D19/D32), inkl. 11 Korpusseiten | **erledigt** (`3c9d669`, Stack 6.2.0) |
| 2 | **#123** | Typ `project` + Collection `kb/gtd/` + Stack-Forderung in `docs verify` | **erledigt** (`ee24b6e`, Stack 7.0.0-beta.1) |
| 3 | **#124** | Provider-Schicht + Super-Productivity-Adapter + `.wikitool-tasks.json` | **erledigt** (`1875449`, Stack 7.0.0-beta.2) |
| 4 | **#125** | `wikitool review` — die fuenf Pruefungen | **erledigt** (`80b57e0`, Stack 7.0.0-beta.3) |
| 5 | **#126** | `wikitool new project` legt Seite und Tracker-Projekt an | **erledigt** (`e4260fc`/`6324024`, Stack 7.0.0-beta.5) |
| 6 | **#127** | Skill `weekly-review` | **erledigt** (`44909c9`, Stack 7.0.0-beta.6) |
| 7 | — | Doku-Nachzug: `INSTALL.md`, `setup-instance.md`, `upgrade-instance.md`, `docs/knowledge-and-commitment.md`, zwei stale `docs/`-Seiten | **erledigt** (`1d695f6`/`8ed8c6f`, Stack 7.0.0-beta.7/beta.8) |
| — | **#128** | Azure-DevOps-Adapter | **ausgegliedert**, eigenstaendig, `prio/waiting` — Ausloeser: die berufliche Instanz existiert |
### Pruefung des Ganzen (2026-09-20)
Alle sechs Umsetzungscommits wurden im vollen Diff gegen D1–D34 geprueft, zusammen mit
Testabdeckung, Doku-Pull-Through und Versionsteilen. Ergebnis: **keine Befunde im Code** - kein Bug,
keine fehlende Fehlerbehandlung, keine Invarianten-Verletzung. Jede im Body behauptete
Umsetzungskorrektur liess sich im tatsaechlichen Diff nachvollziehen (keine Fassaden-Doku), und
jeder der vier Umsetzungsbefunde (siehe unten) ist nicht nur dokumentiert, sondern getestet:
#125s Pruefung-1/4-Ueberlappung als ausdrueckliches Doppel-Finding
(`test_cli_json_and_text_agree_on_findings`), #126s Tracker-vor-Seite-Reihenfolge ueber einen
Fehlerpfad-Test, #127s Provider-Neutralitaet am echten Skill-Text
(`test_weekly_review_skill_names_no_provider`). Gelaufen und gruen: `pytest` (1383 Tests),
`tools/wikitool docs verify`, `tools/wikitool instructions verify`.
**Der einzige Befund lag in der Prosa, die keine Pruefung liest** - und hat Zeile 7 ausgeloest.
`INSTALL.md` § Konfiguration kannte `.wikitool-tasks.json` nicht (die Datei stand nur dort, wo ein
Agent nachschlaegt, nicht dort, wo ein Mensch die Form nachschlaegt); `setup-instance.md` bot den
Tracker nie an; `upgrade-instance.md` hatte keinen Pfad fuer ein neu ausgeliefertes `.template` -
genau den Fall, den der `--major` aus #123 erzwingt. Alle drei sind geschlossen. Dazu zwei `docs/`-
Seiten, deren Begruendung frueher verschoben worden war: `why-gates-are-code.md` kannte Exit 42 nur
als Gate (obwohl `HumanInterventionRequired` denselben Code verlaesst, ohne eine fuenfte Gate zu
sein), und `ownership-and-templates.md` beschrieb die `.template`-Kategorie nur fuer bereits
adoptierte Dateien. Und `instructions/dev/doc-pull-through.md` hat die zwei Tabellenzeilen bekommen,
deren Fehlen die Luecke ueberhaupt erst zugelassen hat.
### Die vier Befunde aus der Umsetzung
Jeder ist im Entwurf unten an seiner Entscheidung vermerkt und im jeweiligen Issue ausgefuehrt:
1. **#124:** der Lesepfad fuer Super Productivity ist nicht `db.json` (die gibt es auf dem Desktop
nicht), sondern der jueingste periodische Backup-Schnappschuss.
2. **#124:** SPs lokale REST-API kann keine Projekte anlegen - daraus wurde
`HumanInterventionRequired`/Exit 42 statt eines automatischen Schreibvorgangs.
3. **#125:** Pruefung 1 und 4 sind nicht disjunkt und melden fuer denselben Zustand beide. Keine
Dopplung, sondern zwei verschiedene Aussagen - so getestet.
4. **#126:** ein zustandsloser CLI-Prozess kann einen Tracker-Treffer nicht automatisch von einer
echten Namenskollision unterscheiden; statt eines automatischen `verify()`-Laufs entscheidet
das explizite `--resume`.
**Nicht Teil davon:** #117 (Seitenvorlage je Subtyp) — mit D17 verliess das Vorhaben den
`entity`-Typ, das Issue steht auf eigenen Beinen. **#118** (Beteiligungs-Label) ist entblockt —
#123 hat die Collection `gtd` und ihren `gtd:`-`outbound:`-Block in `kb/entities/COLLECTION.md`
angelegt; mit D28 ist es ohnehin der Ausnahmefall.
## Architektur
### D1 — Bruchlinie: Wissen und Verpflichtung haben verschiedene Halbwertszeiten
`kb/` ist ein Compiler fuer Dauerhaftes (immutable `raw/`, Quellenbindung, Titel-Identitaet,
generierte Indizes, Gates). Eine Next Action ist das Gegenteil: unbelegt, hochfrequent,
zustandsbehaftet, nur jetzt korrekt. Beides in einer Schicht erzeugt `provenance: general`
ueberall, ein `kb/log.md` voller „Task abgehakt", bedeutungslose Lint-Befunde und ein
Mass-Update-Gate bei jedem Wochenrueckblick. GTD zieht dieselbe Linie bereits: `kb/` deckt
Allens zwei langsamste Zeilen ab (Project Support Material, Reference) und keine andere.
**Ausgeliefert in `docs/knowledge-and-commitment.md`** § "Different half-lives want different
machinery".
### D2 — Muster 4: getrennte Zustaendigkeit ohne Sync
Verworfen: Export (im Tool abgehakt = Haken steht in der Ansicht, nicht in der Wahrheit),
Bidirektional (ID-Mapping, Konfliktaufloesung, Loesch-Semantik). Gewaehlt: Tracker besitzt die
Aufgaben, `kb/` besitzt das Projektgedaechtnis, einziger Beruehrungspunkt ist **ein Name**.
**Ausgeliefert in `docs/knowledge-and-commitment.md`** § "Pattern 4: separate ownership, no
synchronization", samt der drei verworfenen Anordnungen.
### D3 — Der Join passiert zur Lesezeit, nicht als Zustand
Der Review joint ueber den normalisierten Namen, gibt einen Bericht aus, speichert nichts.
**Umgesetzt in #125:** `wikitool review` speichert nichts, nicht einmal eine `reports/`-Datei — es
ist read-only und vom Iterationsbudget ausgenommen wie `search`. **Ausgeliefert in
`docs/knowledge-and-commitment.md`** § "The join happens at read time, and stores nothing".
### D4 — Ein Container pro Projekt; eine Aufgabe ist kein Identitaetstraeger
### D5 — Keine GTD-Kontexte; Prioritaet und verfuegbare Zeit sind die Achsen
Von Allens vier Kriterien entfaellt der Kontext (ein Schreibtisch). Folge: jede Aufgabe braucht
eine Aufwandsschaetzung, und die pflegt per Hand niemand ohne Feedback — ein Werkzeug mit
Soll-Ist-Rueckmeldung ist kategorial besser, nicht nur bequemer. Topkriterium der Werkzeugwahl.
*Offen geblieben:* der Rueckblick liest die Schaetzung bis heute nicht — ob er das soll, ist eine
Frage in #128.
### D6 — Projektlose Sammelstelle: ein Inbox-Container im Tracker
### D7 — Zwei Wahrheiten ueber „Status" sind verboten (Invariante 8)
`kb/`-Seite = dauerhafte Charakterisierung. Tracker = Momentzustand. Die Seite fasst die
Aufgabenliste **nie** zusammen. Folgewirkung: der Agent hat ausserhalb des Rueckblicks keinen
Anlass, Aufgaben zu lesen — davon lebt die kleine Kommandoflaeche in D31.
**Ausgeliefert in `docs/knowledge-and-commitment.md`** § "Status has exactly one home" - samt der
Folgewirkung auf die Kommandoflaeche, die dort der Grund fuer ihre Groesse ist.
### D8 — Der Name erbt die Pflichten eines Identifiers
(1) Vor Anlage global case-normalisierte Eindeutigkeit erzwingen; (2) Rename ist explizit und
selten, mit Preflight, dann Tracker und `kb/`-Seite im selben Ablauf; (3) keine automatische
Ruecksynchronisierung, sondern periodischer Set-Vergleich der normalisierten Namen; (4) der
Review meldet **beidseitig** unmatched — erst dadurch wird ein Rename ein sichtbares Ereignis
statt eines stillen Datenverlusts; (5) bei Hierarchie global eindeutige Namen oder
menschenlesbarer Vollpfad.
**Umgesetzt in #125:** `normalize_project_name` (aus #124) treibt sowohl Pruefung 3 (Tracker ohne
`kb/`-Seite) als auch Pruefung 4 (`kb/`-Seite ohne Tracker-Projekt) — der beidseitige
unmatched-Bericht steht. **Ausgeliefert in `docs/knowledge-and-commitment.md`** § "One name,
carrying the duties of an identifier".
### D9/D30 — Waiting-For: Konvention, und nur zwei Teile davon maschinenlesbar
Nur org-mode bildet `WAITING` nativ ab; ueberall sonst definieren wir es selbst, was die
Werkzeugwahl entkoppelt. **Maschinenlesbar sind ausschliesslich der `WAITING`-Status und
`follow_up_at`** (ein eigenes Datum, ausdruecklich **nicht** das Faelligkeitsdatum). **Die
Person steht im Klartext im Aufgabentitel** — Pruefung 2 braucht das Datum, nicht die Person,
und D28 hat fuer Personen ohnehin entschieden, dass eine Erwaehnung genuegt. Das haelt die
Adapterflaeche minimal und funktioniert in jedem Provider identisch. Preis: keine Auswertung
„worauf warte ich bei X?". Taskwarriors `wait:` ist semantisch ungeeignet.
**Umgesetzt in #124:** fuer Super Productivity ist `WAITING` eine Tag namens `waiting`
(case-insensitiv), `follow_up_at` die Aufgabe eigener Reminder-Zeitstempel (`remindAt`) —
ausdruecklich nicht `dueDay`/`dueWithTime`. **Pruefung 2 in #125** liest das genau so. Diese
Regel bindet auch jeden kuenftigen Adapter und steht deshalb ausgeschrieben in #128.
### D11 — Gitea bleibt fuer Stack-Arbeitspakete, nicht fuer persoenliche Verpflichtungen
Zwei Arbeitsklassen. Der Einwand aus `instructions/dev/issue-tracking.md` („eine Markdown-Datei
hat keinen Zustand und kostet einen Publish") hat allerdings den urspruenglichen Entwurf
gekippt, Verpflichtungen als Dateien im Repo zu halten.
### D12 — Zielort: die private Arbeitsinstanz, nicht dieses Testbett
Maschinerie in den Stack (wandert per `upstream merge`), Inhalte mit echten Personen in den
Clone.
### D13 — Nichts Aufgabenfoermiges wird gepublisht
### D14 — Kein Verlauf noetig
Damit faellt das Kriterium, das das Feld sonst halbiert haette („Was war am 17. Juni offen?");
org-mode verliert seinen groessten Vorsprung.
### D15 — Eine Instanz, ein Provider; keine Migration zwischen Providern
**Folge, die mitentschieden ist:** drei Kontexte heissen drei Instanzen — beruflich, privat,
spaeter ggf. Verein. Drei getrennte Wissensbasen, nicht eine mit drei Faechern. Das ist der Grund,
warum #128 auf die Existenz der beruflichen Instanz wartet und nicht auf Vorrat gebaut wird.
## Typmodell
### D16 — Der Stack kann einen Seitentyp nicht besitzen; er muss ihn **fordern**
**Befund (im Baum geprueft):** `root:` traegt zwei Bedeutungen zugleich — gegen welchen Root
`base_dir` aufloest *und* wem der Typ gehoert. `tools/chemenu/commands/dist_cmd.py:335`:
`(frontmatter.get("root") or "kb") != "kb"`. `root: kb` → ships als `.template` → instanzeigen.
**Ein stack-eigener Seitentyp, der nach `kb/` schreibt, ist nicht ausdrueckbar.**
**Antwort: fordern statt besitzen** — das Idiom fuer `source` (*„There must be a type-spec
declaring `name: source` whose schema requires `raw_files:`"*, geprueft von `docs verify`).
| Ebene | Was | Durchgesetzt von |
|---|---|---|
| **Stack** | Ein Typ dieses Namens muss existieren, sein Schema muss die Felder fuehren, auf die das Tooling verzweigt | `docs verify` (FAIL) |
| **Instanz** | Alles Weitere: zusaetzliche Felder, Template-Text, Sprache, Enum-Werte, `base_dir` | niemand |
Custom Fields on top sind nativ moeglich (`additionalProperties: false` steht im Schema der
*Instanz*). **Verworfen:** ein `owner:`-Feld, das Platzierung und Eigentum trennt;
Schema-Komposition aus stack-eigener Basis plus Instanz-Erweiterung.
**Umgesetzt in #123:** `project`/`state:` steht neben `source`/`raw_files:` in
`STACK_REQUIRED_TYPES`. Anders als bei `source` (das die Forderung von Anfang an trug, vor jeder
Versionierung) war das hier ein *nachtraeglicher* Grenzuebertritt: eine Instanz, die die neue
`tools/`-Fassung uebernimmt, ohne `types/project.md.template` zu adoptieren, faellt bei
`docs verify` durch, wo sie vorher bestand. Deshalb `--major` statt der urspruenglich angenommenen
`--minor`.
**Nachtrag (Stack 7.0.0-beta.7/beta.8):** dieser Grenzuebertritt hatte zunaechst keinen
Reparaturpfad in der Upgrade-Prozedur. `upgrade-instance.md` Schritt 5 sagte „`new` braucht keine
Entscheidung", und die Schritt-6-Tabelle sagt, instanzeigene Dateien koennten dort gar nicht
auftauchen - beides fuer sich richtig, zusammen irrefuehrend. Schritt 5 benennt die Ausnahme jetzt,
Schritt 9 traegt die Reparatur, und `docs/ownership-and-templates.md` nennt den Fall als die eine
Gestalt, in der „das Upgrade schreibt diese Datei nie" zu Arbeit wird.
### D17 — Eigener Typ und eigene Collection, kein `entity`-Subtyp
Ein geforderter **Typname** spiegelt das `source`-Muster; eine Forderung nach einem *Enum-Wert*
in einem instanzeigenen Schema waere genau das, worauf man sich nicht verlassen kann.
### D18 — `entity_type: project` meint etwas anderes: Homonyme, keine Dubletten
Die 11 Seiten unter `kb/entities/projects/` sind Codebasen. Der neue Typ ist ein **Vorhaben**.
Niemand wartet auf `BCDModule`. Die Linie verlaeuft zwischen **Artefakt** („Chemenu",
„die Kueche") und **Vorhaben** (gtd: „Chemenu 7.0 ausliefern", „Kueche renovieren").
### D19/D32 — `project` bleibt beim Vorhaben; der Entity-Subtyp heisst `codebase`
Betreiberentscheidung 2026-09-19: intuitiver schlaegt billiger. `codebase` steht bereits
woertlich im Collection-Contract („Codebases and initiatives"), deckt alle elf Seiten ab und
rutscht weder in `tool` noch in `system`.
Erwogen und verworfen: `initiative` — benennt ein *Vorhaben* und stuende damit auf derselben
Seite der Linie wie `gtd/project`; nebeneinander waeren beide nicht unterscheidbar, was den
Intuitionsgewinn aufzehrt. Das Generalitaets-Bedenken („in anderen Repos liegt hier auch
Nicht-Software") traegt nicht: der Enum gehoert der Instanz (D16), jede darf sich einen Subtyp
ergaenzen; ausgeliefert wird nur der Startwortschatz im `.template`. Geprueft wurde das an
`torben/nathan`, wo unter `projects/` ebenfalls ausnahmslos Software liegt.
**Umgesetzt in #122:** `kb/entities/codebases/` mit elf Seiten, `--minor`, weil `dist upgrade` eine
`.template`-basierte Datei nie schreibt und eine adoptierte Instanz ihren `project`-Wert damit
behaelt.
### D20 — `person` wird **nicht** gespalten
`duplicate_titles` ist ein Lint-Befund ueber ganz `kb/` (`tools/chemenu/lint_core.py:247`); ein
`gtd/person` neben `entity/person` waere genau diese Kollision. Der Unterschied zu D18 liegt im
Referenten: bei `project` zwei Dinge, ein Wort (Homonym, also spalten); bei `person` **derselbe
Referent** — der Kollege, auf den du wartest, ist derselbe, der eine Quelle geschrieben hat.
### D21 — Der Review braucht keinen Personentyp
Titelaufloesung genuegt. Die Stack-Forderung aus D16 bleibt damit auf genau **einem** Typ.
### D22 — Die Collection gehoert der Instanz, der Typname dem Stack
`base_dir:` steht im instanzeigenen Type-Spec, und `kb/CONTRACT.md` leitet `required_by_stack:`
daraus ab. Diese Instanz waehlt **`kb/gtd/`**; eine andere darf `kb/vorhaben/` waehlen. Damit
ist der Einwand entschaerft, eine Methodik in den Stack zu backen: „GTD" steht im
Verzeichnisnamen dieser Instanz, nicht in der Forderung.
### D23 — Archivierung ist ein `state:`-Wert, kein Ortswechsel
Ein abgeschlossenes Vorhaben ist genau dann am wertvollsten; Wegsortieren wuerde es verstecken.
Der Review verzweigt ohnehin auf `state:`, und ein Verschieben wuerde die eine Area-Ebene
verbrauchen, die der Subtyp belegt.
**Ausgeliefert in `docs/knowledge-and-commitment.md`** § "A finished initiative is a state, not a
location", zusammen mit D24/D27s Begruendung fuer `dormant`.
### D24/D27 — `state:` traegt `active` / `dormant` / `completed` / `abandoned`
| Wert | Bedeutung | Review |
|---|---|---|
| `active` | laeuft | mahnt |
| `dormant` | **bewusst** pausiert | mahnt nicht |
| `completed` | fertiggestellt, archiviert | mahnt nicht |
| `abandoned` | abgebrochen, archiviert | mahnt nicht |
**`dormant` gegen stehengeblieben ist Zufall gegen Absicht:** ohne diesen Wert meldet der
Rueckblick jede Woche dieselben bewusst pausierten Vorhaben als „stalled", und nach drei Wochen
liest niemand den Bericht mehr. **`completed` gegen `abandoned`** ist fuer den Review dasselbe,
fuer das Wissen das Gegenteil.
**Die Werte sind englisch, weil Enum-Werte Identifier sind** (`types/type-spec.md`). Die
`layout:`-Titel bleiben Anzeigetext und deutsch.
**Umgesetzt in #123:** `types/project.schema.yaml` fuehrt `state:` genau so. **Pruefung 1 in #125**
liest genau diese vier Werte: nur `active` mahnt bei null offenen Posten, die anderen drei nie —
verifiziert per Fixture-Test je Wert.
### D29 — Schubladen: `responsibility:` als Subtyp, ohne Bereichsseiten
Verantwortungsbereiche werden der Subtyp und ueber `layout:` zu Verzeichnissen (`kb/gtd/haus/`).
**Keine Area-of-Focus-Seiten** — Betreiber-Nachtrag 2026-09-19, die Implikation war zu stark.
Damit entfaellt die Lint-Kopplung, die sonst noetig gewesen waere, um Verzeichnisname und
Bereichsseite synchron zu halten.
**Das Feld heisst nicht `area:`.** „Area" bedeutet in diesem Repo bereits eine Verzeichnisebene
innerhalb einer Collection (`kb/CONTRACT.md`); zwei Bedeutungen fuer ein Wort im selben Baum ist,
wie Missverstaendnisse anfangen. Bereichsseiten sind nicht verboten, nur nicht gefordert.
**Umgesetzt in #123:** Startwortschatz `haus`/`finanzen`/`technik` in `types/project.md`s `layout:`.
## Der Wochenrueckblick
### D10/D26 — Die Pruefliste
| # | Pruefung | speist sich aus |
|---|---|---|
| 1 | Vorhaben ohne Next Action („stalled"), sofern `state: active` | Tracker-Projekt hat null offene Posten |
| 2 | Waiting-For aelter als *n* Tage | `follow_up_at` |
| 3 | Tracker-Projekt ohne `kb/`-Seite | Titelaufloesung + **Altersschwelle** |
| 4 | `kb/`-Seite `active`, aber keine offene Schleife | Join ueber den Namen + `state:` |
| 5 | Someday/Maybe seit *n* Monaten unberuehrt | Tracker-`modified` |
| — | ~~Waiting-For nennt Person ohne `kb/`-Seite~~ | **fallengelassen**, siehe D28 |
**Rauschbremse fuer Pruefung 3:** eine Altersschwelle, kein Marker im Tracker — ein Marker waere
ein zweites Vokabular in Pflege, und Muster 4 lebt davon, dass es genau eine Kopplung gibt.
Drei Schwellwerte sind Konfiguration, nicht Schema: *n* Tage (2), *n* Wochen (3), *n* Monate (5).
**Umgesetzt in #124:** `.wikitool-tasks.json`s `thresholds`-Block
(`stalled_waiting_days`/`unpaged_project_weeks`/`someday_stale_months`) traegt genau diese drei;
seit Stack 7.0.0-beta.7 steht die vollstaendige Form der Datei in `INSTALL.md` § Konfiguration.
**Umgesetzt in #125:** `wikitool review` fuehrt alle fuenf Pruefungen aus, mit Pruefung 3 und 4 als
den zwei Richtungen desselben Namensabgleichs (siehe D8). **Umgesetzt in #127:**
`instructions/weekly-review/SKILL.md` fuehrt das Gespraech, das aus jeder der fuenf Pruefungen eine
Entscheidung macht — je Befund mindestens zwei Handlungsoptionen und ein Unterscheidungsmerkmal,
provider-neutral (D25).
### D28 — Personen: Erwaehnung statt Seite
Die Projektseite traegt `## Beteiligte`, wo eine Person mit ein bis zwei Zeilen charakterisiert
wird — **ohne eigene Seite, ohne Wikilink**. Eine eigene Seite bekommt jemand erst, wenn er fuer
das *Wissen* zaehlt; dann wird aus der Erwaehnung eine Kante mit dem Label aus #118. Bewusste
Ausnahme von `kb/CONTRACT.md` § „Every page should", gehalten von der Schreibdisziplin, nicht
von einem Pruefer.
**Umgesetzt in #123:** `types/project.md` und `kb/gtd/COLLECTION.md` nennen diese Ausnahme beide
explizit, mit Begruendung — sonst liest die naechste Session sie als Fehler.
## Die Provider-Schicht
### D25 — Zugriffsschicht: ausschliesslich die `wikitool`-CLI
Kein MCP fuer die Task-Schicht; der vorhandene Leseserver bekommt **keine** Task-Tools. Wird
spaeter ein entfernter Konsument gebraucht, wird es ein Tool auf dem vorhandenen Server,
gleicher Kern, gleicher Golden-Test.
Begruendung entlang `INSTALL-MCP.md` (*„ein zweiter Konsument desselben Kerns, nicht ein zweites
Programm"*): die Achse ist nicht „CLI oder MCP", sondern welcher Konsument mit welchen
Faehigkeiten. Fuer eine lokale Session mit Checkout und Shell kostet MCP Komponierbarkeit (jeder
Aufruf eine Modellrunde) und eine zweite Flaeche. Dazu: **die Gates sind Exit-Codes.** Exit 42
wirkt, weil ein Prozess sich weigert — eine MCP-Schicht muesste das uebersetzen und schoebe ein
Gate zurueck Richtung Prosa, was `docs/why-gates-are-code.md` gerade vermeiden will.
*Nebenbefund:* MCP mit verzoegertem Tool-Laden **ist** selective disclosure, nur vom Harness
ausgefuehrt statt im Prompt.
**Umgesetzt in #124:** `chemenu.tasks.protocol`/`.superproductivity` sind reine Bibliothek,
importiert von `wikitool doctor`; #125 liest sie ebenso als Bibliothek. **Umgesetzt in #127:**
`weekly-review`s Skill-Body nennt keinen Provider und keine Datei-/API-Form — ein Regressionstest
haelt das am echten Skill-Text fest. **Ausgeliefert in `docs/knowledge-and-commitment.md`**
§ "Which tracker is a decision the stack does not make".
### D31 — Die Kommandoflaeche bleibt minimal
```
tools/wikitool review [--json]
tools/wikitool new project --name <Titel> --set responsibility=<bereich> [--resume]
```
Ein Lesekommando — der Bericht. Die Projektanlage reitet auf dem vorhandenen Seiten-Scaffold
mit: nach Eindeutigkeits-Preflight (D8) entstehen Seite **und** Tracker-Projekt gleichen Namens.
Ein Geburtsort, ein Name.
Tracker-zuerst-Projekte bleiben der Normalfall und laufen weiter ohne Seite — genau das mahnt
Pruefung 3 an. Ein voller Kommandobaum wurde verworfen: D7 nimmt dem Agenten den Anlass,
Aufgaben ausserhalb des Rueckblicks zu lesen, und Entdeckungskosten wachsen mit der Zahl der
Kommandos — der eine Nachteil, den D25 der CLI zugesteht.
**Beide Haelften stehen** (#125 bzw. #126). **Praezisierungen aus der Umsetzung:** fuer Super
Productivity ist die Tracker-Anlage kein Automatismus, weil dessen lokale REST-API keinen
`POST /projects` hat (verifiziert gegen `electron/local-rest-api-handler.service.ts`,
2026-09-19) — sie wird zu einem verifizierten Mensch-in-der-Schleife-Schritt
(`chemenu.errors.HumanInterventionRequired`). Und statt eines automatischen `verify()`-Laufs
entscheidet ein explizites `--resume`, ob ein Tracker-Treffer als bestaetigte Fortsetzung gilt:
ein zustandsloser CLI-Prozess kann ihn nicht von einer echten Namenskollision unterscheiden.
**#127 fuegt der Kommandoflaeche bewusst nichts hinzu** — jede aufgabenseitige Handlung bleibt
eine Handlung im Tracker selbst.
### Konsequenzen fuer das Interface
- **Lese- und Schreibpfad duerfen verschiedene Transporte sein.** SP: lesen aus dem
Backup-Schnappschuss (headless), schreiben ueber die lokale REST-API (Bearer-Token, App muss
laufen). Direktes Schreiben in `db.json` ist **nicht** vorgesehen.
- **Provider-Konfiguration in eigener Datei**, nicht in `ENVIRONMENT.md` (keine Autoritaet,
keine Credentials). `.wikitool-tasks.json`, gitignored sofern Tokens darin liegen; nimmt auch
die drei Schwellwerte auf.
- **Faehigkeitsunterschiede nicht in der Instruction.** Ein Provider, der etwas nicht kann,
scheitert nach dem Tool-Error-Contract mit Exit 1 — oder, wenn die fehlende Faehigkeit ein Mensch
ausgleichen kann, mit `HumanInterventionRequired`/Exit 42. Beides ist "die Instruction erfaehrt
nichts vom Provider" - der Unterschied ist nur, ob ein Mensch die Luecke schliessen kann.
- **Schema-Drift muss laut scheitern.** SPs `db.json` hat kein versioniertes Public-Schema. Ein
Adapter, der still falsch parst, liefert einen Bericht, der plausibel aussieht und falsch ist.
### Provider je Einsatzkontext
| Kontext | Provider | Begruendung |
|---|---|---|
| **Privat** | **Super Productivity** | Beste Antwort auf die 40-Minuten-Frage. Kein zusaetzliches Hosting. Headless lesbar. Sync ueber SuperSync oder vorhandene Nextcloud |
| **Beruflich** | **Azure DevOps** | Gesetzt. Ein PC, 98 % der Wissensarbeit dort — umgesetzt in **#128** |
| **Verein** | **vertagt (D33)** | — |
### D33 — Der Verein wird vertagt
Kein dritter Adapter auf Vorrat. Wenn er kommt, wird der Verein eine eigene Instanz (D15).
**Und Incidents gehoeren nicht in diese Schicht:** ein Incident wird gemeldet, triagiert,
geloest und wiederholt sich — eine andere Form als eine Verpflichtung. Eigene Designfrage.
### D34 — iOS: Capture von Processing trennen
GTD trennt Erfassen von Verarbeiten; erfassen darf an vielen Orten passieren, verarbeitet wird
an einer Stelle. Unterwegs landet etwas in der vorhandenen Nextcloud, verarbeitet wird am
Schreibtisch in SP. Damit ist SPs schwache iOS-Seite kein Architekturproblem. Dasselbe Muster
faehrt dieser Stack fuer Wissen bereits: `incoming/` plus `raw promote`, bzw. `submit` mit dem
Upload Review Gate. Optionale spaetere Ausbaustufe: der Rueckblick prueft, ob der
Capture-Eingang verstaubt.
## Marktrecherche: die zwei Befunde, die zaehlen
Vollrecherche 2026-09-17 (Perplexity), rund 25 Kandidaten.
**MCP-Asymmetrie.** Bei dateibasierten Werkzeugen ist MCP Bequemlichkeit — stirbt er, liest der
Agent die Dateien. Bei dienstbasierten ist er der einzige Zugriffspfad — stirbt er, ist der
Review blind. Fast die gesamte gefundene Landschaft: Einzelmaintainer, 0–2 Stars,
One-shot-Releases. Mit D25 gegenstandslos.
**Muster 4 verschiebt die Gewichte.** Projektmetadaten im Tool: irrelevant. Projekt-CRUD:
nice-to-have, entscheidend ist Lesen. Stabiler Name: zentral. Zugriff ohne laufenden Dienst:
hoch. Schaetzung/Ist/Tagesplanung: Topkriterium.
**Ausgeschieden:** alles Proprietaere (Open Source und Self-Hosting sind hartes Kriterium);
Leantime und Vikunja privat an „keine weitere Webapp"; org-mode mit D14; Focalboard und Tracks
ueber zwoelf Monate ohne Release.
## Verifikationspunkte — abgeschlossen
- [x] SPs lokale REST-API gegen die installierte Version — verifiziert 2026-09-19 gegen
`super-productivity/super-productivity` (`master`): `GET /projects` existiert,
`POST /projects` nicht.
- [x] Erzwingt SP eindeutige Projektnamen? **Nein**, wie vermutet → Preflight laeuft in
`SuperProductivityWriter.create_project`; #126 nutzt denselben Preflight (`find_project`).
- [x] Hat SP einen Someday/Maybe-Container, oder ist das eine Tag-Konvention? **Container**: der
bestehende `backlogTaskIds`-Puffer je Projekt.
- [x] ~~Azure DevOps: Rename-Stabilitaet, Feld fuer die Aufwandsschaetzung, Someday-Aequivalent~~ →
**ausgegliedert nach #128**, wo die drei Fragen als eigene „Vorher zu klaeren"-Liste stehen.
Kein offener Punkt dieses Issues mehr.
- [x] Versionsteile gegen `instructions/dev/version-parts.md` — fuer jedes Paket geklaert: #122
`--minor`, #123 `--major` (abweichend von der urspruenglichen Annahme), #124/#125/#126/#127
`--minor` (plus ein `--patch` fuer einen Testnachtrag in #126), Doku-Nachzug `--patch`.
- [x] Nebenbefund ohne Folgen: SPs Integrations-Seite nennt Gitea unter den Issue-Trackern, die
Perplexity-Recherche nicht. Muster 4 braucht keinen Forge-Sync.
Changelog: D16–D18 neu. D16 haelt den im Baum geprueften Befund fest, dass root: Platzierung und Eigentum zugleich entscheidet (dist_cmd.py:335) und ein stack-eigener kb/-Seitentyp deshalb nicht ausdrueckbar ist — Antwort ist das source-Idiom (fordern statt besitzen). D17 zieht daraus einen eigenen Typ mit eigener Collection statt eines entity-Subtyps. D18 stellt fest, dass die 11 vorhandenen entity_type: project-Seiten Codebasen sind und nicht dasselbe meinen — damit entfaellt die Content-Migration und der --major. Neu offen: Q6 (Typname) und Q7 (Pflichtfeld-Minimum). #117 ist damit vom kritischen Pfad genommen, #118 muss auf die neue Ziel-Collection angepasst werden.
**Changelog:** D16–D18 neu. D16 haelt den im Baum geprueften Befund fest, dass `root:` Platzierung und Eigentum zugleich entscheidet (`dist_cmd.py:335`) und ein stack-eigener `kb/`-Seitentyp deshalb nicht ausdrueckbar ist — Antwort ist das `source`-Idiom (fordern statt besitzen). D17 zieht daraus einen eigenen Typ mit eigener Collection statt eines `entity`-Subtyps. D18 stellt fest, dass die 11 vorhandenen `entity_type: project`-Seiten Codebasen sind und nicht dasselbe meinen — damit entfaellt die Content-Migration und der `--major`. Neu offen: Q6 (Typname) und Q7 (Pflichtfeld-Minimum). #117 ist damit vom kritischen Pfad genommen, #118 muss auf die neue Ziel-Collection angepasst werden.
Changelog: Q6 entschieden → D19 (project bleibt beim Vorhaben, Entity-Subtyp wird umbenannt; kein --major, weil eine Instanz ihre adoptierte types/entity.md besitzt) und D22 (Collection kb/gtd/ — der Name gehoert der Instanz, der Typname dem Stack). Q7 teilentschieden → D24 (state: plus Subtyp) und D23 (Archivierung ist ein state:-Wert, kein Ortswechsel). Neu D20/D21: person wird nicht gespalten — duplicate_titles (lint_core.py:247) verbietet zwei Seiten fuer einen Menschen, und der Review braucht ohnehin keinen Personentyp, nur Titelaufloesung. Damit bleibt die Stack-Forderung aus D16 auf genau einem Typ. Q8 neu aufgenommen mit Analyse (MCP gegen CLI; der Leseserver in INSTALL-MCP.md hat die Frage bereits beantwortet). Q7a/Q7b/Q9 als Restfragen offen; Q3 bleibt offen und wird iterativ erarbeitet.
**Changelog:** Q6 entschieden → D19 (`project` bleibt beim Vorhaben, Entity-Subtyp wird umbenannt; kein `--major`, weil eine Instanz ihre adoptierte `types/entity.md` besitzt) und D22 (Collection `kb/gtd/` — der Name gehoert der Instanz, der Typname dem Stack). Q7 teilentschieden → D24 (`state:` plus Subtyp) und D23 (Archivierung ist ein `state:`-Wert, kein Ortswechsel). Neu D20/D21: `person` wird **nicht** gespalten — `duplicate_titles` (`lint_core.py:247`) verbietet zwei Seiten fuer einen Menschen, und der Review braucht ohnehin keinen Personentyp, nur Titelaufloesung. Damit bleibt die Stack-Forderung aus D16 auf genau einem Typ. Q8 neu aufgenommen mit Analyse (MCP gegen CLI; der Leseserver in `INSTALL-MCP.md` hat die Frage bereits beantwortet). Q7a/Q7b/Q9 als Restfragen offen; Q3 bleibt offen und wird iterativ erarbeitet.
Changelog: Entwurf abgeschlossen — die restlichen Fragen sind beantwortet. Neu: D29 (Verantwortungsbereiche als subtype_field: responsibility, ohne Bereichsseiten; Feld heisst nicht area:, weil das Wort im Repo schon eine Verzeichnisebene meint), D30 (nur WAITING und follow_up_at maschinenlesbar, Person im Klartext im Titel — konsistent mit D28), D31 (minimale Kommandoflaeche: review plus erweitertes new project mit Eindeutigkeits-Preflight und Tracker-Anlage), D32 (Entity-Subtyp heisst codebase; initiative verworfen, weil es ein Vorhaben benennt und neben gtd/project nicht unterscheidbar waere), D33 (Verein vertagt, Incidents sind eine andere Form und gehoeren nicht in diese Schicht), D34 (iOS: Capture von Processing trennen, SP-Entscheidung bleibt). D15 traegt jetzt die mitentschiedene Folge, dass drei Kontexte drei Instanzen bedeuten. Abschnitt „Umsetzung" mit sieben vorgeschlagenen Paketen ergaenzt, noch nicht ausgeschnitten. kind/ wechselt von decision auf build: es wartet keine Betreiberentscheidung mehr, nur noch Umsetzungszeit.
**Changelog:** Entwurf abgeschlossen — die restlichen Fragen sind beantwortet. Neu: D29 (Verantwortungsbereiche als `subtype_field: responsibility`, **ohne** Bereichsseiten; Feld heisst nicht `area:`, weil das Wort im Repo schon eine Verzeichnisebene meint), D30 (nur `WAITING` und `follow_up_at` maschinenlesbar, Person im Klartext im Titel — konsistent mit D28), D31 (minimale Kommandoflaeche: `review` plus erweitertes `new project` mit Eindeutigkeits-Preflight und Tracker-Anlage), D32 (Entity-Subtyp heisst `codebase`; `initiative` verworfen, weil es ein Vorhaben benennt und neben `gtd/project` nicht unterscheidbar waere), D33 (Verein vertagt, Incidents sind eine andere Form und gehoeren nicht in diese Schicht), D34 (iOS: Capture von Processing trennen, SP-Entscheidung bleibt). D15 traegt jetzt die mitentschiedene Folge, dass drei Kontexte drei Instanzen bedeuten. Abschnitt „Umsetzung" mit sieben vorgeschlagenen Paketen ergaenzt, noch nicht ausgeschnitten. `kind/` wechselt von `decision` auf `build`: es wartet keine Betreiberentscheidung mehr, nur noch Umsetzungszeit.
Changelog: Ausgeschnitten. #122 (Entity-Subtyp → codebase), #123 (Typ project + Collection kb/gtd/), #124 (Provider-Schicht + SP-Adapter), #125 (wikitool review), #126 (new project erweitern), #127 (Skill weekly-review), #128 (Azure-DevOps-Adapter, prio/waiting). Der Abschnitt „Umsetzung" traegt jetzt die Reihenfolge und die Blockaden statt eines Vorschlags; die Verifikationspunkte sind in die jeweiligen Issues uebernommen und stehen hier nur noch als Uebersicht. D19/D32 haelt zusaetzlich fest, dass die Benennung an torben/nathan gegengeprueft wurde: dort liegt unter projects/ ebenfalls ausnahmslos Software.
**Changelog:** Ausgeschnitten. #122 (Entity-Subtyp → `codebase`), #123 (Typ `project` + Collection `kb/gtd/`), #124 (Provider-Schicht + SP-Adapter), #125 (`wikitool review`), #126 (`new project` erweitern), #127 (Skill `weekly-review`), #128 (Azure-DevOps-Adapter, `prio/waiting`). Der Abschnitt „Umsetzung" traegt jetzt die Reihenfolge und die Blockaden statt eines Vorschlags; die Verifikationspunkte sind in die jeweiligen Issues uebernommen und stehen hier nur noch als Uebersicht. D19/D32 haelt zusaetzlich fest, dass die Benennung an `torben/nathan` gegengeprueft wurde: dort liegt unter `projects/` ebenfalls ausnahmslos Software.
Changelog: Umsetzungstabelle nachgezogen — #122 ist erledigt (3c9d669, Stack 6.2.0). D19/D32 traegt jetzt einen Umgesetzt-Vermerk mit der bestaetigten Versionsteil-Begruendung. Der Zu-verifizieren-Punkt zu Versionsteilen ist fuer #122 abgehakt, bleibt fuer #123/#124 offen. Kein inhaltlicher Entwurfspunkt veraendert.
**Changelog:** Umsetzungstabelle nachgezogen — #122 ist erledigt (`3c9d669`, Stack 6.2.0). D19/D32 traegt jetzt einen Umgesetzt-Vermerk mit der bestaetigten Versionsteil-Begruendung. Der Zu-verifizieren-Punkt zu Versionsteilen ist fuer #122 abgehakt, bleibt fuer #123/#124 offen. Kein inhaltlicher Entwurfspunkt veraendert.
Changelog:#123 erledigt (ee24b6e, Stack 7.0.0-beta.1) — Umsetzungstabelle nachgezogen, #124/#125/#126 haengen jetzt nur noch an #124, #118 als entblockt vermerkt. D16, D24/D27, D28, D29 tragen je einen „Umgesetzt in #123"-Vermerk; D16s Vermerk haelt zusaetzlich fest, dass die Stack-Forderung fuer project/state: — anders als bei source — ein nachtraeglicher Grenzuebertritt war und deshalb --major statt der in #123 urspruenglich angenommenen --minor wurde. Der Zu-verifizieren-Punkt zu Versionsteilen ist fuer #123 abgehakt, bleibt fuer #124 offen. Kein inhaltlicher Entwurfspunkt veraendert.
**Changelog:** #123 erledigt (`ee24b6e`, Stack 7.0.0-beta.1) — Umsetzungstabelle nachgezogen, #124/#125/#126 haengen jetzt nur noch an #124, #118 als entblockt vermerkt. D16, D24/D27, D28, D29 tragen je einen „Umgesetzt in #123"-Vermerk; D16s Vermerk haelt zusaetzlich fest, dass die Stack-Forderung fuer `project`/`state:` — anders als bei `source` — ein nachtraeglicher Grenzuebertritt war und deshalb `--major` statt der in #123 urspruenglich angenommenen `--minor` wurde. Der Zu-verifizieren-Punkt zu Versionsteilen ist fuer #123 abgehakt, bleibt fuer #124 offen. Kein inhaltlicher Entwurfspunkt veraendert.
#124 erledigt (1875449, Stack 7.0.0-beta.2). Umsetzungstabelle, D31-Nachtrag und die "Zu verifizieren"-Liste aktualisiert - zwei verifizierte Korrekturen am Entwurf (keine db.json zum Lesen, sondern der Backup-Snapshot; keine automatische Projektanlage bei SP, sondern HumanInterventionRequired mit verify()). #125/#126 entblockt, #126s Body zusaetzlich um die daraus folgende Anforderung ergaenzt.
#124 erledigt (`1875449`, Stack 7.0.0-beta.2). Umsetzungstabelle, D31-Nachtrag und die "Zu verifizieren"-Liste aktualisiert - zwei verifizierte Korrekturen am Entwurf (keine `db.json` zum Lesen, sondern der Backup-Snapshot; keine automatische Projektanlage bei SP, sondern `HumanInterventionRequired` mit `verify()`). #125/#126 entblockt, #126s Body zusaetzlich um die daraus folgende Anforderung ergaenzt.
#126 ist erledigt (e4260fc/6324024, Stack 7.0.0-beta.5) - Tabelle, D31 und die
Versionsteile-Uebersicht sind aktualisiert. #127 (weekly-review-Skill) ist jetzt das einzige
freie Paket dieses Entwurfs.
#126 ist erledigt (`e4260fc`/`6324024`, Stack 7.0.0-beta.5) - Tabelle, D31 und die
Versionsteile-Uebersicht sind aktualisiert. #127 (`weekly-review`-Skill) ist jetzt das einzige
freie Paket dieses Entwurfs.
Changelog:#127 marked done in the implementation table (44909c9, Stack 7.0.0-beta.6). D10/D26, D25 and D31 each got a short "Umgesetzt in #127" addendum; the "Zu verifizieren" version-parts bullet now covers #127 too. Only #128 (Azure DevOps adapter, prio/waiting) remains open under this umbrella.
**Changelog:** #127 marked done in the implementation table (`44909c9`, Stack 7.0.0-beta.6). D10/D26, D25 and D31 each got a short "Umgesetzt in #127" addendum; the "Zu verifizieren" version-parts bullet now covers #127 too. Only #128 (Azure DevOps adapter, `prio/waiting`) remains open under this umbrella.
Changelog: Gesamtpruefung (#122–#127 im vollen Diff gegen D1–D34) und der daraus folgende Doku-Nachzug (1d695f6, Stack 7.0.0-beta.7) im Body nachgezogen.
Neu: Abschnitt „Pruefung des Ganzen" mit dem Ergebnis (keine Befunde im Code; pytest/1383, docs verify, instructions verify gruen) und Zeile 7 der Umsetzungstabelle fuer den Doku-Nachzug. D1, D2, D3, D7, D8, D23, D25 tragen jetzt je einen „Ausgeliefert in docs/knowledge-and-commitment.md"-Vermerk - das Warum dieses Entwurfs ist damit nicht mehr nur hier, sondern in der Fassung, die dist export mitliefert. D16 bekommt einen Nachtrag: der --major aus #123 hatte bis jetzt keinen Reparaturpfad in upgrade-instance.md, weil dort ein neu ausgeliefertes .template unter „new braucht keine Entscheidung" fiel; Schritt 5 und 9 tragen ihn jetzt. D10/D26 vermerkt, dass .wikitool-tasks.json erst jetzt in INSTALL.md steht statt nur in tools/CONTRACT.md. Versionsteile-Punkt um den Nachzug (--patch) ergaenzt.
Kein inhaltlicher Entwurfspunkt veraendert. #119 bleibt offen: #128 (Azure DevOps, prio/waiting) ist das einzige verbliebene Paket.
**Changelog:** Gesamtpruefung (#122–#127 im vollen Diff gegen D1–D34) und der daraus folgende Doku-Nachzug (`1d695f6`, Stack 7.0.0-beta.7) im Body nachgezogen.
Neu: Abschnitt „Pruefung des Ganzen" mit dem Ergebnis (keine Befunde im Code; `pytest`/1383, `docs verify`, `instructions verify` gruen) und Zeile 7 der Umsetzungstabelle fuer den Doku-Nachzug. D1, D2, D3, D7, D8, D23, D25 tragen jetzt je einen „Ausgeliefert in `docs/knowledge-and-commitment.md`"-Vermerk - das Warum dieses Entwurfs ist damit nicht mehr nur hier, sondern in der Fassung, die `dist export` mitliefert. D16 bekommt einen Nachtrag: der `--major` aus #123 hatte bis jetzt keinen Reparaturpfad in `upgrade-instance.md`, weil dort ein neu ausgeliefertes `.template` unter „`new` braucht keine Entscheidung" fiel; Schritt 5 und 9 tragen ihn jetzt. D10/D26 vermerkt, dass `.wikitool-tasks.json` erst jetzt in `INSTALL.md` steht statt nur in `tools/CONTRACT.md`. Versionsteile-Punkt um den Nachzug (`--patch`) ergaenzt.
Kein inhaltlicher Entwurfspunkt veraendert. #119 bleibt offen: #128 (Azure DevOps, `prio/waiting`) ist das einzige verbliebene Paket.
Nachtrag zum Doku-Nachzug (8ed8c6f, Stack 7.0.0-beta.8): stack-close Schritt 3 hat zwei docs/-Seiten gefunden, deren Begruendung frueher schon verschoben worden war, ohne dass jemand sie nachzog - beide unpruefbar, weil eine docs/-Seite per Konstruktion keinen normativen Satz traegt.
docs/why-gates-are-code.md kannte Exit 42 nur als Gate, obwohl HumanInterventionRequired (#124/#126) denselben Code verlaesst, ohne eine fuenfte Gate zu sein. Neuer Abschnitt haelt die Unterscheidung fest: die vier Gates sind eine Weigerung (moeglich, aber nicht unbesehen), der neue Fall ist das Gegenteil (gar nicht moeglich, kein Token aendert das) - gemeinsam ist nur, was der Exit-Code sagt.
docs/ownership-and-templates.md beschrieb die .template-Kategorie nur fuer bereits adoptierte Dateien; der Fall „Release liefert ein Template fuer einen Typ, den die Instanz noch gar nicht hat" - der Grenzuebertritt aus #123 - stand nirgends. Die Kategorie nennt ihn jetzt mit Verweis auf den neuen Schritt in upgrade-instance.md.
Zeile 7 der Umsetzungstabelle im Body umfasst damit 1d695f6 (beta.7) und8ed8c6f (beta.8). Am Zustand des Vorhabens aendert sich nichts: #128 bleibt das einzige offene Paket.
**Nachtrag zum Doku-Nachzug** (`8ed8c6f`, Stack 7.0.0-beta.8): `stack-close` Schritt 3 hat zwei `docs/`-Seiten gefunden, deren Begruendung frueher schon verschoben worden war, ohne dass jemand sie nachzog - beide unpruefbar, weil eine `docs/`-Seite per Konstruktion keinen normativen Satz traegt.
- `docs/why-gates-are-code.md` kannte Exit 42 nur als Gate, obwohl `HumanInterventionRequired` (#124/#126) denselben Code verlaesst, ohne eine fuenfte Gate zu sein. Neuer Abschnitt haelt die Unterscheidung fest: die vier Gates sind eine *Weigerung* (moeglich, aber nicht unbesehen), der neue Fall ist das Gegenteil (gar nicht moeglich, kein Token aendert das) - gemeinsam ist nur, was der Exit-Code sagt.
- `docs/ownership-and-templates.md` beschrieb die `.template`-Kategorie nur fuer bereits adoptierte Dateien; der Fall „Release liefert ein Template fuer einen Typ, den die Instanz noch gar nicht hat" - der Grenzuebertritt aus #123 - stand nirgends. Die Kategorie nennt ihn jetzt mit Verweis auf den neuen Schritt in `upgrade-instance.md`.
Zeile 7 der Umsetzungstabelle im Body umfasst damit `1d695f6` (beta.7) **und** `8ed8c6f` (beta.8). Am Zustand des Vorhabens aendert sich nichts: #128 bleibt das einzige offene Paket.
Geschlossen. Body auf Endstand: der Kopf sagt jetzt, dass dieses Issue nur noch Entscheidungsgeschichte ist und wo die geltenden Fassungen liegen (docs/knowledge-and-commitment.md, tools/CONTRACT.md, kb/CONTRACT.md, INSTALL.md, Skill weekly-review). Umsetzungstabelle um Zeile 7 (Doku-Nachzug, 1d695f6/8ed8c6f) ergaenzt; die vier Umsetzungsbefunde stehen jetzt gebuendelt statt ueber den Text verstreut; die Pruefung des Ganzen ist mit Ergebnis und gelaufenen Checks festgehalten.
#128 ist ausgegliedert und eigenstaendig. Sein Body traegt die sechs Regeln fuer einen zweiten Adapter ausgeschrieben, die Flaeche in chemenu/tasks/ als Tabelle, die drei Lehren aus dem SP-Adapter und die drei offenen Azure-DevOps-Fragen, die frueher hier standen. Damit zeigt es auf kein geschlossenes Issue zurueck, und dieser Entwurf wird nicht auf unbestimmte Zeit mitgeschleift. status/blocked dort entfernt (der Blocker #124 ist erledigt); prio/waiting bleibt, der Ausloeser ist die Existenz der beruflichen Instanz.
Der letzte offene Verifikationspunkt (Azure DevOps) ist entsprechend abgehakt und als „ausgegliedert nach #128" gestrichen statt stillschweigend offen gelassen.
**Geschlossen.** Body auf Endstand: der Kopf sagt jetzt, dass dieses Issue nur noch Entscheidungsgeschichte ist und wo die geltenden Fassungen liegen (`docs/knowledge-and-commitment.md`, `tools/CONTRACT.md`, `kb/CONTRACT.md`, `INSTALL.md`, Skill `weekly-review`). Umsetzungstabelle um Zeile 7 (Doku-Nachzug, `1d695f6`/`8ed8c6f`) ergaenzt; die vier Umsetzungsbefunde stehen jetzt gebuendelt statt ueber den Text verstreut; die Pruefung des Ganzen ist mit Ergebnis und gelaufenen Checks festgehalten.
**#128 ist ausgegliedert und eigenstaendig.** Sein Body traegt die sechs Regeln fuer einen zweiten Adapter ausgeschrieben, die Flaeche in `chemenu/tasks/` als Tabelle, die drei Lehren aus dem SP-Adapter und die drei offenen Azure-DevOps-Fragen, die frueher hier standen. Damit zeigt es auf kein geschlossenes Issue zurueck, und dieser Entwurf wird nicht auf unbestimmte Zeit mitgeschleift. `status/blocked` dort entfernt (der Blocker #124 ist erledigt); `prio/waiting` bleibt, der Ausloeser ist die Existenz der beruflichen Instanz.
Der letzte offene Verifikationspunkt (Azure DevOps) ist entsprechend abgehakt und als „ausgegliedert nach #128" gestrichen statt stillschweigend offen gelassen.
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.
Abgeschlossen. Der Entwurf ist vollstaendig umgesetzt (#122–#127), geprueft und ausgeliefert;
dieses Issue ist ab jetzt nur noch die Entscheidungsgeschichte, keine Spezifikation mehr.
Wer wissen will, wie die Schicht funktioniert, liest nicht hier: die Begruendung steht in
docs/knowledge-and-commitment.md(ausgeliefert, erreicht jede Instanz), die verbindlichenRegeln in
tools/CONTRACT.md(review,new project,doctor),kb/CONTRACT.mdundkb/gtd/COLLECTION.md, und die Bedienung inINSTALL.md§ Konfiguration sowie im Skillweekly-review. Der noch offene zweite Provider ist #128 und steht seit 2026-09-20 aufeigenen Beinen — mit eigener Spezifikation, ohne Rueckverweis auf dieses Issue, damit dieser
Entwurf nicht auf unbestimmte Zeit mitgeschleift wird.
Nicht gedeckt von irgendeiner mechanischen Pruefung war: dieser Entwurf selbst, die Wahl der
Versionsteile, und die Prosa jeder Instruction und jedes
docs/-Textes, der daraus entstanden ist.Ziel
Kleine Projekte jeder Art auf Chemenu verwalten: Projektbeschreibung, -status und -wissen,
beteiligte Personen, und die aktuell offenen Aufgaben (eigene und waiting-on), GTD-nah. Gesucht
war nicht ein Todo-Werkzeug, sondern die Verbindung zwischen Verpflichtungen und dem
Projektgedaechtnis in
kb/. Erreicht.Umsetzung
project→codebase(D19/D32), inkl. 11 Korpusseiten3c9d669, Stack 6.2.0)project+ Collectionkb/gtd/+ Stack-Forderung indocs verifyee24b6e, Stack 7.0.0-beta.1).wikitool-tasks.json1875449, Stack 7.0.0-beta.2)wikitool review— die fuenf Pruefungen80b57e0, Stack 7.0.0-beta.3)wikitool new projectlegt Seite und Tracker-Projekt ane4260fc/6324024, Stack 7.0.0-beta.5)weekly-review44909c9, Stack 7.0.0-beta.6)INSTALL.md,setup-instance.md,upgrade-instance.md,docs/knowledge-and-commitment.md, zwei staledocs/-Seiten1d695f6/8ed8c6f, Stack 7.0.0-beta.7/beta.8)prio/waiting— Ausloeser: die berufliche Instanz existiertPruefung des Ganzen (2026-09-20)
Alle sechs Umsetzungscommits wurden im vollen Diff gegen D1–D34 geprueft, zusammen mit
Testabdeckung, Doku-Pull-Through und Versionsteilen. Ergebnis: keine Befunde im Code - kein Bug,
keine fehlende Fehlerbehandlung, keine Invarianten-Verletzung. Jede im Body behauptete
Umsetzungskorrektur liess sich im tatsaechlichen Diff nachvollziehen (keine Fassaden-Doku), und
jeder der vier Umsetzungsbefunde (siehe unten) ist nicht nur dokumentiert, sondern getestet:
#125s Pruefung-1/4-Ueberlappung als ausdrueckliches Doppel-Finding
(
test_cli_json_and_text_agree_on_findings), #126s Tracker-vor-Seite-Reihenfolge ueber einenFehlerpfad-Test, #127s Provider-Neutralitaet am echten Skill-Text
(
test_weekly_review_skill_names_no_provider). Gelaufen und gruen:pytest(1383 Tests),tools/wikitool docs verify,tools/wikitool instructions verify.Der einzige Befund lag in der Prosa, die keine Pruefung liest - und hat Zeile 7 ausgeloest.
INSTALL.md§ Konfiguration kannte.wikitool-tasks.jsonnicht (die Datei stand nur dort, wo einAgent nachschlaegt, nicht dort, wo ein Mensch die Form nachschlaegt);
setup-instance.mdbot denTracker nie an;
upgrade-instance.mdhatte keinen Pfad fuer ein neu ausgeliefertes.template-genau den Fall, den der
--majoraus #123 erzwingt. Alle drei sind geschlossen. Dazu zweidocs/-Seiten, deren Begruendung frueher verschoben worden war:
why-gates-are-code.mdkannte Exit 42 nurals Gate (obwohl
HumanInterventionRequireddenselben Code verlaesst, ohne eine fuenfte Gate zusein), und
ownership-and-templates.mdbeschrieb die.template-Kategorie nur fuer bereitsadoptierte Dateien. Und
instructions/dev/doc-pull-through.mdhat die zwei Tabellenzeilen bekommen,deren Fehlen die Luecke ueberhaupt erst zugelassen hat.
Die vier Befunde aus der Umsetzung
Jeder ist im Entwurf unten an seiner Entscheidung vermerkt und im jeweiligen Issue ausgefuehrt:
db.json(die gibt es auf dem Desktopnicht), sondern der jueingste periodische Backup-Schnappschuss.
HumanInterventionRequired/Exit 42 statt eines automatischen Schreibvorgangs.Dopplung, sondern zwei verschiedene Aussagen - so getestet.
echten Namenskollision unterscheiden; statt eines automatischen
verify()-Laufs entscheidetdas explizite
--resume.Nicht Teil davon: #117 (Seitenvorlage je Subtyp) — mit D17 verliess das Vorhaben den
entity-Typ, das Issue steht auf eigenen Beinen. #118 (Beteiligungs-Label) ist entblockt —#123 hat die Collection
gtdund ihrengtd:-outbound:-Block inkb/entities/COLLECTION.mdangelegt; mit D28 ist es ohnehin der Ausnahmefall.
Architektur
D1 — Bruchlinie: Wissen und Verpflichtung haben verschiedene Halbwertszeiten
kb/ist ein Compiler fuer Dauerhaftes (immutableraw/, Quellenbindung, Titel-Identitaet,generierte Indizes, Gates). Eine Next Action ist das Gegenteil: unbelegt, hochfrequent,
zustandsbehaftet, nur jetzt korrekt. Beides in einer Schicht erzeugt
provenance: generalueberall, ein
kb/log.mdvoller „Task abgehakt", bedeutungslose Lint-Befunde und einMass-Update-Gate bei jedem Wochenrueckblick. GTD zieht dieselbe Linie bereits:
kb/decktAllens zwei langsamste Zeilen ab (Project Support Material, Reference) und keine andere.
Ausgeliefert in
docs/knowledge-and-commitment.md§ "Different half-lives want differentmachinery".
D2 — Muster 4: getrennte Zustaendigkeit ohne Sync
Verworfen: Export (im Tool abgehakt = Haken steht in der Ansicht, nicht in der Wahrheit),
Bidirektional (ID-Mapping, Konfliktaufloesung, Loesch-Semantik). Gewaehlt: Tracker besitzt die
Aufgaben,
kb/besitzt das Projektgedaechtnis, einziger Beruehrungspunkt ist ein Name.Ausgeliefert in
docs/knowledge-and-commitment.md§ "Pattern 4: separate ownership, nosynchronization", samt der drei verworfenen Anordnungen.
D3 — Der Join passiert zur Lesezeit, nicht als Zustand
Der Review joint ueber den normalisierten Namen, gibt einen Bericht aus, speichert nichts.
Umgesetzt in #125:
wikitool reviewspeichert nichts, nicht einmal einereports/-Datei — esist read-only und vom Iterationsbudget ausgenommen wie
search. Ausgeliefert indocs/knowledge-and-commitment.md§ "The join happens at read time, and stores nothing".D4 — Ein Container pro Projekt; eine Aufgabe ist kein Identitaetstraeger
D5 — Keine GTD-Kontexte; Prioritaet und verfuegbare Zeit sind die Achsen
Von Allens vier Kriterien entfaellt der Kontext (ein Schreibtisch). Folge: jede Aufgabe braucht
eine Aufwandsschaetzung, und die pflegt per Hand niemand ohne Feedback — ein Werkzeug mit
Soll-Ist-Rueckmeldung ist kategorial besser, nicht nur bequemer. Topkriterium der Werkzeugwahl.
Offen geblieben: der Rueckblick liest die Schaetzung bis heute nicht — ob er das soll, ist eine
Frage in #128.
D6 — Projektlose Sammelstelle: ein Inbox-Container im Tracker
D7 — Zwei Wahrheiten ueber „Status" sind verboten (Invariante 8)
kb/-Seite = dauerhafte Charakterisierung. Tracker = Momentzustand. Die Seite fasst dieAufgabenliste nie zusammen. Folgewirkung: der Agent hat ausserhalb des Rueckblicks keinen
Anlass, Aufgaben zu lesen — davon lebt die kleine Kommandoflaeche in D31.
Ausgeliefert in
docs/knowledge-and-commitment.md§ "Status has exactly one home" - samt derFolgewirkung auf die Kommandoflaeche, die dort der Grund fuer ihre Groesse ist.
D8 — Der Name erbt die Pflichten eines Identifiers
(1) Vor Anlage global case-normalisierte Eindeutigkeit erzwingen; (2) Rename ist explizit und
selten, mit Preflight, dann Tracker und
kb/-Seite im selben Ablauf; (3) keine automatischeRuecksynchronisierung, sondern periodischer Set-Vergleich der normalisierten Namen; (4) der
Review meldet beidseitig unmatched — erst dadurch wird ein Rename ein sichtbares Ereignis
statt eines stillen Datenverlusts; (5) bei Hierarchie global eindeutige Namen oder
menschenlesbarer Vollpfad.
Umgesetzt in #125:
normalize_project_name(aus #124) treibt sowohl Pruefung 3 (Tracker ohnekb/-Seite) als auch Pruefung 4 (kb/-Seite ohne Tracker-Projekt) — der beidseitigeunmatched-Bericht steht. Ausgeliefert in
docs/knowledge-and-commitment.md§ "One name,carrying the duties of an identifier".
D9/D30 — Waiting-For: Konvention, und nur zwei Teile davon maschinenlesbar
Nur org-mode bildet
WAITINGnativ ab; ueberall sonst definieren wir es selbst, was dieWerkzeugwahl entkoppelt. Maschinenlesbar sind ausschliesslich der
WAITING-Status undfollow_up_at(ein eigenes Datum, ausdruecklich nicht das Faelligkeitsdatum). DiePerson steht im Klartext im Aufgabentitel — Pruefung 2 braucht das Datum, nicht die Person,
und D28 hat fuer Personen ohnehin entschieden, dass eine Erwaehnung genuegt. Das haelt die
Adapterflaeche minimal und funktioniert in jedem Provider identisch. Preis: keine Auswertung
„worauf warte ich bei X?". Taskwarriors
wait:ist semantisch ungeeignet.Umgesetzt in #124: fuer Super Productivity ist
WAITINGeine Tag namenswaiting(case-insensitiv),
follow_up_atdie Aufgabe eigener Reminder-Zeitstempel (remindAt) —ausdruecklich nicht
dueDay/dueWithTime. Pruefung 2 in #125 liest das genau so. DieseRegel bindet auch jeden kuenftigen Adapter und steht deshalb ausgeschrieben in #128.
D11 — Gitea bleibt fuer Stack-Arbeitspakete, nicht fuer persoenliche Verpflichtungen
Zwei Arbeitsklassen. Der Einwand aus
instructions/dev/issue-tracking.md(„eine Markdown-Dateihat keinen Zustand und kostet einen Publish") hat allerdings den urspruenglichen Entwurf
gekippt, Verpflichtungen als Dateien im Repo zu halten.
D12 — Zielort: die private Arbeitsinstanz, nicht dieses Testbett
Maschinerie in den Stack (wandert per
upstream merge), Inhalte mit echten Personen in denClone.
D13 — Nichts Aufgabenfoermiges wird gepublisht
D14 — Kein Verlauf noetig
Damit faellt das Kriterium, das das Feld sonst halbiert haette („Was war am 17. Juni offen?");
org-mode verliert seinen groessten Vorsprung.
D15 — Eine Instanz, ein Provider; keine Migration zwischen Providern
Folge, die mitentschieden ist: drei Kontexte heissen drei Instanzen — beruflich, privat,
spaeter ggf. Verein. Drei getrennte Wissensbasen, nicht eine mit drei Faechern. Das ist der Grund,
warum #128 auf die Existenz der beruflichen Instanz wartet und nicht auf Vorrat gebaut wird.
Typmodell
D16 — Der Stack kann einen Seitentyp nicht besitzen; er muss ihn fordern
Befund (im Baum geprueft):
root:traegt zwei Bedeutungen zugleich — gegen welchen Rootbase_diraufloest und wem der Typ gehoert.tools/chemenu/commands/dist_cmd.py:335:(frontmatter.get("root") or "kb") != "kb".root: kb→ ships als.template→ instanzeigen.Ein stack-eigener Seitentyp, der nach
kb/schreibt, ist nicht ausdrueckbar.Antwort: fordern statt besitzen — das Idiom fuer
source(„There must be a type-specdeclaring
name: sourcewhose schema requiresraw_files:", geprueft vondocs verify).docs verify(FAIL)base_dirCustom Fields on top sind nativ moeglich (
additionalProperties: falsesteht im Schema derInstanz). Verworfen: ein
owner:-Feld, das Platzierung und Eigentum trennt;Schema-Komposition aus stack-eigener Basis plus Instanz-Erweiterung.
Umgesetzt in #123:
project/state:steht nebensource/raw_files:inSTACK_REQUIRED_TYPES. Anders als beisource(das die Forderung von Anfang an trug, vor jederVersionierung) war das hier ein nachtraeglicher Grenzuebertritt: eine Instanz, die die neue
tools/-Fassung uebernimmt, ohnetypes/project.md.templatezu adoptieren, faellt beidocs verifydurch, wo sie vorher bestand. Deshalb--majorstatt der urspruenglich angenommenen--minor.Nachtrag (Stack 7.0.0-beta.7/beta.8): dieser Grenzuebertritt hatte zunaechst keinen
Reparaturpfad in der Upgrade-Prozedur.
upgrade-instance.mdSchritt 5 sagte „newbraucht keineEntscheidung", und die Schritt-6-Tabelle sagt, instanzeigene Dateien koennten dort gar nicht
auftauchen - beides fuer sich richtig, zusammen irrefuehrend. Schritt 5 benennt die Ausnahme jetzt,
Schritt 9 traegt die Reparatur, und
docs/ownership-and-templates.mdnennt den Fall als die eineGestalt, in der „das Upgrade schreibt diese Datei nie" zu Arbeit wird.
D17 — Eigener Typ und eigene Collection, kein
entity-SubtypEin geforderter Typname spiegelt das
source-Muster; eine Forderung nach einem Enum-Wertin einem instanzeigenen Schema waere genau das, worauf man sich nicht verlassen kann.
D18 —
entity_type: projectmeint etwas anderes: Homonyme, keine DublettenDie 11 Seiten unter
kb/entities/projects/sind Codebasen. Der neue Typ ist ein Vorhaben.Niemand wartet auf
BCDModule. Die Linie verlaeuft zwischen Artefakt („Chemenu",„die Kueche") und Vorhaben (gtd: „Chemenu 7.0 ausliefern", „Kueche renovieren").
D19/D32 —
projectbleibt beim Vorhaben; der Entity-Subtyp heisstcodebaseBetreiberentscheidung 2026-09-19: intuitiver schlaegt billiger.
codebasesteht bereitswoertlich im Collection-Contract („Codebases and initiatives"), deckt alle elf Seiten ab und
rutscht weder in
toolnoch insystem.Erwogen und verworfen:
initiative— benennt ein Vorhaben und stuende damit auf derselbenSeite der Linie wie
gtd/project; nebeneinander waeren beide nicht unterscheidbar, was denIntuitionsgewinn aufzehrt. Das Generalitaets-Bedenken („in anderen Repos liegt hier auch
Nicht-Software") traegt nicht: der Enum gehoert der Instanz (D16), jede darf sich einen Subtyp
ergaenzen; ausgeliefert wird nur der Startwortschatz im
.template. Geprueft wurde das antorben/nathan, wo unterprojects/ebenfalls ausnahmslos Software liegt.Umgesetzt in #122:
kb/entities/codebases/mit elf Seiten,--minor, weildist upgradeeine.template-basierte Datei nie schreibt und eine adoptierte Instanz ihrenproject-Wert damitbehaelt.
D20 —
personwird nicht gespaltenduplicate_titlesist ein Lint-Befund ueber ganzkb/(tools/chemenu/lint_core.py:247); eingtd/personnebenentity/personwaere genau diese Kollision. Der Unterschied zu D18 liegt imReferenten: bei
projectzwei Dinge, ein Wort (Homonym, also spalten); beipersonderselbeReferent — der Kollege, auf den du wartest, ist derselbe, der eine Quelle geschrieben hat.
D21 — Der Review braucht keinen Personentyp
Titelaufloesung genuegt. Die Stack-Forderung aus D16 bleibt damit auf genau einem Typ.
D22 — Die Collection gehoert der Instanz, der Typname dem Stack
base_dir:steht im instanzeigenen Type-Spec, undkb/CONTRACT.mdleitetrequired_by_stack:daraus ab. Diese Instanz waehlt
kb/gtd/; eine andere darfkb/vorhaben/waehlen. Damitist der Einwand entschaerft, eine Methodik in den Stack zu backen: „GTD" steht im
Verzeichnisnamen dieser Instanz, nicht in der Forderung.
D23 — Archivierung ist ein
state:-Wert, kein OrtswechselEin abgeschlossenes Vorhaben ist genau dann am wertvollsten; Wegsortieren wuerde es verstecken.
Der Review verzweigt ohnehin auf
state:, und ein Verschieben wuerde die eine Area-Ebeneverbrauchen, die der Subtyp belegt.
Ausgeliefert in
docs/knowledge-and-commitment.md§ "A finished initiative is a state, not alocation", zusammen mit D24/D27s Begruendung fuer
dormant.D24/D27 —
state:traegtactive/dormant/completed/abandonedactivedormantcompletedabandoneddormantgegen stehengeblieben ist Zufall gegen Absicht: ohne diesen Wert meldet derRueckblick jede Woche dieselben bewusst pausierten Vorhaben als „stalled", und nach drei Wochen
liest niemand den Bericht mehr.
completedgegenabandonedist fuer den Review dasselbe,fuer das Wissen das Gegenteil.
Die Werte sind englisch, weil Enum-Werte Identifier sind (
types/type-spec.md). Dielayout:-Titel bleiben Anzeigetext und deutsch.Umgesetzt in #123:
types/project.schema.yamlfuehrtstate:genau so. Pruefung 1 in #125liest genau diese vier Werte: nur
activemahnt bei null offenen Posten, die anderen drei nie —verifiziert per Fixture-Test je Wert.
D29 — Schubladen:
responsibility:als Subtyp, ohne BereichsseitenVerantwortungsbereiche werden der Subtyp und ueber
layout:zu Verzeichnissen (kb/gtd/haus/).Keine Area-of-Focus-Seiten — Betreiber-Nachtrag 2026-09-19, die Implikation war zu stark.
Damit entfaellt die Lint-Kopplung, die sonst noetig gewesen waere, um Verzeichnisname und
Bereichsseite synchron zu halten.
Das Feld heisst nicht
area:. „Area" bedeutet in diesem Repo bereits eine Verzeichnisebeneinnerhalb einer Collection (
kb/CONTRACT.md); zwei Bedeutungen fuer ein Wort im selben Baum ist,wie Missverstaendnisse anfangen. Bereichsseiten sind nicht verboten, nur nicht gefordert.
Umgesetzt in #123: Startwortschatz
haus/finanzen/technikintypes/project.mdslayout:.Der Wochenrueckblick
D10/D26 — Die Pruefliste
state: activefollow_up_atkb/-Seitekb/-Seiteactive, aber keine offene Schleifestate:modifiedWaiting-For nennt Person ohnekb/-SeiteRauschbremse fuer Pruefung 3: eine Altersschwelle, kein Marker im Tracker — ein Marker waere
ein zweites Vokabular in Pflege, und Muster 4 lebt davon, dass es genau eine Kopplung gibt.
Drei Schwellwerte sind Konfiguration, nicht Schema: n Tage (2), n Wochen (3), n Monate (5).
Umgesetzt in #124:
.wikitool-tasks.jsonsthresholds-Block(
stalled_waiting_days/unpaged_project_weeks/someday_stale_months) traegt genau diese drei;seit Stack 7.0.0-beta.7 steht die vollstaendige Form der Datei in
INSTALL.md§ Konfiguration.Umgesetzt in #125:
wikitool reviewfuehrt alle fuenf Pruefungen aus, mit Pruefung 3 und 4 alsden zwei Richtungen desselben Namensabgleichs (siehe D8). Umgesetzt in #127:
instructions/weekly-review/SKILL.mdfuehrt das Gespraech, das aus jeder der fuenf Pruefungen eineEntscheidung macht — je Befund mindestens zwei Handlungsoptionen und ein Unterscheidungsmerkmal,
provider-neutral (D25).
D28 — Personen: Erwaehnung statt Seite
Die Projektseite traegt
## Beteiligte, wo eine Person mit ein bis zwei Zeilen charakterisiertwird — ohne eigene Seite, ohne Wikilink. Eine eigene Seite bekommt jemand erst, wenn er fuer
das Wissen zaehlt; dann wird aus der Erwaehnung eine Kante mit dem Label aus #118. Bewusste
Ausnahme von
kb/CONTRACT.md§ „Every page should", gehalten von der Schreibdisziplin, nichtvon einem Pruefer.
Umgesetzt in #123:
types/project.mdundkb/gtd/COLLECTION.mdnennen diese Ausnahme beideexplizit, mit Begruendung — sonst liest die naechste Session sie als Fehler.
Die Provider-Schicht
D25 — Zugriffsschicht: ausschliesslich die
wikitool-CLIKein MCP fuer die Task-Schicht; der vorhandene Leseserver bekommt keine Task-Tools. Wird
spaeter ein entfernter Konsument gebraucht, wird es ein Tool auf dem vorhandenen Server,
gleicher Kern, gleicher Golden-Test.
Begruendung entlang
INSTALL-MCP.md(„ein zweiter Konsument desselben Kerns, nicht ein zweitesProgramm"): die Achse ist nicht „CLI oder MCP", sondern welcher Konsument mit welchen
Faehigkeiten. Fuer eine lokale Session mit Checkout und Shell kostet MCP Komponierbarkeit (jeder
Aufruf eine Modellrunde) und eine zweite Flaeche. Dazu: die Gates sind Exit-Codes. Exit 42
wirkt, weil ein Prozess sich weigert — eine MCP-Schicht muesste das uebersetzen und schoebe ein
Gate zurueck Richtung Prosa, was
docs/why-gates-are-code.mdgerade vermeiden will.Nebenbefund: MCP mit verzoegertem Tool-Laden ist selective disclosure, nur vom Harness
ausgefuehrt statt im Prompt.
Umgesetzt in #124:
chemenu.tasks.protocol/.superproductivitysind reine Bibliothek,importiert von
wikitool doctor; #125 liest sie ebenso als Bibliothek. Umgesetzt in #127:weekly-reviews Skill-Body nennt keinen Provider und keine Datei-/API-Form — ein Regressionstesthaelt das am echten Skill-Text fest. Ausgeliefert in
docs/knowledge-and-commitment.md§ "Which tracker is a decision the stack does not make".
D31 — Die Kommandoflaeche bleibt minimal
Ein Lesekommando — der Bericht. Die Projektanlage reitet auf dem vorhandenen Seiten-Scaffold
mit: nach Eindeutigkeits-Preflight (D8) entstehen Seite und Tracker-Projekt gleichen Namens.
Ein Geburtsort, ein Name.
Tracker-zuerst-Projekte bleiben der Normalfall und laufen weiter ohne Seite — genau das mahnt
Pruefung 3 an. Ein voller Kommandobaum wurde verworfen: D7 nimmt dem Agenten den Anlass,
Aufgaben ausserhalb des Rueckblicks zu lesen, und Entdeckungskosten wachsen mit der Zahl der
Kommandos — der eine Nachteil, den D25 der CLI zugesteht.
Beide Haelften stehen (#125 bzw. #126). Praezisierungen aus der Umsetzung: fuer Super
Productivity ist die Tracker-Anlage kein Automatismus, weil dessen lokale REST-API keinen
POST /projectshat (verifiziert gegenelectron/local-rest-api-handler.service.ts,2026-09-19) — sie wird zu einem verifizierten Mensch-in-der-Schleife-Schritt
(
chemenu.errors.HumanInterventionRequired). Und statt eines automatischenverify()-Laufsentscheidet ein explizites
--resume, ob ein Tracker-Treffer als bestaetigte Fortsetzung gilt:ein zustandsloser CLI-Prozess kann ihn nicht von einer echten Namenskollision unterscheiden.
#127 fuegt der Kommandoflaeche bewusst nichts hinzu — jede aufgabenseitige Handlung bleibt
eine Handlung im Tracker selbst.
Konsequenzen fuer das Interface
Backup-Schnappschuss (headless), schreiben ueber die lokale REST-API (Bearer-Token, App muss
laufen). Direktes Schreiben in
db.jsonist nicht vorgesehen.ENVIRONMENT.md(keine Autoritaet,keine Credentials).
.wikitool-tasks.json, gitignored sofern Tokens darin liegen; nimmt auchdie drei Schwellwerte auf.
scheitert nach dem Tool-Error-Contract mit Exit 1 — oder, wenn die fehlende Faehigkeit ein Mensch
ausgleichen kann, mit
HumanInterventionRequired/Exit 42. Beides ist "die Instruction erfaehrtnichts vom Provider" - der Unterschied ist nur, ob ein Mensch die Luecke schliessen kann.
db.jsonhat kein versioniertes Public-Schema. EinAdapter, der still falsch parst, liefert einen Bericht, der plausibel aussieht und falsch ist.
Provider je Einsatzkontext
D33 — Der Verein wird vertagt
Kein dritter Adapter auf Vorrat. Wenn er kommt, wird der Verein eine eigene Instanz (D15).
Und Incidents gehoeren nicht in diese Schicht: ein Incident wird gemeldet, triagiert,
geloest und wiederholt sich — eine andere Form als eine Verpflichtung. Eigene Designfrage.
D34 — iOS: Capture von Processing trennen
GTD trennt Erfassen von Verarbeiten; erfassen darf an vielen Orten passieren, verarbeitet wird
an einer Stelle. Unterwegs landet etwas in der vorhandenen Nextcloud, verarbeitet wird am
Schreibtisch in SP. Damit ist SPs schwache iOS-Seite kein Architekturproblem. Dasselbe Muster
faehrt dieser Stack fuer Wissen bereits:
incoming/plusraw promote, bzw.submitmit demUpload Review Gate. Optionale spaetere Ausbaustufe: der Rueckblick prueft, ob der
Capture-Eingang verstaubt.
Marktrecherche: die zwei Befunde, die zaehlen
Vollrecherche 2026-09-17 (Perplexity), rund 25 Kandidaten.
MCP-Asymmetrie. Bei dateibasierten Werkzeugen ist MCP Bequemlichkeit — stirbt er, liest der
Agent die Dateien. Bei dienstbasierten ist er der einzige Zugriffspfad — stirbt er, ist der
Review blind. Fast die gesamte gefundene Landschaft: Einzelmaintainer, 0–2 Stars,
One-shot-Releases. Mit D25 gegenstandslos.
Muster 4 verschiebt die Gewichte. Projektmetadaten im Tool: irrelevant. Projekt-CRUD:
nice-to-have, entscheidend ist Lesen. Stabiler Name: zentral. Zugriff ohne laufenden Dienst:
hoch. Schaetzung/Ist/Tagesplanung: Topkriterium.
Ausgeschieden: alles Proprietaere (Open Source und Self-Hosting sind hartes Kriterium);
Leantime und Vikunja privat an „keine weitere Webapp"; org-mode mit D14; Focalboard und Tracks
ueber zwoelf Monate ohne Release.
Verifikationspunkte — abgeschlossen
super-productivity/super-productivity(master):GET /projectsexistiert,POST /projectsnicht.SuperProductivityWriter.create_project; #126 nutzt denselben Preflight (find_project).bestehende
backlogTaskIds-Puffer je Projekt.Azure DevOps: Rename-Stabilitaet, Feld fuer die Aufwandsschaetzung, Someday-Aequivalent→ausgegliedert nach #128, wo die drei Fragen als eigene „Vorher zu klaeren"-Liste stehen.
Kein offener Punkt dieses Issues mehr.
instructions/dev/version-parts.md— fuer jedes Paket geklaert: #122--minor, #123--major(abweichend von der urspruenglichen Annahme), #124/#125/#126/#127--minor(plus ein--patchfuer einen Testnachtrag in #126), Doku-Nachzug--patch.Perplexity-Recherche nicht. Muster 4 braucht keinen Forge-Sync.
Changelog: D16–D18 neu. D16 haelt den im Baum geprueften Befund fest, dass
root:Platzierung und Eigentum zugleich entscheidet (dist_cmd.py:335) und ein stack-eigenerkb/-Seitentyp deshalb nicht ausdrueckbar ist — Antwort ist dassource-Idiom (fordern statt besitzen). D17 zieht daraus einen eigenen Typ mit eigener Collection statt einesentity-Subtyps. D18 stellt fest, dass die 11 vorhandenenentity_type: project-Seiten Codebasen sind und nicht dasselbe meinen — damit entfaellt die Content-Migration und der--major. Neu offen: Q6 (Typname) und Q7 (Pflichtfeld-Minimum). #117 ist damit vom kritischen Pfad genommen, #118 muss auf die neue Ziel-Collection angepasst werden.Changelog: Q6 entschieden → D19 (
projectbleibt beim Vorhaben, Entity-Subtyp wird umbenannt; kein--major, weil eine Instanz ihre adoptiertetypes/entity.mdbesitzt) und D22 (Collectionkb/gtd/— der Name gehoert der Instanz, der Typname dem Stack). Q7 teilentschieden → D24 (state:plus Subtyp) und D23 (Archivierung ist einstate:-Wert, kein Ortswechsel). Neu D20/D21:personwird nicht gespalten —duplicate_titles(lint_core.py:247) verbietet zwei Seiten fuer einen Menschen, und der Review braucht ohnehin keinen Personentyp, nur Titelaufloesung. Damit bleibt die Stack-Forderung aus D16 auf genau einem Typ. Q8 neu aufgenommen mit Analyse (MCP gegen CLI; der Leseserver inINSTALL-MCP.mdhat die Frage bereits beantwortet). Q7a/Q7b/Q9 als Restfragen offen; Q3 bleibt offen und wird iterativ erarbeitet.Changelog: Entwurf abgeschlossen — die restlichen Fragen sind beantwortet. Neu: D29 (Verantwortungsbereiche als
subtype_field: responsibility, ohne Bereichsseiten; Feld heisst nichtarea:, weil das Wort im Repo schon eine Verzeichnisebene meint), D30 (nurWAITINGundfollow_up_atmaschinenlesbar, Person im Klartext im Titel — konsistent mit D28), D31 (minimale Kommandoflaeche:reviewplus erweitertesnew projectmit Eindeutigkeits-Preflight und Tracker-Anlage), D32 (Entity-Subtyp heisstcodebase;initiativeverworfen, weil es ein Vorhaben benennt und nebengtd/projectnicht unterscheidbar waere), D33 (Verein vertagt, Incidents sind eine andere Form und gehoeren nicht in diese Schicht), D34 (iOS: Capture von Processing trennen, SP-Entscheidung bleibt). D15 traegt jetzt die mitentschiedene Folge, dass drei Kontexte drei Instanzen bedeuten. Abschnitt „Umsetzung" mit sieben vorgeschlagenen Paketen ergaenzt, noch nicht ausgeschnitten.kind/wechselt vondecisionaufbuild: es wartet keine Betreiberentscheidung mehr, nur noch Umsetzungszeit.Changelog: Ausgeschnitten. #122 (Entity-Subtyp →
codebase), #123 (Typproject+ Collectionkb/gtd/), #124 (Provider-Schicht + SP-Adapter), #125 (wikitool review), #126 (new projecterweitern), #127 (Skillweekly-review), #128 (Azure-DevOps-Adapter,prio/waiting). Der Abschnitt „Umsetzung" traegt jetzt die Reihenfolge und die Blockaden statt eines Vorschlags; die Verifikationspunkte sind in die jeweiligen Issues uebernommen und stehen hier nur noch als Uebersicht. D19/D32 haelt zusaetzlich fest, dass die Benennung antorben/nathangegengeprueft wurde: dort liegt unterprojects/ebenfalls ausnahmslos Software.Changelog: Umsetzungstabelle nachgezogen — #122 ist erledigt (
3c9d669, Stack 6.2.0). D19/D32 traegt jetzt einen Umgesetzt-Vermerk mit der bestaetigten Versionsteil-Begruendung. Der Zu-verifizieren-Punkt zu Versionsteilen ist fuer #122 abgehakt, bleibt fuer #123/#124 offen. Kein inhaltlicher Entwurfspunkt veraendert.Changelog: #123 erledigt (
ee24b6e, Stack 7.0.0-beta.1) — Umsetzungstabelle nachgezogen, #124/#125/#126 haengen jetzt nur noch an #124, #118 als entblockt vermerkt. D16, D24/D27, D28, D29 tragen je einen „Umgesetzt in #123"-Vermerk; D16s Vermerk haelt zusaetzlich fest, dass die Stack-Forderung fuerproject/state:— anders als beisource— ein nachtraeglicher Grenzuebertritt war und deshalb--majorstatt der in #123 urspruenglich angenommenen--minorwurde. Der Zu-verifizieren-Punkt zu Versionsteilen ist fuer #123 abgehakt, bleibt fuer #124 offen. Kein inhaltlicher Entwurfspunkt veraendert.#124 erledigt (
1875449, Stack 7.0.0-beta.2). Umsetzungstabelle, D31-Nachtrag und die "Zu verifizieren"-Liste aktualisiert - zwei verifizierte Korrekturen am Entwurf (keinedb.jsonzum Lesen, sondern der Backup-Snapshot; keine automatische Projektanlage bei SP, sondernHumanInterventionRequiredmitverify()). #125/#126 entblockt, #126s Body zusaetzlich um die daraus folgende Anforderung ergaenzt.#125 erledigt (
80b57e0, Stack 7.0.0-beta.3) - Umsetzungstabelle, D3, D8, D9/D30, D24/D27, D10/D26, D25 und D31 entsprechend nachgezogen. #126 und #127 sind jetzt frei.#126 ist erledigt (
e4260fc/6324024, Stack 7.0.0-beta.5) - Tabelle, D31 und dieVersionsteile-Uebersicht sind aktualisiert. #127 (
weekly-review-Skill) ist jetzt das einzigefreie Paket dieses Entwurfs.
Changelog: #127 marked done in the implementation table (
44909c9, Stack 7.0.0-beta.6). D10/D26, D25 and D31 each got a short "Umgesetzt in #127" addendum; the "Zu verifizieren" version-parts bullet now covers #127 too. Only #128 (Azure DevOps adapter,prio/waiting) remains open under this umbrella.Changelog: Gesamtpruefung (#122–#127 im vollen Diff gegen D1–D34) und der daraus folgende Doku-Nachzug (
1d695f6, Stack 7.0.0-beta.7) im Body nachgezogen.Neu: Abschnitt „Pruefung des Ganzen" mit dem Ergebnis (keine Befunde im Code;
pytest/1383,docs verify,instructions verifygruen) und Zeile 7 der Umsetzungstabelle fuer den Doku-Nachzug. D1, D2, D3, D7, D8, D23, D25 tragen jetzt je einen „Ausgeliefert indocs/knowledge-and-commitment.md"-Vermerk - das Warum dieses Entwurfs ist damit nicht mehr nur hier, sondern in der Fassung, diedist exportmitliefert. D16 bekommt einen Nachtrag: der--majoraus #123 hatte bis jetzt keinen Reparaturpfad inupgrade-instance.md, weil dort ein neu ausgeliefertes.templateunter „newbraucht keine Entscheidung" fiel; Schritt 5 und 9 tragen ihn jetzt. D10/D26 vermerkt, dass.wikitool-tasks.jsonerst jetzt inINSTALL.mdsteht statt nur intools/CONTRACT.md. Versionsteile-Punkt um den Nachzug (--patch) ergaenzt.Kein inhaltlicher Entwurfspunkt veraendert. #119 bleibt offen: #128 (Azure DevOps,
prio/waiting) ist das einzige verbliebene Paket.Nachtrag zum Doku-Nachzug (
8ed8c6f, Stack 7.0.0-beta.8):stack-closeSchritt 3 hat zweidocs/-Seiten gefunden, deren Begruendung frueher schon verschoben worden war, ohne dass jemand sie nachzog - beide unpruefbar, weil einedocs/-Seite per Konstruktion keinen normativen Satz traegt.docs/why-gates-are-code.mdkannte Exit 42 nur als Gate, obwohlHumanInterventionRequired(#124/#126) denselben Code verlaesst, ohne eine fuenfte Gate zu sein. Neuer Abschnitt haelt die Unterscheidung fest: die vier Gates sind eine Weigerung (moeglich, aber nicht unbesehen), der neue Fall ist das Gegenteil (gar nicht moeglich, kein Token aendert das) - gemeinsam ist nur, was der Exit-Code sagt.docs/ownership-and-templates.mdbeschrieb die.template-Kategorie nur fuer bereits adoptierte Dateien; der Fall „Release liefert ein Template fuer einen Typ, den die Instanz noch gar nicht hat" - der Grenzuebertritt aus #123 - stand nirgends. Die Kategorie nennt ihn jetzt mit Verweis auf den neuen Schritt inupgrade-instance.md.Zeile 7 der Umsetzungstabelle im Body umfasst damit
1d695f6(beta.7) und8ed8c6f(beta.8). Am Zustand des Vorhabens aendert sich nichts: #128 bleibt das einzige offene Paket.Geschlossen. Body auf Endstand: der Kopf sagt jetzt, dass dieses Issue nur noch Entscheidungsgeschichte ist und wo die geltenden Fassungen liegen (
docs/knowledge-and-commitment.md,tools/CONTRACT.md,kb/CONTRACT.md,INSTALL.md, Skillweekly-review). Umsetzungstabelle um Zeile 7 (Doku-Nachzug,1d695f6/8ed8c6f) ergaenzt; die vier Umsetzungsbefunde stehen jetzt gebuendelt statt ueber den Text verstreut; die Pruefung des Ganzen ist mit Ergebnis und gelaufenen Checks festgehalten.#128 ist ausgegliedert und eigenstaendig. Sein Body traegt die sechs Regeln fuer einen zweiten Adapter ausgeschrieben, die Flaeche in
chemenu/tasks/als Tabelle, die drei Lehren aus dem SP-Adapter und die drei offenen Azure-DevOps-Fragen, die frueher hier standen. Damit zeigt es auf kein geschlossenes Issue zurueck, und dieser Entwurf wird nicht auf unbestimmte Zeit mitgeschleift.status/blockeddort entfernt (der Blocker #124 ist erledigt);prio/waitingbleibt, der Ausloeser ist die Existenz der beruflichen Instanz.Der letzte offene Verifikationspunkt (Azure DevOps) ist entsprechend abgehakt und als „ausgegliedert nach #128" gestrichen statt stillschweigend offen gelassen.
torben referenced this issue2026-09-20 15:36:50 +00:00
torben referenced this issue2026-09-25 19:14:36 +00:00
torben referenced this issue2026-09-30 05:15:50 +00:00