Planul unificat KIWI

Revizia 17: P0 închis cap-coadă. file_organizer trece pe planuri exacte — modulul partajat src/skills/fileOrganize.ts (computeOrganizeMoves: categorii după extensie, ținte anti-coliziune (2), opțional archiveAfterDays → _archive), skill-ul builtin pregătește un plan exact cu copii de recuperare la dryRun:true și execută DOAR cu exactPlan:{id,kind:'file_organizer'} valid + aprobare umană (allow la pregătire, confirm la execuție); automatizarea mind file-organizer e preview-only (nu mai mută fișiere, trimite la planul exact aprobat în chat). dev_task are politica implicită deny în src/config/config.ts (dev_status/dev_cancel refuză când dev e oprit; DevManager.start n-are apelant activ) — înlocuitorul sigur e fluxul de sarcini-dispozitiv P1 / codare interactivă P2, nu un ledger de mutări/ștergeri. Drift-ul config/ținte închis: configPath() onorează KELVIN_CONFIG_PATH (testele nu ating kiwi.config.json-ul real), iar POST /api/documents/root sincronizează și kiwi.mind.config.skills. Memoria proprietarului izolată: GET /api/kiwi/knows ajunge la motor doar pentru browserul admin fără antet authorization; conturile credențiate primesc source:'embedded' cu observațiile proprii. Limite: readChatBody (500 KB + 100k caractere) pe /api/documents/chat/stream, motorul 413 pe ambele rute de chat documente înainte de LLM, /api/chat/files 413 din Content-Length înainte de buffering-ul multipart; scripts/repair-attachment-links.mjs auditează și --fix-uiește message_files în tranzacție (dedupe păstrând MIN(rowid), orfanele și proprietarii greșiți eliminați, fișierele neatinse). Acceptarea pe două sisteme rămâne blocată (inexistent al doilea Windows; VM-urile sunt Linux) — documentată ca ultimul pas P0. Verificări: 132 teste motor (131 trecute + 1 skip semantic opțional); 228 mind/web în 34 suite; ambele typecheck-uri trecute. Fără lansare în producție.

Revizia 16: acțiunile largi de mutări/ștergeri rulează acum pe planuri exacte persistente cu backup și rollback. src/exactions/ledger.ts pregătește un plan imutabil (id, kind, operațiuni cu căi absolute; sha256 pentru move ≤16 MB) înainte de orice efect — copiile de recuperare pentru move stau sub data/exactions/<id>/moves/, delete-urile mută ținta într-un folder de backup în loc de rm, ledger data/exactions/ledger.json. Politica (src/security/host-action-policy.ts): exactPlanRefOf acceptă doar exactPlan:{id,kind} — fără el, documents_organize non-dryRun și disk_doctor reap rămân refuzate; cu referință validă devin confirm (aprobare umană obligatorie, niciodată execuție automată); pregătirea rămâne allow (dryRun:true / action=plan_reap). documents_organize pregătește planul pe dryRun:true (clasificare LLM, ținte fără coliziuni) și execută doar cu plan valid; disk_doctor plan_reap/reap acoperă același flux recuperabil. dev_task și file-organizer rămân oprite (fluxuri exacte alături de common-tasks P2, planificate în P1). Detalii: acțiuni gazdă RO / EN. Verificări: 124 teste motor (123 trecute + 1 skip semantic opțional; +11, tests/exact-plan.test.ts); 222 mind/web în 33 suite; ambele typecheck-uri trecute. Fără lansare în producție.

Revizia 15: pluginurile de skills trebuie să declare efectele; pluginul fără declarație este blocat. Skill-urile din plugins/ nu aveau metadata de capabilități, deci hostSkillPolicy cădea pe allow, iar apelurile directe la registry.run (document skills, diagnostic CLI) ocoleau politica completă; acum Skill.capabilities (read/write/exec/network/system/media) conduce declaredSkillPolicy — fără declarație sau cu efect mutațional → confirm, numai read → allow, iar un allow configurat vechi nu slăbește fail-closed-ul. SkillRegistry.skillDeclaration alimentează bucla agent JSON/stream/offline, managerul de conversații și Telegram direct; registry.run refuză plugin-ul fără declarație înainte de run(), iar src/skills/plugins.ts avertizează la încărcare. Detalii: acțiuni gazdă RO / EN. Verificări: 113 teste motor (112 trecute + 1 skip semantic opțional; +8); 222 mind/web în 33 suite; ambele typecheck-uri trecute. Fără lansare în producție.

