1.854 de linii ca să bifezi un checkbox. Merită?
Codex raportează că a reparat toate regresiile la checkbox-urile de Plan Steps. Am trimis 12 agenți de audit (Fable, Opus + un review independent gpt-5.6-sol) pe toate suprafețele atinse. Verdictul scurt: funcționalitatea e reală și merită — dar o treime din cod apără de un pericol pe care nu-l poate opri.
Ce primești: checkbox-ul învie
Pe main, checkbox-urile de Plan Steps sunt decorative — desenate pe ecran, dar moarte la click. Branch-ul le face reale. Încearcă ambele:
Consumatorul nu e ipotetic: 30 din 327 de task-uri live au deja Plan Steps (ADR-0089 a intrat pe 12 iulie), iar pagina de Tasks e suprafața ta zilnică. Până acum, singura cale de a bifa un pas era un agent prin API — tu, din UI, nu puteai.
Designul „deliberately dumb" din ADR-0089 e respectat: pașii rămân {id, text, done}, endpoint-ul nou schimbă doar done, iar un pas promovat în Task rămâne blocat (one-way).
Unde s-au dus cele 1.854 de linii
Aici se desparte binele de rău. Click pe fiecare segment:
Serverul e partea bună a poveștii: rută de 41 de linii, helper de 93 cu tranzacție + row lock (SELECT … FOR UPDATE), guard-ul de promotion aplicat în trei locuri — și, bonus real, a închis un race pre-existent în PATCH-ul generic (lock + re-read înainte de verificarea promotion-ului).
Clientul e partea umflată: un „coordinator" de 398 de linii — coadă de intenții, fereastră de liniște de 300ms, pompă serializată global și un token bucket propriu — ca să persiste un boolean per click.
Mașinăria care nu-și poate ține promisiunea
Cea mai speculativă piesă: un token bucket în browser (5 click-uri burst, apoi 1 la 3 secunde) care promite să te țină sub limita serverului de 30 de scrieri/minut. Testează promisiunea — apasă cât de repede poți:
Click-urile tale
Scrieri trimise de UI
Bucket-ul serverului (30/min)
Poanta, confirmată de verificarea adversarială: bucket-ul serverului (local:write) e împărțit cu toate scrierile CLI/agenți de pe mașină, pe care browserul nu le vede. Clientul își încetinește doar propriile scrieri — care, cu maxim 20 de pași per task, oricum nu puteau atinge limita. Iar dacă limita totuși pică din cauza agenților, calea de eroare (toast + resync) exista deja.
Tot în modul: un contor de versiuni pe care nu-l citește nimeni, flush() și getPendingChanges() fără apelant de producție, 5 opțiuni de constructor folosite doar în teste. Iar mecanismul (nu doar comportamentul) a fost scris în DESIGN-LANGUAGE.md ca doc obligatoriu — într-un repo unde docurile sunt review-ul, complexitatea se auto-protejează.
Duelul auditorilor: „do not merge" ținea?
Auditorii Claude au zis „solid, cu rezerve de simplitate". Review-ul independent gpt-5.6-sol a zis „do not merge — 4 bug-uri P1". Am verificat fiecare P1 în cod, cu git show pe main. Click pe fiecare:
Scor final: 0 din 4 blochează merge-ul. Două sunt semantici care există deja pe main (branch-ul chiar le-a îmbunătățit), două sunt ferestre de milisecunde dintr-un singur browser, cu resync automat. Lecția veche rămâne: review-ul Codex e dovadă, nu autoritate — dar și auditorii entuziaști au avut nevoie de verificare adversarială: din 7 finding-uri P1/P2 ale Claude, 4 au fost retrogradate la verificare.
Verdictul, pe criteriile tale
Criteriul tău, citat: „soluții concise, simple; dacă o problemă se poate rezolva mai simplu, propune varianta simplă". Aplicat pe fiecare suprafață:
| Suprafață | Calitate | Simplitate | Nota auditului |
|---|---|---|---|
| API · PATCH /plan-steps/:stepId | excelent | 41 linii | paritate completă cu rutele-surori, tranzacție + lock, guard promotion |
| Lib server · plan-step-toggle.ts | excelent | 93 linii | a închis și un race pre-existent din PATCH-ul generic |
| Client · coordinator + bucket | corect | 398 linii | funcționează, dar ~150 de linii sunt mașinărie speculativă |
| Teste · 10 fișiere, ~1.044 linii | contract OK | 2 gap-uri | zero negative-path pe endpoint-ul nou; un test face grep pe sursă |
| Docs · API.md, ADR-0089, skill | actualizate | 1 exces | DESIGN-LANGUAGE.md canonizează mecanismul, nu invarianta |
| Fix-ul conta (călător în branch) | îmbunătățire | −sleep 150ms | NU e test slăbit — scoate un anti-pattern, păstrează toate aserțiunile |
Merge după o tunsoare mică
- Taie token bucket-ul + mașinăria moartă (~150 linii cod + feliile lor de teste)
- Rescrie fraza din DESIGN-LANGUAGE.md la invariantă („fără backlog de request-uri"), nu mecanism
- Adaugă 2–3 teste negative-path pe endpoint (stepId inexistent, task șters, body invalid)
Merge as-is + issue de follow-up
- Nimic nu e greșit funcțional — toate afirmațiile Codex s-au confirmat, testele trec în worktree
- Dar complexitatea intră în canon și devine mai scumpă de scos mai târziu
„Serverul a rezolvat problema.
Clientul a rezolvat o problemă pe care doar el o vedea."