Geschlossen, ohne gebaut worden zu sein: eine Entscheidung in #133 hat den Fall beseitigt. Der
Verdacht wurde nie gegen tatsächliches Verhalten geprüft — er musste es nicht mehr.
Der Verdacht, wie er bestand
SuperProductivityWriter.create_project kann nichts anlegen (die lokale REST-API hat keinen
Endpunkt dafür) und wirft HumanInterventionRequired mit einer verify-Closure. wikitool new project zeigt die Anweisungen und endet mit Exit 42; ein späterer Lauf mit --resume ruft verify() auf, statt der Behauptung des Menschen zu glauben.
verify() ist find_project(reader, name), und der Reader las latest_snapshot_path(): die
lexikalisch größte *.json-Datei unter backups_dir — den neuesten Schnappschuss, nicht den
aktuellen Zustand. Hatte Super Productivity seit der Anlage kein Backup geschrieben, konnte die
Verifikation das Projekt nicht sehen, obwohl es existierte, und dieselbe Exit-42-Meldung kam
zurück: der Tracker habe es immer noch nicht.
Dazu der Doku-Widerspruch: tasks/protocol.py begründet das Nicht-Cachen damit, ein Aufrufer sehe
beim Prüfen von verify() „the current state, not a snapshot from before that step". Für eine
Schnappschuss-Quelle traf der zweite Halbsatz nicht zu — neu gelesen wurde bei jedem Aufruf, nur
eben dieselbe, womöglich veraltete Datei.
Warum es sich erledigt hat
#133 entscheidet: der Zugriffsweg ist je Instanz ausdrücklich konfiguriert (access: api oder access: snapshot), ohne Rückfall — und die Projektanlage gibt es nur bei access: api. Damit
läuft verify() nur noch dort, wo live gelesen wird; ein Schnappschuss kann die Prüfung nicht mehr
beantworten, weil er in diesem Ablauf nicht mehr vorkommt.
Das Fenster ist also nicht kleiner geworden, sondern hat keinen Ort mehr. Ob Super Productivity
häufig oder selten ein Backup schreibt — die Frage, an der die Verifikation dieses Verdachts hing —
ist damit gegenstandslos.
Was mitgenommen wurde
Die Korrektur der Begründung in tasks/protocol.py steht als Akzeptanzkriterium in #133: der Satz
über „the current state" muss sagen, was tatsächlich gilt. Der Verdacht war insofern kein
Fehlalarm — er hat eine falsche Begründung im Code gefunden, auch wenn das Verhalten, das sie
beschreibt, künftig nicht mehr eintreten kann.
Nicht mitgenommen: der vorgeschlagene dritte Schritt in der HumanInterventionRequired-Meldung
(„in Super Productivity ein Backup auslösen"). Er wäre auf einer api-Instanz sinnlos, und eine snapshot-Instanz legt keine Projekte mehr an.
**Geschlossen, ohne gebaut worden zu sein: eine Entscheidung in #133 hat den Fall beseitigt.** Der
Verdacht wurde nie gegen tatsächliches Verhalten geprüft — er musste es nicht mehr.
## Der Verdacht, wie er bestand
`SuperProductivityWriter.create_project` kann nichts anlegen (die lokale REST-API hat keinen
Endpunkt dafür) und wirft `HumanInterventionRequired` mit einer `verify`-Closure. `wikitool new
project` zeigt die Anweisungen und endet mit Exit 42; ein späterer Lauf mit `--resume` ruft
`verify()` auf, statt der Behauptung des Menschen zu glauben.
`verify()` ist `find_project(reader, name)`, und der Reader las `latest_snapshot_path()`: die
lexikalisch größte `*.json`-Datei unter `backups_dir` — den neuesten Schnappschuss, nicht den
aktuellen Zustand. Hatte Super Productivity seit der Anlage kein Backup geschrieben, konnte die
Verifikation das Projekt nicht sehen, obwohl es existierte, und dieselbe Exit-42-Meldung kam
zurück: der Tracker habe es immer noch nicht.
Dazu der Doku-Widerspruch: `tasks/protocol.py` begründet das Nicht-Cachen damit, ein Aufrufer sehe
beim Prüfen von `verify()` „the current state, not a snapshot from before that step". Für eine
Schnappschuss-Quelle traf der zweite Halbsatz nicht zu — neu gelesen wurde bei jedem Aufruf, nur
eben dieselbe, womöglich veraltete Datei.
## Warum es sich erledigt hat
#133 entscheidet: der Zugriffsweg ist je Instanz ausdrücklich konfiguriert (`access: api` oder
`access: snapshot`), ohne Rückfall — **und die Projektanlage gibt es nur bei `access: api`.** Damit
läuft `verify()` nur noch dort, wo live gelesen wird; ein Schnappschuss kann die Prüfung nicht mehr
beantworten, weil er in diesem Ablauf nicht mehr vorkommt.
Das Fenster ist also nicht kleiner geworden, sondern hat keinen Ort mehr. Ob Super Productivity
häufig oder selten ein Backup schreibt — die Frage, an der die Verifikation dieses Verdachts hing —
ist damit gegenstandslos.
## Was mitgenommen wurde
Die Korrektur der Begründung in `tasks/protocol.py` steht als Akzeptanzkriterium in #133: der Satz
über „the current state" muss sagen, was tatsächlich gilt. Der Verdacht war insofern kein
Fehlalarm — er hat eine falsche Begründung im Code gefunden, auch wenn das Verhalten, das sie
beschreibt, künftig nicht mehr eintreten kann.
**Nicht mitgenommen:** der vorgeschlagene dritte Schritt in der `HumanInterventionRequired`-Meldung
(„in Super Productivity ein Backup auslösen"). Er wäre auf einer `api`-Instanz sinnlos, und eine
`snapshot`-Instanz legt keine Projekte mehr an.
## Abhängigkeiten
Aufgelöst durch #133.
torben
changed title from Verdacht: `new project --resume` verifiziert gegen einen Schnappschuss, der älter ist als der Schritt des Menschen to Aufgelöst: `--resume` verifizierte gegen einen womöglich älteren Schnappschuss2026-09-20 14:43:20 +00:00
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.
Geschlossen, ohne gebaut worden zu sein: eine Entscheidung in #133 hat den Fall beseitigt. Der
Verdacht wurde nie gegen tatsächliches Verhalten geprüft — er musste es nicht mehr.
Der Verdacht, wie er bestand
SuperProductivityWriter.create_projectkann nichts anlegen (die lokale REST-API hat keinenEndpunkt dafür) und wirft
HumanInterventionRequiredmit einerverify-Closure.wikitool new projectzeigt die Anweisungen und endet mit Exit 42; ein späterer Lauf mit--resumeruftverify()auf, statt der Behauptung des Menschen zu glauben.verify()istfind_project(reader, name), und der Reader laslatest_snapshot_path(): dielexikalisch größte
*.json-Datei unterbackups_dir— den neuesten Schnappschuss, nicht denaktuellen Zustand. Hatte Super Productivity seit der Anlage kein Backup geschrieben, konnte die
Verifikation das Projekt nicht sehen, obwohl es existierte, und dieselbe Exit-42-Meldung kam
zurück: der Tracker habe es immer noch nicht.
Dazu der Doku-Widerspruch:
tasks/protocol.pybegründet das Nicht-Cachen damit, ein Aufrufer sehebeim Prüfen von
verify()„the current state, not a snapshot from before that step". Für eineSchnappschuss-Quelle traf der zweite Halbsatz nicht zu — neu gelesen wurde bei jedem Aufruf, nur
eben dieselbe, womöglich veraltete Datei.
Warum es sich erledigt hat
#133 entscheidet: der Zugriffsweg ist je Instanz ausdrücklich konfiguriert (
access: apioderaccess: snapshot), ohne Rückfall — und die Projektanlage gibt es nur beiaccess: api. Damitläuft
verify()nur noch dort, wo live gelesen wird; ein Schnappschuss kann die Prüfung nicht mehrbeantworten, weil er in diesem Ablauf nicht mehr vorkommt.
Das Fenster ist also nicht kleiner geworden, sondern hat keinen Ort mehr. Ob Super Productivity
häufig oder selten ein Backup schreibt — die Frage, an der die Verifikation dieses Verdachts hing —
ist damit gegenstandslos.
Was mitgenommen wurde
Die Korrektur der Begründung in
tasks/protocol.pysteht als Akzeptanzkriterium in #133: der Satzüber „the current state" muss sagen, was tatsächlich gilt. Der Verdacht war insofern kein
Fehlalarm — er hat eine falsche Begründung im Code gefunden, auch wenn das Verhalten, das sie
beschreibt, künftig nicht mehr eintreten kann.
Nicht mitgenommen: der vorgeschlagene dritte Schritt in der
HumanInterventionRequired-Meldung(„in Super Productivity ein Backup auslösen"). Er wäre auf einer
api-Instanz sinnlos, und einesnapshot-Instanz legt keine Projekte mehr an.Abhängigkeiten
Aufgelöst durch #133.
Verdacht: `new project --resume` verifiziert gegen einen Schnappschuss, der älter ist als der Schritt des Menschento Aufgelöst: `--resume` verifizierte gegen einen womöglich älteren Schnappschuss