tools/wikitool doctor bricht mit einem ungefangenen Traceback ab (SecretSourceLocked), statt den tasks-provider-Check als WARN oder Exit 42 zu melden. Das passiert, sobald tasks.provider auf caldav steht, caldav.app_password eine op://-Referenz ist und 1Password das Secret nicht herausgibt (op ist installiert und im Preflight erfasst, aber kein Konto angemeldet, App gesperrt oder Freigabe offen). Die Checks hinter tasks-provider laufen dann nicht mehr; der Report ist unvollstaendig.
Gemessen (Stack 10.0.0), Ende des Tracebacks:
SecretSourceLocked: caldav.app_password: 1Password did not hand out the value -
it is locked, not signed in, or waiting for approval. Unlock the 1Password app
or run `op signin` (in CI: set OP_SERVICE_ACCOUNT_TOKEN), then run this command
again.
Zum Vergleich: Fehlt op im Checkout, kommt stattdessen ein sauberes FAIL tasks-provider mit Hinweis auf den Preflight. Das ist eine ValidationError und wird gefangen. Der Absturz tritt also nur im Fall "op da, Secret nicht lieferbar" auf.
Ursache
tools/chemenu/commands/doctor.py:782 ruft cd.CalDAVConfig.from_section(cfg.provider_config) auf. Dort wird section["app_password"] gelesen (tools/chemenu/tasks/caldav.py:127), was ueber Section.__getitem__ (tools/chemenu/settings.py:315) die Referenz aufloest (settings.resolve, settings.py:618) und SecretSourceLocked wirft.
Der umgebende try faengt nur ValidationError (doctor.py:783). SecretSourceLocked erbt von ChemenuError, aber nicht von ValidationError (tools/chemenu/settings.py:86, tools/chemenu/errors.py:23). Die Exception entkommt, und doctor hat dafuer anders als der settings-secrets-Check keinen Pfad.
Der settings-secrets-Check im selben Befehl macht es richtig: doctor.py:871 faengt settings.SecretSourceLocked getrennt (locked-Liste). Auch clearance_on_settings und setting_value in tools/chemenu/commands/_util.py:133,146 kennen den Fall und mappen ihn auf Exit 42.
Ungeprueft: der Superproductivity-Zweig davor (doctor.py:756, SuperProductivityConfig.from_section) liest api_token ebenfalls als Referenz und duerfte gleich betroffen sein. Das habe ich nicht reproduziert.
Reproduktion
tasks.provider = "caldav" und eine vollstaendige caldav-Sektion setzen, caldav.app_password als Referenz der Form op://<vault>/<item>/<feld>.
op installiert und per Preflight erfasst, aber ohne nutzbares Konto: weder App-Integration noch OP_SERVICE_ACCOUNT_TOKEN (op whoami meldet "no account found").
tools/wikitool doctor ausfuehren.
Erwartet: tasks-provider als WARN (oder Exit 42 wie bei den anderen Befehlen) mit der Meldung zum Entsperren, alle weiteren Checks laufen.
Tatsaechlich: Traceback, kein Gesamtreport.
Loesungsvorschlag
In doctor.py um den from_section-Aufruf (und analog im Superproductivity-Zweig) settings.SecretSourceLocked getrennt fangen und als Check("tasks-provider", "WARN", str(exc), "Unlock 1Password ...") melden, konsistent zum locked-Zweig des settings-secrets-Checks. Ob WARN oder Exit 42 gilt, folgt der Entscheidung, die dort schon fuer settings-secrets getroffen wurde.
Verworfen: SecretSourceLocked von ValidationError ableiten. Das wuerde den bewussten Unterschied "Eingabefehler (Exit 1)" gegen "Mensch muss handeln (Exit 42)" verwischen, den _util.py und der settings-secrets-Check voraussetzen.
Akzeptanzkriterien
doctor meldet bei gesperrtem Secret tasks-provider als WARN (bzw. gemaess Entscheidung oben) und laeuft bis zum Ende durch.
Gleiches Verhalten fuer den Superproductivity-Zweig, falls dort reproduzierbar.
Test, der SecretSourceLocked aus from_section simuliert und prueft, dass doctor keinen Traceback wirft.
pytest, docs verify, instructions verify sauber.
Herkunft
Beim Einrichten des CalDAV-Backends in einer privaten Instanz gefunden. Der Report enthaelt keinen Instanzinhalt; Pfade und Fehlertext stammen aus dem Stack selbst.
## Befund
`tools/wikitool doctor` bricht mit einem ungefangenen Traceback ab (`SecretSourceLocked`), statt den `tasks-provider`-Check als WARN oder Exit 42 zu melden. Das passiert, sobald `tasks.provider` auf `caldav` steht, `caldav.app_password` eine `op://`-Referenz ist und 1Password das Secret nicht herausgibt (`op` ist installiert und im Preflight erfasst, aber kein Konto angemeldet, App gesperrt oder Freigabe offen). Die Checks hinter `tasks-provider` laufen dann nicht mehr; der Report ist unvollstaendig.
Gemessen (Stack 10.0.0), Ende des Tracebacks:
```
SecretSourceLocked: caldav.app_password: 1Password did not hand out the value -
it is locked, not signed in, or waiting for approval. Unlock the 1Password app
or run `op signin` (in CI: set OP_SERVICE_ACCOUNT_TOKEN), then run this command
again.
```
Zum Vergleich: Fehlt `op` im Checkout, kommt stattdessen ein sauberes `FAIL tasks-provider` mit Hinweis auf den Preflight. Das ist eine `ValidationError` und wird gefangen. Der Absturz tritt also nur im Fall "`op` da, Secret nicht lieferbar" auf.
## Ursache
`tools/chemenu/commands/doctor.py:782` ruft `cd.CalDAVConfig.from_section(cfg.provider_config)` auf. Dort wird `section["app_password"]` gelesen (`tools/chemenu/tasks/caldav.py:127`), was ueber `Section.__getitem__` (`tools/chemenu/settings.py:315`) die Referenz aufloest (`settings.resolve`, `settings.py:618`) und `SecretSourceLocked` wirft.
Der umgebende `try` faengt nur `ValidationError` (`doctor.py:783`). `SecretSourceLocked` erbt von `ChemenuError`, aber nicht von `ValidationError` (`tools/chemenu/settings.py:86`, `tools/chemenu/errors.py:23`). Die Exception entkommt, und `doctor` hat dafuer anders als der `settings-secrets`-Check keinen Pfad.
Der `settings-secrets`-Check im selben Befehl macht es richtig: `doctor.py:871` faengt `settings.SecretSourceLocked` getrennt (`locked`-Liste). Auch `clearance_on_settings` und `setting_value` in `tools/chemenu/commands/_util.py:133,146` kennen den Fall und mappen ihn auf Exit 42.
Ungeprueft: der Superproductivity-Zweig davor (`doctor.py:756`, `SuperProductivityConfig.from_section`) liest `api_token` ebenfalls als Referenz und duerfte gleich betroffen sein. Das habe ich nicht reproduziert.
## Reproduktion
1. `tasks.provider = "caldav"` und eine vollstaendige `caldav`-Sektion setzen, `caldav.app_password` als Referenz der Form `op://<vault>/<item>/<feld>`.
2. `op` installiert und per Preflight erfasst, aber ohne nutzbares Konto: weder App-Integration noch `OP_SERVICE_ACCOUNT_TOKEN` (`op whoami` meldet "no account found").
3. `tools/wikitool doctor` ausfuehren.
Erwartet: `tasks-provider` als WARN (oder Exit 42 wie bei den anderen Befehlen) mit der Meldung zum Entsperren, alle weiteren Checks laufen.
Tatsaechlich: Traceback, kein Gesamtreport.
## Loesungsvorschlag
In `doctor.py` um den `from_section`-Aufruf (und analog im Superproductivity-Zweig) `settings.SecretSourceLocked` getrennt fangen und als `Check("tasks-provider", "WARN", str(exc), "Unlock 1Password ...")` melden, konsistent zum `locked`-Zweig des `settings-secrets`-Checks. Ob WARN oder Exit 42 gilt, folgt der Entscheidung, die dort schon fuer `settings-secrets` getroffen wurde.
Verworfen: `SecretSourceLocked` von `ValidationError` ableiten. Das wuerde den bewussten Unterschied "Eingabefehler (Exit 1)" gegen "Mensch muss handeln (Exit 42)" verwischen, den `_util.py` und der `settings-secrets`-Check voraussetzen.
## Akzeptanzkriterien
- [ ] `doctor` meldet bei gesperrtem Secret `tasks-provider` als WARN (bzw. gemaess Entscheidung oben) und laeuft bis zum Ende durch.
- [ ] Gleiches Verhalten fuer den Superproductivity-Zweig, falls dort reproduzierbar.
- [ ] Test, der `SecretSourceLocked` aus `from_section` simuliert und prueft, dass `doctor` keinen Traceback wirft.
- [ ] `pytest`, `docs verify`, `instructions verify` sauber.
## Herkunft
Beim Einrichten des CalDAV-Backends in einer privaten Instanz gefunden. Der Report enthaelt keinen Instanzinhalt; Pfade und Fehlertext stammen aus dem Stack selbst.
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.
Befund
tools/wikitool doctorbricht mit einem ungefangenen Traceback ab (SecretSourceLocked), statt dentasks-provider-Check als WARN oder Exit 42 zu melden. Das passiert, sobaldtasks.provideraufcaldavsteht,caldav.app_passwordeineop://-Referenz ist und 1Password das Secret nicht herausgibt (opist installiert und im Preflight erfasst, aber kein Konto angemeldet, App gesperrt oder Freigabe offen). Die Checks hintertasks-providerlaufen dann nicht mehr; der Report ist unvollstaendig.Gemessen (Stack 10.0.0), Ende des Tracebacks:
Zum Vergleich: Fehlt
opim Checkout, kommt stattdessen ein sauberesFAIL tasks-providermit Hinweis auf den Preflight. Das ist eineValidationErrorund wird gefangen. Der Absturz tritt also nur im Fall "opda, Secret nicht lieferbar" auf.Ursache
tools/chemenu/commands/doctor.py:782ruftcd.CalDAVConfig.from_section(cfg.provider_config)auf. Dort wirdsection["app_password"]gelesen (tools/chemenu/tasks/caldav.py:127), was ueberSection.__getitem__(tools/chemenu/settings.py:315) die Referenz aufloest (settings.resolve,settings.py:618) undSecretSourceLockedwirft.Der umgebende
tryfaengt nurValidationError(doctor.py:783).SecretSourceLockederbt vonChemenuError, aber nicht vonValidationError(tools/chemenu/settings.py:86,tools/chemenu/errors.py:23). Die Exception entkommt, unddoctorhat dafuer anders als dersettings-secrets-Check keinen Pfad.Der
settings-secrets-Check im selben Befehl macht es richtig:doctor.py:871faengtsettings.SecretSourceLockedgetrennt (locked-Liste). Auchclearance_on_settingsundsetting_valueintools/chemenu/commands/_util.py:133,146kennen den Fall und mappen ihn auf Exit 42.Ungeprueft: der Superproductivity-Zweig davor (
doctor.py:756,SuperProductivityConfig.from_section) liestapi_tokenebenfalls als Referenz und duerfte gleich betroffen sein. Das habe ich nicht reproduziert.Reproduktion
tasks.provider = "caldav"und eine vollstaendigecaldav-Sektion setzen,caldav.app_passwordals Referenz der Formop://<vault>/<item>/<feld>.opinstalliert und per Preflight erfasst, aber ohne nutzbares Konto: weder App-Integration nochOP_SERVICE_ACCOUNT_TOKEN(op whoamimeldet "no account found").tools/wikitool doctorausfuehren.Erwartet:
tasks-providerals WARN (oder Exit 42 wie bei den anderen Befehlen) mit der Meldung zum Entsperren, alle weiteren Checks laufen.Tatsaechlich: Traceback, kein Gesamtreport.
Loesungsvorschlag
In
doctor.pyum denfrom_section-Aufruf (und analog im Superproductivity-Zweig)settings.SecretSourceLockedgetrennt fangen und alsCheck("tasks-provider", "WARN", str(exc), "Unlock 1Password ...")melden, konsistent zumlocked-Zweig dessettings-secrets-Checks. Ob WARN oder Exit 42 gilt, folgt der Entscheidung, die dort schon fuersettings-secretsgetroffen wurde.Verworfen:
SecretSourceLockedvonValidationErrorableiten. Das wuerde den bewussten Unterschied "Eingabefehler (Exit 1)" gegen "Mensch muss handeln (Exit 42)" verwischen, den_util.pyund dersettings-secrets-Check voraussetzen.Akzeptanzkriterien
doctormeldet bei gesperrtem Secrettasks-providerals WARN (bzw. gemaess Entscheidung oben) und laeuft bis zum Ende durch.SecretSourceLockedausfrom_sectionsimuliert und prueft, dassdoctorkeinen Traceback wirft.pytest,docs verify,instructions verifysauber.Herkunft
Beim Einrichten des CalDAV-Backends in einer privaten Instanz gefunden. Der Report enthaelt keinen Instanzinhalt; Pfade und Fehlertext stammen aus dem Stack selbst.