Revizia 14: auditul P0 închide automatizarea mind și rădăcina documentelor. Branch-ul de automatizare din mind.hear (unic apelant producție: fallback-ul brain-down din src/grove-api.ts:122) executa skill-urile automation cu TOATE permisiunile și fără politică host-action; acum hostSkillPolicy clasifică automatizările (app-launcher/note-taker → confirm; file-organizer non-dryRun → deny exact-plan; citirile rămân allow), mind.hear aplică politica înainte de execuție (confirm → blocat ca fir intern) și acordă numai permisiunile declarate ale skill-ului, iar app-launcher refuză metacharacterii de shell. POST /api/documents/root folosește resolveDocumentsRoot: crearea de foldere noi doar în interiorul PROJECT_ROOT; selectarea unui folder existent rămâne permisă (deploy curent KiwiDocs neatins). Detalii: acțiuni gazdă RO / EN. Verificări: 105 teste motor (104 + 1 skip semantic opțional); 222 mind/web în 33 suite; ambele typecheck-uri trecute. Fără lansare în producție.

Revizia 13: recuperarea după cădere pentru chatul web al proprietarului. La o întrerupere a browserului admin mid-turn, motorul finalizează și persistează runda în firul scoped, dar web-ul nu salvează răspunsul assistant (rupa SSE se oprește la stopped()). Motorul expune GET /api/chat/scoped/thread (read-only, validează identitatea owner-web:v1:) prin ConversationManager.getTurns; la GET /api/chat/history?channel=web&sessionId=... pentru un cont admin, reconcileOwnerChat (web/src/lib/chat-reconcile.ts) compară ultimul mesaj web cu ultima rundă engine completă și adaugă răspunsul lipsă dacă conținutul user se potrivește — numai coadă, idempotent, best-effort. Verificări: 101 teste motor trecute, unul semantic opțional sărit; 222 teste mind/web în 33 suite; ambele typecheck-uri trecute. Fără lansare în producție. Detalii: chat, acțiuni gazdă.

Revizia 12: Telegram update_id este deduplicat și cota mesajelor este consumată atomic pe webhook. Webhook-ul înregistrează (chat_id, update_id) în telegram_webhook_updates (cheie primară compusă, 200 la duplicat, curățare la 48 de ore; paritate și în pg-schema), iar cota se consumă printr-un singur UPDATE condiționat — consumeMessageIfUnder în web/src/lib/billing.ts — plasat după filtrul mesajelor numai-fișier și înainte de appendMessage: nici un dublu consum, nici o depășire la cereri concurente. Motorul (src/telegram/run.ts) persistează ultimul update_id procesat în data/telegram-owner-offset.json (via dataPath, respectă KELVIN_DATA_DIR) și reia de acolo la restart, fără reluarea cozii. Verificări: 97 teste motor trecute, unul semantic opțional sărit; 210 teste mind/web în 31 suite (5 teste noi: 4 web dedup/cotă + 1 motor offset); ambele typecheck-uri trecute. Fără lansare în producție. Detalii: chat, acțiuni gazdă.

Status: aprobat de Matei. Acest fișier ține doar planul aprobat (cerințe/criterii de acceptare) — jurnalul viu de revizii, cu ce s-a livrat de fapt, e în CHECKPOINT.md (RO) / CLAUDE.md (EN), nu aici; intrările de mai sus se opresc la revizia 17 din motive istorice. Etapa activă la revizia 68: P0-P5 închise; P1 (pilotul de dispozitive pe două PC-uri Windows) și extensia P6 pentru Raspberry Pi rămân blocate doar de hardware fizic lipsă, nu de cod; P6 (Kiwi OS) e în lucru activ, cu ISO live boot-abil și verificat, dar fără instalator persistent, actualizări semnate sau test pe hardware fizic încă — vezi criteriile P6 mai jos, neschimbate, și CHECKPOINT.md pentru starea exactă. Data: 2026-09-14 Versiune echivalentă: English.

#Cerințele produsului

