Ghid ELI20 pentru agentic-os

Ce face

agentic-os este skill-ul umbrelă pentru verificări de sănătate și propuneri mici de îmbunătățire pentru un workspace agentic. Nu este un robot de reparații autonome. Este o inspecție tehnică: citește semnale, compară surse, găsește degradări și propune următorul pas mic.

Se uită la zone ca event bus, registrul de capabilități, lessons active, learning digest, scorecard-uri, daemon health, audit de organizare a vault-ului, încălcări de plasare și planuri mv doar propuse. Postura implicită este read-only / propose-only: poate diagnostica, rezuma și recomanda; nu mută fișiere, nu repară linkuri, nu restartează daemons, nu marchează evenimente ca procesate și nu rescrie dashboard-uri fără autorizare separată.

Pe scurt: autopsie, nu chirurgie.

Când îmi folosește

Îl folosești când vrei o imagine rapidă despre starea sistemului: ce erori sau warnings s-au repetat recent, ce capabilități lipsesc, ce lessons contează acum, ce spune digest-ul de învățare, dacă scorecard-ul arată degradare sau dacă daemons par tăcuți.

Mai este potrivit pentru întrebări despre organizarea vault-ului: taxonomie de root, rutare între zonele principale ale repository-ului, audit violations sau un plan mv gata de rulat. Aici regula importantă este: verifică evidence-ul live înainte să accepte premisa întrebării. Dacă sursele autoritative spun că nu există violări, planul corect este explicit gol. Nu inventează mutări doar pentru că întrebarea cere mutări.

Îl folosești și pentru triere de inbox, propuneri PARA, ingest de surse brute în stratul compilat de cunoaștere sau sugestii zilnice mici pentru inspectabilitate, preflight-uri și fixture-uri.

Înapoi la All guides când vrei lista completă de ghiduri.

Cum îl invoc / declanșez

Invocarea exactă depinde de runtime. Skill-ul este declanșat de intenții, nu de o singură comandă universală.

Exemple de cereri:

„review last 24h event bus”

„agentic OS signals”

„capability gaps”

„active lessons”

„learning digest”

„daemon health”

„Agentic OS scorecard”

„vault organization audit violations”

„root placement”

„routing între zonele principale ale vault-ului”

„propose-only mv plan”

„daily small suggestions”

„read-only proposal pass”

Dacă ceri „each violating path + correct destination, ready-to-run mv plan”, skill-ul trebuie să distingă între încălcări reale de plasare și checks care nu se rezolvă prin mv.

Exemplu practic

Cerere:

„Verifică auditul de vault și dă-mi un ready-to-run mv plan, propose-only.”

Comportament corect:

1. Citește dashboard-ul operator-facing al auditului.
2. Citește snapshot-ul structurat al auditului, dacă este disponibil.
3. Compară cele două surse înainte de orice concluzie.
4. Dacă ambele sunt clean, răspunsul include un plan mv explicit gol.
5. Dacă apare un link rupt, nu propune mutare de fișier; propune fix de link sau creare de target doar dacă are sens conceptual.
6. Dacă apare un adapter lipsă, nu inventează o sursă pentru mv; verifică dacă este o ștergere urmărită și preferă restore din repository.
7. Dacă apare output generat necomis, îl tratează ca stare generată murdară, nu ca fișier pus în loc greșit.
8. Nu rulează un audit în mod publicare/scriere într-o cerere strict propose-only. Dacă este nevoie de verificare proaspătă, folosește mod read-only, no-write/no-publish.

Output / unde aterizează

Output-ul normal este un verdict scurt, cu evidence și recomandări mici. Poate include:

verdict de sănătate;

cauze repetate;

gaps de capabilități;

teme din lessons active;

anomalii din digest;

semnale de daemon health;

plan mv propus;

plan mv explicit gol când nu există mutări valide.

Pentru cereri de audit, un output bun separă clar: ce este violare de plasare, ce este link rupt, ce este fișier lipsă, ce este stare generată și ce necesită decizie de operator. Dacă propune comenzi, include și o comandă de verificare după plan. Nu execută planul decât dacă primește autorizație separată.

Limite / gotchas

Read-only înseamnă read-only. Nu folosi skill-ul ca pretext pentru editare, mutare, restart, cleanup sau rescriere de dashboard.

Nu repeta aceeași propunere zilnică dacă digest-ul arată că a mai fost propusă. Alege o îmbunătățire adiacentă: inspectabilitate, preflight, fixture de prim pas.

Nu trata sumarul stale ca adevăr absolut. Când numerele contează, compară sursa live cu sumarul.

Nu confunda auditul de vault cu search în notițe personale. Aici vorbim de governance de repository și plasare, nu de găsit documente.

Nu fabrica mv doar ca să existe un block de comandă. Uneori planul corect este gol. Igiena are rareori instinct dramatic.