Der MCP-Zugriff ist analysierend, nicht agierend. Das ist die Linie, an der die Fläche
geschnitten wird, und alles Weitere folgt daraus: gelesen wird von außen, gehandelt wird am
Arbeitsplatz. Zu bauen wäre deshalb eine Lesefläche über die Aufgaben-Schicht — Projekte, offene
Posten, Waiting, Someday —, und ausdrücklich kein Weg, von außen etwas zu ändern.
prio/waiting, und der Auslöser ist benannt: ein belegter Fall ohne PC. Der mobile Fall ist
heute Spielerei (Betreiber, 2026-09-20). Ohne ihn rechtfertigt sich weder die Lesefläche noch die
Snapshot-Verteilung: am Desktop liegt die Datei ohnehin, und dort gibt es die CLI. Die Analyse
unten bleibt gültig und wartet auf das Szenario — die Gegenrichtung (Ingest schreibt Wissen und
Verpflichtung) ist #132 und hängt an keiner dieser Fragen.
Dieses Issue steht auf eigenen Beinen. Die Begründung der Zwei-Schichten-Konstruktion steht in docs/knowledge-and-commitment.md, die verbindlichen Zeilen zum MCP-Server und zur Aufgaben-Schicht
in tools/CONTRACT.md.
Befunde aus dem Baum
Am 2026-09-20 gegen den Baum geprüft.
Der Lesepfad braucht nichts als eine Datei.SuperProductivityReader liest einen
Backup-Schnappschuss, ohne API und ohne Token; backups_dir bzw. db_path in .wikitool-tasks.json sind frei konfigurierbare Pfade. Ein entfernter Checkout kann damit ohne eine Zeile Code vollständig lesen — die Datei dorthin zu bekommen ist reine
Deployment-Arbeit.
Der Schreibpfad kommt dort per Transport nicht an. Er ist die lokale REST-API auf 127.0.0.1:3876. Ein Server abseits des Desktops hat keine Route dahin. „Analysierend, nicht
agierend" ist damit keine Disziplin, die jemand einhalten muss, sondern eine Eigenschaft der
Konstruktion — dieselbe Qualität, die #19 für kb/ hat (nicht gefiltert, sondern unerreichbar).
„Projekte vollständig abfragen" passt heute nicht ganz durch das Protokoll.OpenItems
trägt count plus die WAITING-Posten mit Titel — die Titel der übrigen offenen Posten wirft
der Adapter weg, obwohl er sie in der Hand hat (open_items() iteriert bereits über sie).
Extern „was steht bei Projekt X an" zu beantworten heißt also: Protokoll verbreitern, und das
bindet jeden Adapter (#128 Regel 1). Siehe D3.
Der Schnappschuss ist der vollständige App-Zustand. Der Adapter liest drei Schlüssel
(project, task, tag). Was sonst in der Datei steht, ist anzusehen, bevor sie die
Maschine verlässt — und mit ihr wandert die Sprengweite des Server-Tokens vom öffentlichen
Testbett-Korpus zum kompletten persönlichen Aufgabenbestand.
Die Aufgaben-Hälfte hat keinen Commit, aber ein Alter. Jede MCP-Antwort trägt heute den
Commit, aus dem sie berechnet wurde; für eine Datei, die per File-Sync ankommt, gibt es keinen.
Der Zeitstempel steht aber im Dateinamen — latest_snapshot_path() sortiert genau danach. Daraus
wird der Alters-Stempel der Aufgaben-Hälfte, statt sie ungestempelt neben eine gestempelte kb/-Hälfte zu legen.
Der Weg über unsere Schicht ist bereits entschieden.chemenu/tasks/__init__.py: der Tracker
wird durch diese Schicht erreicht, „never an instruction, never a second MCP server" (#119 D25).
Ein externer Aufgaben-Zugriff geht deshalb durch unseren Server, nicht dadurch, dass der
Konsument zusätzlich den des Trackers einbindet.
Zu entscheiden
D1 — Lesewerkzeuge über die Aufgaben-Schicht
Empfehlung: ja, sobald der Auslöser eintritt. Ein Werkzeug, das die Projekte mit
offenen-Posten-Zahl liefert, und eines für die Posten eines Projekts (Waiting mit follow_up_at
inbegriffen); Someday als drittes oder als Filter. Registriert nur, wenn .wikitool-tasks.json
vorhanden ist — dieselbe Haltung wie bei submit: ohne Konfiguration existiert das Werkzeug nicht,
statt zu existieren und immer abzusagen.
Keine Schreibwerkzeuge, kein create_project — nicht als Verzicht, sondern weil Befund 2 es
ohnehin nicht zulässt. Das gehört als Entscheidungspunkt in instructions/mcp-read-server.md,
damit es beim nächsten Deployment nicht als Lücke gelesen wird.
D2 — die Datei dorthin bekommen
Empfehlung: File-Sync parallel zu git, mit dem Ziel außerhalb des bedienten Baums. Der
Korpus-Sync ist git fetch && git reset --hard; .wikitool-tasks.json ist gitignored und kommt
dort nie an, also wird beides — Konfiguration und Snapshot-Verzeichnis — dem Deployment aus der
Hand gereicht, nicht aus dem Repo. Das Snapshot-Verzeichnis liegt dabei außerhalb des Korpus,
aus demselben Grund, aus dem WIKI_TRACE_DIR dort nicht liegen darf.
Zwei Uhren, die das mit sich bringt: die kb/-Hälfte bewegt sich mit git, die Aufgaben-Hälfte mit
dem File-Sync, und der Snapshot selbst entsteht nur, wenn Super Productivity ein Backup schreibt.
Eine externe Antwort ist damit dreifach verzögert. Befund 5 ist die Antwort darauf: das Alter
sichtbar machen, statt es zu glätten.
D3 — Protokoll verbreitern für die Titel offener Posten?
Die eine echte Designfrage, und noch nicht entschieden. Ohne sie liefert die Lesefläche „7
offene Posten" und nennt nur die Waiting-Posten beim Namen — was für einen Blick von außen dünn
ist, aber das Protokoll unangetastet lässt. Mit ihr wird OpenItems um die Posten selbst
erweitert, jeder Adapter muss sie liefern, und #128 zieht nach, bevor er existiert.
Neigung: verbreitern, aber minimal — Titel und nichts weiter, ausdrücklich kein Fälligkeits-,
Aufwands- oder Zuständigkeitsfeld. Die Regel aus #128 gilt unverändert: ein gemeinsames Modell,
das je Provider verschieden viel weiß, ist kein gemeinsames Modell; jedes Feld, das hier
dazukommt, muss ein Azure-DevOps-Adapter genauso liefern können.
Was hier herausfällt
review als MCP-Werkzeug: gestrichen. Der wöchentliche Rückblick endet in touch, new project und publish — er ist die Handlungshälfte, und die findet am Arbeitsplatz statt.
Die Prozedur über MCP-prompts: gestrichen, mit demselben Grund.
Ein Morning Briefing ist kein Server-Feature. Steht die Lesefläche, ist ein Briefing eine
Komposition beim Konsumenten — Korpus-Suche plus Aufgaben-Lesen, zusammengesetzt von dessen
Modell. Genau das ist das Argument, hier die Fläche zu bauen und nichts darüber hinaus.
Der Schreibweg in den Tracker gehört nicht hierher, aber es gibt ihn:#132 baut ihn für den
Ingest am Arbeitsplatz. Das ist die Gegenrichtung und hängt an keiner Frage dieses Issues.
Akzeptanzkriterien
Gelten, sobald der Auslöser eintritt.
Die Aufgaben-Lesewerkzeuge liefern dieselben Werte wie der TaskReader, gegen Fixtures
geprüft; kein Test braucht eine laufende Super-Productivity-Instanz.
Ohne .wikitool-tasks.jsonenthält die Werkzeugliste des Servers sie nicht; ein Test
vergleicht beide Fälle.
Der Server importiert weiterhin nichts unter chemenu.commands; der vorhandene sys.modules-Test bleibt grün und deckt den neuen Pfad mit ab.
Es gibt über MCP kein Werkzeug, das eine Aufgabe oder ein Tracker-Projekt anlegt oder ändert.
Jede Aufgaben-Antwort trägt das Alter des Schnappschusses, aus dem sie stammt, und eine
Antwort, die beide Hälften mischt, macht unterscheidbar, dass die kb/-Hälfte
commit-gestempelt ist und die Aufgaben-Hälfte datei-gestempelt.
Ein Lauf hinterlässt im bedienten Baum keine Änderung: Dateibaum, HEAD und git status --porcelain sind vorher und nachher gleich — derselbe Test, den die übrigen
Werkzeuge haben.
Ein Schnappschuss, dessen Form der Adapter nicht kennt, scheitert laut; über MCP kommt das
als Werkzeug-Fehler an, nie als leere Projektliste.
Falls D3 „verbreitern" ausgeht: tasks/protocol.py trägt das neue Feld, der SP-Adapter füllt
es, und #128 ist um das Kriterium ergänzt, dass ein Azure-DevOps-Adapter es liefert.
Nachgezogen: tools/CONTRACT.md (MCP-Designnotiz und die Aufgaben-Schicht-Notiz), instructions/mcp-read-server.md (inkl. Entscheidungspunkt „kein Schreibweg zum Tracker" und
dem Snapshot-Verzeichnis außerhalb des Korpus), INSTALL-MCP.md (Werkzeugtabelle,
Verifikations-Ausgabe, ein Schritt zur Snapshot-Zustellung), README.md.
kb/concepts/architectures/MCP-Leseserver.md beschreibt weiterhin den tatsächlichen
Werkzeugsatz — über den normalen Inhaltsweg (wiki-manage), nicht von Hand.
docs verify, instructions verify, pytest grün; Version gebumpt (neue Fähigkeit,
beidseitig drop-in → --minor; eine Protokolländerung aus D3 ist für eine ausgelieferte
Instanz trotzdem drop-in, solange kein Adapter von außen existiert).
Vorher zu klären
Ist der mobile Fall real genug? Nein — heute Spielerei (Betreiber, 2026-09-20). Das ist
der Grund für prio/waiting; der Auslöser steht oben.
D3 entscheiden — Titel der offenen Posten ins Protokoll oder nicht. Bestimmt, ob die
Lesefläche „wie viel" oder „was" beantwortet, und ob #128 nachzieht. Fällt womöglich vorher
an: #132 verbreitert den Schreib-Teil desselben Protokolls, und wer dort ohnehin hineinfasst,
kann diese Frage gleich mitentscheiden.
Was steht außer project/task/tag im Schnappschuss? Befund 4. Einmal ansehen, bevor
die Datei die Maschine verlässt; danach ist die Frage, ob sie gefiltert wandert oder ganz.
Welcher File-Sync, und mit welcher Frequenz? Zusammen mit #37 zu beantworten, weil das
Deployment dann zwei Sync-Wege mit verschiedenen Uhren hat statt einem.
Abhängigkeiten
Keine blockierenden. Berührungspunkte: #37 (Container-Image — dort fällt D2 an), #128
(Azure-DevOps-Adapter — zieht eine Protokolländerung aus D3 nach), #132 (der Schreibweg für den
Ingest; berührt dasselbe Protokoll von der anderen Seite).
Der MCP-Zugriff ist **analysierend, nicht agierend**. Das ist die Linie, an der die Fläche
geschnitten wird, und alles Weitere folgt daraus: gelesen wird von außen, gehandelt wird am
Arbeitsplatz. Zu bauen wäre deshalb eine Lesefläche über die Aufgaben-Schicht — Projekte, offene
Posten, Waiting, Someday —, und ausdrücklich kein Weg, von außen etwas zu ändern.
> **`prio/waiting`, und der Auslöser ist benannt: ein belegter Fall ohne PC.** Der mobile Fall ist
> heute Spielerei (Betreiber, 2026-09-20). Ohne ihn rechtfertigt sich weder die Lesefläche noch die
> Snapshot-Verteilung: am Desktop liegt die Datei ohnehin, und dort gibt es die CLI. Die Analyse
> unten bleibt gültig und wartet auf das Szenario — die Gegenrichtung (Ingest schreibt Wissen *und*
> Verpflichtung) ist #132 und hängt an keiner dieser Fragen.
**Dieses Issue steht auf eigenen Beinen.** Die Begründung der Zwei-Schichten-Konstruktion steht in
`docs/knowledge-and-commitment.md`, die verbindlichen Zeilen zum MCP-Server und zur Aufgaben-Schicht
in `tools/CONTRACT.md`.
## Befunde aus dem Baum
Am 2026-09-20 gegen den Baum geprüft.
1. **Der Lesepfad braucht nichts als eine Datei.** `SuperProductivityReader` liest einen
Backup-Schnappschuss, ohne API und ohne Token; `backups_dir` bzw. `db_path` in
`.wikitool-tasks.json` sind frei konfigurierbare Pfade. Ein entfernter Checkout kann damit
**ohne eine Zeile Code** vollständig lesen — die Datei dorthin zu bekommen ist reine
Deployment-Arbeit.
2. **Der Schreibpfad kommt dort per Transport nicht an.** Er ist die lokale REST-API auf
`127.0.0.1:3876`. Ein Server abseits des Desktops hat keine Route dahin. „Analysierend, nicht
agierend" ist damit keine Disziplin, die jemand einhalten muss, sondern eine Eigenschaft der
Konstruktion — dieselbe Qualität, die #19 für `kb/` hat (nicht gefiltert, sondern unerreichbar).
3. **„Projekte vollständig abfragen" passt heute nicht ganz durch das Protokoll.** `OpenItems`
trägt `count` plus die `WAITING`-Posten mit Titel — die Titel der übrigen offenen Posten wirft
der Adapter weg, obwohl er sie in der Hand hat (`open_items()` iteriert bereits über sie).
Extern „was steht bei Projekt X an" zu beantworten heißt also: Protokoll verbreitern, und das
bindet jeden Adapter (#128 Regel 1). Siehe D3.
4. **Der Schnappschuss ist der vollständige App-Zustand.** Der Adapter liest drei Schlüssel
(`project`, `task`, `tag`). Was sonst in der Datei steht, ist anzusehen, **bevor** sie die
Maschine verlässt — und mit ihr wandert die Sprengweite des Server-Tokens vom öffentlichen
Testbett-Korpus zum kompletten persönlichen Aufgabenbestand.
5. **Die Aufgaben-Hälfte hat keinen Commit, aber ein Alter.** Jede MCP-Antwort trägt heute den
Commit, aus dem sie berechnet wurde; für eine Datei, die per File-Sync ankommt, gibt es keinen.
Der Zeitstempel steht aber im Dateinamen — `latest_snapshot_path()` sortiert genau danach. Daraus
wird der Alters-Stempel der Aufgaben-Hälfte, statt sie ungestempelt neben eine gestempelte
`kb/`-Hälfte zu legen.
6. **Der Weg über unsere Schicht ist bereits entschieden.** `chemenu/tasks/__init__.py`: der Tracker
wird durch diese Schicht erreicht, „never an instruction, never a second MCP server" (#119 D25).
Ein externer Aufgaben-Zugriff geht deshalb durch *unseren* Server, nicht dadurch, dass der
Konsument zusätzlich den des Trackers einbindet.
## Zu entscheiden
### D1 — Lesewerkzeuge über die Aufgaben-Schicht
**Empfehlung: ja, sobald der Auslöser eintritt.** Ein Werkzeug, das die Projekte mit
offenen-Posten-Zahl liefert, und eines für die Posten eines Projekts (Waiting mit `follow_up_at`
inbegriffen); Someday als drittes oder als Filter. Registriert nur, wenn `.wikitool-tasks.json`
vorhanden ist — dieselbe Haltung wie bei `submit`: ohne Konfiguration existiert das Werkzeug nicht,
statt zu existieren und immer abzusagen.
Keine Schreibwerkzeuge, kein `create_project` — nicht als Verzicht, sondern weil Befund 2 es
ohnehin nicht zulässt. Das gehört als Entscheidungspunkt in `instructions/mcp-read-server.md`,
damit es beim nächsten Deployment nicht als Lücke gelesen wird.
### D2 — die Datei dorthin bekommen
**Empfehlung: File-Sync parallel zu git, mit dem Ziel außerhalb des bedienten Baums.** Der
Korpus-Sync ist `git fetch && git reset --hard`; `.wikitool-tasks.json` ist gitignored und kommt
dort nie an, also wird beides — Konfiguration und Snapshot-Verzeichnis — dem Deployment aus der
Hand gereicht, nicht aus dem Repo. Das Snapshot-Verzeichnis liegt dabei **außerhalb** des Korpus,
aus demselben Grund, aus dem `WIKI_TRACE_DIR` dort nicht liegen darf.
Zwei Uhren, die das mit sich bringt: die `kb/`-Hälfte bewegt sich mit git, die Aufgaben-Hälfte mit
dem File-Sync, und der Snapshot selbst entsteht nur, wenn Super Productivity ein Backup schreibt.
Eine externe Antwort ist damit *dreifach* verzögert. Befund 5 ist die Antwort darauf: das Alter
sichtbar machen, statt es zu glätten.
### D3 — Protokoll verbreitern für die Titel offener Posten?
**Die eine echte Designfrage, und noch nicht entschieden.** Ohne sie liefert die Lesefläche „7
offene Posten" und nennt nur die Waiting-Posten beim Namen — was für einen Blick von außen dünn
ist, aber das Protokoll unangetastet lässt. Mit ihr wird `OpenItems` um die Posten selbst
erweitert, jeder Adapter muss sie liefern, und #128 zieht nach, bevor er existiert.
**Neigung: verbreitern, aber minimal** — Titel und nichts weiter, ausdrücklich kein Fälligkeits-,
Aufwands- oder Zuständigkeitsfeld. Die Regel aus #128 gilt unverändert: ein gemeinsames Modell,
das je Provider verschieden viel weiß, ist kein gemeinsames Modell; jedes Feld, das hier
dazukommt, muss ein Azure-DevOps-Adapter genauso liefern können.
### Was hier herausfällt
- **`review` als MCP-Werkzeug: gestrichen.** Der wöchentliche Rückblick endet in `touch`,
`new project` und `publish` — er *ist* die Handlungshälfte, und die findet am Arbeitsplatz statt.
- **Die Prozedur über MCP-`prompts`: gestrichen**, mit demselben Grund.
- **Ein Morning Briefing ist kein Server-Feature.** Steht die Lesefläche, ist ein Briefing eine
Komposition beim Konsumenten — Korpus-Suche plus Aufgaben-Lesen, zusammengesetzt von dessen
Modell. Genau das ist das Argument, hier die Fläche zu bauen und nichts darüber hinaus.
- **Der Schreibweg in den Tracker gehört nicht hierher, aber es gibt ihn:** #132 baut ihn für den
Ingest am Arbeitsplatz. Das ist die Gegenrichtung und hängt an keiner Frage dieses Issues.
## Akzeptanzkriterien
Gelten, sobald der Auslöser eintritt.
- [ ] Die Aufgaben-Lesewerkzeuge liefern dieselben Werte wie der `TaskReader`, gegen Fixtures
geprüft; **kein Test braucht eine laufende Super-Productivity-Instanz.**
- [ ] Ohne `.wikitool-tasks.json` **enthält die Werkzeugliste des Servers sie nicht**; ein Test
vergleicht beide Fälle.
- [ ] Der Server importiert weiterhin nichts unter `chemenu.commands`; der vorhandene
`sys.modules`-Test bleibt grün und deckt den neuen Pfad mit ab.
- [ ] Es gibt über MCP kein Werkzeug, das eine Aufgabe oder ein Tracker-Projekt anlegt oder ändert.
- [ ] Jede Aufgaben-Antwort trägt das Alter des Schnappschusses, aus dem sie stammt, und eine
Antwort, die beide Hälften mischt, macht unterscheidbar, dass die `kb/`-Hälfte
commit-gestempelt ist und die Aufgaben-Hälfte datei-gestempelt.
- [ ] Ein Lauf hinterlässt im bedienten Baum keine Änderung: Dateibaum, `HEAD` und
`git status --porcelain` sind vorher und nachher gleich — derselbe Test, den die übrigen
Werkzeuge haben.
- [ ] Ein Schnappschuss, dessen Form der Adapter nicht kennt, scheitert laut; über MCP kommt das
als Werkzeug-Fehler an, nie als leere Projektliste.
- [ ] Falls D3 „verbreitern" ausgeht: `tasks/protocol.py` trägt das neue Feld, der SP-Adapter füllt
es, und #128 ist um das Kriterium ergänzt, dass ein Azure-DevOps-Adapter es liefert.
- [ ] Nachgezogen: `tools/CONTRACT.md` (MCP-Designnotiz und die Aufgaben-Schicht-Notiz),
`instructions/mcp-read-server.md` (inkl. Entscheidungspunkt „kein Schreibweg zum Tracker" und
dem Snapshot-Verzeichnis außerhalb des Korpus), `INSTALL-MCP.md` (Werkzeugtabelle,
Verifikations-Ausgabe, ein Schritt zur Snapshot-Zustellung), `README.md`.
- [ ] `kb/concepts/architectures/MCP-Leseserver.md` beschreibt weiterhin den tatsächlichen
Werkzeugsatz — über den normalen Inhaltsweg (`wiki-manage`), nicht von Hand.
- [ ] `docs verify`, `instructions verify`, `pytest` grün; Version gebumpt (neue Fähigkeit,
beidseitig drop-in → `--minor`; eine Protokolländerung aus D3 ist für eine ausgelieferte
Instanz trotzdem drop-in, solange kein Adapter von außen existiert).
## Vorher zu klären
- [x] **Ist der mobile Fall real genug?** Nein — heute Spielerei (Betreiber, 2026-09-20). Das ist
der Grund für `prio/waiting`; der Auslöser steht oben.
- [ ] **D3 entscheiden** — Titel der offenen Posten ins Protokoll oder nicht. Bestimmt, ob die
Lesefläche „wie viel" oder „was" beantwortet, und ob #128 nachzieht. Fällt womöglich vorher
an: #132 verbreitert den *Schreib*-Teil desselben Protokolls, und wer dort ohnehin hineinfasst,
kann diese Frage gleich mitentscheiden.
- [ ] **Was steht außer `project`/`task`/`tag` im Schnappschuss?** Befund 4. Einmal ansehen, bevor
die Datei die Maschine verlässt; danach ist die Frage, ob sie gefiltert wandert oder ganz.
- [ ] **Welcher File-Sync, und mit welcher Frequenz?** Zusammen mit #37 zu beantworten, weil das
Deployment dann zwei Sync-Wege mit verschiedenen Uhren hat statt einem.
## Abhängigkeiten
Keine blockierenden. Berührungspunkte: #37 (Container-Image — dort fällt D2 an), #128
(Azure-DevOps-Adapter — zieht eine Protokolländerung aus D3 nach), #132 (der Schreibweg für den
Ingest; berührt dasselbe Protokoll von der anderen Seite).
torben
changed title from GTD über MCP: `review` als Lesewerkzeug, und ob es eine Aufgaben-Fläche braucht to Aufgaben lesend über MCP: externer Blick auf die Projekte, ohne Handlungspfad2026-09-20 10:18:42 +00:00
Changelog: Body und Titel neu geschrieben nach der Betreiber-Entscheidung „MCP ist
analysierend, nicht agierend".
Gestrichen:review als MCP-Werkzeug (alte D1) und die Prozedur über prompts (alte D2) —
der wöchentliche Rückblick ist Arbeitsplatz-Arbeit.
Gedreht: die alte D3 empfahl keine Aufgaben-Fläche; das galt dem Schreib-/CRUD-Fall. Die
Lesefläche ist jetzt der Inhalt des Issues.
Neu belegt: der Lesepfad braucht nur eine Datei und ist frei konfigurierbar (also ohne
Codeänderung entfernt lesbar); der Schreibpfad ist per Transport unerreichbar, womit
„analysierend" eine Konstruktions- statt einer Disziplin-Eigenschaft ist; OpenItems trägt keine
Titel der offenen Posten (neue D3); der Snapshot-Zeitstempel steht im Dateinamen und wird zum
Alters-Stempel.
**Changelog:** Body und Titel neu geschrieben nach der Betreiber-Entscheidung „MCP ist
analysierend, nicht agierend".
- **Gestrichen:** `review` als MCP-Werkzeug (alte D1) und die Prozedur über `prompts` (alte D2) —
der wöchentliche Rückblick ist Arbeitsplatz-Arbeit.
- **Gedreht:** die alte D3 empfahl *keine* Aufgaben-Fläche; das galt dem Schreib-/CRUD-Fall. Die
Lesefläche ist jetzt der Inhalt des Issues.
- **Neu belegt:** der Lesepfad braucht nur eine Datei und ist frei konfigurierbar (also ohne
Codeänderung entfernt lesbar); der Schreibpfad ist per Transport unerreichbar, womit
„analysierend" eine Konstruktions- statt einer Disziplin-Eigenschaft ist; `OpenItems` trägt keine
Titel der offenen Posten (neue D3); der Snapshot-Zeitstempel steht im Dateinamen und wird zum
Alters-Stempel.
- **Ausgelagert:** Capture und Zielwahl nach #132.
Changelog:prio/planned → prio/waiting, Auslöser benannt (ein belegter Fall ohne PC). Der
mobile Fall ist heute Spielerei (Betreiber, 2026-09-20) — die entsprechende offene Frage ist als
beantwortet abgehakt statt gestrichen, weil sie der Grund für das Label ist. Analyse und
Akzeptanzkriterien unverändert gültig. Neu vermerkt: #132 fasst denselben Protokollrahmen von der
Schreibseite an, D3 kann dort mitentschieden werden.
**Changelog:** `prio/planned` → `prio/waiting`, Auslöser benannt (ein belegter Fall ohne PC). Der
mobile Fall ist heute Spielerei (Betreiber, 2026-09-20) — die entsprechende offene Frage ist als
beantwortet abgehakt statt gestrichen, weil sie der Grund für das Label ist. Analyse und
Akzeptanzkriterien unverändert gültig. Neu vermerkt: #132 fasst denselben Protokollrahmen von der
Schreibseite an, D3 kann dort mitentschieden werden.
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.
Der MCP-Zugriff ist analysierend, nicht agierend. Das ist die Linie, an der die Fläche
geschnitten wird, und alles Weitere folgt daraus: gelesen wird von außen, gehandelt wird am
Arbeitsplatz. Zu bauen wäre deshalb eine Lesefläche über die Aufgaben-Schicht — Projekte, offene
Posten, Waiting, Someday —, und ausdrücklich kein Weg, von außen etwas zu ändern.
Dieses Issue steht auf eigenen Beinen. Die Begründung der Zwei-Schichten-Konstruktion steht in
docs/knowledge-and-commitment.md, die verbindlichen Zeilen zum MCP-Server und zur Aufgaben-Schichtin
tools/CONTRACT.md.Befunde aus dem Baum
Am 2026-09-20 gegen den Baum geprüft.
Der Lesepfad braucht nichts als eine Datei.
SuperProductivityReaderliest einenBackup-Schnappschuss, ohne API und ohne Token;
backups_dirbzw.db_pathin.wikitool-tasks.jsonsind frei konfigurierbare Pfade. Ein entfernter Checkout kann damitohne eine Zeile Code vollständig lesen — die Datei dorthin zu bekommen ist reine
Deployment-Arbeit.
Der Schreibpfad kommt dort per Transport nicht an. Er ist die lokale REST-API auf
127.0.0.1:3876. Ein Server abseits des Desktops hat keine Route dahin. „Analysierend, nichtagierend" ist damit keine Disziplin, die jemand einhalten muss, sondern eine Eigenschaft der
Konstruktion — dieselbe Qualität, die #19 für
kb/hat (nicht gefiltert, sondern unerreichbar).„Projekte vollständig abfragen" passt heute nicht ganz durch das Protokoll.
OpenItemsträgt
countplus dieWAITING-Posten mit Titel — die Titel der übrigen offenen Posten wirftder Adapter weg, obwohl er sie in der Hand hat (
open_items()iteriert bereits über sie).Extern „was steht bei Projekt X an" zu beantworten heißt also: Protokoll verbreitern, und das
bindet jeden Adapter (#128 Regel 1). Siehe D3.
Der Schnappschuss ist der vollständige App-Zustand. Der Adapter liest drei Schlüssel
(
project,task,tag). Was sonst in der Datei steht, ist anzusehen, bevor sie dieMaschine verlässt — und mit ihr wandert die Sprengweite des Server-Tokens vom öffentlichen
Testbett-Korpus zum kompletten persönlichen Aufgabenbestand.
Die Aufgaben-Hälfte hat keinen Commit, aber ein Alter. Jede MCP-Antwort trägt heute den
Commit, aus dem sie berechnet wurde; für eine Datei, die per File-Sync ankommt, gibt es keinen.
Der Zeitstempel steht aber im Dateinamen —
latest_snapshot_path()sortiert genau danach. Darauswird der Alters-Stempel der Aufgaben-Hälfte, statt sie ungestempelt neben eine gestempelte
kb/-Hälfte zu legen.Der Weg über unsere Schicht ist bereits entschieden.
chemenu/tasks/__init__.py: der Trackerwird durch diese Schicht erreicht, „never an instruction, never a second MCP server" (#119 D25).
Ein externer Aufgaben-Zugriff geht deshalb durch unseren Server, nicht dadurch, dass der
Konsument zusätzlich den des Trackers einbindet.
Zu entscheiden
D1 — Lesewerkzeuge über die Aufgaben-Schicht
Empfehlung: ja, sobald der Auslöser eintritt. Ein Werkzeug, das die Projekte mit
offenen-Posten-Zahl liefert, und eines für die Posten eines Projekts (Waiting mit
follow_up_atinbegriffen); Someday als drittes oder als Filter. Registriert nur, wenn
.wikitool-tasks.jsonvorhanden ist — dieselbe Haltung wie bei
submit: ohne Konfiguration existiert das Werkzeug nicht,statt zu existieren und immer abzusagen.
Keine Schreibwerkzeuge, kein
create_project— nicht als Verzicht, sondern weil Befund 2 esohnehin nicht zulässt. Das gehört als Entscheidungspunkt in
instructions/mcp-read-server.md,damit es beim nächsten Deployment nicht als Lücke gelesen wird.
D2 — die Datei dorthin bekommen
Empfehlung: File-Sync parallel zu git, mit dem Ziel außerhalb des bedienten Baums. Der
Korpus-Sync ist
git fetch && git reset --hard;.wikitool-tasks.jsonist gitignored und kommtdort nie an, also wird beides — Konfiguration und Snapshot-Verzeichnis — dem Deployment aus der
Hand gereicht, nicht aus dem Repo. Das Snapshot-Verzeichnis liegt dabei außerhalb des Korpus,
aus demselben Grund, aus dem
WIKI_TRACE_DIRdort nicht liegen darf.Zwei Uhren, die das mit sich bringt: die
kb/-Hälfte bewegt sich mit git, die Aufgaben-Hälfte mitdem File-Sync, und der Snapshot selbst entsteht nur, wenn Super Productivity ein Backup schreibt.
Eine externe Antwort ist damit dreifach verzögert. Befund 5 ist die Antwort darauf: das Alter
sichtbar machen, statt es zu glätten.
D3 — Protokoll verbreitern für die Titel offener Posten?
Die eine echte Designfrage, und noch nicht entschieden. Ohne sie liefert die Lesefläche „7
offene Posten" und nennt nur die Waiting-Posten beim Namen — was für einen Blick von außen dünn
ist, aber das Protokoll unangetastet lässt. Mit ihr wird
OpenItemsum die Posten selbsterweitert, jeder Adapter muss sie liefern, und #128 zieht nach, bevor er existiert.
Neigung: verbreitern, aber minimal — Titel und nichts weiter, ausdrücklich kein Fälligkeits-,
Aufwands- oder Zuständigkeitsfeld. Die Regel aus #128 gilt unverändert: ein gemeinsames Modell,
das je Provider verschieden viel weiß, ist kein gemeinsames Modell; jedes Feld, das hier
dazukommt, muss ein Azure-DevOps-Adapter genauso liefern können.
Was hier herausfällt
reviewals MCP-Werkzeug: gestrichen. Der wöchentliche Rückblick endet intouch,new projectundpublish— er ist die Handlungshälfte, und die findet am Arbeitsplatz statt.prompts: gestrichen, mit demselben Grund.Komposition beim Konsumenten — Korpus-Suche plus Aufgaben-Lesen, zusammengesetzt von dessen
Modell. Genau das ist das Argument, hier die Fläche zu bauen und nichts darüber hinaus.
Ingest am Arbeitsplatz. Das ist die Gegenrichtung und hängt an keiner Frage dieses Issues.
Akzeptanzkriterien
Gelten, sobald der Auslöser eintritt.
TaskReader, gegen Fixturesgeprüft; kein Test braucht eine laufende Super-Productivity-Instanz.
.wikitool-tasks.jsonenthält die Werkzeugliste des Servers sie nicht; ein Testvergleicht beide Fälle.
chemenu.commands; der vorhandenesys.modules-Test bleibt grün und deckt den neuen Pfad mit ab.Antwort, die beide Hälften mischt, macht unterscheidbar, dass die
kb/-Hälftecommit-gestempelt ist und die Aufgaben-Hälfte datei-gestempelt.
HEADundgit status --porcelainsind vorher und nachher gleich — derselbe Test, den die übrigenWerkzeuge haben.
als Werkzeug-Fehler an, nie als leere Projektliste.
tasks/protocol.pyträgt das neue Feld, der SP-Adapter fülltes, und #128 ist um das Kriterium ergänzt, dass ein Azure-DevOps-Adapter es liefert.
tools/CONTRACT.md(MCP-Designnotiz und die Aufgaben-Schicht-Notiz),instructions/mcp-read-server.md(inkl. Entscheidungspunkt „kein Schreibweg zum Tracker" unddem Snapshot-Verzeichnis außerhalb des Korpus),
INSTALL-MCP.md(Werkzeugtabelle,Verifikations-Ausgabe, ein Schritt zur Snapshot-Zustellung),
README.md.kb/concepts/architectures/MCP-Leseserver.mdbeschreibt weiterhin den tatsächlichenWerkzeugsatz — über den normalen Inhaltsweg (
wiki-manage), nicht von Hand.docs verify,instructions verify,pytestgrün; Version gebumpt (neue Fähigkeit,beidseitig drop-in →
--minor; eine Protokolländerung aus D3 ist für eine ausgelieferteInstanz trotzdem drop-in, solange kein Adapter von außen existiert).
Vorher zu klären
der Grund für
prio/waiting; der Auslöser steht oben.Lesefläche „wie viel" oder „was" beantwortet, und ob #128 nachzieht. Fällt womöglich vorher
an: #132 verbreitert den Schreib-Teil desselben Protokolls, und wer dort ohnehin hineinfasst,
kann diese Frage gleich mitentscheiden.
project/task/tagim Schnappschuss? Befund 4. Einmal ansehen, bevordie Datei die Maschine verlässt; danach ist die Frage, ob sie gefiltert wandert oder ganz.
Deployment dann zwei Sync-Wege mit verschiedenen Uhren hat statt einem.
Abhängigkeiten
Keine blockierenden. Berührungspunkte: #37 (Container-Image — dort fällt D2 an), #128
(Azure-DevOps-Adapter — zieht eine Protokolländerung aus D3 nach), #132 (der Schreibweg für den
Ingest; berührt dasselbe Protokoll von der anderen Seite).
GTD über MCP: `review` als Lesewerkzeug, und ob es eine Aufgaben-Fläche brauchtto Aufgaben lesend über MCP: externer Blick auf die Projekte, ohne HandlungspfadChangelog: Body und Titel neu geschrieben nach der Betreiber-Entscheidung „MCP ist
analysierend, nicht agierend".
reviewals MCP-Werkzeug (alte D1) und die Prozedur überprompts(alte D2) —der wöchentliche Rückblick ist Arbeitsplatz-Arbeit.
Lesefläche ist jetzt der Inhalt des Issues.
Codeänderung entfernt lesbar); der Schreibpfad ist per Transport unerreichbar, womit
„analysierend" eine Konstruktions- statt einer Disziplin-Eigenschaft ist;
OpenItemsträgt keineTitel der offenen Posten (neue D3); der Snapshot-Zeitstempel steht im Dateinamen und wird zum
Alters-Stempel.
Changelog:
prio/planned→prio/waiting, Auslöser benannt (ein belegter Fall ohne PC). Dermobile Fall ist heute Spielerei (Betreiber, 2026-09-20) — die entsprechende offene Frage ist als
beantwortet abgehakt statt gestrichen, weil sie der Grund für das Label ist. Analyse und
Akzeptanzkriterien unverändert gültig. Neu vermerkt: #132 fasst denselben Protokollrahmen von der
Schreibseite an, D3 kann dort mitentschieden werden.