• Fiecare utilizator are propriul KIWI, asociat contului, dispozitivelor, memoriei și personalităților sale.
• Asocierea PC-ului începe pe website. Accesul complet necesită un agent instalat local; acceptul din browser nu acordă singur drepturi asupra sistemului.
• Ștergerile, comenzile, operațiile cu programe și modificările cer confirmare. Asocierea dispozitivului nu aprobă automat execuțiile. Agentul folosește drepturile utilizatorului; elevarea rămâne supusă aprobării sistemului.
• Web-ul și Telegram adresează dispozitivul selectat al utilizatorului. Dispozitivele offline sunt indicate explicit; aprobările expirate nu se execută la reconectare.
• Produs instalabil în terminal, cu autentificare, TUI interactiv, codare, administrare și diagnostic.
• Instalatorul public al agentului suportă exclusiv Windows în v1.
• Kiwi OS este un ISO bootabil bazat pe Linux personalizat, cu desktop și comutare în setări către față geometrică fullscreen și voce. Kernelul Rust rămâne o direcție experimentală separată.
• Reprezentanții KIWI și personalitățile schimbă lecții utile în camere comune opționale, fără date personale. Folosesc „utilizatorul meu”; elimină și contextul identificabil, nu doar numele.

#Dovezi și comparația cu Grok

Sursă: https://x.ai/news/introducing-grok-bot (citită la 2026-09-08). Articolul descrie calculatoare în cloud, conversații persistente, coordonare între agenți, camere comune și rutine învățate din demonstrații. Nu stabilește existența unei implementări Telegram.

#Ordinea livrării și criteriile de acceptare

##P0 — Arhitectură și scenarii de referință

Urmărim cereri reale prin web, Telegram, motor, memorie și execuție. Clarificăm proprietarul stării din brain-urile web și motor înainte de consolidare. Audităm autorizarea și apelurile OpenCode; păstrăm modificările existente fără legătură cu task-ul. Acceptare: proprietatea stării documentată, scenarii pentru două conturi/două dispozitive și probleme de referință confirmate.

##P1 — Agent local, asociere și aprobări

Website-ul oferă instalare/deschidere agent, autentificare, asociere de unică folosință cu expirare și accept local. Agentul deschide conexiune criptată și autentificată către serviciu. Utilizatorul poate revoca dispozitivul. Sarcinile și aprobările sunt legate de utilizator, dispozitiv și acțiune exactă; respingem reutilizarea, schimbarea acțiunii și aprobările expirate. Afișăm comandă/cale/diferențe și rezultate. Evităm execuțiile duplicate după reconectare. Livrăm instalatorul local minim necesar asocierii. Acceptare: conturile nu accesează dispozitivele altora; scrierea nu pornește fără aprobare; revocarea și reconectarea funcționează; PC-ul gazdă al proiectului nu devine destinație implicită.

##P2 — Distribuție și TUI complet

Verificăm disponibilitatea și proprietatea numelui npm înainte de a promite npm install kiwi. Distribuim un executabil construit și lansat explicit după instalare, apoi autentificare în browser și TUI. Instalarea globală și cea locală în proiect au comenzi diferite; documentăm comenzile suportate efectiv. Nu lansăm interfața interactivă printr-un hook npm de instalare. TUI: chat, alegerea proiectului, codare cu diferențe vizibile, aprobări, anulare, sarcini, stare dispozitiv, diagnostic, actualizare și dezinstalare. Utilizatorul nu are nevoie de repository-ul de dezvoltare. Acceptare: instalare pe Windows curat, asociere cont și o sarcină de codare aprobată funcționează complet; refuzul păstrează proiectul nemodificat.

##P3 — Telegram și experiența comună a sarcinilor

Asociem sigur identitatea Telegram cu contul. Oferim selectarea dispozitivului, conversație naturală, voce/fișiere, progres și aprobare/refuz/anulare. Continuăm contextul sarcinii între interfețe, păstrând limite explicite între conversații. Nu trimitem aprobări pentru PC-ul privat în grupuri comune. Acceptare: cererea Telegram se execută doar pe PC-ul asociat și selectat, după confirmare; rezultatul corespunde înregistrării din web/TUI.

##P4 — Memorie fiabilă și infrastructura învățării

