Voost Control · sâmbătă, 1 august 2026

Un număr de telefon suspendat a scos la iveală două lucruri

Unul era o funcție care lipsea din produs. Celălalt era o defecțiune care bloca livrările de o zi — și care nu apăruse dintr-o schimbare de cod, ci dintr-o dată din calendar.

Livrat, așteaptă aprobarea ta
4 PR-uri
Taskuri recurente native + reparația care deblochează deploy-ul.
Prinse de verificare, nu de mine
11 defecte
Două dintre ele închideau o serie recurentă pentru totdeauna, cu un click.
Dimineața · problema

Cârja de pe mașină

ClickPhone îți ia 25 € pe 1 ale lunii din creditul contului. Aveai 2,50 €, așa că linia s-a suspendat la 00:06. Reconectarea se face manual la ei, în până la 24 de ore — pe care le-am aflat din chiar notificarea lor, nu din presupuneri.

Ca să nu se repete, am pus un memento lunar. Dar l-am pus în afara produsului: o sarcină programată pe Mac mini, care crea taskul în Voost Control pe 25 ale lunii.

De ce e o cârjă și nu o soluție

Apasă pe fiecare, ca să vezi diferența.

Asta a fost concluzia ta, și era corectă: dacă produsul are nevoie de o funcție, funcția stă în produs, nu lângă el.

După-amiaza · ce s-a construit

Taskul care se reprogramează singur

Voost Control avea deja tipul de task „recurent" în interfață. Nu făcea nimic. Zero taskuri de tipul ăsta în producție, iar singurul lui comportament era ascuns pe o cale pe care doar agenții o folosesc.

Acum îl declari o dată, iar când bifezi o ocurență, taskul revine singur la următoarea dată.

Încearcă

Alege ritmul, apoi bifează taskul. Uită-te ce scrie în istoric.

Ce se întâmplă dacă uiți o lună
Nu se stivuiește. Rămâne un singur task, afișat ca restant, până îl bifezi — pentru că starea aia restantă este semnalul că ai ratat luna. Un sistem care ar șterge urma ar arăta curat exact când ai cea mai mare nevoie să nu arate curat.
De ce doar zilnic / săptămânal / lunar
Puteam accepta orice regulă complicată. N-am făcut-o: le citești pe un ecran de operator, iar un vocabular închis poate fi verificat exact și refuzat clar. Dacă vreodată chiar ai nevoie de „a doua marți din lună", ăla e momentul să extindem — nu înainte.
Pe parcurs · ce a prins verificarea

Un click care închidea seria pentru totdeauna

Fiecare felie a trecut prin agenți de verificare independenți. Au găsit 11 defecte blocante. Cel mai serios: existau căi prin care un task recurent era marcat „gata" fără să se reprogrameze — deci seria murea în tăcere.

Bara de acțiuni din Tasks

Selectezi două taskuri și le marchezi „Done". Comută între înainte și după reparație.

Aceeași gaură exista și pe calea prin care se aplică propunerile din apeluri — exact forma pe care o are un task de mentenanță lunară la un client.

Tiparul care s-a repetat, și care merită reținut
De două ori am reparat doar jumătate din problemă: am închis ușa de creare, dar nu și pe cea de editare. Și o dată am „reparat" o bombă cu dată într-un fel care doar părea corect — a prins-o abia runda următoare de verificare, care a re-derivat comportamentul în loc să creadă descrierea mea. Verificarea independentă n-a fost teatru de proces; a fost singurul lucru care a prins astea.
Seara · de ce nu se putea livra

Bomba din calendar

Voost Control refuză să livreze dacă suita de teste pică pe ramura principală. Pica de sâmbăta trecută. Nimeni nu stricase nimic.

Testele construiau un lead cu data fixă 1 iulie. Fereastra în care se poate retrimite o sesizare la furnizor e de 30 de zile. Pe 31 iulie la 08:00 fereastra a expirat — și de atunci 24 de teste au început să pice singure.

Trage de „azi” și uită-te ce se întâmplă

Bara verde e fereastra de 30 de zile. Linia neagră e ziua curentă.

1 iul · lead
31 iul · expiră
De ce raportul inițial părea incomplet
Alarma a fost deschisă pe 31 iulie la 05:42, dintr-o rulare automată de la 05:33 — cu două ore și jumătate înainte ca fereastra să expire. Rularea aia a prins alte trei teste, care oricum erau instabile. Suitele de sesizări au căzut mai târziu în aceeași zi, singure. Erau două defecțiuni diferite, iar una era declanșată de calendar.

Reparația nu mută bomba mai încolo, ceea ce era capcana evidentă. Tot fișierul atârnă acum de un singur ceas care merge odată cu ceasul real, iar fiecare dată e un decalaj față de el — relațiile dintre momente rămân exact aceleași.

Suita completă după reparație: trece integral
Ce trebuie să știi

Trei lucruri, pe scurt

Mai există o bombă

Un alt fișier de test are exact aceeași problemă, cu fitilul pe 31 august. Am deschis un issue separat, cu rețeta de reparație. Dacă nu se atinge nimeni de el, ramura principală redevine roșie peste 30 de zile și deploy-urile se blochează din nou.

Reminderul ClickPhone e încă pe cârjă

Mutarea lui pe rail-ul nativ are nevoie de un deploy. Până atunci sarcina programată de pe Mac mini rămâne activă — funcționează, dar e în afara produsului și nu o vede niciun test.

Ce nu am atins

Nu am făcut niciun merge și niciun deploy. Amândouă rămân decizia ta. Producția a fost verificată înainte și după testarea pe date reale: identică

Dacă vrei să mergem mai departe, ordinea e asta

  1. Reparația ramurii principale — deblochează livrările pentru toată lumea.
  2. Cele trei felii de recurență, în ordine, pentru că sunt construite una peste alta.
  3. Deploy, apoi mutarea reminderului ClickPhone pe rail-ul nativ și ștergerea cârjei.