37 Releases 37 Tags

RSS Feed

• v7.0.0 4446424e01

  Compare

  v7.0.0 Stable

  torben released this 2026-09-22 20:56:08 +00:00 | 88 commits to main since this release

  7.0.0 - 2026-09-22 - Task-Tracker-Anbindung: Vorhaben als Seitenart, Verpflichtungsschicht, Weekly Review als Read-Time-Join

  Author: Torben Nehmer

  Breaking Change:

  • docs verify now requires an adopted project type-spec (schema requiring state:) and its kb/gtd/ collection - an instance must adopt types/project.md(.schema.yaml) and kb/gtd/COLLECTION.md from their .template before docs verify passes again
  • superproductivity's provider section in .wikitool-tasks.json now requires 'access' ('api' or 'snapshot'), no default and no fallback between the two; 'db_path' no longer exists at all. An existing config must add 'access' and, if it used 'db_path', switch to 'backups_dir' (see INSTALL.md's example).

  Migration: none required - No kb/ page content changes - the break is confined to .wikitool-tasks.json, an instance-owned, gitignored file every operator already edits by hand per INSTALL.md's example.

  High impact

  • SP-Zugriffsweg explizit (access: api/snapshot, #133) und follow_up_at-Korrektur (dueWithTime/dueDay, #135)

  Medium impact

  • Typ project und Collection kb/gtd/: das Vorhaben als eigene Seitenart
  • Task-tracker provider layer, with a Super Productivity adapter
  • wikitool review: the weekly GTD review as a read-time join
  • wikitool new project: Seite und Tracker-Projekt unter einem Namen
  • Skill weekly-review: turning wikitool review's findings into decisions
  • Doku-Nachzug zu #119: die Verpflichtungsschicht erreicht Installation, Setup und docs/
  • task new: einen zweiten Schreibweg in den Tracker (ein Posten, keine Seite)
  • wiki-ingest: raw accept rückt hinter die Verpflichtungsentscheidung
  • Weekly review proposes task new/task close; tracker gains a closing write path

  Low impact

  • new project: Testabdeckung fuer die required-responsibility-Ablehnung
  • docs/-Nachzug: Exit 42 als Haltung, und die Adoption eines neu ausgelieferten Templates
  • Skill-Namensfamilien: weekly-review -> gtd-weekly-review, dritte Person in allen Descriptions
  • Veraltete Skill-Aufzaehlungen in der Instruction-Schicht nachgezogen
  • gtd-weekly-review: task new nachgezogen, veralteter Begründungszeiger korrigiert
  • instructions/CONTRACT.md drops other files' step counts from the copy-in-checklist rationale

  Dieser Kandidat bringt die Verpflichtungsschicht in den Stack: ein neuer Seitentyp project und
  die Collection kb/gtd/ geben dem Vorhaben (Ziel, Beteiligte, dauerhafter Status) eine eigene
  Seitenart neben dem Artefakt; eine Task-Tracker-Provider-Schicht (chemenu.tasks) verbindet das
  mit einem echten Tracker, mit Super Productivity als erstem Adapter; wikitool review liest beide
  Seiten zur Laufzeit zusammen statt sie zu synchronisieren, und das neue Skill
  gtd-weekly-review macht dessen Funde zu Entscheidungen. Der Tracker bekommt zwei neue
  Schreibwege dazu (task new, task close) neben den bestehenden Lesekommandos, und wiki-ingest
  stellt seither bei jeder Quelle die Verpflichtungsfrage in beide Richtungen. Zwei
  Grenzübertritte kommen mit: docs verify verlangt jetzt den adoptierten Typ project und die
  Collection kb/gtd/, und .wikitool-tasks.jsons Provider-Abschnitt verlangt ein explizites
  access (api/snapshot) ohne Fallback auf db_path. Der Rest der Bumps sind Nacharbeiten und
  kleinere Korrekturen an genau dieser Naht - Doku-Nachzug, Namensfamilien, eine korrigierte
  Zurückweisungs-Meldung, und die hier laufende Bereinigung veralteter Schrittzahlen in der
  Instruction-Schicht.

  Typ project und Collection kb/gtd/: das Vorhaben als eigene Seitenart

  Gitea #119 (Paket #123): ein neuer Seitentyp project fuer das Vorhaben - Ziel, Beteiligte,
  dauerhafter Status, offene Schleifen - abgegrenzt gegen das Artefakt (entity/codebase, seit
  6.2.0). types/project.md/.schema.yaml und die neue Collection kb/gtd/ (Bereiche haus/,
  finanzen/, technik/ ueber responsibility:) folgen exakt dem Muster, das entity/concept/
  source/comparison schon vorgeben - kein Code noetig fuer wikitool new project, types list
  oder den Template-Versand, alles daran ist bereits generisch.

  Neu ist nur eine Zeile Code: project tritt neben source in
  kb_collections.STACK_REQUIRED_TYPES, nach demselben "fordern statt besitzen"-Idiom (D16) - ein
  Type-Spec name: project, dessen Schema state: fuehrt, muss existieren, weil der
  Wochenrueckblick (#125) sonst nichts hat, wogegen er ein Tracker-Projekt abgleichen kann. Das
  macht docs verify zum Grenzuebertritt (siehe Breaking Change oben): eine Instanz, die die
  neue tools/-Fassung uebernimmt, ohne types/project.md.template und
  kb/gtd/COLLECTION.md.template zu adoptieren, faellt fortan durch, wo sie vorher bestand. Dabei
  aufgefallen und mitkorrigiert: kb_collections.declaration_issues()s Meldung fuer eine fehlende
  Pflicht-Collection nannte immer source, unabhaengig davon, welcher Typ tatsaechlich fehlte -
  jetzt benennt sie den Typ, den stack_required_collection_owners() tatsaechlich dafuer
  verantwortlich macht. kb/entities/COLLECTION.md traegt jetzt einen gtd:-Block (vorerst nur
  see-also), ohne den keine Kante von einer Entity auf ein Vorhaben autorisierbar waere - das ist
  der Block, auf den #118 wartet.

  Task-tracker provider layer, with a Super Productivity adapter

  Gitea #119 (Paket #124): die Schicht, ueber die wikitool an einen Aufgaben-Tracker kommt -
  ohne dass eine Instruction je erfaehrt, welcher es ist (D25). chemenu.tasks.protocol deklariert
  TaskReader/TaskWriter als getrennte Protocols, chemenu.tasks.superproductivity implementiert
  beide gegen Super Productivity, .wikitool-tasks.json (chemenu.tasks.config) traegt Provider,
  Verbindungsangaben und die drei Schwellwerte des Wochenrueckblicks (#125). wikitool doctor
  berichtet den konfigurierten Provider, seinen Lesepfad-Status und ob seine lokale REST-API
  antwortet - read-only, FAILt nur auf eine kaputte Konfiguration, nie auf einen nicht laufenden
  Tracker. Kein Kommando entsteht hier (#124s eigene Abgrenzung) - das ist #125/#126.

  Zwei Zwischenbefunde aus der Umsetzung, gegen den tatsaechlichen Quellcode von
  super-productivity/super-productivity (master, 2026-09-19) verifiziert:

  • Der Lesepfad liest keine db.json - die gibt es auf dem Desktop nicht, der Live-Zustand
    liegt in IndexedDB. Gelesen wird die neueste Datei unter dessen periodischen
    Dateisystem-Backups (electron/backup.ts, <userData>/backups/<timestamp>.json), deren
    Inhalt exakt die verifizierte Form hat.
  • Die lokale REST-API kann keine Projekte anlegen - GET /projects existiert,
    POST /projects nicht (electron/local-rest-api-handler.service.ts). Damit entfaellt fuer
    diesen Provider der in #119 D31 vorgesehene automatische Schreibpfad; create_project prueft
    weiterhin die Namenskollision (D8), verlangt dann aber menschliches Eingreifen statt es zu
    simulieren: SuperProductivityWriter.create_project wirft ein neues
    chemenu.errors.HumanInterventionRequired mit Anweisungen fuer den Menschen und einem
    verify(), das den Lesepfad danach erneut befragt statt der Bestaetigung einfach zu glauben.
    Dieselbe Klasse haengt sich an den bestehenden EXIT_NEEDS_CLEARANCE-Code (42) - keine neue
    benannte Gate, aber dieselbe Haltung: dem Menschen die Ausgabe zeigen und anhalten, statt eine
    Umgehung zu erfinden. Die CLI-seitige Uebersetzung (needs_clearance) folgt mit dem Kommando
    in #126; #124 liefert nur die Bibliotheksseite. #119s Umsetzungstabelle und #124s eigener
    Akzeptanzkriterien-Absatz sind entsprechend nachgezogen.

  Ausserdem verifiziert, ohne Designfolgen: Super Productivitys Someday/Maybe-Aequivalent ist der
  bestehende backlogTaskIds-Puffer je Projekt, keine eigene Tag-Konvention.

  wikitool review: the weekly GTD review as a read-time join

  Gitea #119 (Paket #125): das tragende Bauteil - wikitool review joint die Tracker-Seite
  (chemenu.tasks, #124) und die kb/gtd/-Projektseiten ueber den case-normalisierten Namen und
  gibt einen Bericht aus. Es speichert nichts, nicht einmal eine reports/-Datei (D3) - search
  ist das naechste Vorbild dafuer, und review ist deshalb genauso vom Iterationsbudget
  ausgenommen.

  Fuenf Pruefungen (#119 D10/D26), alle in chemenu.review.run_review: stalled (Tracker-
  Projekt ohne offene Posten, kb/-Seite state: active - dormant/completed/abandoned
  melden nie, D27), waiting_overdue (follow_up_at aelter als stalled_waiting_days),
  unpaged_project (Tracker-Projekt ohne kb/-Seite, aelter als unpaged_project_weeks),
  no_open_loop (kb/-Seite active, aber kein Tracker-Projekt dieses Namens oder keine
  offenen Posten - die Gegenrichtung des vorigen Abgleichs, D8s beidseitiger unmatched-Bericht),
  someday_stale (Someday-Posten seit someday_stale_months unveraendert, ueber Kalendermonate
  gerechnet statt ueber Tage / 30). Ein Tracker-Projekt ohne offene Posten mit aktiver kb/-Seite
  erfuellt zugleich stalled und no_open_loop - beide melden, das ist keine Dopplung, sondern zwei
  verschiedene Aussagen ueber denselben Zustand.

  Jeder Providerzugriff ist einzeln abgesichert: scheitert projects(), entfallen die vier darauf
  aufbauenden Pruefungen; scheitert someday_items(), entfaellt nur die fuenfte; scheitert
  open_items() fuer ein einzelnes Tracker-Projekt, faellt nur dieses eine aus den betroffenen
  Pruefungen heraus, der Rest laeuft weiter. Ein so unvollstaendiger Bericht setzt complete auf
  false, druckt trotzdem alles, was noch entschieden werden konnte, und die CLI beendet sich mit
  Exit 1 - nie mit einem leisen Teilbericht, der wie eine ruhige Woche aussieht. Fehlt
  .wikitool-tasks.json ganz, oder ist es kaputt, scheitert der Aufruf sofort und sagt das - das
  ist ein Konfigurationsfehler, kein Erreichbarkeitsproblem, und braucht deshalb keinen Teilbericht.

  --json traegt dieselben Befunde maschinenlesbar (findings/checks_run/checks_skipped/
  kb_project_count/complete); ein Test haelt beide Formen gegeneinander, wie es
  test_mcp_server.py fuer den MCP-Lesepfad gegen die CLI tut.

  wikitool new project: Seite und Tracker-Projekt unter einem Namen

  Gitea #119 (Paket #126): wikitool new project --name X --set responsibility=Y legt jetzt, wenn
  .wikitool-tasks.json einen Tracker konfiguriert, zusaetzlich ein gleichnamiges Tracker-Projekt
  an - ein Geburtsort, ein Name (D8/D31). Tracker vor Seite: erst steht die Tracker-Seite fest,
  erst danach wird die kb/-Seite geschrieben, damit ein Fehlschlag zwischen beiden immer im
  selben, bereits bekannten Zustand landet - "Tracker-Projekt ohne Seite", das reviews Pruefung 3
  ohnehin meldet - nie im unbekannten "Seite ohne Tracker-Projekt". Ist kein Tracker konfiguriert,
  bleibt es bei der reinen Seitenanlage, jetzt aber ausdruecklich als solche vermerkt statt
  stillschweigend.

  chemenu.tasks.build_reader/build_writer (neu in chemenu/tasks/__init__.py) sind die eine
  Dispatch-Tabelle von TasksConfig.provider auf einen konkreten Adapter, jetzt von review.py
  und new_page.py geteilt statt zweimal derselben if cfg.provider == "superproductivity".

  Fuer einen Provider ohne Schreibpfad (Super Productivity, #124: keine POST /projects) wirft
  create_project chemenu.errors.HumanInterventionRequired - das Kommando zeigt die Anweisung
  und beendet sich mit Exit 42, ohne irgendetwas anzulegen. Die offene Frage aus #126s eigenem
  Issue-Text war, wie ein zustandsloser CLI-Prozess bei einem erneuten Aufruf eine echte
  Namenskollision von "der Mensch hat gerade getan, worum genau dieses Kommando gebeten hat"
  unterscheidet - beides sieht am Lesepfad identisch aus (Tracker hat den Namen, kb/ noch keine
  Seite). Entschieden (mit dem Betreiber, nicht allein): ein explizites --resume, das ein Treffer
  im Tracker als bestaetigte Fortsetzung liest statt als Kollision - ohne --resume bleibt jeder
  Treffer eine Ablehnung samt Fundort, auch bei einem Wiederholungsaufruf. --resume ohne einen
  tatsaechlich fehlenden Tracker-Eintrag wirft dieselbe HumanInterventionRequired-Meldung erneut,
  keine stille Weiterarbeit auf Zuruf. --resume bei jedem anderen Typ wird abgelehnt.

  Ein erzwungener Fehlschlag der eigentlichen Seiten-Schreibaktion (Schritt 3) nach bereits
  bestaetigtem Tracker-Projekt ist eigens getestet: die Meldung nennt, dass die Tracker-Seite schon
  steht und nur die kb/-Seite fehlt, nie umgekehrt.

  new project: Testabdeckung fuer die required-responsibility-Ablehnung

  Gitea #119 (Paket #126s eigenes AC): --responsibility ist Pflicht und ein Wert ausserhalb des
  Enums wird abgelehnt - beides galt schon vorher generisch ueber types/project.schema.yamls
  required:/enum: (#123), ohne dass #126 dafuer neuen Code brauchte. Nachgetragen: ein Test,
  der das fuer den fehlenden Fall (--set responsibility=... ganz weggelassen) tatsaechlich belegt,
  statt es nur zu behaupten.

  Skill weekly-review: turning wikitool review's findings into decisions

  Gitea #119 (Paket #127): instructions/weekly-review/SKILL.md, publiziert nach .agents/skills/
  und .claude/skills/. wikitool review liefert fuenf Befunde (#125); dieser Skill fuehrt das
  Gespraech, das aus jedem eine Entscheidung macht - je Befund mindestens zwei Handlungsoptionen und
  ein Unterscheidungsmerkmal, wie in #127s Akzeptanzkriterien gefordert.

  Der Skill nennt bewusst keinen Provider, keine Datei- und keine API-Form (D25) - eine neue
  Regressionstest (test_weekly_review_skill_names_no_provider) haelt das am echten Repo-Inhalt
  fest, nicht nur als Review-Behauptung. Erinnert im Text an D28 (Personen in ## Beteiligte
  bleiben Erwaehnung, bekommen keine Seite) und D7 (die Seite fasst die Aufgabenliste nie
  zusammen). Die Kommandoflaeche bleibt bei review/new project; alles Aufgabenbezogene - eine
  naechste Aktion anlegen, follow_up_at verschieben, einen Someday-Eintrag streichen - bleibt eine
  Handlung im Tracker selbst, weil dafuer kein wikitool-Kommando existiert (D31).

  Doku-Nachzug zu #119: die Verpflichtungsschicht erreicht Installation, Setup und docs/

  Gitea #119, nach Abschluss von #122-#127: die sechs Umsetzungspakete haben ihre Vertragszeilen
  jeweils mitgebracht (tools/CONTRACT.md, kb/CONTRACT.md), aber drei Flaechen blieben zurueck,
  die kein Paket fuer sich allein besass - und keine davon faellt bei docs verify auf, weil dort
  keine Zeile fehlt, sondern Prosa.

  • INSTALL.md § Konfiguration kannte .wikitool-tasks.json nicht. Die Datei stand in
    tools/CONTRACT.mds doctor-Zeile und in reviews Fehlerkontrakt, also dort, wo ein Agent
    nachschlaegt - nur nicht dort, wo ein Mensch die Form nachschlaegt. Sie steht jetzt neben
    .wikitool-telemetry.json und .wikitool-remotes.json, mit vollstaendigem Beispiel, den drei
    Schwellwerten als Konfiguration statt Schema, und dem fuer Super Productivity getrennten
    Lese-/Schreibpfad. Die doctor-Beschreibung unter § Verifikation nennt den Tracker jetzt mit.
  • setup-instance.md bot den Tracker nie an. Eine neue Instanz bekam Typ und Collection ueber
    die generische Template-Adoption (Schritt 5), aber nichts fragte nach der anderen Haelfte des
    Rueckblicks. Neuer Entscheidungspunkt (Schritt 11, parallel zur Telemetrie): einmal fragen,
    .wikitool-tasks.json anlegen oder nichts tun - kein Tracker ist ein gueltiger Endzustand. Die
    Form steht nicht hier, sondern in INSTALL.md (Invariante 8). Folgenummern 12-16 nachgezogen,
    Skill-Liste um weekly-review ergaenzt.
  • upgrade-instance.md hatte keinen Pfad fuer ein neu ausgeliefertes .template. Genau der
    Fall, den 7.0.0 erzwingt: Schritt 5 sagte „new braucht keine Entscheidung", und die
    Schritt-6-Tabelle sagt, instanzeigene Dateien koennten dort gar nicht auftauchen - beides
    richtig und zusammen irrefuehrend, weil ein neues types/<name>.md.template fuer einen
    geforderten Typ sehr wohl eine Handlung braucht. Schritt 5 benennt diese eine Ausnahme jetzt,
    Schritt 9 traegt die Reparatur neben der TOC-Reparatur: die gewoehnliche Adoption, mit den zwei
    cp-Zeilen, ausdruecklich keine Datenmigration.

  Dazu die Begruendung selbst: docs/knowledge-and-commitment.md ist neu und haelt fest, warum
  Wissen und Verpflichtung zwei Schichten sind (verschiedene Halbwertszeiten), warum nicht
  synchronisiert wird (Muster 4, mit den drei verworfenen Anordnungen), warum der Join zur Lesezeit
  passiert und nichts speichert, warum ein Name die Pflichten eines Identifiers erbt, warum eine
  Seite ihre Aufgabenliste nie zusammenfasst, warum Archivierung ein state:-Wert ist, und warum
  keine Instruction je den Provider nennt. Das stand bisher ausschliesslich in Gitea #119 - und ein
  Issue ist genau das, was dist export nicht mitliefert: eine ausgelieferte Instanz bekam den
  Mechanismus ohne das Warum. AGENTS.md § File naming zaehlt jetzt sechs statt fuenf von dort
  verlinkte docs/-Seiten.

  tools/README.md § Layout fuehrt review.py und das Paket tasks/; und
  instructions/dev/doc-pull-through.md bekommt die zwei Zeilen, deren Fehlen dieser Nachzug ist:
  eine fuer eine instanzeigene Konfigurationsdatei (INSTALL.md § Konfiguration + der
  setup-instance-Entscheidungspunkt + doctors Vertragszeile), eine fuer einen neuen geforderten
  Seitentyp oder eine neue Collection (Type-Spec/COLLECTION.md + kb/CONTRACT.md + beide
  Adoptionspfade). Die Zeile zur docs/-Begruendung sagt jetzt zusaetzlich, dass eine Entscheidung
  ohne Seite die eigentliche Luecke ist, weil Begruendungen aus einem Issue nie ausgeliefert werden.

  docs/-Nachzug: Exit 42 als Haltung, und die Adoption eines neu ausgelieferten Templates

  Die Abschlusspruefung dieses Kandidaten (stack-close Schritt 3) hat zwei docs/-Seiten gefunden,
  deren Begruendung die Pakete #124/#126 bzw. #123 verschoben hatten, 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. Die Seite oeffnet mit „vier harte
    Grenzen", und seit #124/#126 verlaesst HumanInterventionRequired denselben Code, ohne eine
    fuenfte Gate zu sein. Neuer Abschnitt „Exit 42 is a posture, and it outgrew the gates": die vier
    Gates teilen eine Weigerung (die Operation waere moeglich, das Werkzeug fuehrt sie
    unbesehen nicht aus), der neue Fall ist das Gegenteil (die Operation ist gar nicht moeglich, kein
    Token koennte das aendern) - gemeinsam ist beiden nur, was der Exit-Code tatsaechlich sagt:
    anhalten, einem Menschen zeigen, nichts umgehen. Dazu die verworfene Alternative, die Luecke in
    der Instruction-Schicht zu beschreiben - genau die Prosa-Regel, gegen die diese Seite argumentiert.
  • docs/ownership-and-templates.md beschrieb die .template-Kategorie nur von innen. „Wird
    von einem Upgrade nie geschrieben" stimmt weiterhin fuer eine bereits adoptierte Datei; der Fall,
    dass ein Release ein Template fuer einen Typ liefert, den die Instanz noch gar nicht hat, stand
    nirgends - und genau der ist seit #123 der Grenzuebertritt. Die Kategorie nennt ihn jetzt als die
    eine Gestalt, in der „das Upgrade schreibt diese Datei nie" zu Arbeit wird, mit Verweis auf den
    Schritt in upgrade-instance.md, den Stack 7.0.0-beta.7 dort angelegt hat.

  Skill-Namensfamilien: weekly-review -> gtd-weekly-review, dritte Person in allen Descriptions

  Gitea #129: the published skill collection had drifted into three naming shapes where it should
  have three families. weekly-review (added earlier in this same candidate, never released)
  named neither its domain nor its distribution boundary, unlike wiki-* and stack-* either
  side of it - renamed to gtd-weekly-review, joining a new gtd- prefix for the commitment layer
  (kb/gtd/, types/project.md, docs/knowledge-and-commitment.md) that sits beside wiki- (the
  knowledge pipeline) and stack- (the stack's own development, under instructions/dev/).
  instructions/CONTRACT.md § "Writing an instruction" now states both the family-prefix
  convention and, separately, that a skill's description speaks in third person per Anthropic's
  skill-authoring guidance - all eight published skills' descriptions were rewritten to match
  ("Processes...", not "Process..."); the flat instructions/<name>.md form keeps its existing
  imperative-title convention, since its description is read on demand rather than injected into
  the system prompt. No --breaking line: the renamed skill was introduced by this same
  unreleased candidate, so no existing instance carries the old name to migrate away from.

  Veraltete Skill-Aufzaehlungen in der Instruction-Schicht nachgezogen

  Gitea #129s Abschlusspruefung: die Skill-Umbenennung hat sichtbar gemacht, dass mehrere Dokumente
  die Skill-Liste hart aufzaehlen und beim Wachsen der Liste still veralten. Vier Stellen waren
  falsch, eine davon schon vor diesem Paket:

  • instructions/CONTRACT.md § "When a skill carries a copy-in checklist" zaehlte „die zwei
    Skills mit Block und die drei ohne" - also fuenf von inzwischen acht. Die Zahlen im Einstiegssatz
    sind jetzt ganz raus (sie unterscheiden sich ohnehin zwischen diesem Repo und einer
    ausgelieferten Instanz, die instructions/dev/ nicht hat), die Aufzaehlung nennt alle
    ausgelieferten Skills, und die beiden Dev-Skills stehen in einem dist:strip-Block.
  • Dieselbe Passage nannte wiki-query mit sechs Schritten - es sind sieben, und zwar schon
    laenger. Die Regel selbst (ein Flow ab acht Schritten und still scheiternde Schritte) bleibt
    unveraendert; kein Skill wechselt dadurch die Seite.
  • instructions/CONTRACT.md § "outbound reference" sprach im Praesens von „this repo's seven
    skills", wo die Zahl zu einer datierten Messung (52 von 58 Links) gehoert - jetzt als „at the
    time" markiert, statt die Messung nachzurechnen.
  • instructions/bootstrap.md und die Scope-Abschnitte von stack-dev/stack-close listeten
    die Content-Skills ohne gtd-weekly-review auf.

  Dazu test_the_real_repo_publishes_the_six_wiki_skills -> ..._every_skill: der Test pruefte
  sechs der acht Skills und trug die veraltete Zahl im Namen; er nennt jetzt alle acht, nach
  Familien erklaert. Dass die Passage weiterhin Schrittzahlen fremder Dateien zitiert, die genauso
  still veralten koennen, ist als eigene Frage festgehalten und hier bewusst nicht geloest.

  SP-Zugriffsweg explizit (access: api/snapshot, #133) und follow_up_at-Korrektur (dueWithTime/dueDay, #135)

  Gitea #133: der Super-Productivity-Adapter unterscheidet jetzt zwei sich ausschliessende
  Zugriffswege, per Pflichtfeld access ohne Default und ohne Laufzeit-Ruckfall - "api" liest
  und (fuer #132 vorbereitet) schreibt ausschliesslich ueber die lokale REST-API und den aktuellen
  Zustand, "snapshot" liest ausschliesslich den juengsten Backup-Schnappschuss und ist von dort
  aus nie schreibbar. db_path entfaellt vollstaendig, backups_dirs Glob ist auf das echte
  Zeitstempelmuster (YYYY-MM-DD_HHmmss.json) gehaertet, und beide Wege blenden archivierte
  Tracker-Projekte aus - verifiziert gegen den tatsaechlichen Quellcode von
  super-productivity/super-productivity (master, 2026-09-20). SuperProductivityApiReader ist
  der neue Leser fuer access: "api", gegen eine Attrappe getestet, nie gegen eine laufende App.
  tools/wikitool new project verweigert auf einer access: "snapshot"-Instanz jetzt vollstaendig
  (Exit 1, weder Tracker-Projekt noch Seite) statt den nicht mehr moeglichen 42er-Menschenschritt zu
  versuchen; wikitool doctor und wikitool review berichten nur noch den tatsaechlich
  konfigurierten Weg, und jede Antwort von review nennt jetzt explizit, aus welchem Weg sie
  stammt (bei snapshot samt Alter des gelesenen Schnappschusses). Aufgeloest damit: #134, dessen
  Verdacht (--resume koennte gegen einen veralteten Schnappschuss verifizieren) durch den Wegfall
  der Projektanlage auf snapshot-Instanzen gegenstandslos wurde.

  Gitea #135, im selben Zug korrigiert: follow_up_at las bislang remindAt, das sich nur bei
  einer mit Uhrzeit terminierten und benachrichtigten Aufgabe fuellt - ein ganztaegiger, stiller
  Tickler (dueDay ohne dueWithTime, das haeufigste WAITING-Muster) hatte dadurch nie einen
  follow_up_at und fiel bei Pruefung 2 des Wochenrueckblicks still durch. Gelesen wird jetzt
  dueWithTime, sonst dueDay - Super Productivitys eigene Leseregel - nie deadline* (D9 bleibt
  in der Sache unveraendert, nur die falsche Berufung auf sie ist korrigiert). Bestehende Instanzen
  sehen dadurch rueckblickend mehr Befunde, nicht weniger.

  task new: einen zweiten Schreibweg in den Tracker (ein Posten, keine Seite)

  Gitea #132: eine Quelle kann Wissen und eine Verpflichtung zugleich tragen (eine Kundenreklamation
  etwa), und bislang hatte nur die Wissenshaelfte einen Schreibweg. chemenu.tasks.protocol.TaskWriter
  traegt jetzt eine zweite Methode, create_item - Projekt, Titel, optional WAITING mit
  follow_up_at, optional ein Freitext-Rueckverweis in notes -, darueber das neue Kommando
  wikitool task new. Anders als create_project schreibt sie tatsaechlich: bei Super Productivity
  existiert POST /tasks, wo POST /projects fehlt, also gibt es hier keinen
  HumanInterventionRequired-Fall. Das Kommando ordnet kein Projekt selbst zu - ein --project, das
  zu keinem Tracker-Projekt passt, oder --waiting ohne vorhandenen waiting-Tag scheitert laut,
  exit 1, statt zu raten oder einen Posten ohne seinen Status anzulegen. Die Eingangs-Ablage
  (--inbox) ist eine eigene, ausdrueckliche Form am Kommando, nie ein Ersatz fuer ein vergessenes
  --project.

  Verifiziert gegen super-productivity/super-productivity@master (2026-09-20): Super Productivitys
  INBOX_PROJECT ist zwar immer ein echtes Projekt-Entity im Store, aber
  selectUnarchivedProjects - der Selektor hinter GET /projects - filtert es ueber seine feste id
  unbedingt heraus. Ein per --inbox abgelegter Posten erscheint deshalb in keiner
  wikitool review-Pruefung, nicht weil eine Ausnahme dafuer noetig waere, sondern weil der Eingang
  in der Projektliste schlicht nie auftaucht - der Ingest-Skill nennt diese Kosten jetzt ausdruecklich,
  wenn er die Route anbietet.

  Der Ingest-Skill (instructions/wiki-ingest/SKILL.md) fragt in Schritt 5 jetzt auch nach einer
  Verpflichtung, nicht nur nach dem Wissen, und legt Titel und vorgeschlagenes Projekt in einem
  Bestaetigungsschritt vor (nie eine automatische Zuordnung, auch nicht bei einem eindeutigen
  search-Treffer). Der Posten wird vor der Quellenseite angelegt - dieselbe Tracker-vor-Seite-
  Reihenfolge, die new project schon haelt, hier mit eigenem Beleg: eine Rohdatei ohne Quellenseite
  meldet lint als uncovered_raw_files, eine stillschweigend verlorene Verpflichtung meldet
  nichts. Der bestehende Regressionstest, der sicherstellt, dass kein Skill den Tracker-Provider
  nennt, ist entsprechend auf wiki-ingest erweitert. docs/knowledge-and-commitment.md und
  tools/CONTRACT.md sind nachgezogen; Gitea #128 (der zweite Adapter) traegt jetzt create_item
  in seiner eigenen Flaeche.

  wiki-ingest: raw accept rückt hinter die Verpflichtungsentscheidung

  Gitea #136, eine offen gebliebene Teilfrage aus #132: raw accept lief dort weiterhin ganz am
  Anfang des Laufs, vor Lesen, Diskussion und Verpflichtungserkennung - scheiterte task new, fand
  sich eine bereits nach raw/ befoerderte Rohdatei vor, obwohl #132s eigenes Kriterium "keine
  Seite geschrieben und keine Rohdatei befoerdert" verlangte. docs/knowledge-and-commitment.md
  behauptete diese Eigenschaft seit demselben Commit bereits als Tatsache; der Baum beschrieb ein
  Design, das es nicht gab.

  wiki-ingests Schritte 1-5 sind neu geordnet: lesen, Metadaten, search, Diskussion inklusive
  Verpflichtung und task new, dann erst raw accept. Die Schritte 6-12 behalten ihre Nummern
  unveraendert, ebenso jeder Fremdverweis, der eine dieser Nummern nennt. Zwei Stellen sind dabei
  verschaerft, nicht nur verschoben: die fidelity/authority-Frage in Schritt 5 benennt jetzt
  ausdruecklich, dass die Datei zu diesem Zeitpunkt schon vollstaendig gelesen ist - der Moment, in
  dem die Versuchung, den Wert aus dem Inhalt zu erschliessen statt ihn zu erfragen, am groessten
  ist -, und derselbe Schritt benennt, dass seine Kollisionsverweigerung jetzt spaeter faellt, nach
  Lesen, Diskussion und moeglicherweise bereits angelegtem Tracker-Posten.

  Eine Ausnahme bleibt bewusst bestehen: ein Lauf, der wegen Volumen oder Breite an
  instructions/ingest-large-tree.md uebergibt, befoerdert weiterhin vor der Verpflichtungsfrage -
  dessen work new --input <pfad> verweigert jeden Pfad ausserhalb raw/, und der Lauf ist ohnehin
  nicht atomar, da er unit-weise ueber Tage publiziert und seine eigene Verpflichtungsfrage erst in
  Schritt 5d je Unit stellt. docs/knowledge-and-commitment.md nennt diese Ausnahme jetzt explizit,
  statt die Eigenschaft unbedingt zu behaupten. README.md und instructions/CONTRACT.md sind
  nachgezogen.

  Zwei Fragen, die sich beim Durchsehen der Naht zwischen Wissen und Verpflichtungen zusaetzlich
  zeigten - gtd-weekly-reviews veraltete Zaehlung der GTD-Kommandos, und ob der Weekly Review
  task new kuenftig anbieten soll -, sind bewusst nicht Teil dieser Aenderung: Gitea #137 und #138.

  gtd-weekly-review: task new nachgezogen, veralteter Begründungszeiger korrigiert

  Gitea #137, der liegengebliebene Pull-Through von #132 am GTD-Rand: instructions/gtd-weekly- review/SKILL.md behauptete zweimal, review und new project seien die einzigen zwei
  GTD-Kommandos, und begruendete die Haltung "der Nutzer handelt selbst in seinem Tracker" mit
  "because wikitool has no command for it" - seit #132s task new schlicht falsch. Der
  Begruendungszeiger fuer die schmale Kommandoflaeche zeigte zudem auf types/project.md und
  kb/gtd/COLLECTION.md; die Begruendung steht tatsaechlich in
  docs/knowledge-and-commitment.md § "Status has exactly one home", die #132 korrekt nachzog,
  waehrend dieses Skill unberuehrt blieb.

  Beide Stellen benennen task new jetzt als drittes, tatsaechlich vorhandenes Kommando, das dieses
  Skill bewusst nicht aufruft - die Haltung selbst ist unveraendert, nur ihre Begruendung ist jetzt
  eine Wahl statt eine Behauptung ueber eine fehlende Faehigkeit. Ob der Weekly Review task new
  kuenftig anbieten soll, bleibt unentschieden in Gitea #138; dieses Issue korrigiert nur, was
  nachweislich falsch dastand.

  Weekly review proposes task new/task close; tracker gains a closing write path

  Gitea #138 entschied die dort offene Frage: der Weekly Review bietet task new jetzt bei
  stalled/no_open_loop Option (a) an, nach ausdruecklicher Bestaetigung von Titel und Projekt in
  einer Frage - dieselbe Haltung wie im Ingest. Die zweite Haelfte derselben Naht war unentschieden
  liegen geblieben: eine Quelle kann eine Verpflichtung anlegen, aber nie schliessen. Der Tracker
  bekommt dafuer einen dritten, letzten Schreibweg, task close --id, der einen Posten erledigt
  markiert - niemals loescht, verifiziert gegen Super Productivitys master-Branch, dass
  PATCH /tasks/:id mit isDone: true bit-identisch zur eigenen "erledigt"-Checkbox der App ist.
  task list --project liefert dazu die Item-Ids, die task close und die Review-Funde fuer
  waiting_overdue/someday_stale jetzt mitfuehren. wiki-ingest stellt die Verpflichtungsfrage
  seither in beide Richtungen (oeffnen und schliessen), und ingest-large-tree Schritt 5d begruendet
  jetzt in einem Satz, warum diese Frage pro Unit gestellt wird statt einmal pro Baum.

  Die zwei Instruktionsstellen, an denen die Haltung zum Tracker-Schreibzugriff bislang doppelt
  stand, sind auf eine zusammengezogen; die zweite verweist nur noch.
  docs/knowledge-and-commitment.md § "Status has exactly one home" zaehlt die Kommandoflaeche
  korrekt (zwei Lese-, drei Schreibkommandos) und haelt fest, warum sie bei "anlegen" und "erledigt
  markieren" endet, nie bei "loeschen" oder "aendern".

  instructions/CONTRACT.md drops other files' step counts from the copy-in-checklist rationale

  instructions/CONTRACT.md § "When a skill carries a copy-in checklist" used to justify the
  threshold by citing each other skill's step count by number - evidence that the two-halves test
  (length and a silently-omittable step) is what actually decides wiki-ingest/wiki-lint, not a
  count fitted after the fact. Nothing kept those numbers in sync with the SKILL.md files they
  described: one of them had already drifted silently (wiki-query cited at six steps where it had
  been seven for a while), and the passage itself named only five of the eight skills that exist -
  neither wrong number failed any check, because docs verify reads presence, not another file's
  prose (instructions/dev/doc-pull-through.md).

  Of the three fixes considered - a docs verify check against a codified step-counting convention,
  a qualitative rewrite that drops the numbers, or tracking the sync as a manual doc-pull-through.md
  duty - the qualitative rewrite won: it is the only one of the three that removes the possibility of
  drift rather than catching or documenting it, and the per-skill counts were decoration for the
  two-halves test, never load-bearing for it. The passage now names which skills qualify and why,
  without citing a number that belongs to a file it does not own. Today's counts were checked against
  the actual files before this bump (wiki-ingest twelve, wiki-lint nine, wiki-manage two flows
  of seven, wiki-query seven, wiki-status five, gtd-weekly-review five, stack-dev six,
  stack-close four) - all correct, confirming the passage was not itself wrong, only unguarded.

  ---

  This note is a snapshot of the CHANGES.md entry as it stood when the tag was cut, and
  is never edited afterwards. The maintained version of this text - including any later
  correction - is the entry for this version in CHANGES.md in the repository.

  Downloads

  • chemenu-stack-7.0.0.tar.gz
    744 KiB

    2026-09-22 20:56:08 +00:00
  • chemenu-stack-7.0.0.tar.gz.sha256
    93 B

    2026-09-22 20:56:08 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)