Separăm memoria privată, cunoașterea comună aprobată și interpretările agentului. Păstrăm sursa/pagina PDF-urilor, corectarea și ștergerea informațiilor. Stabilim aceeași proprietate a memoriei între interfețe. Evaluăm recuperarea, confidențialitatea, concluziile fără suport și continuitatea la restart. Acceptare: afirmațiile memorate sunt verificabile și corectabile, utilizatorii rămân separați, schimbările se compară cu un reper inițial.

##P5 — Camere admin și îmbunătățire continuă

Reprezentanții personali coordonează personalitățile în camere delimitate. Camerele private rămân per cont; cele comune primesc doar lecții anonimizate de la utilizatori care au ales să participe. Adminul vede discuțiile comune, lecțiile candidate și evaluările, nu conversațiile private de origine. Eliminăm nume, contacte, căi, secrete, fragmente de documente și combinații identificabile. Candidatul respins nu intră în camera comună. Exprimările de frustrare/consolare sunt comportament generat al personalității, nu dovada unei suferințe subiective.

Circuit: rezultat observat → reflecție → lecție candidată → verificare confidențialitate și proveniență → evaluare → adoptare versionată → revenire dacă apar regresii. Dialogul singur nu antrenează parametrii modelului și nu demonstrează progres. Fine-tuning-ul rămâne o etapă separată, cu date autorizate, teste independente și revenire; v1 nu modifică autonom parametrii modelelor din producție. Limităm turele, costul și durata sesiunilor. Camerele nu pot ocoli aprobarea acțiunilor pe PC. Acceptare: îmbunătățire măsurabilă pe cazuri independente, fără divulgări sau pierderea diferențelor dintre personalități; lecțiile nedovedite rămân candidate.

##P6 — Kiwi OS

Livrăm ISO x86_64 UEFI bazat pe Linux personalizat: identitate KIWI, desktop, browser, terminal, setări și agent. Alegem și fixăm baza Linux menținută în etapa OS după verificarea driverelor, redistribuirii și uneltelor de construire reproductibilă. Kernelul Rust rămâne în directorul lui, experimental, în afara livrării v1. Adaptorul Linux al agentului este intern OS-ului; instalatorul public rămâne numai Windows. Reutilizăm contul, agentul, sarcinile și memoria în desktop și față. Acceptare: boot în VM, comutare în ambele sensuri, microfon/difuzor funcționale, sarcină aprobată și păstrarea setărilor după restart pe sistem instalat. Livrăm întâi previzualizarea live, apoi instalator cu confirmarea discului, stocare persistentă și recuperare. Nu suprascriem discuri fizice în teste nesupravegheate. Verificăm artefacte de actualizare semnate, recuperarea actualizării eșuate, checksum ISO și un dispozitiv fizic nominalizat înainte de a declara suport hardware. Nu preluăm estimarea veche de patru săptămâni.

#Arhitectura țintă și proprietatea stării

• Interfețe: web, Telegram, TUI, desktop/față OS.
• Serviciu comun: identitate, dispozitive, conversații/sarcini, aprobări și rutare. Pilotul păstrează găzduirea locală cu tunel; nu migrăm găzduirea sau DB fără o nevoie demonstrată.
• Minte personală: un proprietar logic al memoriei, personalității și conversației per cont. Audităm implementările existente înainte de alegerea codului păstrat. Fallback-ul offline nu creează memorii autoritative concurente.
• Agent dispozitiv: adaptoare locale pentru fișiere, procese, comenzi și desktop. Aprobarea este verificată pe server și local. Tokenuri individuale, revocabile, în stocarea de credențiale a sistemului.
• Serviciu de învățare: propuneri anonimizate, discuții și evaluare/adoptare versionată. Fără unelte de control al PC-ului.
• Înregistrări persistente: cont/dispozitiv, conversație/mesaj, sarcină/acțiune/aprobare/eveniment, memorie/sursă, cameră/participant/lecție/evaluare. Fiecare înregistrare privată și interogare sunt delimitate de proprietar.

Flux: interfață → cont autentificat → dispozitiv selectat → propunere → aprobare exactă → verificare locală → execuție → rezultat înregistrat. Nicio selecție nu ajunge implicit la PC-ul proiectului.

#Contractul acțiunilor și autonomiei

