Paket 3 aus #119 (D15, D25, D30). Die Schicht, ueber die wikitool an den Aufgaben-Tracker
kommt — ohne dass irgendeine Instruction je erfaehrt, welcher es ist.
Der tragende Gedanke
Die Provider-Grenze ist eine Kommandoflaeche, keine Instruction-Frage. Der Agent ruft tools/wikitool und nichts sonst. Damit entfaellt selective disclosure, ein Filter beim
Skill-Publishing und jede Faehigkeitsmatrix in Prosa: es gibt einen Skill, provider-agnostisch.
Kein fremder MCP (D25). Wir schreiben den Adapter selbst gegen das dokumentierte Format
bzw. die dokumentierte API. Die Marktrecherche in #119 hat gezeigt, dass nahezu die gesamte
MCP-Landschaft aus Einzelmaintainer-Projekten mit 0–2 Stars besteht; bei einem dienstbasierten
Werkzeug waere so ein Server der einzige Zugriffspfad und sein Tod das Ende des Rueckblicks.
Zwei Befunde aus der Umsetzung, die den urspruenglichen Entwurf korrigieren
Beide gegen den tatsaechlichen Quellcode von super-productivity/super-productivity (master)
verifiziert, 2026-09-19.
1. Kein db.json zum Lesen — das ist der Backup-Snapshot
Desktop-SP haelt seinen Live-Zustand in IndexedDB, nicht in einer Datei db.json. Was existiert: electron/backup.ts schreibt den vollstaendigen Zustand als JSON.stringify(data) nach <userData>/backups/<timestamp>.json, neueste Datei zuletzt (Dateiname sortiert lexikalisch,
so der eigene Kommentar dort). Form: AppDataComplete/AppDataCompleteLegacy
(src/app/op-log/model/model-config.ts bzw. src/app/imex/sync/sync.model.ts), flach, je
Feature ein Top-Level-Key — task/project/tag als @ngrx/entity {"ids": [...], "entities": {...}}. Der Lesepfad liest genau diese drei Keys aus der neuesten
Backup-Datei (db_path fuer eine feste Datei, sonst backups_dir + lexikalisches Maximum) und
scheitert laut (Exit 1, ValidationError) auf jede Struktur, die nicht passt — SPs internes
Modell ist unversioniert, Drift ist erwartbar, kein Randfall.
2. Die lokale REST-API kann keine Projekte anlegen
electron/local-rest-api-handler.service.ts routet GET /projects, aber kein POST /projects — Task-CRUD existiert, Projekt-CRUD nicht. Das bricht die in #119 D31
vorausgesetzte Automatik ("Projektanlage reitet auf dem vorhandenen Seiten-Scaffold mit: ...
entstehen Seite und Tracker-Projekt gleichen Namens").
Entscheidung des Betreibers (2026-09-19), umgesetzt: kein Workaround (kein Task-in-Inbox-
Trick, kein direktes db.json-Schreiben trotz D8/D31-Vorbehalt). Stattdessen ein neuer
Fehlertyp, der dieselbe Haltung wie die vier benannten Gates in AGENTS.md § Gates traegt, ohne
selbst eine fuenfte benannte Gate zu sein (kein Schwellwert, kein --confirm-Token): chemenu.errors.HumanInterventionRequired. SuperProductivityWriter.create_project:
Preflight-Kollisionspruefung ueber den Lesepfad (D8, case-normalisiert) — bei Kollision ValidationError, nichts wird angelegt.
Sonst HumanInterventionRequired mit einer fuer den Menschen lesbaren Anweisung ("Projekt <name> selbst in Super Productivity anlegen") und einem verify() — ein zustandsloses
Callable, das den Lesepfad danach erneut befragt, ob das Projekt jetzt existiert. Eine
Bestaetigung des Nutzers wird nie als Tatsache genommen, ohne dass verify() sie bestaetigt.
Was das fuer #126 bedeutet: die CLI-seitige Uebersetzung ("Anweisung zeigen, anhalten, nach
Bestaetigung verify() aufrufen, erst dann fortfahren") ist noch nicht gebaut — #124 liefert nur
die Bibliotheksseite (HumanInterventionRequired selbst, dessen Docstring die Uebersetzung nach commands._util.needs_clearance()/Exit 42 fuer den kuenftigen Aufrufer vorschreibt). #126s wikitool new project muss diesen Fehler fangen und die Pause-bis-Bestaetigung-dann-verify-
Schleife tatsaechlich fahren; dieses Issue ist entsprechend praezisiert (siehe unten).
Nebenbefund ohne Designfolgen: SPs Someday/Maybe-Aequivalent ist der bestehende backlogTaskIds-Puffer je Projekt (separat von der aktiven taskIds-Liste) — keine eigene
Tag-Konvention noetig. Beantwortet die "Zu verifizieren"-Frage aus #119.
Was gebaut wurde
Adapter-Protokoll (chemenu.tasks.protocol)
TaskReader/TaskWriter als getrennte Protocols — ein Adapter kann TaskWriter weglassen,
ohne dass TaskReader davon beruehrt wird (erfuellt per Konstruktion: SP implementiert nur
einen halb-funktionalen Writer, der Reader ist vollstaendig unabhaengig).
Operation
liefert
Projekte
Name, Anlagedatum
Offene Posten je Projekt
Anzahl; fuer WAITING-Posten zusaetzlich Titel und follow_up_at
Someday-Posten
Aenderungsdatum
Schreibpfad: ein Vorgang — ein Projekt anlegen (fuer SP: siehe Befund 2 oben).
Waiting-For nach D30: maschinenlesbar sind nur der WAITING-Status (eine Tag namens waiting, case-insensitiv) und follow_up_at (der Reminder-Zeitstempel der Aufgabe, remindAt
— ausdruecklich nichtdueDay/dueWithTime). Die Person steht im Klartext im Aufgabentitel
und wird nicht geparst.
Analog .wikitool-upload.json: provider, dessen eigener Abschnitt (fuer SP: backups_dir
oder db_path, api_base_url, optional api_token — aktuell ungenutzt, da kein Aufruf hier
Authentifizierung braucht), und die drei Schwellwerte des Rueckblicks
(stalled_waiting_days/unpaged_project_weeks/someday_stale_months). Gitignored
(.gitignore, docs_verify.REQUIRED_IGNORE_CANARIES).
wikitool doctor
Neuer Check tasks-provider: Provider konfiguriert oder nicht (beides OK), bei SP zusaetzlich
Lesepfad-Status und ob GET /health antwortet — nie FAIL auf Nichterreichbarkeit, nur auf eine
kaputte Konfigurationsdatei.
Akzeptanzkriterien
Ein Adapter-Protokoll existiert, das Lese- und Schreibpfad getrennt deklariert; ein
Adapter kann den Schreibpfad nicht anbieten, ohne dass der Lesepfad davon beruehrt wird.
Der SP-Adapter liefert gegen eine Fixture (die reale Backup-Snapshot-Form, s.o. — nicht
"db.json" im woertlichen Sinn, siehe Befund 1) Projekte mit Alter, offene Posten je
Projekt, WAITING-Posten mit follow_up_at und Someday-Posten mit Aenderungsdatum — ohne dass ein Prozess laeuft.
Fehlt .wikitool-tasks.json, nennt die Fehlermeldung die Datei und das erwartete Format;
kein Stacktrace, kein stiller Default.
Der Schreibpfad prueft vor dem Anlegen, ob der Name im Tracker schon vergeben ist
(case-normalisiert, D8), und legt bei Kollision nichts an — praezisiert durch Befund 2:
"legt nichts an" heisst fuer SP nie "legt automatisch an", sondern "verlangt einen
verifizierten menschlichen Schritt" (HumanInterventionRequired).
Laeuft die SP-App nicht, ist das fuer den Lesepfad irrelevant (headless); fuer den Schreibpfad ist es ohnehin immer HumanInterventionRequired — es gibt keinen
API-Aufruf, der noch auf "App laeuft nicht" pruefen muesste (Befund 2 aendert diesen
Punkt inhaltlich).
Kein Credential liegt im Repo..wikitool-tasks.json in .gitignore und docs_verify.REQUIRED_IGNORE_CANARIES.
tools/wikitool doctor berichtet den konfigurierten Provider und ob er erreichbar ist —
read-only, FAILt nicht, wenn keiner konfiguriert ist.
docs verify, instructions verify, pytest gruen (1354 Tests, inkl. Lauf gegen eine
leere Maschine per instructions/dev/testing-conventions.md Schritt 6).
Versionsteil: --minor (neue Faehigkeit, drop-in in beide Richtungen; die Instanz-seitige --major-Eskalation dieses Kandidaten stammt aus #123, nicht aus diesem Paket).
Was hier ausdruecklich nicht gebaut wird
Kein Kommando. Diese Schicht ist Bibliothek; die Kommandos sind Paket 4 und 5. Und kein
MCP-Tool — wird spaeter ein entfernter Konsument gebraucht, wird es eines auf dem vorhandenen
Leseserver, gleicher Kern, gleicher Golden-Test (D25).
Neu abgegrenzt durch Befund 2:#126 (wikitool new project) muss jetzt zusaetzlich die
Pause-bis-Bestaetigung-Schleife um HumanInterventionRequired bauen (Anweisung zeigen via commands._util.needs_clearance()/Exit 42, nach Nutzerbestaetigung verify() aufrufen, nur bei True fortfahren) — das war im urspruenglichen Entwurf implizit "der Schreibpfad legt an", ist
jetzt fuer SP explizit ein Mensch-in-der-Schleife-Schritt.
Testhinweis
instructions/dev/testing-conventions.md gilt: die Suite laeuft gegen eine bewusst leere
Maschine. Der Adapter darf in keinem Test eine laufende SP-Instanz, ein Netzwerk oder einen
Pfad im Home des Benutzers voraussetzen — alles ueber Fixtures und konfigurierte Pfade. test_superproductivity.pys health()-Tests nutzen ausschliesslich Loopback-Sockets
(127.0.0.1, ephemerer Port oder ein garantiert geschlossener Port) — kein echtes Netzwerk.
Abhaengigkeiten
Unabhaengig von #122 und dem Typ-Paket. Blockiert Paket 4 und Paket 5 — beide jetzt frei, #126 mit der oben genannten zusaetzlichen Anforderung.
**Erledigt** (`1875449`, Stack 7.0.0-beta.2). `chemenu.tasks.protocol` (`TaskReader`/`TaskWriter`),
`chemenu.tasks.config` (`.wikitool-tasks.json`), `chemenu.tasks.superproductivity`
(`SuperProductivityReader`/`SuperProductivityWriter`), `wikitool doctor`-Integration, Tests unter
`tools/chemenu/tests/test_tasks_*.py`/`test_superproductivity.py`.
Paket 3 aus #119 (D15, D25, D30). Die Schicht, ueber die `wikitool` an den Aufgaben-Tracker
kommt — ohne dass irgendeine Instruction je erfaehrt, welcher es ist.
## Der tragende Gedanke
**Die Provider-Grenze ist eine Kommandoflaeche, keine Instruction-Frage.** Der Agent ruft
`tools/wikitool` und nichts sonst. Damit entfaellt selective disclosure, ein Filter beim
Skill-Publishing und jede Faehigkeitsmatrix in Prosa: es gibt einen Skill, provider-agnostisch.
**Kein fremder MCP** (D25). Wir schreiben den Adapter selbst gegen das dokumentierte Format
bzw. die dokumentierte API. Die Marktrecherche in #119 hat gezeigt, dass nahezu die gesamte
MCP-Landschaft aus Einzelmaintainer-Projekten mit 0–2 Stars besteht; bei einem dienstbasierten
Werkzeug waere so ein Server der einzige Zugriffspfad und sein Tod das Ende des Rueckblicks.
## Zwei Befunde aus der Umsetzung, die den urspruenglichen Entwurf korrigieren
Beide gegen den tatsaechlichen Quellcode von `super-productivity/super-productivity` (`master`)
verifiziert, 2026-09-19.
### 1. Kein `db.json` zum Lesen — das ist der Backup-Snapshot
Desktop-SP haelt seinen Live-Zustand in IndexedDB, nicht in einer Datei `db.json`. Was existiert:
`electron/backup.ts` schreibt den vollstaendigen Zustand als `JSON.stringify(data)` nach
`<userData>/backups/<timestamp>.json`, neueste Datei zuletzt (Dateiname sortiert lexikalisch,
so der eigene Kommentar dort). Form: `AppDataComplete`/`AppDataCompleteLegacy`
(`src/app/op-log/model/model-config.ts` bzw. `src/app/imex/sync/sync.model.ts`), flach, je
Feature ein Top-Level-Key — `task`/`project`/`tag` als `@ngrx/entity`
`{"ids": [...], "entities": {...}}`. Der Lesepfad liest genau diese drei Keys aus der neuesten
Backup-Datei (`db_path` fuer eine feste Datei, sonst `backups_dir` + lexikalisches Maximum) und
scheitert laut (Exit 1, `ValidationError`) auf jede Struktur, die nicht passt — SPs internes
Modell ist unversioniert, Drift ist erwartbar, kein Randfall.
### 2. Die lokale REST-API kann keine Projekte anlegen
`electron/local-rest-api-handler.service.ts` routet `GET /projects`, aber **kein**
`POST /projects` — Task-CRUD existiert, Projekt-CRUD nicht. Das bricht die in #119 D31
vorausgesetzte Automatik ("Projektanlage reitet auf dem vorhandenen Seiten-Scaffold mit: ...
entstehen Seite und Tracker-Projekt gleichen Namens").
**Entscheidung des Betreibers (2026-09-19), umgesetzt:** kein Workaround (kein Task-in-Inbox-
Trick, kein direktes `db.json`-Schreiben trotz D8/D31-Vorbehalt). Stattdessen ein neuer
Fehlertyp, der dieselbe Haltung wie die vier benannten Gates in AGENTS.md § Gates traegt, ohne
selbst eine fuenfte benannte Gate zu sein (kein Schwellwert, kein `--confirm`-Token):
`chemenu.errors.HumanInterventionRequired`. `SuperProductivityWriter.create_project`:
1. Preflight-Kollisionspruefung ueber den Lesepfad (D8, case-normalisiert) — bei Kollision
`ValidationError`, nichts wird angelegt.
2. Sonst `HumanInterventionRequired` mit einer fuer den Menschen lesbaren Anweisung ("Projekt
`<name>` selbst in Super Productivity anlegen") und einem `verify()` — ein zustandsloses
Callable, das den Lesepfad danach erneut befragt, ob das Projekt jetzt existiert. Eine
Bestaetigung des Nutzers wird nie als Tatsache genommen, ohne dass `verify()` sie bestaetigt.
**Was das fuer #126 bedeutet:** die CLI-seitige Uebersetzung ("Anweisung zeigen, anhalten, nach
Bestaetigung `verify()` aufrufen, erst dann fortfahren") ist noch nicht gebaut — #124 liefert nur
die Bibliotheksseite (`HumanInterventionRequired` selbst, dessen Docstring die Uebersetzung nach
`commands._util.needs_clearance()`/Exit 42 fuer den kuenftigen Aufrufer vorschreibt). #126s
`wikitool new project` muss diesen Fehler fangen und die Pause-bis-Bestaetigung-dann-verify-
Schleife tatsaechlich fahren; dieses Issue ist entsprechend praezisiert (siehe unten).
**Nebenbefund ohne Designfolgen:** SPs Someday/Maybe-Aequivalent ist der bestehende
`backlogTaskIds`-Puffer je Projekt (separat von der aktiven `taskIds`-Liste) — keine eigene
Tag-Konvention noetig. Beantwortet die "Zu verifizieren"-Frage aus #119.
## Was gebaut wurde
### Adapter-Protokoll (`chemenu.tasks.protocol`)
`TaskReader`/`TaskWriter` als getrennte `Protocol`s — ein Adapter kann `TaskWriter` weglassen,
ohne dass `TaskReader` davon beruehrt wird (erfuellt per Konstruktion: SP implementiert nur
einen halb-funktionalen Writer, der Reader ist vollstaendig unabhaengig).
| Operation | liefert |
|---|---|
| Projekte | Name, Anlagedatum |
| Offene Posten je Projekt | Anzahl; fuer `WAITING`-Posten zusaetzlich Titel und `follow_up_at` |
| Someday-Posten | Aenderungsdatum |
Schreibpfad: **ein** Vorgang — ein Projekt anlegen (fuer SP: siehe Befund 2 oben).
### Super-Productivity-Adapter (`chemenu.tasks.superproductivity`)
| Pfad | Wie |
|---|---|
| **Lesen** | neueste Backup-Datei unter `backups_dir`, oder eine feste `db_path` — headless, ohne laufende App |
| **Schreiben** | `HumanInterventionRequired` statt REST-API-Aufruf (Befund 2) |
Waiting-For nach D30: maschinenlesbar sind **nur** der `WAITING`-Status (eine Tag namens
`waiting`, case-insensitiv) und `follow_up_at` (der Reminder-Zeitstempel der Aufgabe, `remindAt`
— ausdruecklich **nicht** `dueDay`/`dueWithTime`). Die Person steht im Klartext im Aufgabentitel
und wird nicht geparst.
### Konfiguration (`chemenu.tasks.config`, `.wikitool-tasks.json`)
Analog `.wikitool-upload.json`: `provider`, dessen eigener Abschnitt (fuer SP: `backups_dir`
oder `db_path`, `api_base_url`, optional `api_token` — aktuell ungenutzt, da kein Aufruf hier
Authentifizierung braucht), und die drei Schwellwerte des Rueckblicks
(`stalled_waiting_days`/`unpaged_project_weeks`/`someday_stale_months`). Gitignored
(`.gitignore`, `docs_verify.REQUIRED_IGNORE_CANARIES`).
### `wikitool doctor`
Neuer Check `tasks-provider`: Provider konfiguriert oder nicht (beides `OK`), bei SP zusaetzlich
Lesepfad-Status und ob `GET /health` antwortet — nie `FAIL` auf Nichterreichbarkeit, nur auf eine
kaputte Konfigurationsdatei.
## Akzeptanzkriterien
- [x] Ein Adapter-Protokoll existiert, das Lese- und Schreibpfad **getrennt** deklariert; ein
Adapter kann den Schreibpfad nicht anbieten, ohne dass der Lesepfad davon beruehrt wird.
- [x] Der SP-Adapter liefert gegen eine Fixture (die reale Backup-Snapshot-Form, s.o. — nicht
"db.json" im woertlichen Sinn, siehe Befund 1) Projekte mit Alter, offene Posten je
Projekt, `WAITING`-Posten mit `follow_up_at` und Someday-Posten mit Aenderungsdatum —
**ohne dass ein Prozess laeuft**.
- [x] **Schema-Drift scheitert laut.** `test_schema_drift_on_task_key_fails_loud_not_silent`,
`test_missing_top_level_key_fails_loud`.
- [x] Fehlt `.wikitool-tasks.json`, nennt die Fehlermeldung die Datei und das erwartete Format;
kein Stacktrace, kein stiller Default.
- [x] Der Schreibpfad prueft **vor** dem Anlegen, ob der Name im Tracker schon vergeben ist
(case-normalisiert, D8), und legt bei Kollision nichts an — **praezisiert durch Befund 2**:
"legt nichts an" heisst fuer SP nie "legt automatisch an", sondern "verlangt einen
verifizierten menschlichen Schritt" (`HumanInterventionRequired`).
- [x] Laeuft die SP-App nicht, ist das fuer den *Lesepfad* irrelevant (headless); fuer den
*Schreibpfad* ist es ohnehin immer `HumanInterventionRequired` — es gibt keinen
API-Aufruf, der noch auf "App laeuft nicht" pruefen muesste (Befund 2 aendert diesen
Punkt inhaltlich).
- [x] **Kein Credential liegt im Repo.** `.wikitool-tasks.json` in `.gitignore` und
`docs_verify.REQUIRED_IGNORE_CANARIES`.
- [x] `tools/wikitool doctor` berichtet den konfigurierten Provider und ob er erreichbar ist —
read-only, FAILt nicht, wenn keiner konfiguriert ist.
- [x] `docs verify`, `instructions verify`, `pytest` gruen (1354 Tests, inkl. Lauf gegen eine
leere Maschine per `instructions/dev/testing-conventions.md` Schritt 6).
- [x] Versionsteil: `--minor` (neue Faehigkeit, drop-in in beide Richtungen; die Instanz-seitige
`--major`-Eskalation dieses Kandidaten stammt aus #123, nicht aus diesem Paket).
## Was hier ausdruecklich nicht gebaut wird
Kein Kommando. Diese Schicht ist Bibliothek; die Kommandos sind Paket 4 und 5. Und kein
MCP-Tool — wird spaeter ein entfernter Konsument gebraucht, wird es eines auf dem vorhandenen
Leseserver, gleicher Kern, gleicher Golden-Test (D25).
**Neu abgegrenzt durch Befund 2:** #126 (`wikitool new project`) muss jetzt zusaetzlich die
Pause-bis-Bestaetigung-Schleife um `HumanInterventionRequired` bauen (Anweisung zeigen via
`commands._util.needs_clearance()`/Exit 42, nach Nutzerbestaetigung `verify()` aufrufen, nur bei
`True` fortfahren) — das war im urspruenglichen Entwurf implizit "der Schreibpfad legt an", ist
jetzt fuer SP explizit ein Mensch-in-der-Schleife-Schritt.
## Testhinweis
`instructions/dev/testing-conventions.md` gilt: die Suite laeuft gegen eine bewusst leere
Maschine. Der Adapter darf in keinem Test eine laufende SP-Instanz, ein Netzwerk oder einen
Pfad im Home des Benutzers voraussetzen — alles ueber Fixtures und konfigurierte Pfade.
`test_superproductivity.py`s `health()`-Tests nutzen ausschliesslich Loopback-Sockets
(`127.0.0.1`, ephemerer Port oder ein garantiert geschlossener Port) — kein echtes Netzwerk.
## Abhaengigkeiten
Unabhaengig von #122 und dem Typ-Paket. Blockiert Paket 4 und Paket 5 — beide jetzt frei,
#126 mit der oben genannten zusaetzlichen Anforderung.
Geschlossen mit 1875449 (Stack 7.0.0-beta.2). Gegenueber der Ausschreibung zwei verifizierte Korrekturen: der Lesepfad liest den Backup-Snapshot statt einer nicht existierenden db.json, und der Schreibpfad kann SPs lokale REST-API nicht fuer die Projektanlage nutzen (kein POST /projects) - dafuer jetzt chemenu.errors.HumanInterventionRequired mit verify(), wie im Body oben unter "Zwei Befunde" beschrieben. Alle Akzeptanzkriterien erfuellt oder praezisiert; #126 traegt eine neue, dort nachgetragene Anforderung (die Pause-bis-Bestaetigung-Schleife um diesen Fehlertyp).
Geschlossen mit `1875449` (Stack 7.0.0-beta.2). Gegenueber der Ausschreibung zwei verifizierte Korrekturen: der Lesepfad liest den Backup-Snapshot statt einer nicht existierenden `db.json`, und der Schreibpfad kann SPs lokale REST-API nicht fuer die Projektanlage nutzen (kein `POST /projects`) - dafuer jetzt `chemenu.errors.HumanInterventionRequired` mit `verify()`, wie im Body oben unter "Zwei Befunde" beschrieben. Alle Akzeptanzkriterien erfuellt oder praezisiert; #126 traegt eine neue, dort nachgetragene Anforderung (die Pause-bis-Bestaetigung-Schleife um diesen Fehlertyp).
Modell-Uebergabe: Design/Verifikation (der Trace-Vergleich gegen super-productivity/super-productivity, die Grenzfall-Entscheidung mit dem Betreiber), die mechanische Umsetzung (Code, Tests, Version-Bump) und diese Closing-Phase liefen alle auf Sonnet 5 - kein Modellwechsel in dieser Sitzung.
Modell-Uebergabe: Design/Verifikation (der Trace-Vergleich gegen `super-productivity/super-productivity`, die Grenzfall-Entscheidung mit dem Betreiber), die mechanische Umsetzung (Code, Tests, Version-Bump) und diese Closing-Phase liefen alle auf Sonnet 5 - kein Modellwechsel in dieser Sitzung.
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.
Erledigt (
1875449, Stack 7.0.0-beta.2).chemenu.tasks.protocol(TaskReader/TaskWriter),chemenu.tasks.config(.wikitool-tasks.json),chemenu.tasks.superproductivity(
SuperProductivityReader/SuperProductivityWriter),wikitool doctor-Integration, Tests untertools/chemenu/tests/test_tasks_*.py/test_superproductivity.py.Paket 3 aus #119 (D15, D25, D30). Die Schicht, ueber die
wikitoolan den Aufgaben-Trackerkommt — ohne dass irgendeine Instruction je erfaehrt, welcher es ist.
Der tragende Gedanke
Die Provider-Grenze ist eine Kommandoflaeche, keine Instruction-Frage. Der Agent ruft
tools/wikitoolund nichts sonst. Damit entfaellt selective disclosure, ein Filter beimSkill-Publishing und jede Faehigkeitsmatrix in Prosa: es gibt einen Skill, provider-agnostisch.
Kein fremder MCP (D25). Wir schreiben den Adapter selbst gegen das dokumentierte Format
bzw. die dokumentierte API. Die Marktrecherche in #119 hat gezeigt, dass nahezu die gesamte
MCP-Landschaft aus Einzelmaintainer-Projekten mit 0–2 Stars besteht; bei einem dienstbasierten
Werkzeug waere so ein Server der einzige Zugriffspfad und sein Tod das Ende des Rueckblicks.
Zwei Befunde aus der Umsetzung, die den urspruenglichen Entwurf korrigieren
Beide gegen den tatsaechlichen Quellcode von
super-productivity/super-productivity(master)verifiziert, 2026-09-19.
1. Kein
db.jsonzum Lesen — das ist der Backup-SnapshotDesktop-SP haelt seinen Live-Zustand in IndexedDB, nicht in einer Datei
db.json. Was existiert:electron/backup.tsschreibt den vollstaendigen Zustand alsJSON.stringify(data)nach<userData>/backups/<timestamp>.json, neueste Datei zuletzt (Dateiname sortiert lexikalisch,so der eigene Kommentar dort). Form:
AppDataComplete/AppDataCompleteLegacy(
src/app/op-log/model/model-config.tsbzw.src/app/imex/sync/sync.model.ts), flach, jeFeature ein Top-Level-Key —
task/project/tagals@ngrx/entity{"ids": [...], "entities": {...}}. Der Lesepfad liest genau diese drei Keys aus der neuestenBackup-Datei (
db_pathfuer eine feste Datei, sonstbackups_dir+ lexikalisches Maximum) undscheitert laut (Exit 1,
ValidationError) auf jede Struktur, die nicht passt — SPs internesModell ist unversioniert, Drift ist erwartbar, kein Randfall.
2. Die lokale REST-API kann keine Projekte anlegen
electron/local-rest-api-handler.service.tsroutetGET /projects, aber keinPOST /projects— Task-CRUD existiert, Projekt-CRUD nicht. Das bricht die in #119 D31vorausgesetzte Automatik ("Projektanlage reitet auf dem vorhandenen Seiten-Scaffold mit: ...
entstehen Seite und Tracker-Projekt gleichen Namens").
Entscheidung des Betreibers (2026-09-19), umgesetzt: kein Workaround (kein Task-in-Inbox-
Trick, kein direktes
db.json-Schreiben trotz D8/D31-Vorbehalt). Stattdessen ein neuerFehlertyp, der dieselbe Haltung wie die vier benannten Gates in AGENTS.md § Gates traegt, ohne
selbst eine fuenfte benannte Gate zu sein (kein Schwellwert, kein
--confirm-Token):chemenu.errors.HumanInterventionRequired.SuperProductivityWriter.create_project:ValidationError, nichts wird angelegt.HumanInterventionRequiredmit einer fuer den Menschen lesbaren Anweisung ("Projekt<name>selbst in Super Productivity anlegen") und einemverify()— ein zustandslosesCallable, das den Lesepfad danach erneut befragt, ob das Projekt jetzt existiert. Eine
Bestaetigung des Nutzers wird nie als Tatsache genommen, ohne dass
verify()sie bestaetigt.Was das fuer #126 bedeutet: die CLI-seitige Uebersetzung ("Anweisung zeigen, anhalten, nach
Bestaetigung
verify()aufrufen, erst dann fortfahren") ist noch nicht gebaut — #124 liefert nurdie Bibliotheksseite (
HumanInterventionRequiredselbst, dessen Docstring die Uebersetzung nachcommands._util.needs_clearance()/Exit 42 fuer den kuenftigen Aufrufer vorschreibt). #126swikitool new projectmuss diesen Fehler fangen und die Pause-bis-Bestaetigung-dann-verify-Schleife tatsaechlich fahren; dieses Issue ist entsprechend praezisiert (siehe unten).
Nebenbefund ohne Designfolgen: SPs Someday/Maybe-Aequivalent ist der bestehende
backlogTaskIds-Puffer je Projekt (separat von der aktiventaskIds-Liste) — keine eigeneTag-Konvention noetig. Beantwortet die "Zu verifizieren"-Frage aus #119.
Was gebaut wurde
Adapter-Protokoll (
chemenu.tasks.protocol)TaskReader/TaskWriterals getrennteProtocols — ein Adapter kannTaskWriterweglassen,ohne dass
TaskReaderdavon beruehrt wird (erfuellt per Konstruktion: SP implementiert nureinen halb-funktionalen Writer, der Reader ist vollstaendig unabhaengig).
WAITING-Posten zusaetzlich Titel undfollow_up_atSchreibpfad: ein Vorgang — ein Projekt anlegen (fuer SP: siehe Befund 2 oben).
Super-Productivity-Adapter (
chemenu.tasks.superproductivity)backups_dir, oder eine festedb_path— headless, ohne laufende AppHumanInterventionRequiredstatt REST-API-Aufruf (Befund 2)Waiting-For nach D30: maschinenlesbar sind nur der
WAITING-Status (eine Tag namenswaiting, case-insensitiv) undfollow_up_at(der Reminder-Zeitstempel der Aufgabe,remindAt— ausdruecklich nicht
dueDay/dueWithTime). Die Person steht im Klartext im Aufgabentitelund wird nicht geparst.
Konfiguration (
chemenu.tasks.config,.wikitool-tasks.json)Analog
.wikitool-upload.json:provider, dessen eigener Abschnitt (fuer SP:backups_diroder
db_path,api_base_url, optionalapi_token— aktuell ungenutzt, da kein Aufruf hierAuthentifizierung braucht), und die drei Schwellwerte des Rueckblicks
(
stalled_waiting_days/unpaged_project_weeks/someday_stale_months). Gitignored(
.gitignore,docs_verify.REQUIRED_IGNORE_CANARIES).wikitool doctorNeuer Check
tasks-provider: Provider konfiguriert oder nicht (beidesOK), bei SP zusaetzlichLesepfad-Status und ob
GET /healthantwortet — nieFAILauf Nichterreichbarkeit, nur auf einekaputte Konfigurationsdatei.
Akzeptanzkriterien
Adapter kann den Schreibpfad nicht anbieten, ohne dass der Lesepfad davon beruehrt wird.
"db.json" im woertlichen Sinn, siehe Befund 1) Projekte mit Alter, offene Posten je
Projekt,
WAITING-Posten mitfollow_up_atund Someday-Posten mit Aenderungsdatum —ohne dass ein Prozess laeuft.
test_schema_drift_on_task_key_fails_loud_not_silent,test_missing_top_level_key_fails_loud..wikitool-tasks.json, nennt die Fehlermeldung die Datei und das erwartete Format;kein Stacktrace, kein stiller Default.
(case-normalisiert, D8), und legt bei Kollision nichts an — praezisiert durch Befund 2:
"legt nichts an" heisst fuer SP nie "legt automatisch an", sondern "verlangt einen
verifizierten menschlichen Schritt" (
HumanInterventionRequired).Schreibpfad ist es ohnehin immer
HumanInterventionRequired— es gibt keinenAPI-Aufruf, der noch auf "App laeuft nicht" pruefen muesste (Befund 2 aendert diesen
Punkt inhaltlich).
.wikitool-tasks.jsonin.gitignoreunddocs_verify.REQUIRED_IGNORE_CANARIES.tools/wikitool doctorberichtet den konfigurierten Provider und ob er erreichbar ist —read-only, FAILt nicht, wenn keiner konfiguriert ist.
docs verify,instructions verify,pytestgruen (1354 Tests, inkl. Lauf gegen eineleere Maschine per
instructions/dev/testing-conventions.mdSchritt 6).--minor(neue Faehigkeit, drop-in in beide Richtungen; die Instanz-seitige--major-Eskalation dieses Kandidaten stammt aus #123, nicht aus diesem Paket).Was hier ausdruecklich nicht gebaut wird
Kein Kommando. Diese Schicht ist Bibliothek; die Kommandos sind Paket 4 und 5. Und kein
MCP-Tool — wird spaeter ein entfernter Konsument gebraucht, wird es eines auf dem vorhandenen
Leseserver, gleicher Kern, gleicher Golden-Test (D25).
Neu abgegrenzt durch Befund 2: #126 (
wikitool new project) muss jetzt zusaetzlich diePause-bis-Bestaetigung-Schleife um
HumanInterventionRequiredbauen (Anweisung zeigen viacommands._util.needs_clearance()/Exit 42, nach Nutzerbestaetigungverify()aufrufen, nur beiTruefortfahren) — das war im urspruenglichen Entwurf implizit "der Schreibpfad legt an", istjetzt fuer SP explizit ein Mensch-in-der-Schleife-Schritt.
Testhinweis
instructions/dev/testing-conventions.mdgilt: die Suite laeuft gegen eine bewusst leereMaschine. Der Adapter darf in keinem Test eine laufende SP-Instanz, ein Netzwerk oder einen
Pfad im Home des Benutzers voraussetzen — alles ueber Fixtures und konfigurierte Pfade.
test_superproductivity.pyshealth()-Tests nutzen ausschliesslich Loopback-Sockets(
127.0.0.1, ephemerer Port oder ein garantiert geschlossener Port) — kein echtes Netzwerk.Abhaengigkeiten
Unabhaengig von #122 und dem Typ-Paket. Blockiert Paket 4 und Paket 5 — beide jetzt frei,
#126 mit der oben genannten zusaetzlichen Anforderung.
Geschlossen mit
1875449(Stack 7.0.0-beta.2). Gegenueber der Ausschreibung zwei verifizierte Korrekturen: der Lesepfad liest den Backup-Snapshot statt einer nicht existierendendb.json, und der Schreibpfad kann SPs lokale REST-API nicht fuer die Projektanlage nutzen (keinPOST /projects) - dafuer jetztchemenu.errors.HumanInterventionRequiredmitverify(), wie im Body oben unter "Zwei Befunde" beschrieben. Alle Akzeptanzkriterien erfuellt oder praezisiert; #126 traegt eine neue, dort nachgetragene Anforderung (die Pause-bis-Bestaetigung-Schleife um diesen Fehlertyp).Modell-Uebergabe: Design/Verifikation (der Trace-Vergleich gegen
super-productivity/super-productivity, die Grenzfall-Entscheidung mit dem Betreiber), die mechanische Umsetzung (Code, Tests, Version-Bump) und diese Closing-Phase liefen alle auf Sonnet 5 - kein Modellwechsel in dieser Sitzung.torben referenced this issue2026-09-30 05:15:50 +00:00