Un lacăt, două chei
De ce a tăcut cutia poștală care citește verdictele Necesit — și ce alegem ca să nu se mai repete. Spoiler: „token expirat” a fost de fiecare dată diagnosticul greșit.
Fixul ieftin acoperă tot ce s-a întâmplat de fapt. Opțiunea A (întărirea setup-ului actual) + C în varianta subțire (Hermes rulează singur playbook-ul de reparație). Opțiunea B (service account) rămâne în buzunar până la o a doua revocare reală. D și E — nu acum.
Lanțul: cum ajunge un verdict Necesit în Voost Control
Când Necesit aprobă sau respinge o sesizare, trimite un email pe contact@voostvision.com. Voost Control îl citește printr-un lanț de 5 verigi. Apasă pe fiecare verigă ca să vezi ce face și cu ce cheie umblă.
Apasă o verigă ↑
Ideea-cheie a întregii povești: în lanț există două chei diferite. Cheia de la seif (parola keyring-ului, stă pe Mac, în ~/.secrets) și cheia de la Google (refresh token-ul, stă în seif). Când canalul pică, prima întrebare corectă e: care dintre chei a dat greș? Pentru că se repară complet diferit.
Ce s-a rupt de fapt: trei simptome, trei cauze
Canalul a picat de mai multe ori, și de fiecare dată mesajul de eroare arăta diferit — pentru că se rupsese altă verigă. Astea sunt incidentele reale, apasă pe fiecare:
Eroarea era invalid_grant — Google refuza cheia. Cauza: aplicația OAuth era în modul Testing, iar Google expiră intenționat refresh token-urile aplicațiilor de test după 7 zile. Reconcilierea Necesit murea în tăcere o dată pe săptămână.
Fixul (deja făcut): pe 7 iulie ai publicat aplicația „In production”. De atunci, cheia Google nu mai expiră de la sine. Poate fi doar revocată: schimbare de parolă Google, revocare manuală, sau nefolosire 6 luni.
Eroarea: aes.KeyUnwrap(): integrity check failed. Tradus: cheia Google era acolo, în seif, probabil perfect validă — dar lacătul seifului nu s-a mai deschis. Fișierul cu tokenul fusese criptat cu altă cheie decât cea pe care o avea procesul la îndemână.
Asta nu e o problemă Google. Niciun service account, niciun „token care nu expiră” nu te apăra de ea — e o problemă de menaj local pe Mac. Neo a reparat-o la 19:58: backup la tokenul corupt + reautentificare (clickul tău pe linkul Google).
Când am pregătit draftul de ofertă pentru Romwolf, gog mi-a spus sec: No auth for gmail contact@voostvision.com — deși tokenul era valid și proaspăt reparat. Motivul: procesul meu nu avea setate GOG_KEYRING_BACKEND=file și parola seifului din ~/.secrets/gog-keyring.env. Fără ele, gog nici nu vede seiful.
De ce contează: exact în situația asta va fi și Voost Control după un restart curat al Mac-ului — vezi Actul 4. Al treilea simptom, a treia cauză, și tot nimic „expirat”.
Concluzia actului: din trei căderi, una singură a fost vina Google — și aia e deja fixată. Restul sunt probleme de menaj local. Orice soluție care atacă doar „token-urile care expiră” repară problema greșită.
Prototip: clasificatorul de erori
Asta e regula pe care ar instala-o Opțiunea A ca „preflight” — portată aici ca să te joci cu ea. Alege o eroare (toate sunt reale, din incidentele de mai sus) și vezi diagnosticul + cine o poate repara:
Observă modelul: trei din patru erori se repară complet automat — retry, restaurare din backup, încărcarea mediului corect. Singura care are nevoie de tine e revocarea reală Google, și acolo tot ce poate face un om e un click pe linkul de consimțământ — restul (generarea linkului, importul, verificarea) e automatizabil. Asta e exact împărțirea pe care o propune Opțiunea C.
Bomba cu ceas: ce se întâmplă la un restart curat
Neo a găsit în diagnoză o vulnerabilitate care încă e acolo: LaunchAgent-ul care pornește Voost Control nu-și declară persistent configurația de seif. Procesul de acum o are doar pentru că a moștenit-o din sesiunea în care a fost pornit. Comută:
Asta e partea perfidă: tokenul e perfect valid în ambele scenarii. După reboot, gog pur și simplu nu mai știe unde e seiful și cum se deschide — și ai primi din nou o alertă care arată ca o problemă de token. Fixul e o linie de configurare persistentă (partea centrală a Opțiunii A), nu o arhitectură nouă.
Opțiunile din #1297, judecate pe căderile reale
Testul corect pentru fiecare opțiune nu e „sună robust?”, ci: care dintre căderile care chiar s-au întâmplat ar fi prevenit-o sau reparat-o? Alege o opțiune și citește matricea:
| Expirare la 7 zile (Testing)incidentele din iunie–iulie | |
|---|---|
| Seif local corupt / cheie nepotrivităincidentul de pe 14 iulie | |
| Mediu pierdut după rebootbomba cu ceas din Actul 4 | |
| Revocare reală Googleschimbare parolă, revocare manuală — încă nu s-a întâmplat | |
| Cine repară când totuși picăom sau mașină? |
Și gotcha-ul pe care issue-ul nu-l prinde: criteriul „redu accesul la Gmail read-only” sună a igienă, dar tokenul contact@voostvision.com e unul singur pentru toate serviciile gog — iar pe același token, contabilitatea citește Google Drive. Îngustezi scope-urile pe tokenul unic → repari Necesit și rupi conta. Corect: un client/token separat doar pentru cititorul Necesit, sau accepți scope-ul larg și documentezi excepția.
Verdictul, pe criteriile tale
- Decide pe #1297: scope = Opțiunea A întreagă + C light (Hermes rulează automat playbook-ul de azi la alerta existentă; link de consent pe Telegram doar când e inevitabil).
- Rutare: spec-ul e mecanic și bine delimitat → gpt-5.6-sol pe implementare, review Claude la final.
- La least-privilege: client/token separat pentru cititorul Necesit, ca să nu atingi Drive-ul contabilității.
- B rămâne documentat în issue — se activează la a doua revocare reală, nu înainte.