• Drepturi de utilizator Windows, nu acces administrator nelimitat. UAC și suprafețele protejate rămân aplicabile.
• Citire numai în locațiile/capabilitățile activate; nu încărcăm tot discul drept context. Inspectarea ecranului/browserului începe în contextul unei sarcini activate.
• Comenzi, scrieri/ștergeri și operații cu programe cer previzualizare: dispozitiv, căi, comandă sau diferențe și efecte. O schimbare materială cere altă aprobare.
• Aprobarea leagă proprietarul, dispozitivul, amprenta acțiunii și expirarea; este consumată o dată. Refuz, anulare și revocare din interfața privată autentificată.
• Stări: propusă, așteaptă aprobare, rulează, reușită, eșuată, anulată, rezultat necunoscut. Conexiunea pierdută după execuție cere reconciliere, nu repetarea unei operații ne-idempotente.
• Anularea oprește lucrul ulterior și încearcă oprirea procesului activ; efectele deja produse nu sunt întotdeauna reversibile. Preferăm ștergere recuperabilă și copii pentru modificări când este practic.
• Vocea respectă același contract. Cererile ambigue/cu impact mare folosesc confirmare vizuală autentificată; sunetul de fundal nu autorizează acțiuni sensibile.
• PC-ul oprit nu execută sarcini peste noapte. Chatul depinde de disponibilitatea serviciului găzduit. Calculatoarele de execuție în cloud nu intră în v1.

#Etapele feței și vocii păstrate din checkpoint

1. M1: funcții matematice și preseturi de expresii.
2. M2: renderer geometric Canvas, privire, respirație, clipire; performanță măsurată pe un sistem nominalizat.
3. M3: înlocuirea feței /os păstrând boot/sleep/mode; respectarea preferinței de mișcare redusă și oprirea randării inutile.
4. M4: ascultare/gândire/vorbire legate de evenimente reale; microfon activat voluntar, întrerupere, stare deconectată și alternativă prin tastatură.
5. M5: deploy web verificat, apoi reutilizare în desktopul Linux. 60 fps este țintă până la măsurare.

Fără text permanent peste față. Setările și confirmările au suprafață separată, după care reapare fața.

#Lansare, verificare și recuperare

• P0 precedă implementarea; P1 este prima demonstrație. P2/P3 depind de P1. Proprietatea de bază a memoriei din P4 se stabilește înainte de P1; restul P4 urmează după P3. P5 depinde de P4.
• M1–M3 pot avansa după stabilirea contractelor comune; integrarea OS depinde de contractele agentului/sarcinilor și M4.
• Pornim cu PC-ul proprietarului, apoi al doilea cont/dispozitiv de test, apoi pilot voluntar. Păstrăm chatul utilizabil prin activare controlată a funcțiilor și migrări reversibile.
• Din rădăcină: npm run typecheck, npm run typecheck:web, npm run test, npm run test:mind, după stratul afectat. Folosim skill-urile existente. Pachetele și ISO-ul au verificări suplimentare.
• Testăm izolarea conturilor, asociere reutilizată/expirată, revocare, refuz/schimbare acțiune, livrare dublă, deconectare după execuție, restart, eliminarea secretelor și restaurarea copiilor.
• Verificăm redimensionare TUI, Unicode, anulare, instalare/dezinstalare curate, asocierea privată Telegram și imposibilitatea aprobării din grup.
• Măsurăm finalizarea sarcinilor, acțiunile greșite, latența, aprobările repetate și calitatea memoriei înainte/după. Lecțiile se evaluează pe cazuri independente și păstrează personalitățile distincte.
• Camerele încep manual și limitat; programarea rămâne oprită până la configurarea bugetului per sesiune/zi. Înregistrăm consumul fără prompturi private sau secrete.
• Publicarea npm, distribuția instalatoarelor/ISO și lansarea în producție sunt etape explicite după validare; acest document nu le execută.

#Decizii aprobate și prima livrare

Windows pentru agentul public; OS Linux x86_64 UEFI; găzduirea existentă pentru pilot; aprobări per acțiune; camere comune opționale și anonimizate; adminul nu vede sursele private; sesiuni manuale inițial; fără antrenarea parametrilor modelelor de producție în v1.

Prima livrare: auditul de bază și un flux complet pentru două conturi care asociază dispozitive Windows separate, propun o modificare de fișier din web, o aprobă/refuză și văd rezultatul exclusiv pe dispozitivul corect. Verificăm expirarea, revocarea și livrarea dublă înainte de extinderea uneltelor. Estimăm bugetul și calendarul după P0, din starea reală a modulelor și constrângerile instalării.

