Gefunden bei der Vorbereitung von #156, am 2026-09-30 live bestätigt gegen Super Productivity v19.1.0: offizielles superProductivity-amd64.deb, headless in debian:trixie-slim. Behoben in 529793b, Version 8.0.0-beta.2. CI auf diesem Commit: Läufe 433 und 434, beide grün.
Was falsch war und wie es behoben ist
Die Test-Fakes waren nach denselben Annahmen geschrieben wie der Adapter. Deshalb blieb die Suite grün, obwohl access: "api" nichts lesen konnte.
Umschlag {ok, data}.
Vorher: Die App antwortet {"ok":true,"data":…} bzw. {"ok":false,"error":{"code","message"}}, der Adapter erwartete eine nackte Liste. Jeder Lesezugriff scheiterte mit „did not return a list of objects“. Betroffen waren review, task list, task new und task close.
Jetzt: _ApiClient packt data aus. Bei ok: false stehen Code und Meldung der API im ValidationError. Einen Body ohne Umschlag lehnt er ab, statt zu raten.
Inbox als Projekt.
Vorher: GET /projects liefert INBOX_PROJECT, und das Backup führt es ebenfalls. Der Snapshot-Pfad war also auch betroffen.
Jetzt: Beide Leser und die Namensauflösung des Writers blenden es aus. review meldet keine „Inbox“ mehr.
doneOn beim Schließen.
PATCH /tasks/:id {"isDone":true} setzt in v19.1.0 auch doneOn und modified, genau wie ein Haken in der Oberfläche.
Das Verhalten ist unschädlich; der Modul-Docstring beschreibt es jetzt richtig.
health(). Gilt erst dann als gesund, wenn data.rendererReady wahr ist. doctor sagt es, wenn der Renderer noch lädt.
Akzeptanzkriterien
_ApiClient packt data aus. Bei ok: false stehen error.code und error.message im Fehler, und ein fehlender Umschlag bricht laut ab. Belegt durch test_api_reader_ok_false_surfaces_the_error_code_and_message, test_api_reader_rejects_a_bare_list_without_the_envelope und test_api_http_error_names_the_error_envelope_code.
Beide Lesepfade schließen INBOX_PROJECT aus. Belegt je Pfad durch test_api_reader_excludes_the_inbox_project und test_snapshot_reader_excludes_the_inbox_project, dazu test_project_id_never_resolves_to_the_inbox_even_under_a_user_project_name.
Der Docstring über doneOn entspricht dem beobachteten Verhalten (v19.1.0).
health() verlangt data.rendererReady. Belegt durch test_health_is_false_while_the_renderer_is_still_loading und test_health_is_false_without_the_renderer_ready_flag.
Die Fakes in test_superproductivity.py, test_task_cmd.py und test_new_page.py antworten im echten Umschlag.
Die Live-Suite aus #156 läuft mit access: "api" grün gegen v19.1.0. Belegt durch den Lauf im Image chemenu-sp-live (Run-ID f0253f72) mit task new, task list, review und task close. Zusätzlich halten die in #156 aufgenommenen echten Antworten (tests/fixtures/sp/api/) den Umschlag und die Inbox bei jedem Push im Replay-Test fest.
Version
Patch im 8.0.0-Kandidaten (8.0.0-beta.2). Drop-in in beide Richtungen; .wikitool-tasks.json bleibt unverändert.
Gefunden bei der Vorbereitung von #156, am 2026-09-30 live bestätigt gegen Super Productivity **v19.1.0**: offizielles `superProductivity-amd64.deb`, headless in `debian:trixie-slim`. **Behoben in `529793b`, Version 8.0.0-beta.2.** CI auf diesem Commit: Läufe 433 und 434, beide grün.
## Was falsch war und wie es behoben ist
Die Test-Fakes waren nach denselben Annahmen geschrieben wie der Adapter. Deshalb blieb die Suite grün, obwohl `access: "api"` nichts lesen konnte.
1. **Umschlag `{ok, data}`.**
- Vorher: Die App antwortet `{"ok":true,"data":…}` bzw. `{"ok":false,"error":{"code","message"}}`, der Adapter erwartete eine nackte Liste. Jeder Lesezugriff scheiterte mit „did not return a list of objects“. Betroffen waren `review`, `task list`, `task new` und `task close`.
- Jetzt: `_ApiClient` packt `data` aus. Bei `ok: false` stehen Code und Meldung der API im `ValidationError`. Einen Body ohne Umschlag lehnt er ab, statt zu raten.
2. **Inbox als Projekt.**
- Vorher: `GET /projects` liefert `INBOX_PROJECT`, und das Backup führt es ebenfalls. Der Snapshot-Pfad war also auch betroffen.
- Jetzt: Beide Leser und die Namensauflösung des Writers blenden es aus. `review` meldet keine „Inbox“ mehr.
3. **`doneOn` beim Schließen.**
- `PATCH /tasks/:id {"isDone":true}` setzt in v19.1.0 auch `doneOn` und `modified`, genau wie ein Haken in der Oberfläche.
- Das Verhalten ist unschädlich; der Modul-Docstring beschreibt es jetzt richtig.
4. **`health()`.** Gilt erst dann als gesund, wenn `data.rendererReady` wahr ist. `doctor` sagt es, wenn der Renderer noch lädt.
## Akzeptanzkriterien
- [x] `_ApiClient` packt `data` aus. Bei `ok: false` stehen `error.code` und `error.message` im Fehler, und ein fehlender Umschlag bricht laut ab. Belegt durch `test_api_reader_ok_false_surfaces_the_error_code_and_message`, `test_api_reader_rejects_a_bare_list_without_the_envelope` und `test_api_http_error_names_the_error_envelope_code`.
- [x] Beide Lesepfade schließen `INBOX_PROJECT` aus. Belegt je Pfad durch `test_api_reader_excludes_the_inbox_project` und `test_snapshot_reader_excludes_the_inbox_project`, dazu `test_project_id_never_resolves_to_the_inbox_even_under_a_user_project_name`.
- [x] Der Docstring über `doneOn` entspricht dem beobachteten Verhalten (v19.1.0).
- [x] `health()` verlangt `data.rendererReady`. Belegt durch `test_health_is_false_while_the_renderer_is_still_loading` und `test_health_is_false_without_the_renderer_ready_flag`.
- [x] Die Fakes in `test_superproductivity.py`, `test_task_cmd.py` und `test_new_page.py` antworten im echten Umschlag.
- [x] Die Live-Suite aus #156 läuft mit `access: "api"` grün gegen v19.1.0. Belegt durch den Lauf im Image `chemenu-sp-live` (Run-ID `f0253f72`) mit `task new`, `task list`, `review` und `task close`. Zusätzlich halten die in #156 aufgenommenen echten Antworten (`tests/fixtures/sp/api/`) den Umschlag und die Inbox bei jedem Push im Replay-Test fest.
## Version
Patch im 8.0.0-Kandidaten (8.0.0-beta.2). Drop-in in beide Richtungen; `.wikitool-tasks.json` bleibt unverändert.
torben
changed title from Super-Productivity-API-Pfad erwartet nackte Listen, die API liefert aber einen {ok, data}-Umschlag to Super-Productivity-API-Pfad: {ok, data}-Umschlag nicht ausgepackt, Inbox als Projekt gezählt, falsche doneOn-Annahme2026-09-30 05:14:36 +00:00
Changelog: Live gegen v19.1.0 bestätigt (headless .deb, siehe #156), deshalb ist status/unconfirmed entfernt. Neu hinzugekommen sind Befund 2 (Inbox in GET /projects) und Befund 3 (doneOn wird gesetzt). Die Reihenfolge-Empfehlung lautet jetzt: vor #156 bauen.
**Changelog:** Live gegen v19.1.0 bestätigt (headless `.deb`, siehe #156), deshalb ist `status/unconfirmed` entfernt. Neu hinzugekommen sind Befund 2 (Inbox in `GET /projects`) und Befund 3 (`doneOn` wird gesetzt). Die Reihenfolge-Empfehlung lautet jetzt: vor #156 bauen.
Abgeschlossen. Der Body steht jetzt auf dem Endzustand. Alle Kriterien sind abgehakt, mit Tests bzw. dem Live-Lauf als Beleg. Neu gegenüber dem Stand vorher: Der Snapshot-Pfad war von der Inbox ebenfalls betroffen und ist mit behoben. CI auf 529793b (Läufe 433 und 434) ist grün.
Abgeschlossen. Der Body steht jetzt auf dem Endzustand. Alle Kriterien sind abgehakt, mit Tests bzw. dem Live-Lauf als Beleg. Neu gegenüber dem Stand vorher: Der Snapshot-Pfad war von der Inbox ebenfalls betroffen und ist mit behoben. CI auf `529793b` (Läufe 433 und 434) ist grün.
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.
Gefunden bei der Vorbereitung von #156, am 2026-09-30 live bestätigt gegen Super Productivity v19.1.0: offizielles
superProductivity-amd64.deb, headless indebian:trixie-slim. Behoben in529793b, Version 8.0.0-beta.2. CI auf diesem Commit: Läufe 433 und 434, beide grün.Was falsch war und wie es behoben ist
Die Test-Fakes waren nach denselben Annahmen geschrieben wie der Adapter. Deshalb blieb die Suite grün, obwohl
access: "api"nichts lesen konnte.{ok, data}.{"ok":true,"data":…}bzw.{"ok":false,"error":{"code","message"}}, der Adapter erwartete eine nackte Liste. Jeder Lesezugriff scheiterte mit „did not return a list of objects“. Betroffen warenreview,task list,task newundtask close._ApiClientpacktdataaus. Beiok: falsestehen Code und Meldung der API imValidationError. Einen Body ohne Umschlag lehnt er ab, statt zu raten.GET /projectsliefertINBOX_PROJECT, und das Backup führt es ebenfalls. Der Snapshot-Pfad war also auch betroffen.reviewmeldet keine „Inbox“ mehr.doneOnbeim Schließen.PATCH /tasks/:id {"isDone":true}setzt in v19.1.0 auchdoneOnundmodified, genau wie ein Haken in der Oberfläche.health(). Gilt erst dann als gesund, wenndata.rendererReadywahr ist.doctorsagt es, wenn der Renderer noch lädt.Akzeptanzkriterien
_ApiClientpacktdataaus. Beiok: falsestehenerror.codeunderror.messageim Fehler, und ein fehlender Umschlag bricht laut ab. Belegt durchtest_api_reader_ok_false_surfaces_the_error_code_and_message,test_api_reader_rejects_a_bare_list_without_the_envelopeundtest_api_http_error_names_the_error_envelope_code.INBOX_PROJECTaus. Belegt je Pfad durchtest_api_reader_excludes_the_inbox_projectundtest_snapshot_reader_excludes_the_inbox_project, dazutest_project_id_never_resolves_to_the_inbox_even_under_a_user_project_name.doneOnentspricht dem beobachteten Verhalten (v19.1.0).health()verlangtdata.rendererReady. Belegt durchtest_health_is_false_while_the_renderer_is_still_loadingundtest_health_is_false_without_the_renderer_ready_flag.test_superproductivity.py,test_task_cmd.pyundtest_new_page.pyantworten im echten Umschlag.access: "api"grün gegen v19.1.0. Belegt durch den Lauf im Imagechemenu-sp-live(Run-IDf0253f72) mittask new,task list,reviewundtask close. Zusätzlich halten die in #156 aufgenommenen echten Antworten (tests/fixtures/sp/api/) den Umschlag und die Inbox bei jedem Push im Replay-Test fest.Version
Patch im 8.0.0-Kandidaten (8.0.0-beta.2). Drop-in in beide Richtungen;
.wikitool-tasks.jsonbleibt unverändert.Super-Productivity-API-Pfad erwartet nackte Listen, die API liefert aber einen {ok, data}-Umschlagto Super-Productivity-API-Pfad: {ok, data}-Umschlag nicht ausgepackt, Inbox als Projekt gezählt, falsche doneOn-AnnahmeChangelog: Live gegen v19.1.0 bestätigt (headless
.deb, siehe #156), deshalb iststatus/unconfirmedentfernt. Neu hinzugekommen sind Befund 2 (Inbox inGET /projects) und Befund 3 (doneOnwird gesetzt). Die Reihenfolge-Empfehlung lautet jetzt: vor #156 bauen.Abgeschlossen. Der Body steht jetzt auf dem Endzustand. Alle Kriterien sind abgehakt, mit Tests bzw. dem Live-Lauf als Beleg. Neu gegenüber dem Stand vorher: Der Snapshot-Pfad war von der Inbox ebenfalls betroffen und ist mit behoben. CI auf
529793b(Läufe 433 und 434) ist grün.