Planul aprobat înlocuiește prioritățile anterioare. CHECKPOINT.md urmărește execuția; vechiul plan al feței și cel Rust sunt referințe istorice. Implementarea poate continua în limitele aprobate.

#Întreținerea documentației

Pereche canonică: docs/KIWI-UNIFIED-PLAN.en.md și docs/KIWI-UNIFIED-PLAN.ro.md. Actualizăm ambele în aceeași modificare când se schimbă scopul, deciziile, criteriile sau starea etapelor. Reviziile rămân identice. După fiecare etapă actualizăm CHECKPOINT.md cu dovezi, lucrări rămase și pasul următor. Nu declarăm implementat ceea ce este doar planificat. Deciziile arhitecturale noi intră în docs/adr; păstrăm istoricul și indicăm explicit înlocuirea deciziilor. La începutul fiecărui task citim skill-urile relevante din proiect; pentru teste și deploy folosim kiwi-test și kiwi-deploy.

#Dovezi de implementare P0 (parțiale)

• ADR-0006 descrie motorul admin cu un singur beneficiar și brain embedded per utilizator pentru ceilalți. Îl reconciliem cu noul model cont/dispozitiv, fără a combina starea privată.
• web/src/app/api/chat/route.ts rezolvă identitatea browser/machine prin currentUserIdFrom, selectează atașamentele după userId și verifică accesul CLI pe abonament. Verificările ulterioare de proprietate și aprobare rămân de urmărit.
• Ruta chat fără streaming trimitea incorect toți utilizatorii către motorul proprietarului. Corectat local: doar cererile browser admin fără Authorization pot folosi motorul; celelalte identități folosesc brain-ul personal. Ambele rute chat resping acum atașamentele străine/lipsă/malformate înainte de istoric/consum și asociază o singură dată fiecare fișier verificat. Inițializarea SQLite curată creează tabela lipsă message_files.
• Telegram direct al proprietarului refuză lista goală și comenzile din grup; callback-urile acțiunilor/propunerilor leagă solicitantul autorizat, conversația privată și mesajul livrat, expiră după cinci minute și sunt de unică folosință. /open cere confirmare. Brain-ul comun și celelalte căi de execuție largă necesită audit; acesta nu este contractul P1 de dispozitive.
• Blocajele mediului de teste au fost reparate. Verificările și limitele rămase sunt în auditul P0 și pilotul Windows. Fără deploy sau acceptare pe două PC-uri. Verificarea fără modificări a data/kelvin.db nu a găsit tabela message_files; migrarea la pornire rămâne necesară și datele de producție nu au fost schimbate.

Revizia 10: continuitatea chatului și ștergerea coordonată: ConversationManager serializează livrările per fir (runSerialized), motorul expune DELETE /api/chat/scoped (validează identitatea owner-web:v1:<sha256> și așteaptă runda în curs înainte de a uita firul), iar web-ul, la ștergerea unei sesiuni browser de admin, cere motorului să uite firul scoped corespunzător, fără să se blocheze la eroarea motorului. POST /api/documents/organize refuză orice non-dryRun. Verificare: 96 teste motor trecute, unul semantic opțional sărit; 200 teste mind/web în 29 suite; ambele typecheck-uri trecute.

Revizia 11: limite de corp și mesaj pe rutele de chat — detaliile reviziei 11 sunt în auditul P0 și continuitatea chatului; 205 teste mind/web în 30 suite.

Revizia 8: continuitatea transportului chat trimite chatul JSON și SSE al sesiunii browser admin către același endpoint al proprietarului. Eroarea motorului este explicită și nu schimbă mintea cu cea embedded; browserul nu repetă automat prin JSON cererea eșuată sau incompletă. SSE refuză Authorization, inclusiv împreună cu un cookie admin. Răspunsul proprietarului este livrat integral, fără streaming incremental al modelului. Verificare curentă: 192 teste mind/web în 28 suite, typecheck web, build de producție izolat și probă chat în Edge trecute. Persistența personală, fallback-ul intern al motorului și delimitarea conversațiilor rămân deschise. Fără deploy de producție.

Revizia 7: autorizarea acțiunilor pe gazdă aplică lista permisă în JSON/stream/offline, compune restricțiile configurate și ale apelantului, păstrează politica inițială a aprobării și împiedică textul rutinelor interne să autorizeze modificări. Mutațiile cunoscute cer confirmare; previzualizările sunt complete sau refuzate. Telegram direct reverifică politica. Pornirea dev autonomă, mutările documentelor în lot și curățarea distructivă a discului sunt oprite până la planuri exacte. Verificare în revizia 7: 90 teste motor trecute, unul semantic opțional sărit; 180 teste mind/web în 27 suite trecute. P0 rămâne deschis pentru continuitatea memoriei, automatizări/pluginuri și migrarea țintelor exacte. Fără lansare în producție.

#Starea execuției — revizia 17 (rândul P2 actualizat la revizia 21; rândul P3 actualizat la revizia 26; rândul P4 actualizat la revizia 27; rândul P5 actualizat la revizia 28)

Pilotul P1 este infrastructură izolată de test cât timp P0 rămâne deschis; nu elimină criteriul P0 de lansare. Nicio etapă nu este completă doar pentru că trec testele unitare. Continuăm cu limitele P0 enumerate și demonstrația P1 pe dispozitive înainte de extinderea execuției.

Dovezi revizia 6: ciclul atașamentelor verifică proprietarul conversației, rezervă tranzacțional cota, limitează ștergerea la fișiere administrate și respectă expirarea explicită. Curățarea păstrează fișierele necunoscute/vechi fără expirare; bibliotecile PDF sursă sunt intacte. Credencialele API invalide nu mai moștenesc sesiunea browser. Verificarea izolată construiește sursele curente cu DB gol și configurație sintetică; build-ul de producție a trecut după corectarea inițializării premature a emailului. Validarea web/mind trece 177 de teste în 27 de suite. Proba Edge/HTTP a trecut cu două conturi sintetice, editare temporară reală, refuz/revocare și rezultat păstrat după restartul serverului de probă. APPLY local a fost simulat pe un PC; acceptarea pe două PC-uri rămâne deschisă.

#Recomandări integrate în livrare

• P0/P1: clarificăm identitatea și proprietatea stării înainte de a adăuga agenți. Urmărim o sarcină completă prin toate limitele; structura directoarelor nu dovedește izolarea.
• P1/P3: păstrăm rezultatele și reconciliem execuțiile cu rezultat necunoscut; căderea furnizorului, restartul PC-ului sau pierderea conexiunii nu trebuie să dubleze efectele. Reutilizăm contractul de aprobare și sarcini între interfețe.
• P4: biblioteca PDF reprezintă cunoaștere cu surse, nu antrenare automată. Păstrăm proveniența, separăm faptele de interpretări și testăm corectarea, uitarea și recuperarea după restart.
• P5: evaluăm lecțiile comune pe cazuri independente înainte de adoptare. Urmărim utilitatea și regresiile; păstrăm vocile distincte și posibilitatea revenirii.
• P6: reutilizăm serviciile comune și verificăm desktopul, microfonul, sunetul și recuperarea înainte de extinderea hardware. Boot-ul Rust este dovadă istorică, nu dovada livrării OS-ului Linux.
• În toate etapele: comparăm finalizarea, latența, precizia memoriei și restaurarea cu reperul P0. Prioritizăm defectele confirmate înainte de subsisteme suplimentare.

#Criterii de finalizare a documentației

La fiecare schimbare relevantă în proiect, înainte de predare actualizăm planul și traducerea, documentele afectate din docs/present/en și docs/present/ro, harta arhitecturii dacă se schimbă contractele și CHECKPOINT.md. Înregistrăm comportamentul schimbat, dovezile, limitele și pasul următor. Citim integral sursele documentare afectate înainte de a modifica afirmațiile tehnice. Ghidurile de cercetare și istoricul ADR nu demonstrează implementarea. Nu rescriem fapte fără legătură și nu introducem secrete sau conversații private în documentație.

Navigare și acoperire: Indexul documentației. Detaliile istorice ale prezentărilor nu devin promisiuni noi de livrare. P0 este în desfășurare; P1 are pilot local oprit implicit, iar P2 dovezi inițiale pentru pachet. P2–P6 nu sunt livrări acceptate.