Orkestrirano agentsko programiranje

Delovna disciplina pod človeškim upravljanjem za strateško UI, visoko avtonomno izvajanje in predajo programske opreme, pripravljene za pregled

Razvito v SLAIF, preverjeno v praksi in vključeno v usposabljanje rastoče skupnosti

Orkestrirano agentsko programiranje (Orchestrated Agentic Programming, OAP) je upravljan delovni tok za prenos obsežnega dela programskega inženirstva na agente UI ob ohranjanju človeškega nadzora nad namenom izdelka, arhitekturo, tveganji, dokazi in izdajo.

OAP ni nastal v praznem prostoru. Razvit in izpopolnjen je bil v Slovenski tovarni umetne inteligence (SLAIF) s praktično uporabo na resničnih programskih projektih, nato pa je prerasel v napreden program usposabljanja SLAIF.

Prvi dve celodnevni delavnici OAP, izvedeni junija 2026, sta zabeležili 43 udeležb, od tega 30 iz industrije ter MSP/zagonskih podjetij. Zaradi velikega povpraševanja je bila druga delavnica organizirana le 14 dni po prvi, število udeležencev pa se je povečalo z 18 na 25. Odzivi udeležencev so bili zelo pozitivni: skupne ocene so dosegle 4,50/5 za kakovost vsebine, 4,61/5 za jasnost predstavitve in 4,43/5 za priporočilo.

Povpraševanje še naprej raste. Septembrska delavnica je že zapolnjena, četrta izvedba pa je v načrtovanju. Ta odziv kaže, da upravljan agentski razvoj programske opreme ni le metodološki raziskovalni rezultat, temveč odgovarja na neposredno in hitro rastočo potrebo razvijalcev, raziskovalcev in strokovnjakov iz industrije.

Prvo poglavje predstavlja sam OAP: ločitev vlog, omejene delovne naloge, dokaze v repozitoriju, preverjanje, pregled in človeško pristojnost za izdajo. Drugo poglavje: Koncentrirani OAP predstavlja napredni način dela, ki temelji na vnaprejšnjem vlaganju človeškega dela, naknadni človeški presoji, odloženem človeškem razsojanju in neodvisni zaključni reviziji.

Metodologijo podpira rastoča zbirka praktičnih učnih virov. Zbirka delavnic SLAIF OAP vsebuje celotne priročnike v angleščini in slovenščini ter navodila za hiter začetek z WSL2 za praktično uvajanje.

Nadaljuj na drugo poglavje: Koncentrirani OAP Razišči gradiva delavnic OAP

Zakaj OAP

Majhna ekipa lahko danes programsko opremo ustvari hitreje, kot lahko dokaže, da je pravilna.

Predstavljajmo si MSP z dvema ali tremi razvijalci. Kodirni agenti UI lahko ekipi omogočijo izvedbo več funkcionalnosti v času, ki je bil prej potreben za eno. Toda ista majhna ekipa mora še vedno odločiti, kaj naj se izdela, varovati arhitekturo, pregledati varnostno občutljive spremembe, preveriti preskuse, pregledati dokumentacijo, upravljati sistem in prevzeti odgovornost, ko kaj odpove.

Nastane nevarno neravnovesje. Kodo, konfiguracijo, preskuse in dokumentacijo je mogoče ustvariti hitro; vse to je lahko videti prepričljivo, čeprav dokazuje napačno stvar. Uspešen preskus lahko izvaja nadomestek namesto produkcijske poti. Dovršeno poročilo lahko zamolči izpuščeno preverjanje. Dokumentacija lahko opisuje načrtovano namesto dejansko izvedenega vedenja. Repozitorij raste hitreje, zaupanje vanj pa ne.

OAP je praktičen model dela za odpravljanje tega neravnovesja:

človek določi namen izdelka, meje tveganja ter pristojnosti za sprejem in izdajo;
strateška UI ta namen pretvori v arhitekturo in omejene delovne naloge, nato pa kritično preveri vrnjene dokaze;
izvajalni agent naenkrat izvede eno spremembo, ki jo je mogoče pregledati;
repozitorij in CI ohranita natančno kodo, preskuse, rezultate, dokumentacijo in zgodovino pregledov.

Cilj ni zgolj ustvariti več kode. Cilj je majhni ekipi omogočiti uporabo obsežnih izvedbenih zmogljivosti UI, ne da bi izgubila nadzor nad tem, kaj se izdeluje, kaj je bilo dejansko dokazano in kaj je varno izdati.

Zato je OAP posebej pomemben za MSP in organizacije z omejenimi specialističnimi zmogljivostmi. Podpira tudi širši evropski cilj, da MSP uvajajo zaupanja vredno UI s pomočjo usposobljene delovne sile, praktične podpore in upravljanja, osredotočenega na človeka; ta cilj odražata strategija Apply AI in pobuda za tovarne UI Evropske komisije.

1. Razmerje do virov in obseg

Ta dokument je berljiva spremljevalna razlaga s številnimi diagrami k objavljenemu priročniku Orchestrated Agentic Programming Manual, različica 1.0.1. Ne nadomešča priročnika, njegovih navodil za nastavitev posameznih platform, študij primerov ali virov. OAP predstavlja kot povezano delovno arhitekturo: njegove vloge, krmilne zanke, artefakte, kontrolne točke, načine odpovedi in praktično pot uvajanja.

Dokument opisuje sam OAP. Ne določa poznejših razširitev, ki več človeškega dela v celoti prestavijo pred zanko ali po njej, in ne predpostavlja samodejnega združevanja sprememb po odločitvi strateškega agenta. V OAP človek ostaja odgovorna avtoriteta za namen, tveganje, sprejem in izdajo. Stopnja avtonomije, dodeljena posamezni vlogi UI, se lahko razlikuje, struktura upravljanja pa ostaja.

flowchart LR
    M["Objavljeni priročnik OAP"] --> P["Načela in doktrina"]
    M --> R["Operativna navodila"]
    M --> T["Predloge in primeri"]
    P --> D["Ta spremljevalni dokument"]
    R --> D
    T --> D
    D --> U["Berljiv konceptualni model"]
    D --> A["Izvedbena arhitektura"]
    D --> C["Kontrolni seznami in ponovno uporabni artefakti"]

OAP je mogoče izvajati z različnimi orodji, modeli, operacijskimi sistemi, sistemi CI in gostitelji repozitorijev. Metodo določata struktura nadzora in disciplina dokazovanja, ne posamezen ukaz določenega ponudnika.

Več kratkih okvirjev Zapis iz prakse v tej izdaji izhaja iz izvajanj SLAIF OAP avgusta 2026 v repozitorijih slaif-agent-site, slaif-local-coding, slaif-api-gateway in slaif-zap-it. To so operativni primeri, ne rezultati primerjalnih meritev ali trditve, da se bo vsak projekt obnašal enako. Navedki so bili rahlo urejeni le tam, kjer je bilo to potrebno za berljivost.

2. Zakaj OAP obstaja

2.1 Razvojna zanka programske opreme se je razširila

Razvoj programske opreme s pomočjo UI je napredoval skozi vedno širše krmilne zanke. Dopolnjevanje kode predlaga lokalno nadaljevanje. Pomočniki za programiranje v paru razlagajo ali urejajo bližnjo kodo. Programiranje prek klepeta lahko ustvari datoteke in zasnove. Kodirni agenti lahko pregledujejo repozitorije, izvajajo ukaze, nameščajo odvisnosti in oddajajo zahteve za združitev (PR).

Ko agent lahko upravlja repozitorij, se osrednje inženirsko vprašanje spremeni. Težava ni več zgolj:

Ali model zna napisati kodo?

Vprašanje postane:

Kdo določi sistem, kdo omeji agenta, kaj dokazuje rezultat, kje se ohranja trajna resnica, kdo presoja tveganje in kdo odloči, da je programska oprema pripravljena?

flowchart LR
    A["Dopolnjevanje kode<br/>lokalni predlogi"] --> B["Programiranje v paru z UI<br/>človek ostane v zanki urejanja"]
    B --> C["Programiranje prek klepeta<br/>datoteke in zasnove"]
    C --> D["Kodirni agent<br/>operacije v repozitoriju"]
    D --> E["OAP<br/>upravljana zanka predaje"]

    A -. glavno tveganje .-> A1["Sprejet slab odsek kode"]
    B -. glavno tveganje .-> B1["Verjeten nasvet brez dokazov"]
    C -. glavno tveganje .-> C1["Razhajanje klepeta in repozitorija"]
    D -. glavno tveganje .-> D1["Avtonomija brez upravljanja"]
    E -. glavno tveganje .-> E1["Človek nekritično potrdi šibke dokaze"]

OAP sodi v zadnjo stopnjo. Kodiranje z UI obravnava kot del širšega sistema vodenja in zagotavljanja kakovosti.

2.2 Izdelava kode postaja poceni; dokazovanje ne

Agenti lahko izvedbo ustvarijo hitreje, kot jo ljudje lahko validirajo. Ozko grlo se zato s tipkanja premakne na:

odločanje, kaj naj obstaja;
ohranjanje arhitekturnega namena;
nadzor obsega;
preskušanje smiselnega vedenja;
prepoznavanje negativnih poti;
pregled varnosti in ravnanja s podatki;
ohranjanje poštene dokumentacije;
razlikovanje med delno izvedbo in podprtim vedenjem;
presojo, ali je trditev ob izdaji upravičena.

OAP zato dolg validacije obravnava kot prevladujoči dolg razvoja, pospešenega z UI.

flowchart TD
    SPEED["UI poveča hitrost izvedbe"] --> CODE["Nastane več kode in konfiguracije"]
    CODE --> CLAIMS["Več nakazanih trditev o vedenju"]
    CLAIMS --> PROOF["Potrebnih je več dokazov"]
    PROOF --> TESTS["Preskusi in CI"]
    PROOF --> REVIEW["Pregled arhitekture in varnosti"]
    PROOF --> DOCS["Točnost dokumentacije"]
    PROOF --> RELEASE["Poštenost trditev ob izdaji"]
    TESTS --> BOTTLENECK["Validacija postane ozko grlo"]
    REVIEW --> BOTTLENECK
    DOCS --> BOTTLENECK
    RELEASE --> BOTTLENECK

OAP torej ni predvsem trik za večjo produktivnost. Je metoda upravljanja validacije, zasnovana za čas, v katerem lahko izvedbene zmogljivosti presežejo človeške zmogljivosti pregledovanja.

2.3 OAP je sistem nadzora

OAP človeško pozornost ohranja na ravni, kjer ima največji učinek: pri pomenu izdelka, domenski pravilnosti, tveganju, dokazih in izdaji. Mehansko izvedbeno delo prenese na izvajalnega agenta, pred izvedbo in po njej pa vključi plast strateškega sklepanja.

flowchart TD
    H["Človeški vodja<br/>namen, domenska resnica, tveganje, izdaja"] --> S["Strateška UI<br/>raziskovanje, arhitektura, delovni nalogi, kritika"]
    S --> E["Izvajalni agent<br/>delo v repozitoriju in na računalniku"]
    E --> G["Oddaljeni repozitorij<br/>veja, PR, CI, dokumentacija, poročilo"]
    G --> S
    S --> B["Povzetek za odločanje, povezan z dokazi"]
    B --> H
    H -->|odobri, popravi, zavrni, odloži| S

Zanka je upravljana, ker se od nobene plasti ne pričakuje, da bo opravila vse:

človek ne postane upravljavec agentovega terminala;
strateški model ne postane rutinski izvajalec;
izvajalni agent ne določa pomena izdelka ali pripravljenosti za izdajo;
lokalni računalnik ne postane vir resnice.

3. Delovna opredelitev

3.1 Opredelitev

Orkestrirano agentsko programiranje je delovni tok predaje programske opreme pod človeškim upravljanjem, v katerem strateška UI domenski namen pretvori v arhitekturo, strojno berljivo upravljanje, omejene delovne naloge, kritiko in priporočila, povezana z dokazi, visoko avtonomni izvajalni agent pa opravi izvedbeno delo v omejenem izvajalnem okolju ter spremembe vrne prek pregledljivih artefaktov repozitorija.

Človeški vodja ostaja odgovoren za:

opredelitev problema;
namen izdelka;
domensko resnico;
potrebe uporabnikov;
etične in pravne meje;
pripravljenost za prevzemanje tveganj;
prednostne naloge;
sprejemna merila;
pomembne odločitve o združitvi in izdaji;
odgovornost, kadar je rezultat napačen.

3.2 Zakaj »orkestrirano«

Delo ni predano agentu kot en sam neomejen cilj. Razdeljeno je na vloge, artefakte, meje, delovne enote, zahteve glede dokazov in kontrolne točke. Strateško sklepanje in izvajanje sta namenoma ločena. Proces ima nadzorno ravnino, izvajalno ravnino, trajno stanje in izrecne točke sprejema.

3.3 Zakaj »agentsko«

Izvajalnemu agentu je dovoljeno delovati, ne zgolj predlagati. Odvisno od okolja lahko:

pregleduje in ureja datoteke repozitorija;
namešča pakete in sistemske odvisnosti;
zaganja lokalne podatkovne zbirke in storitve;
izvaja migracije v preskusnih okoljih;
uporablja orodja za preskuse, statično analizo, preverjanje tipov, gradnjo in brskalnik;
diagnosticira napake in ponavlja poskuse;
ustvarja veje in potrditve sprememb;
pošilja spremembe v oddaljeni repozitorij in odpira PR-je;
piše poročila o izvedbi in preverjanju.

Strateška UI je agentska v drugem smislu: raziskuje, primerja arhitekture, preverja stanje repozitorija, piše delovne naloge, pregleduje dokaze, prepoznava potrebno popravljalno delo in vzdržuje kontinuiteto.

3.4 Zakaj »programiranje«

Programiranje ne izgine. Premakne se na višjo raven. Sistem še vedno sestavljajo izvorna koda, preskusi, sheme, konfiguracija, logika namestitve in dokumentacija. Človek vse bolj programira:

namen;
arhitekturo;
omejitve;
proces;
pričakovanja glede dokazov;
merila za sprejem in izdajo.

Agenti ta program na višji ravni pretvorijo v operativno delo.

3.5 Kaj OAP ni

OAP ni:

programiranje po občutku (vibe coding), pri katerem so rezultati sprejeti predvsem zato, ker so videti verjetni;
običajno programiranje v paru z UI, pri katerem človek ostaja v izvedbeni zanki;
en sam ogromen avtonomen poziv, brez meja PR-jev ali dogovora o dokazih;
neomejen roj agentov, v katerem pristojnosti in odgovornosti niso jasne;
povsem avtonomno programsko inženirstvo, saj človek ohrani pristojnost nad namenom, tveganjem in izdajo;
navidezna avtomatizacija, pri kateri ustvarjena poročila nadomeščajo dejanske dokaze iz repozitorija in CI.

flowchart TB
    OAP["OAP"] --> G1["Izrecno upravljanje"]
    OAP --> G2["Ločitev vlog"]
    OAP --> G3["Omejena avtonomija"]
    OAP --> G4["Delo v obsegu PR-ja"]
    OAP --> G5["Dokazi in pregled"]
    OAP --> G6["Človeška odgovornost"]

    V["Programiranje po občutku"] -. nima .-> G1
    P["Programiranje v paru"] -. ohranja človeka v .-> G4
    X["Neomejena avtonomija"] -. slabi .-> G2
    S["Roj agentov"] -. zamegljuje .-> G6

4. Vloge in pristojnosti

4.1 Človeški vodja

Od človeškega vodje se ne pričakuje, da bo natipkal večino kode ali posredoval vsako sporočilo o napaki. Pričakuje se, da bo upravljal projekt.

Človeški vodja določa:

zakaj projekt obstaja;
kateri uporabniki in delovni tokovi so pomembni;
kateri kompromisi so sprejemljivi;
katera tveganja je mogoče sprejeti;
kaj naj prva izdaja naredi in česa naj ne;
kateri dokazi zadostujejo;
ali je rezultat dovolj uporaben in varen;
ali je združitev, izdaja ali namestitev odobrena.

Najboljši človeški vodja je zato lahko oseba z najglobljim razumevanjem domene, ne nujno oseba, ki zna vsako komponento izvesti ročno.

4.2 Strateška UI

Strateška UI je nadzorna ravnina, s katero sodeluje človek. Praviloma naj bo to najzmogljivejši praktično uporaben model, ki je projektu na voljo, saj mora njegov kontekst ohranjati:

namen in besedišče izdelka;
arhitekturo in meje zaupanja;
prejšnje odločitve;
trenutno stanje repozitorija;
odprta tveganja;
zgodovino delovnih nalogov;
dokaze iz pregledov;
stanje izdaje;
človeške prednostne naloge in popravke.

Njene odgovornosti vključujejo:

strateško raziskovanje;
izbiro arhitekture in tehnologij;
pripravo in vzdrževanje ustave;
razčlenitev dela na obseg posameznih PR-jev;
avtorstvo delovnih nalogov;
pregled poročil o izvedbi, razlik in CI;
odkrivanje širjenja obsega in šibkih dokazov;
pripravo popravljalnih nalogov;
jedrnato gradivo za človeško odločanje;
ohranjanje kontinuitete in pripravo predaj.

Privzeto je prvi pregledovalec, ni pa končna odgovorna avtoriteta.

4.3 Izvajalni agent

Izvajalni agent zagotavlja omejeno izvedbeno delo v zamenljivem okolju. Znotraj svojega izvajalnega okolja naj ima dovolj pristojnosti, da delo dokonča, ne da bi človeka uporabljal kot nameščevalca paketov, posrednika terminala ali pomočnika pri razhroščevanju.

Odgovoren je za:

pregled repozitorija, pomemben za nalog;
spremembe kode in preskusov;
lokalno nastavitev odvisnosti in orodij v dovoljenem izvajalnem okolju;
usmerjeno preverjanje;
ustvarjanje vej, potrditev sprememb, pošiljanje v oddaljeni repozitorij in odpiranje PR-jev;
točno poročanje o uspešnih, neuspešnih in izpuščenih preverjanjih ter preostalih blokadah.

Ni pristojen za:

namen izdelka;
arhitekturne spremembe zunaj naloga;
trditve ob izdaji;
produkcijske poverilnice ali produkcijske podatke;
združitev lastnega PR-ja, razen če je izrecno sprejet drugačen model upravljanja;
spreminjanje sprejemnih meril, ko izvedba postane zahtevna.

4.4 Repozitorij in CI

Oddaljeni repozitorij ni pasivno mesto shranjevanja. Je trajna podlaga za usklajevanje:

potrditve sprememb ohranijo natančne spremembe;
veje ločijo delo;
PR-ji razkrijejo obseg in razpravo;
CI ponovi preverjanje;
komentarji pregledov ohranijo kritiko;
dokumentacija ohranja veljavne pogodbe;
prijave težav in predaje ohranjajo kontinuiteto;
oznake in izdaje ohranijo trditve.

flowchart LR
    H["Človek<br/>pomen in pristojnost"] --> S["Strateška UI<br/>nadzorna ravnina"]
    S --> E["Izvajalni agent<br/>izvajalna ravnina"]
    E --> R["Repozitorij in CI<br/>trajna resnica"]
    R --> S
    S --> H

    subgraph HumanAuthority["Neprenosljive človeške pristojnosti"]
        HA1["Namen"]
        HA2["Pripravljenost za prevzemanje tveganj"]
        HA3["Sprejem"]
        HA4["Izdaja"]
    end

    H --> HumanAuthority

4.5 Pravilo proti obračanju vlog

Jedrnato pravilo OAP je:

Človek vodi strateško UI; strateška UI usmerja izvajalnega agenta; izvajalni agent upravlja računalnik.

Če izvajalni agent človeka vedno znova prosi, naj namesti pakete, izvede ukaze, prilepi dnevnike, popravi okolje ali odloča o rutinskih izvedbenih podrobnostih, se je smer nadzora obrnila.

flowchart TD
    GOOD["Pravilna smer nadzora"] --> H["Človek določi namen"]
    H --> S["Strateška UI pripravi delo"]
    S --> E["Izvajalec upravlja računalnik"]
    E --> EV["Dokazi se vrnejo navzgor"]
    EV --> S
    S --> H

    BAD["Obrat smeri nadzora"] --> E2["Izvajalec naleti na rutinsko oviro"]
    E2 --> H2["Človek namešča, zaganja, lepi in popravlja"]
    H2 --> E2

    style BAD fill:#f8d7da,stroke:#9b2c2c
    style H2 fill:#f8d7da,stroke:#9b2c2c

Rešitev je navadno boljša zasnova izvajalnega okolja, jasnejši delovni nalogi ali učinkovitejše strateško posredovanje, ne več človeškega dela v terminalu.

5. Strateško raziskovanje

5.1 Začnite z domenskim problemom, ne s tehnološkim skladom

OAP se začne pred izvedbo. Prvi strateški pogovor preveri, kakšen sistem naj sploh obstaja.

Človek lahko natančno pozna operativno potrebo, ne da bi poznal najboljšo arhitekturo. Strateško raziskovanje pomaga določiti:

dejansko kategorijo izdelka;
predvidene uporabnike in delovne tokove;
meje zaupanja;
modele groženj in odpovedi;
lastništvo in hrambo podatkov;
potrebne vmesnike;
primerne, preverjene in vzdržljive tehnologije;
opravila v ozadju in operativne procese;
obliko namestitve;
strategijo preskušanja;
kaj mora biti izključeno iz prve izdaje;
o čem izvajalni agent nikoli ne sme improvizirati.

flowchart TD
    P["Domenski problem"] --> Q1["Kakšen sistem je to?"]
    Q1 --> Q2["Kdo ga uporablja in čemu zaupamo?"]
    Q2 --> Q3["Kateri podatki in operacije obstajajo?"]
    Q3 --> Q4["Katera arhitektura omeji tveganja?"]
    Q4 --> Q5["Kateri sklad je primeren in vzdržljiv?"]
    Q5 --> Q6["Kaj sodi v prvo izdajo?"]
    Q6 --> ART["Arhitektura, ustava, razvojni načrt, prvi delovni nalog"]

Človeku ni treba vnaprej poznati vsakega tehničnega odgovora. Domeno mora poznati dovolj dobro, da zavrne tehnično elegantno, a operativno napačno rešitev.

5.2 Raziskovanje je skupna presoja

Strateški model predlaga možnosti in razloži posledice. Človek jih sprejme, zavrne ali preusmeri. To ni enkraten modelov izhod.

sequenceDiagram
    participant H as Človeški vodja
    participant S as Strateška UI
    participant W as Dokazi iz spleta, dokumentacije in repozitorija

    H->>S: Opiši operativni problem in omejitve
    S->>W: Razišči sorodna orodja in aktualna dejstva
    W-->>S: Dokazi in možnosti
    S->>H: Razlaga izdelka in arhitekturne možnosti
    H->>S: Domenski popravek in odnos do tveganja
    S->>H: Izpopolnjena arhitektura, meje in obseg prve izdaje
    H->>S: Odobri ali preusmeri
    S->>H: Ustava, projektni artefakti in načrt delovnih nalogov

5.3 Artefakti raziskovanja

Temeljita faza raziskovanja naj ustvari trajne artefakte, ne le zgodovine klepeta. Glede na velikost projekta lahko vključujejo:

ARCHITECTURE.md;
model meja zaupanja ali varnosti;
dokument s pogodbo API-ja ali podatkov;
opredelitev obsega izdaje;
razvojni načrt;
zapise arhitekturnih odločitev;
projektno ustavo, na primer AGENTS.md;
začetne delovne naloge;
pričakovanja glede preskusov in dokazov.

Strateški pogovor je uspešen, ko drug usposobljen agent razume predvideni sistem, ne da bi moral obnoviti celotno zgodovino človeškega klepeta.

5.4 Kontrolna točka raziskovanja

Širše izvajanje naj se ne začne, dokler projekt ni dovolj opredeljen, da omejuje smiselno delo.

stateDiagram-v2
    state "Domenski problem" as DomainProblem
    state "Strateško raziskovanje" as StrategicDiscovery
    state "Nejasno" as Ambiguous
    state "Upravljano" as Governed
    state "Ustava" as Constitution
    state "Prvi delovni nalog" as FirstWorkOrder
    state "Izvajanje" as Execution
    [*] --> DomainProblem
    DomainProblem --> StrategicDiscovery
    StrategicDiscovery --> Ambiguous: nerazrešena oblika izdelka
    Ambiguous --> StrategicDiscovery: človeško pojasnilo
    StrategicDiscovery --> Governed: sprejete arhitektura in meje
    Governed --> Constitution
    Constitution --> FirstWorkOrder
    FirstWorkOrder --> Execution

To ne zahteva popolne daljnovidnosti. Zahteva dovolj izrecnih pravil, da izvajalec med pisanjem kode ne izumlja izdelka.

6. Projektna ustava

6.1 Strojno berljivo upravljanje

Projektna ustava, pogosto AGENTS.md, CLAUDE.md ali enakovredna datoteka z navodili, ponavljajoče se človeške popravke pretvori v trajna operativna pravila. Agentom pove, kako naj ravnajo, ko jih človek ne opazuje.

Brez ustave projekt postane zaporedje domiselnih pozivov. Z ustavo vsak delovni nalog podeduje stabilna pravila.

6.2 Kaj naj vsebuje ustava

Uporabna ustava navadno določa:

namen projekta in kaj ni njegov namen;
arhitekturne meje;
pravila o viru resnice;
delovni tok repozitorija;
zahteve glede vej in PR-jev;
ukaze za preskušanje in preverjanje;
pravila varnosti in zasebnosti;
prepovedana dejanja;
politiko odvisnosti;
obveznosti glede dokumentacije;
besedišče poročanja;
opredelitev dokončanosti;
pogoje za predajo vprašanja višji ravni;
meje vlog in pristojnost za združitev.

Razlikuje naj med:

normativnimi pravili: kaj agenti morajo ali ne smejo storiti;
arhitekturo: kako naj sistem deluje;
postopkom: natančnimi ukazi ali delovnimi tokovi;
referenčnim gradivom: razlagami in primeri.

6.3 Večplastne ustave

Večji repozitoriji lahko potrebujejo večplastna navodila. Korenska pravila veljajo za celoten projekt, pravila poddrevesa pa jih podrobneje določijo za jezik, storitev, uporabniški vmesnik, podatkovno plast ali namestitveno komponento.

flowchart TD
    ROOT["Ustava repozitorija<br/>splošna pravila"] --> API["Pravila poddrevesa API"]
    ROOT --> WEB["Pravila spletnega poddrevesa"]
    ROOT --> DATA["Pravila poddrevesa podatkovne zbirke"]
    ROOT --> OPS["Pravila operativnega poddrevesa"]

    API --> TASKA["Delovni nalog za API"]
    WEB --> TASKW["Delovni nalog za uporabniški vmesnik"]
    DATA --> TASKD["Delovni nalog za migracijo"]
    OPS --> TASKO["Delovni nalog za namestitev"]

Lokalna navodila lahko dodajo omejitve, naj pa ne slabijo tiho pravil višje ravni o varnosti, viru resnice ali pristojnostih.

6.4 Ustava kot spomin

Ustava je mehanizem spomina. Modeli izgubljajo kontekst, seje se končajo in člani ekipe se menjajo. Trajna navodila ohranjajo:

ponavljajoče se popravke;
arhitekturne invariante;
znane nevarne bližnjice;
natančna pričakovanja glede preskusov;
dogovore o delovnem toku;
pomen besede »končano«.

Ustava naj ostane dovolj jedrnata za zanesljivo nalaganje. Poglobljena razlaga sodi v povezane arhitekturne dokumente in operativne priročnike.

6.5 Znaki šibke ustave

Ustava je šibka, če:

vsebuje le splošne nasvete, kot je »piši čisto kodo«;
podvaja obsežno dokumentacijo, ne da bi določila normativna pravila;
nasprotuje trenutnemu vedenju repozitorija;
ne navede natančnih ukazov za preskuse;
izpusti pravila o viru resnice in vejah;
agentu dopušča spreminjanje obsega ali sprejemnih meril;
daje splošna opozorila brez konkretnih prepovedanih dejanj;
postane tako dolga in zastarela, da agenti ne morejo prepoznati zavezujočih pravil.

Močna ustava strateškemu modelu omogoča odgovoriti:

Katera projektna pravila omejujejo ta delovni nalog?

Izvajalcu pa omogoča odgovoriti:

Kaj mora med izvedbo ostati resnično?

7. Operativno predhodno preverjanje in meja izvajalnega okolja

7.1 Avtonomija je odločitev o zasnovi izvajalnega okolja

Agent, ki lahko ureja kodo, ne more pa namestiti manjkajoče odvisnosti, zagnati preskusne podatkovne zbirke ali izvesti dejanskega nabora preskusov, ni smiselno avtonomen. Namesto tega lahko za mehansko delo zaposli človeka.

OAP lahko uporablja previdne načine odobravanja, njegova značilna visoko avtonomna oblika pa zmogljivosti umešča v namensko omejeno izvajalno okolje, ki ga je mogoče ponovno zgraditi.

7.2 Vzorec omejene visoke avtonomije

Prednostni vzorec vključuje:

namenski navidezni stroj, distribucijo WSL2, vsebnik, razvojni vsebnik ali peskovnik v oblaku;
samo predvideni repozitorij in preskusne pripomočke;
dovolj privilegijev za nameščanje, gradnjo, preskušanje in zagon lokalnih storitev;
brez produkcijskih skrivnosti;
brez produkcijskih podatkov;
brez nenadomestljivega stanja;
ozko omejene priklope gostiteljevih imenikov;
vidnost vseh trajnih sprememb v sistemu za nadzor različic;
PR-je namesto neposrednega spreminjanja zaščitenih vej;
možnost posnetka, izvoza ali ponovne gradnje;
dnevnike, ki zadostujejo za diagnozo.

flowchart LR
    subgraph HOST["Gostiteljevo ali organizacijsko okolje"]
        HS["Dolgotrajne skrivnosti"]
        HD["Produkcijski podatki"]
        HP["Zaščitena infrastruktura"]
    end

    subgraph GUEST["Omejeno izvajalno okolje"]
        REPO["Klon repozitorija"]
        FIX["Preskusni pripomočki"]
        TOOLS["Prevajalniki, paketi, brskalniki, podatkovne zbirke"]
        AGENT["Visoko avtonomni izvajalni agent"]
    end

    AGENT --> REPO
    AGENT --> TOOLS
    FIX --> AGENT
    REPO --> REMOTE["Oddaljeni repozitorij in CI"]

    HOST -. brez širokega dostopa .-> GUEST
    HS -. prepovedano .-> AGENT
    HD -. prepovedano .-> AGENT
    HP -. samo prek izrecne kontrolne točke .-> AGENT

7.3 Privilegiji so tudi meja učinkovitosti

Vprašanje ni zgolj »kako malo lahko agent naredi?«, temveč:

Kaj lahko agent varno naredi v prostoru, ki smo ga pripravljeni zavreči?

Skrbniški privilegiji brez gesla so lahko sprejemljivi v zamenljivem gostujočem okolju brez dragocenih skrivnosti ali stanja. Enaki privilegiji na običajni delovni postaji s širokim dostopom do domačega imenika so lahko nesprejemljivi.

Meja naj bo zasnovana tako, da je rutinska nastavitev za agenta cenejša kot za človeka.

7.4 Izolacija in odobritev sta različna mehanizma nadzora

OAP razlikuje med:

zmožnostjo izvajalnega okolja: kaj lahko agent tehnično doseže ali spremeni;
procesno pristojnostjo: kaj sme agent sprejeti, združiti, izdati ali namestiti.

Peskovnik lahko prepreči dejanje. Kontrolna točka upravljanja lahko prepove sprejem, tudi kadar je dejanje tehnično izvedljivo.

flowchart TD
    ACTION["Predlagano dejanje agenta"] --> CAP{"Ga izvajalno okolje dopušča?"}
    CAP -->|Ne| BLOCK["Tehnično blokirano"]
    CAP -->|Da| AUTH{"Ga projektna pravila dovoljujejo?"}
    AUTH -->|Ne| REFUSE["Agent mora zavrniti ali predati vprašanje višji ravni"]
    AUTH -->|Da| EVID{"So dokazi in delovni tok ustrezni?"}
    EVID -->|Ne| REPAIR["Popravi ali zberi dokaze"]
    EVID -->|Da| EXEC["Izvedi znotraj obsega"]

7.5 Ponastavitev mora biti poceni

Izvajalno okolje ni varno zamenljivo, če njegova ponovna gradnja traja več dni in temelji na nedokumentiranem ročnem znanju.

stateDiagram-v2
    state "Čist posnetek" as CleanSnapshot
    state "Aktivno izvajanje" as ActiveRun
    state "Uporaben rezultat" as UsefulResult
    state "Pokvarjeno izvajalno okolje" as BrokenRuntime
    state "Ohrani trajno stanje" as PreserveDurableState
    state "Oddaljeni repozitorij" as RemoteRepository
    state "Povrni ali uniči" as RevertOrDestroy
    [*] --> CleanSnapshot
    CleanSnapshot --> ActiveRun
    ActiveRun --> UsefulResult
    ActiveRun --> BrokenRuntime
    UsefulResult --> PreserveDurableState
    PreserveDurableState --> RemoteRepository
    BrokenRuntime --> RevertOrDestroy
    RevertOrDestroy --> CleanSnapshot
    RemoteRepository --> CleanSnapshot: ponovno zgradi po potrebi

Po uporabnem delu ohranite potrditve sprememb, PR-je, dnevnike in dokumentirano nastavitev. Po uničujoči odpovedi okolje povrnite ali ponovno zgradite, namesto da bi vzdrževali nenadomestljivo agentovo delovno postajo.

7.6 Kontrolni seznam predhodnega preverjanja

Pred visoko avtonomnim izvajanjem preverite vsaj:

Vodilno načelo je:

Agent je lahko znotraj gostujočega okolja zmogljiv, vendar to okolje ne sme vsebovati ničesar, česar si človek ne more privoščiti izgubiti ali zamenjati.

8. Inženirstvo delovnih nalogov

8.1 Delovni nalog je izvedljivi izdelek strateške plasti

Najpomembnejši izhod strateške UI običajno ni koda. Je delovni nalog, ki človeški in arhitekturni namen pretvori v omejeno izvedbeno pogodbo.

Dober delovni nalog izvajalcu omogoča delovanje, ne da bi:

izumljal izdelek;
človeka prosil za rutinsko nastavitev;
širil obseg, ker se sosednje delo zdi koristno;
na novo opredelil uspeh, ko preskusi postanejo zahtevni;
obnavljal zastarelo stanje projekta iz starega spomina na klepet.

flowchart LR
    INTENT["Človeški namen"] --> STRAT["Strateško sklepanje"]
    ARCH["Arhitektura in ustava"] --> STRAT
    LIVE["Trenutna resnica repozitorija"] --> STRAT
    RISK["Tveganje in sprejemna merila"] --> STRAT
    STRAT --> ORDER["Delovni nalog v obsegu PR-ja"]
    ORDER --> EXEC["Izvajalni agent"]

8.2 Zahtevana vsebina

Močan delovni nalog navadno vključuje:

veljavna navodila;
trenutno preverjeno stanje;
natančen cilj;
domensko vedenje, ki ga je treba ohraniti;
obseg;
izrecne necilje;
datoteke ali podsisteme za pregled;
zahtevano vedenje in invariante;
preskuse za dodajanje in ukaze za izvajanje;
dovoljeno lokalno nastavitev;
omejitve varnosti in ravnanja s podatki;
posodobitve dokumentacije;
delovni tok vej, potrditev sprememb in PR-jev;
natančno obliko končnega poročila.

8.3 Trenutno stanje mora biti res trenutno

Strateški model mora pred izdajo naloga preveriti dejansko stanje repozitorija. Predaja ali prejšnje poročilo je spominski pripomoček, ne avtoriteta.

Pred pripravo naloga po potrebi preverite:

oddaljeno privzeto vejo in SHA njenega vrha;
odprte PR-je;
nedavne združitve;
trenutno stanje CI;
ustrezne datoteke in preskuse;
nerazrešene komentarje pregledov;
obstoječe migracije ali pogodbe API-jev;
lokalne neoddane spremembe, ki jih ni dovoljeno prepisati.

stateDiagram-v2
    state "Predlagani nalog" as ProposedOrder
    state "Osveži stanje" as RefreshState
    state "Zastarelo" as Stale
    state "Pripravi nov osnutek" as Redraft
    state "Aktualno" as Current
    state "Aktiviraj nalog" as ActivateOrder
    state "Izvedi" as Execute
    [*] --> ProposedOrder
    ProposedOrder --> RefreshState
    RefreshState --> Stale: razlikuje se od predpostavk
    Stale --> Redraft
    Redraft --> RefreshState
    RefreshState --> Current: dokazi se ujemajo
    Current --> ActivateOrder
    ActivateOrder --> Execute

8.4 Necilji so varnostna orodja

Agenti so učeni, da pomagajo. Brez izrecnih neciljev se pripravljenost pomagati spremeni v širjenje obsega.

Uporabni necilji določajo konkretne meje:

ne dodajaj migracije;
ne spreminjaj javnega API-ja;
ne dodajaj odvisnosti;
ne shranjuj surovih pozivov ali vsebine zahtev;
ne kliči dejanskih zunanjih storitev;
ne spreminjaj nepovezanih datotek;
ne trdi, da je sistem produkcijsko pripravljen;
izpuščenih brskalniških preskusov ne obravnavaj kot uspešnih.

8.5 Preskusi morajo biti poimenovani

»Izvedi preskuse« je šibko navodilo. Delovni nalog naj navede:

usmerjene ukaze;
ustrezne širše nabore preskusov;
pričakovane negativne preskuse;
predpostavke o okolju;
kaj se sme izpustiti in kako je treba o tem poročati;
preverjanja CI, pričakovana na končnem vrhu veje PR-ja.

8.6 Popravljalno delo ni nova funkcionalnost

Kadar ima PR neuspešen CI, nerazrešene komentarje pregledov, šibke preskuse, varnostne pomisleke ali neskladno dokumentacijo, naj naslednji nalog popravi ta PR, ne začne sosednjega dela.

flowchart TD
    PR["Odprt PR"] --> REVIEW{"Rezultat pregleda"}
    REVIEW -->|Sprejeto| MERGE["Združitev s človeško odobritvijo"]
    REVIEW -->|Potreben popravek| REPAIR["Ozko omejen popravljalni delovni nalog"]
    REPAIR --> SAME["Ista veja in PR"]
    SAME --> PR
    REVIEW -->|Napačna smer| REJECT["Zapri ali preoblikuj"]

Zapis iz prakse — Popravljalni krog je ostal v istem PR-ju.

Med ciljem 066 projekta Agent-Site je zagon Compose v produkcijskem slogu pokazal, da aplikacija Agent deluje, javni vzdevek NGINX za preverjanje delovanja pa vrača 404. Strateški agent ni izumil nove funkcionalnosti, odprl nadomestnega PR-ja ali začel naslednjega cilja. Izdal je ozko omejen popravek 066-d na isti veji in PR-ju, prepovedal spremembe avtentikacije in pristojnosti podatkovne zbirke ter zahteval dokaz nameščenega robnega vedenja 200/401/404.

Operativni nauk: resnična napaka, odkrita med pregledom, sodi v najmanjši popravljalni krog, ki zaključi obstoječi PR. Popravek je nadaljevanje, ne ustvarjanje nove funkcionalnosti.

8.7 Predloga delovnega naloga

# Delovni nalog — <identifikator>

## Veljavna navodila
- Najprej preberi projektno ustavo.
- Upoštevaj delovni tok repozitorija in pravila o viru resnice.
- Če se dejansko stanje razlikuje od naloga, ustavi spreminjanje in poročaj o razliki.

## Trenutno preverjeno stanje
- Privzeta veja in njen vrh:
- Pomembni odprti PR-ji:
- Pomembno izvedeno vedenje:
- Znana neuspešna ali izpuščena preverjanja:

## Cilj
- Natančen rezultat v domenskem jeziku.

## Obseg
- Zahtevano izvedbeno delo.

## Necilji
- Izrecno izključeno delo, datoteke, API-ji, migracije, odvisnosti ali trditve.

## Datoteke in sistemi za pregled
- ...

## Zahtevano vedenje in invariante
- ...

## Preverjanje
- Preskusi za dodajanje:
- Ukazi za izvajanje:
- Zahtevane negativne poti:
- Zahtevani CI na končnem vrhu veje:

## Dovoljena lokalna nastavitev
- Po potrebi namesti manjkajoča preskusna orodja znotraj omejenega izvajalnega okolja.
- Dokumentiraj opravljeno nastavitev.
- Človeka ne prosi za rutinsko nastavitev, razen če jo blokira določena varnostna meja.

## Zahtevana dokumentacija
- ...

## Delovni tok Git in PR
- Začni na trenutni privzeti veji.
- Ustvari ali uporabi določeno funkcionalno vejo.
- Potrdi le povezane spremembe.
- Pošlji spremembe in odpri/posodobi PR.
- Ne združuj.

## Končno poročilo
- Veja in izvedbena potrditev sprememb.
- URL PR-ja.
- Povzetek vedenja.
- Spremenjene datoteke.
- Preskusi in natančni rezultati.
- Opravljena nastavitev.
- Spremenjena dokumentacija.
- Tveganja, napake, izpuščena preverjanja in nerazrešena vprašanja.

8.8 Znaki šibkega poziva

Delovni nalog je šibek, če pravi:

»izboljšaj to«;
»dokončaj funkcionalnost«;
»odpravi vse težave«;
»uporabi svojo presojo« brez omejitev;
»izvedi preskuse« brez določitve dokazov;
»posodobi dokumentacijo« brez določitve pogodbe;
»vprašaj me, če kaj manjka« za rutinsko delo v okolju.

Močan nalog omogoča določitev uspeha ali neuspeha še pred začetkom izvajanja.

8.9 Izvor delovnih nalogov in dokazljivo obvladljiv obseg

Vsak delovni nalog naj bo sledljiv do trajnega razloga. Zadostuje jedrnato besedišče izvora:

Oznaka	Izvor dela
H	Izrecno človeško navodilo ali vnaprej določen namen
A	Zahteva arhitekture, ustave, pogodbe ali razvojnega načrta
E	Opaženi dokazi o napaki ali odstopanje med izvajanjem
I	Ugotovitev neodvisne revizije
R	Odprava zabeleženega tveganja, ugotovitve pregleda ali neuspešne kontrolne točke sprejema

Nalog ima lahko več oznak. Namen ni birokracija. Namen je odgovoriti na eno vprašanje, preden avtonomni sistem porabi še en izvedbeni cikel:

Zakaj to delo obstaja?

Strateška plast naj izbere tudi najmanjši povezan del, ki dokaže mehanizem. Razumevanje končne arhitekture ne zahteva izvedbe celotne arhitekture v naslednjem PR-ju.

Zapis iz prakse — Zasnova s 26 točkami je postala en dokazni PR.

Razprava o ohranjanju dolgega konteksta upravljanja se je hitro razširila v celovito arhitekturo predpomnjenja. Človek je posegel z besedami v smislu: »Ne dajaj mi specifikacije s 26 točkami. Najprej povej, kaj je mogoče z OAP razumno hitro izdelati.« Načrt je bil nato zožen na en PR, ki je dokazal eno samo pot ponovnega vnašanja konteksta, z izrecno izključitvijo splošnega predpomnjenja, samodejnega opazovanja, demonov, podatkovnih zbirk in priprave produkcijskih paketov.

Operativni nauk: najprej dokaži mehanizem na eni dejanski meji. Posploši ga šele, ko dokazi upravičijo nov delovni nalog.

9. Izvajalna plast in delegiranje v obsegu PR-ja

9.1 Ena naloga, en kontekst

Izvajalni kontekst se hitro porablja. Kodirni agent bere datoteke, izhode ukazov, dnevnike, napake preskusov in izvedbene podrobnosti. OAP zato eno nalogo v obsegu PR-ja obravnava kot naravno življenjsko dobo izvajalnega konteksta. Če je treba kontekst ali proces zamenjati pred dokončanjem naloge, nova izvajalna epizoda nadaljuje isti delovni nalog, vejo in PR; zamenjava konteksta ni nov cilj.

Strateški kontekst naj ohranja projekt, izvajalni kontekst pa dokonča eno omejeno spremembo.

flowchart LR
    subgraph StrategicContext["Strateški kontekst: počasna poraba"]
        SG["Cilj"]
        SA["Arhitektura"]
        SR["Tveganje"]
        SH["Zgodovina in stanje izdaje"]
    end

    subgraph ExecutionContexts["Zamenljivi izvajalni konteksti"]
        E1["Kontekst PR-ja 1"]
        E2["Kontekst PR-ja 2"]
        E3["Kontekst PR-ja 3"]
    end

    StrategicContext --> E1
    StrategicContext --> E2
    StrategicContext --> E3
    E1 --> REPO["Resnica oddaljenega repozitorija"]
    E2 --> REPO
    E3 --> REPO
    REPO --> StrategicContext

9.2 Zakaj je PR delovna enota

Enota v obsegu PR-ja je:

dovolj velika za izvedbo uporabnega vedenja;
dovolj majhna za pregled in povrnitev;
dovolj omejena za en izvajalni kontekst;
dovolj izrecna za preskušanje;
dovolj vidna za revizijo;
dovolj trajna, da postane del zgodovine projekta.

Ogromna naloga zamegli vzročnost. Drobna naloga z navodili ukaz za ukazom vključi človeka v izvedbo. PR je srednje velika enota vodenja.

9.3 Delovni tok izvajalca

sequenceDiagram
    participant S as Strateška UI
    participant E as Izvajalni agent
    participant R as Repozitorij
    participant C as CI

    S->>E: Aktualen, omejen delovni nalog
    E->>R: Osveži privzeto vejo in ustvari funkcionalno vejo
    E->>E: Preglej, izvedi, preskusi, dokumentiraj
    E->>R: Potrdi in pošlji spremembe
    E->>R: Odpri ali posodobi PR
    R->>C: Sproži preverjanja
    C-->>E: Rezultati
    E->>E: Kjer je mogoče, popravi znotraj obsega
    E->>R: Končna izvedbena potrditev sprememb
    E-->>S: Strukturirano poročilo s PR-jem in dokazi

9.4 Disciplina izvajalca

Izvajalec mora:

upoštevati aktivni obseg;
izključiti nepovezane spremembe;
ohraniti lokalno delo, ki ni njegovo;
razlikovati med trenutnimi dejstvi in predpostavkami;
izvesti določeno preverjanje;
poročati o natančnih izidih;
ne slabiti preskusov ali validacije, da bi ustvaril videz uspeha;
posodobiti dokumentacijo, kadar se vedenje spremeni;
pustiti delo v stanju, primernem za pregled;
v okviru običajnih pristojnosti OAP ne združevati lastnega PR-ja.

9.5 Poročilo o izvedbi je vmesnik

Končno poročilo ni pripovedni okras. Je vmesnik med izvajanjem in strategijo.

Razlikovati mora med:

uspešno;
neuspešno;
izpuščeno;
ni izvedeno;
blokirano;
zunaj obsega.

»Vsi preskusi so uspeli« velja le, če je ustrezni zahtevani nabor dobesedno uspel. »Usmerjeni enotski preskusi so uspeli; integracijski preskusi niso bili izvedeni, ker preskusna storitev ni na voljo« je uporabnejše in poštenejše.

9.6 Predloga poročila o izvedbi

# Poročilo o izvedbi — <identifikator delovnega naloga>

## Rezultat
- COMPLETE / PARTIAL / BLOCKED / FAILED

## Stanje Git
- Veja:
- Izvedbena potrditev sprememb:
- URL PR-ja:
- Osnovna veja in ustrezni vrh:

## Izvedeno
- ...

## Spremenjene datoteke
- `path`: razlog

## Preverjanje
| Ukaz ali preverjanje | Rezultat | Dokaz ali omejitev |
|---|---|---|
| ... | PASS / FAIL / SKIPPED / NOT RUN / BLOCKED | ... |

## Preverjene negativne poti
- ...

## Opravljena lokalna nastavitev
- Paketi, brskalniki, podatkovne zbirke, storitve ali konfiguracija, dodani znotraj izvajalnega okolja.

## Dokumentacija
- Posodobljeno:
- Ni prizadeto:

## Tveganja in nerazrešene zadeve
- ...

## Potrditev obsega
- Spremenjene nepovezane datoteke: NO / pojasni
- Uporabljene produkcijske poverilnice ali podatki: NO / pojasni
- Izpuščena zahtevana preverjanja: NO / natančno naštej

10. Preverjanje kot dokaz

10.1 Preskusi so dokazi, ne obred

Nabor preskusov je koristen le toliko, kolikor podpira podano trditev. Agenti zlahka ustvarijo preskuse, ki potrjujejo njihove lastne izvedbene podrobnosti, spregledajo pa dejansko tveganje.

Za vsako pomembno trditev vprašajte:

Katero opazljivo vedenje jo dokazuje?
Katera negativna pot bi jo ovrgla?
Bi preskus pred spremembo spodletel?
Je nadomestek postavljen na pravo mejo?
Ali preskus preverja avtorizacijo, trajno shranjevanje, obravnavo napak ali sočasnost, kadar prav to predstavlja tveganje?

flowchart LR
    CLAIM["Trditev o vedenju"] --> RISK["Način odpovedi ali zlorabe"]
    RISK --> TEST["Usmerjen preskus"]
    TEST --> RESULT["Opaženi rezultat"]
    RESULT --> EVIDENCE["Dokazi, povezani s PR-jem"]
    EVIDENCE --> DECISION["Odločitev pregleda"]

10.2 Preverjanje, zvesto dejanskim mejam

Uspešen preskus podpira trditev le, če izvaja mejo, na katero se ta trditev nanaša. Preverjanje mora ohraniti pomembne produkcijske lastnosti:

dejansko vstopno točko namesto tovarniške poti samo za preskus;
dejansko pristojnost ali razred poverilnic namesto priročnega nadomestka;
dejansko mejo trajnega shranjevanja, kadar se trditev nanaša na shranjevanje;
dejansko usmerjevalno plast, kadar se trditev nanaša na vedenje na robu;
dejanski mehanizem sočasnosti, povrnitve ali izolacije, kadar je to tveganje;
dejansko integrirano konfiguracijo, kadar se zatrjuje pripravljenost za namestitev.

Nadomestki ostajajo koristni, vendar morajo biti zunaj preskušane meje. Preskus, ki zamenja prav objekt, identiteto ali proces, katerega vedenje zatrjuje, je lahko uspešen, čeprav dokazuje drug sistem.

Zapis iz prakse — Zelena luč ni zadostovala.

Delo na avtentikaciji z zmogljivostnimi žetoni v projektu Agent-Site je bilo sprva videti uspešno. Strateški pregled je eno različico zavrnil, ker je preskus produkcijsko stanje podatkovne zbirke zamenjal s priročnim objektom, ki ga dejanski proces ni uporabljal. Poznejša različica je bila ponovno zavrnjena, ko je pregled pokazal, da bi nameščeni API Agent uporabljal napačno pristojnost podatkovne zbirke in da njegova dejanska vstopna točka modula še vedno zaganja le izvajalnik preverjanja delovanja. Preskusi niso bili lažni; zvesti so bili napačni izvajalni poti.

Operativno pravilo: ne sprašuj le, ali so preskusi zeleni. Vprašaj, ali zeleni preskusi dokazujejo zatrjevani sistem.

10.3 Pozitivni in negativni dokazi

Pozitivni preskus dokaže, da pričakovano vedenje lahko deluje. Negativni preskus dokaže, da je nevarno ali neveljavno vedenje zavrnjeno.

Primeri:

uspešna zahteva in zavrnjena nepooblaščena zahteva;
veljavna migracija in pot povrnitve/napake;
sprejet vhod in zavrnjen prevelik ali nepravilno oblikovan vhod;
posredovanje ponudniku in dokaz, da prepovedane zahteve nikoli ne dosežejo ponudnika;
uspešen izbris in zaščita pred neujemajočo se različico ali konfliktom;
veljavna konfiguracija in zavrnitev nevarne konfiguracije.

10.4 Plasti preverjanja

flowchart TB
    U["Enotski preskusi<br/>lokalna logika"] --> I["Integracijski preskusi<br/>pogodbe komponent"]
    I --> E["Preskusi E2E in brskalniški preskusi<br/>dejanski delovni tokovi"]
    E --> O["Operativni preskusi<br/>varnostna kopija, obnovitev, nadgradnja, povrnitev"]
    O --> A["Revizija in preverjanje izdaje"]

    S["Statična preverjanja<br/>analiza kode, tipi, iskanje skrivnosti in pregled odvisnosti"] --> U
    C["Ponovljivost CI"] --> A

Vsak PR ne potrebuje vsake plasti. Delovni nalog naj določi plast, ki jo zahteva trditev.

10.5 CI je neodvisna ponovitev

Lokalni preskusi so potrebni, vendar ne zadostujejo. CI zagotavlja:

sveže okolje;
dosledne ukaze;
neodvisno izvedbo na poslani potrditvi sprememb;
vidne dnevnike;
povezavo z zaščiteno vejo;
stabilno kontrolno točko združitve.

Pregled mora preveriti končni vrh veje PR-ja, ne zgodnejše zelene potrditve sprememb.

10.6 Neznano ostane neznano

OAP uporablja strogo besedišče dokazov:

stateDiagram-v2
    state "Načrtovano" as Planned
    state "Uspešno" as Passed
    state "Neuspešno" as Failed
    state "Izpuščeno" as Skipped
    state "Ni izvedeno" as NotRun
    state "Blokirano" as Blocked
    [*] --> Planned
    Planned --> Passed: izvedeno in uspešno
    Planned --> Failed: izvedeno in neuspešno
    Planned --> Skipped: namenoma izpuščeno
    Planned --> NotRun: nikoli izvedeno
    Planned --> Blocked: predpogoj ni na voljo

    Skipped --> [*]
    NotRun --> [*]
    Blocked --> [*]
    Passed --> [*]
    Failed --> [*]

Le uspešno podpira pozitivno trditev. Izpuščeno, neizvedeno in blokirano niso nepoštena poročila, vendar tudi niso dokaz.

10.7 Prva meja odpovedi in najmanjši razločevalni poskus

Ko pot od začetka do konca odpove, pred spreminjanjem kode izdelka poiščite prvo mejo, ki dokazljivo odpove. Odpoved nad komponento ni dokaz, da je komponenta pod njo pokvarjena.

flowchart TD
    START["Začetek poti sprejema"] --> B1["Odjemalec ali zaganjalnik"]
    B1 --> B2["Peskovnik ali izvajanje orodja"]
    B2 --> B3["Vmesniški prilagodilnik izdelka"]
    B3 --> B4["Trajno shranjevanje, prevajalnik ali model"]
    B4 --> RESULT["Pričakovano vedenje"]

    B2 -->|prva ponovljiva odpoved| STOP["Ustavi spreminjanje izdelka"]
    STOP --> EXP["Izvedi najmanjši poskus, ki loči okolje od izdelka"]

Strateški agent naj izbere najmanjši poskus, ki razlikuje med verjetnimi hipotezami. Vsak diagnostični nalog potrebuje izrecen pogoj za ustavitev, da raziskovanje ne postane avtonomen raziskovalni projekt brez povezave z mejnikom izdelka.

Zapis iz prakse — Človeški ugovor je ponovno odprl samozavestno diagnozo.

Med ciljem 004 projekta Local Coding je bila neposredna napaka Bubblewrap razložena kot omejitev gostitelja ali jedra. Človek je vprašal: »Če Codex na istem računalniku pri meni deluje, zakaj se ta napaka pri običajni uporabi ne pokaže?« To protislovje je ponovno odprlo razlago. Poznejše popravljalno poročilo je ugotovitev zožilo na: »Prva odpoved je še vedno pred mejo Local Coding.« Odločilen poskus je postal drobna razvejena preverba: izvedi dejansko politiko Codex z neškodljivim ukazom; šele po uspehu preberi natančno odvisnost in nadaljuj upravljani preskus E2E.

Prvotno opažanje je ostalo veljavno. Vzročna razlaga je bila premočna. OAP zato ohranja pravilo: ohrani dokaze; razlago izrecno nadomesti, ko to zahtevajo poznejši dokazi.

10.8 Varnostna preverjanja in preverjanja urejenosti

Varnostno občutljive spremembe lahko zahtevajo določena preverjanja, na primer:

rg -n "api_key|Authorization|Bearer|password|secret|token" app tests docs
git diff --check
python -m pytest tests/unit
ruff check app tests

Natančni ukazi so odvisni od tehnološkega sklada. Načelo je, da so preverjanja ponovljiva in povezana s tveganji.

10.9 Preprečevanje nevarne ustrežljivosti

Agenti lahko poskusijo nalogo »usposobiti« tako, da:

izklopijo neuspešen preskus;
omilijo validacijo;
dodajo preširoko splošno prestrezanje napak;
nadomestek postavijo na napačno mejo;
izpustijo zahtevno integracijsko pot;
uporabijo dejansko storitev, ker je preskusni nadomestek nepriročen;
tiho spremenijo API;
napišejo dokumentacijo, ki zveni bolj dokončano od izvedbe.

Strateški pregledovalec mora takšne bližnjice obravnavati kot pomanjkljivosti dokazov, ne kot iznajdljivost.

11. Resnica oddaljenega repozitorija in trajni spomin

11.1 Izvajalno okolje je začasno; resnica projekta je trajna

OAP temelji na jasni ločitvi:

flowchart TD
    subgraph Disposable["Zamenljivo ali obnovljivo"]
        VM["Izvajalni navidezni stroj"]
        LOCAL["Lokalna delovna kopija"]
        CACHE["Predpomnilniki in ustvarjeno stanje"]
        SESSION["Kontekst agentove seje"]
    end

    subgraph Durable["Trajna resnica projekta"]
        COMMITS["Oddaljene potrditve sprememb"]
        PRS["PR-ji in pregled"]
        CI["Dnevniki in artefakti CI"]
        DOCS["Dokumentacija in operativni priročniki"]
        ISSUES["Prijave težav, odločitve, izdaje"]
    end

    VM --> COMMITS
    LOCAL --> PRS
    SESSION --> DOCS
    CACHE -. ni avtoritativno .-> Durable

Lokalno vejo lahko opustimo. Navidezni stroj lahko ponovno zgradimo. Seja se lahko izgubi. Projekt mora biti kljub temu obnovljiv iz oddaljenih, različicami opremljenih artefaktov.

11.2 Hierarhija resnice

Kadar si viri nasprotujejo, dajte prednost:

trenutnemu oddaljenemu repozitoriju in zaščiteni veji;
trenutni razliki PR-ja in CI na končnem vrhu veje;
trenutni različici arhitekture, ustave, preskusov in dokumentacije;
zgodovini prijav težav in pregledov;
nedavni predaji;
klepetu ali modelovemu spominu.

Predaja, ki pravi, da je PR odprt, je po njegovi združitvi zastarela. Model, ki se spominja stare arhitekture, se moti, če se je sprejeti dokument spremenil.

11.3 Pravilo kontinuitete orkestracije

Vloga OAP je logični udeleženec protokola, ne posamezen proces, model, seja ponudnika, računalnik ali kontekstno okno. Trajno stanje projekta mora novemu procesu omogočiti nadaljevanje iste vloge brez izmišljanja novega dela.

Zato velja:

ponovni zagon procesa  != nov cilj
ponastavitev konteksta != nov cilj
zamenjava modela       != nov cilj
zamenjava ponudnika    != nov cilj
ponovni zagon stroja   != nov cilj

nove strateške zahteve po pregledu
                    = nov popravljalni nalog

Obnovitev se začne z uskladitvijo repozitorija, aktivnega naloga, veje, PR-ja, poročil in CI. Dokončanega poročila ni dovoljeno ponovno izvajati zgolj zato, ker je modelova seja prenehala; nedokončan nalog se mora nadaljevati pri prvi nedokončani zahtevi na isti veji in PR-ju.

flowchart LR
    LOST["Izgubljen proces ali ponudnik"] --> DURABLE["Preberi GitHub in zapis OAP"]
    DURABLE --> STATE{"Končno poročilo že obstaja?"}
    STATE -->|Da| REVIEW["Nadaljuj strateški pregled"]
    STATE -->|Ne| CONTINUE["Nadaljuj isti kodirni nalog"]
    REVIEW --> NEXT["Združitev, popravek ali naslednji cilj"]
    CONTINUE --> SAME["Ista veja in PR"]

Zapis iz prakse — Proces je umrl; delovni nalog ni.

V enem koncu tedna so kodirni procesi prenehali po porabi signalov FIFO, ponudniki so odpovedovali, modeli so bili zamenjani, strateških sej pa ni bilo več mogoče nadaljevati. Uspešno navodilo za obnovitev je bilo jedrnato: »GitHub je resnica programske opreme; datoteke OAP so resnica orkestracije; spomin procesa/seje je zamenljiv.« Novi agenti so obnovili aktivno stanje protokola, namesto da bi ponovno ustvarili dokončane PR-je ali preštevilčili delo samo zato, ker so prejšnji »možgani« izginili.

11.4 Dokumentacija kot operativni spomin

Zrel projekt lahko potrebuje:

README in navodila za hiter začetek;
pregled arhitekture;
varnostni model;
matriko API-jev in združljivosti;
navodila za namestitev in obratovanje;
navodila za preskušanje;
operativne priročnike;
opombe ob izdaji;
arhiv pregledov in revizij;
matriko odprave pomanjkljivosti;
strateške predaje.

Dokumentacija mora slediti vedenju. Če je končna točka delna, je dokumentacija ne sme imenovati popolnoma združljiva. Če obnovitev ni bila preskušena, je operativni priročnik ne sme obljubljati.

11.5 Strateške predaje

Predaje so napisane za naslednjo strateško sejo. Naj bodo jedrnate in povezane z dokazi.

# Predaja projekta

## Trenutna resnica repozitorija
- Privzeta veja in njen vrh:
- Odprti PR-ji:
- Nedavno združeni PR-ji:
- Trenutno stanje CI:

## Izdelek in mejnik
- Cilj:
- Trenutni cilj izdaje:

## Izvedeno
- ...

## Manjkajoče ali blokirano
- ...

## Nespremenljiva pravila
- ...

## Znana tveganja
- ...

## Naslednja priporočena naloga
- ...

## Česa ne naredi naslednje
- ...

flowchart LR
    S1["Strateška seja 1"] --> H["Predaja pod nadzorom različic"]
    H --> VERIFY["Preveri dejanski repozitorij"]
    VERIFY --> S2["Strateška seja 2"]
    S2 --> ORDER["Naslednji delovni nalog"]
    ORDER --> REPO["Dokazi iz repozitorija"]
    REPO --> H2["Posodobljena predaja"]

Predaja zmanjša strošek ponovnega nalaganja konteksta, vendar nikoli ne prevlada nad dejansko resnico repozitorija.

12. Strateški pregled in človeško izpraševanje dokazov

12.1 Pri pregledu OAP postane inženirstvo

Brez resnega pregleda se OAP izrodi v navidezno avtomatizacijo. Izvajalni agent lahko pripravi dovršeno poročilo in zelene usmerjene preskuse, čeprav rešuje napačen problem, posega v preširok obseg ali skriva nepreskušeno mejo.

Strateška UI pregleda:

ujemanje s ciljem;
obseg razlike;
ohranitev arhitekture;
kakovost preskusov;
pokritost negativnih poti;
izpuščena in blokirana preverjanja;
spremembe odvisnosti;
varnost in ravnanje s podatki;
točnost dokumentacije;
vpliv na upravljavca in migracije;
ali je potreben popravek.

12.2 Izpraševanje dokazov

Človek navadno sodeluje prek zgoščenega strateškega gradiva, nato pa po potrebi razišče podrobnosti.

Koristna vprašanja vključujejo:

Ali je PR izvedel natančno zahtevano?
Katere datoteke uveljavljajo invarianto?
Kateri preskus dokazuje ključno vedenje?
Katera negativna pot je bila preskušena?
Kaj ni bilo preskušeno?
Ali je v izvajalno okolje vstopila dejanska poverilnica ali podatek, podoben produkcijskemu?
Ali je agent dodal odvisnost ali migracijo?
Ali dokumentacija pretirava s trditvami?
Zaradi česa bi ta PR zavrnili?
V kaj ste najmanj prepričani?

sequenceDiagram
    participant E as Izvajalni agent
    participant G as GitHub in CI
    participant S as Strateška UI
    participant H as Človeški vodja

    E->>G: PR, potrditve sprememb, poročilo, preskusi
    G-->>S: Razlika, CI na končnem vrhu veje, stanje pregleda
    S->>S: Poveži trditve z dokazi in tveganji
    S->>H: Kratek povzetek za odločanje
    H->>S: Postavi usmerjena kritična vprašanja
    S->>G: Pridobi natančne dokaze
    G-->>S: Datoteke, dnevniki, preverjanja, komentarji
    S->>H: Utemeljen odgovor in priporočilo
    H->>S: Združi, popravi, zavrni ali odloži

12.3 Povzetek za odločanje

## Povzetek za odločanje

**Priporočilo:** MERGE / REPAIR / REJECT / DEFER

### Ujemanje s ciljem
- ...

### Dokazi
- Ukaz za preskus in rezultat:
- Rezultat CI na končnem vrhu veje:
- Ključne datoteke in invariante:
- Spremenjena dokumentacija:

### Obseg
- Pričakovane spremembe:
- Nepričakovane ali nepovezane spremembe:

### Tveganja in negotovost
- ...

### Manjkajoči ali izpuščeni dokazi
- ...

### Potrebna človeška odločitev
- ...

Povzetek naj bo dovolj kratek za hitro branje in dovolj natančen za nadaljnje preverjanje podrobnosti.

12.4 Izidi pregleda

stateDiagram-v2
    state "V pregledu" as UnderReview
    state "Priporočena združitev" as MergeRecommended
    state "Potreben popravek" as RepairRequired
    state "Zavrnitev" as Reject
    state "Odložitev" as Defer
    state "Človeška odločitev" as HumanDecision
    state "Združeno" as Merged
    [*] --> UnderReview
    UnderReview --> MergeRecommended: cilj dosežen in dokazi zadostni
    UnderReview --> RepairRequired: omejene napake ali manjkajoči dokazi
    UnderReview --> Reject: napačna smer ali nesprejemljivo tveganje
    UnderReview --> Defer: čakanje na zunanjo odločitev ali predpogoj
    RepairRequired --> UnderReview: isti PR popravljen in ponovno preverjen
    MergeRecommended --> HumanDecision
    HumanDecision --> Merged: človek odobri
    HumanDecision --> RepairRequired: človek zahteva spremembe
    HumanDecision --> Reject

12.5 Usmerjen človeški pregled

OAP ne prepoveduje človeškega pregleda vrstice za vrstico. Usmeri ga glede na tveganje, namesto da bi bil privzeto ozko grlo.

Poglobljen ročni pregled je primeren za:

avtentikacijo in avtorizacijo;
kriptografijo in pretok poverilnic;
nepovratne spremembe podatkov;
funkcije podatkovne zbirke, ki se izvajajo s pravicami lastnika (SECURITY DEFINER);
migracije in povrnitev;
omrežne meje in meje SSRF;
javno izpostavitev;
sumljive ali pretirano široke razlike;
šibke ali nasprotujoče si dokaze.

13. Revizija in odprava pomanjkljivosti

13.1 Revizija je običajna

Zunanja kritika ni dokaz neuspeha OAP. Je del zrelega OAP, saj imata lahko strateški in izvajalni model skupne slepe pege.

Revizorji so lahko:

drug model;
varnostni pregledovalnik;
pregledovalnik odvisnosti ali licenc;
človeški specialist;
preskusno ogrodje v čistem okolju;
upravljavec, ki izvede svežo namestitev;
ločena ekipa, ki pregleduje trditve ob izdaji.

13.2 Ravni revizije

flowchart TB
    L1["Raven 1<br/>strateški pregled poročila in CI"] --> L2["Raven 2<br/>usmerjen pregled razlike in preskusov"]
    L2 --> L3["Raven 3<br/>neodvisna revizija z modelom ali orodjem"]
    L3 --> L4["Raven 4<br/>pregled človeškega specialista"]
    L4 --> L5["Raven 5<br/>kvalifikacija izdaje v čistem okolju"]

Potrebna raven je odvisna od tveganja, ne od projektne nečimrnosti.

13.3 Matrika odprave pomanjkljivosti

Revizijske ugotovitve naj postanejo sledljivo delo, ne besedilo, ki izgine.

Ugotovitev	Resnost	Dokazi	Nosilec	Potrebno dejanje	Preverjanje	Stanje
Primer	Visoka	Povezava na pregledovalnik/preskus	Strateški agent/kodirni agent/človek	Natančna sprememba	Natančen ukaz/preverjanje	Odprto

13.4 Revizijska zanka

flowchart LR
    BUILD["Izvedeni PR-ji"] --> AUDIT["Neodvisna revizija"]
    AUDIT --> FIND{"Ugotovitve?"}
    FIND -->|Ni pomembnih ugotovitev| READY["Dokazi o pripravljenosti"]
    FIND -->|Da| MATRIX["Matrika odprave pomanjkljivosti"]
    MATRIX --> ORDER["Popravljalni delovni nalogi"]
    ORDER --> PR["Popravljalni PR-ji in CI"]
    PR --> AUDIT

Ugotovitve se zaključijo le z dokazi. »Obravnavano« brez spremenjenega artefakta in preverjanja ni zaključek.

13.5 Neodvisna zaključna revizija

Agent, ki je dolg mejnik načrtoval, izvedel, pregledal in povzel, ne sme biti edina avtoriteta za potrditev njegove dokončanosti. Pred razglasitvijo dokončanosti arhitekturno določenega mejnika, na primer MVP, naj OAP izvede neodvisno zaključno revizijo (Independent Closure Audit, ICA).

Revizija izhaja iz obsega, ki ga določa človek, in sprejete arhitekture, ne iz seznama dokončanih delovnih nalogov:

flowchart TD
    ARCH["Arhitektura in človeška opredelitev mejnika"] --> MATRIX["Matrika po posameznih zahtevah"]
    MAIN["Trenutna združena veja main"] --> MATRIX
    TESTS["Izvedljivi dokazi, zvesti dejanskim mejam"] --> MATRIX
    REPORTS["Poročila agentov in trditve v README"] -. samo trditve .-> MATRIX
    MATRIX --> CLASS{"Izvedeno, delno, odsotno ali nedokazano?"}
    CLASS -->|vrzeli| ORDERS["Novi omejeni zaključni nalogi"]
    ORDERS --> MAIN
    CLASS -->|pokritost dokazana| GATE["Kontrolna točka odločitve o mejniku"]
    MAIN --> REAUDIT["Ponovi ICA po odpravi pomanjkljivosti"]
    REAUDIT --> MATRIX

Zaključna vrsta nalogov ni dokaz, da pokriva arhitekturo. Po njenem dokončanju revizijo ponovite; sicer lahko tudi dobro izveden načrt izpusti zahteve, ki vanj sploh niso bile vključene.

Zapis iz prakse — »Ne zaupajte agentom.«

Med izvajanjem Agent-Site ob koncu tedna je spremljajoča avtonomna dokazna sled dosegla oznako »100 % MVP«. Človek je naročil novo revizijo arhitekture glede na trenutni main z navodilom: »Ne zaupajte agentom.« Kritična revizija je besedila PR-jev, poročila, odstotke v README in povzetke zelenih preverjanj obravnavala kot trditve, dokler jih niso podprle izvorna koda in izvajalne poti. Odkrila je bistvene poti izdelka, ki so bile nadomestne, sintetične ali nepovezane, in neformalno oceno dokončanosti znižala na približno 40 odstotkov. Poznejši zaključni načrt je bil koristen, vendar je pregled nato pokazal, da bi lahko tudi ta izpustil pogodbene cilje za MCP, medije, rekonstrukcijo in vizualne rezultate.

Operativno pravilo: strateški agent lahko priporoči zaključek mejnika, vendar mora mejnik prestati revizijo arhitekture glede na izvedbo, ki ne izhaja iz agentovega lastnega sklepa.

14. Združitev, izdaja in človeška pristojnost

14.1 Združitev in izdaja sta različni odločitvi

PR je lahko pravilen znotraj svojega obsega, ne da bi bil izdelek zaradi tega pripravljen za produkcijo. OAP ločuje:

sprejem spremembe: ali je ta PR dovolj dober za združitev?
pripravljenost za izdajo: ali je integrirani sistem pripravljen za zatrjevano raven in obratovanje na njej?
odobritev namestitve: ali sme sistem preiti v ciljno okolje?

14.2 Kontrolne točke človeške odobritve

Človeška odobritev je navadno potrebna za:

združitev v zaščitene veje;
produkcijsko namestitev;
uničujoče podatkovne operacije;
zamenjavo poverilnic;
javne trditve ob izdaji;
dodajanje tveganih odvisnosti;
širitev omrežnega dostopa;
spreminjanje varnostne zasnove.

Projekti lahko dodajo še kontrolne točke za regulirane podatke, stroškovno izpostavljenost, pravne pogoje ali nepovratne migracije.

flowchart TD
    PR["PR dokončan"] --> REVIEW["Strateški pregled"]
    REVIEW --> CI{"Preverjanja na končnem vrhu veje zelena?"}
    CI -->|Ne| REPAIR["Popravek"]
    REPAIR --> PR
    CI -->|Da| HM{"Človeška odločitev o združitvi"}
    HM -->|Ne| REPAIR
    HM -->|Da| MAIN["Združeno v main"]
    MAIN --> QUAL["Kvalifikacija integrirane izdaje"]
    QUAL --> HR{"Človeška odločitev o izdaji"}
    HR -->|Ni pripravljeno| HARDEN["Utrjevanje in odprava pomanjkljivosti"]
    HARDEN --> QUAL
    HR -->|Pripravljeno| HD{"Človeška odobritev namestitve"}
    HD -->|Da| DEPLOY["Namesti"]

14.3 Pošten jezik pripravljenosti

OAP zavrača napihovanje pripravljenosti:

»izvedeno« ne pomeni nujno »podprto«;
»usmerjeni preskusi so uspeli« ne pomeni »v celoti preskušeno«;
»demonstracija deluje« ne pomeni »produkcijsko pripravljeno«;
»kandidat za izdajo« ne pomeni »varnostno certificirano«;
»ni znanih odpovedi« ne pomeni »preskušeni so vsi načini odpovedi«.

Dokumentacija, opombe ob izdaji in povzetki za odločanje morajo opisovati dejanski obseg.

14.4 Dokazi za izdajo

Resna odločitev o izdaji lahko zahteva:

vsa zahtevana preverjanja CI uspešna na potrditvi sprememb za izdajo;
končno preverjalno ogrodje;
namestitev iz čistega klona;
dokaze o nadgradnji in povrnitvi;
dokaze o varnostnem kopiranju in obnovitvi;
preglede odvisnosti in iskanje skrivnosti;
matriko združljivosti;
seznam nerazrešenih tveganj;
operativne priročnike za upravljavce;
poštene opombe ob izdaji;
pregled topologije namestitve in dostopa.

Človek s pristojnostjo za izdajo presodi, ali ti dokazi zadostujejo za navedeni cilj.

15. Ekonomika konteksta in kontinuiteta

15.1 Strateški kontekst se porablja počasi

Strateški model naj dolgoročno ohranja kontekst o tem:

zakaj sistem obstaja;
katera arhitektura je bila sprejeta;
katera tveganja ostajajo;
kateri PR-ji so spremenili katere zmogljivosti;
kaj pomeni cilj izdaje;
kaj je človek sprejel ali zavrnil.

15.2 Izvajalni kontekst se porablja hitro

Izvajalni agent porablja kontekst za:

vsebino datotek;
izhode ukazov;
razreševanje odvisnosti;
dnevnike;
neuspešne preskuse;
izvedbene iteracije.

To je sprejemljivo, ker je njegov kontekst po eni delovni enoti zamenljiv.

flowchart TD
    S["Strateški kontekst"] --> O1["Delovni nalog 1"]
    S --> O2["Delovni nalog 2"]
    S --> O3["Delovni nalog 3"]

    O1 --> E1["Izvajalčev kontekst 1"]
    O2 --> E2["Izvajalčev kontekst 2"]
    O3 --> E3["Izvajalčev kontekst 3"]

    E1 --> P1["Dokazi PR-ja 1"]
    E2 --> P2["Dokazi PR-ja 2"]
    E3 --> P3["Dokazi PR-ja 3"]

    P1 --> S
    P2 --> S
    P3 --> S

15.3 Pravila ohranjanja konteksta

Za strategijo uporabi najzmogljivejši praktično uporaben model.
Strateški kontekst usmeri v cilje, arhitekturo, stanje in dokaze.
Med nalogami v obsegu PR-ja izvajalni kontekst ponastavi ali zgosti.
Trajne odločitve zapiši v repozitorij.
Pripravi predaje, preden strateški kontekst postane nezanesljiv.
Po vsaki predaji preveri dejansko stanje.
Spomina na klepet ne uporabljaj kot vira resnice.
Strateško trajnost obravnavaj kot logično kontinuiteto vloge, ne kot nesmrtnost enega procesa ali modelovega konteksta.

15.4 Izbira modela

Strateška in izvajalna vloga ne potrebujeta istega modela.

Smiselna razporeditev lahko uporablja:

vrhunski model z dolgim kontekstom in močnim sklepanjem za strategijo;
hitrejši ali cenejši, a sposoben kodirni model za izvajanje;
drugačen model ali pregledovalnik za kritično revizijo.

Vloga določa potrebno zmogljivost.

16. Načini odpovedi in varovala

OAP agentskega razvoja programske opreme ne naredi samodejno pravilnega. Odpovedi naredi bolj obvladljive, vidne in pregledljive.

16.1 Šibek strateški model

Odpoved: samozavestni povzetki spregledajo odmik arhitekture, tveganje ali nerazrešene cilje.
Omilitev: močnejši model, dolg kontekst, izrecne preslikave dokazov, revizija z drugim modelom, trajne predaje.

16.2 Zastarela dejstva in odmik konteksta

Odpoved: nalogi temeljijo na starem stanju PR-jev, starih API-jih ali nadomeščeni arhitekturi.
Omilitev: preverjanje dejanskega stanja repozitorija, aktualne uradne dokumentacije, trenutnega CI in trenutno sprejetih artefaktov.

16.3 Površinski preskusi

Odpoved: preskusi dokazujejo obliko izvedbe namesto zahtevanega vedenja.
Omilitev: negativni preskusi, povezovanje tveganj s preskusi, preskusi, ki pred popravkom odpovejo, kadar je to izvedljivo, pregled nadomestkov.

16.4 Širjenje obsega

Odpoved: izvajalec izvede sosednje funkcionalnosti ali obsežno prestrukturiranje kode.
Omilitev: izrecni necilji, ozki PR-ji, pregled razlik, zavrnitev širokih sprememb.

16.5 Nevarna ustrežljivost

Odpoved: agent oslabi validacijo ali izpusti zahtevno pot, da ustvari uspešen rezultat.
Omilitev: nespremenljiva sprejemna merila, določeni preskusi, strateški nadzor, obvezno poročanje o izpustitvah.

16.6 Obrat smeri nadzora

Odpoved: človek postane izvajalčev nameščevalec odvisnosti in posrednik terminala.
Omilitev: zmogljivejše izvajalno okolje, zadostni privilegiji gostujočega okolja, dokumentirana nastavitev, strateško posredovanje.

16.7 Pretirano bralno breme človeka

Odpoved: človek mora prebrati vsak dnevnik in razliko, zato se ozko grlo ponovno vzpostavi.
Omilitev: kratki povzetki za odločanje, povezave do dokazov, usmerjen pregled, manjši PR-ji.

16.8 Razkritje poverilnic

Odpoved: skrivnosti se pojavijo v pozivih, dnevnikih, potrditvah sprememb, posnetkih zaslona ali telemetriji.
Omilitev: brez produkcijskih skrivnosti v izvajalnem okolju, začasne poverilnice z najmanjšimi potrebnimi privilegiji, iskanje skrivnosti, odstranjevanje občutljivih podatkov, omejeno beleženje.

16.9 Pretirane trditve

Odpoved: delna izvedba je opisana kot dokončana ali produkcijsko pripravljena.
Omilitev: nadzorovano besedišče, pregled dokumentacije, kontrolni seznam izdaje, neodvisna revizija.

16.10 Človeška samozadovoljnost

Odpoved: človek sprejme dovršeno predstavljene dokaze brez presoje.
Omilitev: kritična vprašanja, upočasnitev pri kontrolnih točkah, pregled področij z visokim tveganjem, obravnava združitve in izdaje kot odgovornih človeških odločitev.

flowchart TD
    F["Tveganje agentske odpovedi"] --> B{"Kje jo je treba prestreči?"}
    B --> RUNTIME["Meja izvajalnega okolja<br/>omeji škodo"]
    B --> CONST["Ustava<br/>prepovej vedenje"]
    B --> ORDER["Delovni nalog<br/>omeji obseg"]
    B --> TEST["Preskusi in CI<br/>odkrij napako"]
    B --> REVIEW["Strateški pregled<br/>izprašaj dokaze"]
    B --> HUMAN["Človeška kontrolna točka<br/>prevzemi odgovornost"]

OAP uporablja večplastno obrambo skozi celoten proces predaje, ne vere v en model.

17. Minimalni izvedljivi in zreli OAP

17.1 Minimalni izvedljivi OAP

Majhen, resen projekt lahko izvaja OAP z naslednjim:

enim pogovorom za strateško raziskovanje;
sprejeto obliko izdelka, tehnološkim skladom, mejami zaupanja in obsegom prve izdaje;
projektno ustavo;
enim sposobnim strateškim modelom kot nadzorno ravnino za človeka;
namensko vejo za vsako nalogo;
delovnimi nalogi s ciljem, necilji, preskusi in obliko poročila;
usmerjenim preverjanjem;
predajo prek PR-jev;
kratkim strateškim povzetkom za odločanje;
človeškim izpraševanjem dokazov pred združitvijo;
jedrnato datoteko predaje.

17.2 Zreli OAP

Večji projekt ali projekt z višjim tveganjem doda:

dokumentirano arhitekturno utemeljitev;
večplastne ustave;
namenski izvajalni navidezni stroj ali peskovnik;
visoko avtonomen način znotraj utrjene meje;
odsotnost produkcijskih skrivnosti ali nenadomestljivega stanja;
zaščitene veje in obvezni CI;
ponastavitev izvajalnega konteksta za vsak PR;
varnostne preglede in preglede odvisnosti;
neodvisno revizijo z modelom ali človekom;
operativne priročnike;
ocenjevanje pripravljenosti za izdajo;
končno preverjalno ogrodje;
arhivirane ugotovitve in dokaze o odpravi pomanjkljivosti.

flowchart LR
    L1["Raven 1<br/>raziskovanje in ustava"] --> L2["Raven 2<br/>izvajanje v obsegu PR-ja in poročila"]
    L2 --> L3["Raven 3<br/>omejena visoka avtonomija in CI"]
    L3 --> L4["Raven 4<br/>neodvisna revizija in operativni priročniki"]
    L4 --> L5["Raven 5<br/>kvalifikacija izdaje in operativni dokazi"]

Zrelosti ne merimo po tem, kako avtonomni so agenti videti. Merimo jo po tem, kako jasno so upravljani pristojnosti, dokazi, obnovitev in izdaja.

18. Uvajanje v ekipo in delovni ritem

18.1 Začnite z delom z nizkim tveganjem

Ekipe naj začnejo z:

izboljšavami dokumentacije;
dodajanjem preskusov;
manjšimi popravki napak;
prestrukturiranjem kode, zaščitenim s preskusi;
notranjimi orodji.

Na razvoj funkcionalnosti naj preidejo, ko zaupajo:

kakovosti ustave;
natančnosti delovnih nalogov;
izolaciji izvajalnega okolja;
kakovosti strateškega pregleda;
povzetkom za odločanje;
pokritosti s CI;
postopkom obnovitve.

18.2 Praktičen delovni ritem

flowchart LR
    PLAN["Človeško in strateško načrtovanje"] --> ORDER["Delovni nalog"]
    ORDER --> EXEC["Izvajanje agenta"]
    EXEC --> PR["PR in CI"]
    PR --> REVIEW["Strateški pregled"]
    REVIEW --> HUMAN["Človeška odločitev"]
    HUMAN -->|popravek| ORDER
    HUMAN -->|združitev| NEXT["Naslednji cilj"]
    NEXT --> PLAN

Človek lahko med začetnim uvajanjem sodeluje pogosto, pozneje, ko procesu zaupa, pa manj pogosto. Bistveno je, da ostane na ravni vodenja in sprejema, ne da bi bilo zahtevano določeno število človeških sporočil.

18.3 Metrike, ki jih je vredno spremljati

Koristne operativne meritve vključujejo:

trajanje cikla PR-ja;
število popravljalnih krogov na PR;
vzroke neuspehov CI;
napake, ki so ušle preverjanju;
delež izpuščenih ali blokiranih preverjanj;
čas človeškega pregleda;
primere širjenja obsega;
čas ponovne gradnje okolja;
ugotovitve o odmiku dokumentacije;
revizijske ugotovitve na izdajo;
čas od domenske zahteve do združitve, podprte z dokazi.

Metrike naj izboljšujejo upravljanje, ne nagrajujejo agentov za ustvarjanje več kode.

Napredek je treba obravnavati kot vektor, ne kot en sam privlačen odstotek:

Os	Vprašanje
Funkcionalna dokončanost	Katera nova zmogljivost, vidna uporabniku ali sistemu, zdaj deluje?
Zaupanje v dokaze	Katera pomembna trditev je zdaj dokazana na pravi meji?
Zmanjšanje negotovosti	Kateri verjetni vzroki ali tveganja so bili izključeni?
Zmanjšanje tehničnega dolga in napadalne površine	Katera nepotrebna zapletenost ali nevarni mehanizmi so bili odstranjeni?
Širina zmogljivosti	Je platforma dobila novo zmogljivost po MVP, ne da bi se prvotni mejnik spremenil?

Diagnostično delo ne postane funkcionalna dokončanost zato, ker je bilo zahtevno. Dokumentacija ne postane izvedba. Razširitev po MVP za nazaj ne poveča dokončanosti prvotnega MVP.

Zapis iz prakse — Nič točk za funkcionalnosti, velik napredek.

Krog Local Coding 004-k namenoma ni dodal skoraj nobene funkcionalnosti MVP. Iz nameščenega produkcijskega paketa je odstranil približno 3.400 vrstic diagnostičnih mehanizmov E2E, ohranjena pomožna orodja premaknil v preskusno mejo, zmanjšal podvajanje diagnostične kode ter utrdil ravnanje z okoljem podprocesov in poverilnicami. Poštena ocena je bila: pridobitev funkcionalnosti izdelka približno nič; izboljšanje kakovosti kode ter zmanjšanje napadalne površine in tehničnega dolga veliko.

Zahteven krog je lahko vreden truda, ne da bi ga šteli kot funkcionalnost.

19. Celoten življenjski cikel OAP

sequenceDiagram
    participant H as Človeški vodja
    participant S as Strateška UI
    participant A as Izvajalni agent
    participant R as Oddaljeni repozitorij
    participant C as CI in pregledovalniki
    participant X as Neodvisna revizija

    H->>S: Domenski problem, omejitve, pripravljenost za prevzemanje tveganj
    S->>H: Arhitekturne možnosti in obseg izdaje
    H->>S: Sprejmi ali preusmeri
    S->>R: Ustava, arhitektura, razvojni načrt

    loop En cilj v obsegu PR-ja naenkrat
        S->>R: Preveri trenutno resnico repozitorija
        S->>A: Omejen delovni nalog
        A->>A: Preglej, izvedi, preskusi, dokumentiraj
        A->>R: Veja, potrditve sprememb, PR, poročilo o izvedbi
        R->>C: Izvedi zahtevana preverjanja
        C-->>S: Dokazi na končnem vrhu veje
        S->>R: Preglej razliko, poročilo, komentarje in CI
        alt Potreben popravek
            S->>A: Ozek popravljalni nalog na istem PR-ju
        else Dokazi zadostujejo
            S->>H: Povzetek za odločanje in priporočilo
            H->>R: Odobri združitev ali zavrni/odloži
        end
    end

    R->>X: Kandidat za izdajo in dokazi
    X-->>S: Ugotovitve
    S->>H: Povzetek pripravljenosti za izdajo
    H->>R: Odobri izdajo/namestitev ali zahtevaj utrjevanje

Življenjski cikel oblikuje hierarhijo zgoščevanja:

izvajalec izvedbo zgosti v strukturirano poročilo;
repozitorij in CI ohranita natančne dokaze;
strateška UI dokaze zgosti v povzetek za odločanje;
človek podrobneje razišče le dele, potrebne za presojo.

flowchart LR
    DETAIL["Datoteke, dnevniki, ukazi, preskusi"] --> REPORT["Poročilo o izvedbi"]
    REPORT --> REVIEW["Strateška preslikava dokazov"]
    REVIEW --> BRIEF["Povzetek za odločanje"]
    BRIEF --> JUDGMENT["Človeška presoja"]
    JUDGMENT --> DRILL["Usmerjeno raziskovanje podrobnosti po potrebi"]
    DRILL --> DETAIL

Tako OAP zmanjša človeško delo, ne da bi zmanjšal človeško pristojnost.

20. Praktična doktrina

OAP lahko povzamemo v dvaindvajsetih pravilih:

Človek se premakne na višjo raven. Njegova vrednost se s tipkanja premakne k namenu, tveganju, dokazom in izdaji.
Najboljši človeški vodja je lahko domenski strokovnjak. Resnica izdelka je pomembnejša od hitrosti tipkanja.
Začni s strateškim raziskovanjem. Pred širšim kodiranjem določi, kakšen sistem naj obstaja.
Človek določa namen. Pomena izdelka ni mogoče prenesti na zunanjega izvajalca.
Človek je odgovoren za tveganje. Model ne more prevzeti odgovornosti organizacije.
Človek je pristojen za izdajo. Agenti pripravljenosti ne razglašajo na podlagi lastne pristojnosti.
Človek dela s kratkim gradivom za odločanje. Zgosti podrobnosti, ne da bi skril dokaze.
Strateška UI je nadzorna ravnina. Uporabi jo za arhitekturo, spomin, delovne naloge, kritiko in sintezo dokazov.
Izvajalni agent je zamenljiva izvedbena delovna sila. Njegov kontekst naj praviloma traja eno nalogo v obsegu PR-ja.
Strategija in izvajanje sta ločena. Načrtovanje in spreminjanje repozitorija sta različni vlogi.
Ustava upravlja delo. Trajna projektna pravila so pomembnejša od ponavljajočih se opomnikov.
Avtonomija deluje znotraj obnovljive meje. Zmogljivost je sprejemljiva le tam, kjer je odpoved preživljiva.
Oddaljeni repozitorij je resnica. Lokalno izvajalno okolje in spomin na klepet sta zamenljiva.
PR je delovna enota. Delo mora biti pregledljivo, povratno in podprto z dokazi.
Necilji so varnostna orodja. Izrecno povej, česa ne narediti.
Preskusi so dokazi, ne obred. Preverjanje uskladi s trditvami in tveganji.
Izpuščeno ni uspešno. Neznano ostane neznano.
Dokumentacija je del artefakta. Vedenje in trditve morajo ostati usklajeni.
Revizija je običajna. Neodvisna kritika je del inženirstva.
Jezik izdaje mora biti pošten. Beta, RC, pilot in produkcija so različne trditve.
Hitrost ne sme prehiteti presoje. Hitrejša izvedba povečuje odgovornost za validacijo.
Nikoli ne dovoli, da agent vodi človeka. Kadar se nizkonivojsko delo prenaša navzgor, preoblikuj izvajalno okolje ali orkestracijo.

Izvajanje v praksi tem temeljnim pravilom dodaja sedem praktičnih varoval:

Vsak delovni nalog ima izvor. Človeški namen, arhitektura, dokazi, revizija ali odprava pomanjkljivosti morajo pojasniti, zakaj delo obstaja.
Zeleni preskusi morajo dokazovati navedeno mejo. Preskus nadomestnega izvajalnega okolja ne more potrditi produkcijskega vedenja.
Poišči prvo mejo odpovedi. Ne spreminjaj komponente, ki je pot odpovedi še ni dosegla.
Uporabi najmanjši razločevalni poskus. Razširjanje diagnoze ustavi takoj, ko razločiš hipoteze.
Vloga preživi svoj proces. Po odpovedi modela, ponudnika ali računalnika isti cilj obnovi iz trajne resnice.
Ohrani opažanja in nadomesti razlage. Zgodovine ne prepisuj, da bi bil proces videti nezmotljiv.
Mejniki zahtevajo neodvisno zaključno revizijo. Dokončanje strateške vrste nalogov se ne potrdi samo.

mindmap
  root((OAP))
    Človeška pristojnost
      Namen
      Tveganje
      Sprejem
      Izdaja
    Strateška nadzorna ravnina
      Raziskovanje
      Arhitektura
      Ustava
      Delovni nalogi
      Pregled
    Izvajalna ravnina
      Izvedi
      Preskusi
      Dokumentiraj
      PR
    Trajna resnica
      Repozitorij
      CI
      Poročila
      Predaje
    Varnost
      Omejeno izvajalno okolje
      Necilji
      Negativni preskusi
      Človeške kontrolne točke

21. Sklep

Orkestrirano agentsko programiranje je metoda vodenja razvoja programske opreme v razmerah, ko agenti UI lahko opravijo obsežno izvedbeno delo, vendar še vedno potrebujejo upravljanje, omejevanje, dokaze in odgovorno presojo.

Njegova osrednja novost ni posamezno orodje, temveč povezava:

strateškega raziskovanja pred izvedbo;
strateške nadzorne ravnine, s katero sodeluje človek;
strojno berljive ustave;
omejenega visoko avtonomnega izvajalnega okolja;
delegiranja v obsegu PR-ja in zamenljivih izvajalnih kontekstov;
resnice oddaljenega repozitorija;
izrecnih dokazov in preskušanja negativnih poti;
strukturiranih poročil in strateškega pregleda;
človeške pristojnosti na kontrolnih točkah združitve, izdaje in namestitve.

OAP ljudi ne odstrani iz programskega inženirstva. Premakne jih v pomembnejšo vlogo. Človek postane manj upravljavec terminala in bolj nosilec izdelka, domenski strokovnjak, nosilec tveganja, izpraševalec dokazov in avtoriteta za izdajo.

Izvajalni agent je najkoristnejši, kadar lahko hitro dela znotraj meje, katere izgubo si projekt lahko privošči. Strateška UI je najkoristnejša, kadar ohranja dolgoročni namen, ga pretvarja v omejeno delo in kritično presoja dokaze izvajanja. Repozitorij je najkoristnejši, kadar ohranja natančno, pregledljivo resnico. Človek je najkoristnejši, kadar pozornost nameni vprašanjem, za katera stroji v imenu organizacije ne morejo odgovorno odločati.

Metodo zato lahko izrazimo z enim stavkom:

OAP prenese izvedbeno delo, ne prenese pa pomena izdelka, odgovornosti za tveganje ali odgovornosti za izdajo.

Nadaljujte na drugo poglavje

Nadaljujte s koncentriranim orkestriranim agentskim programiranjem, naprednim načinom dela, ki temelji na vnaprejšnjem vlaganju človeškega dela (Human Work Preloading, HWP), naknadni človeški presoji (Human Judgment Postloading, HJP), odloženem človeškem razsojanju (Deferred Human Adjudication, DHA) in neodvisni zaključni reviziji (Independent Closure Audit, ICA).

Dodatek A: Minimalna predloga projektne ustave

# Projektna ustava

## Namen
- Čemu je projekt namenjen.
- Čemu ni namenjen.

## Vir resnice
- Oddaljeni repozitorij, zaščitena veja, PR, CI in dokumenti pod nadzorom različic.
- Dejanska resnica repozitorija prevlada nad spominom na klepet in zastarelimi predajami.

## Arhitekturna pravila
- Komponente in meje zaupanja.
- Nespremenljive invariante.
- Kanonični arhitekturni dokumenti.

## Meje vlog
- Človeška pristojnost.
- Odgovornosti strateškega agenta.
- Odgovornosti izvajalnega agenta.
- Pristojnost za združitev in izdajo.

## Delovni tok repozitorija
- Pravila vej.
- Obveznost PR-ja.
- Pravila potrjevanja sprememb in obsega.
- Brez neposrednega spreminjanja zaščitenih vej.

## Preverjanje
- Obvezni preskusi, statična analiza, preverjanje tipov, gradnje, varnosti in dokumentacije.
- Izpuščeno/neizvedeno/blokirano se nikoli ne poroča kot uspešno.

## Varnost in podatki
- Prepovedane poverilnice in podatki.
- Dovoljeni preskusni pripomočki.
- Omrežna politika in politika odvisnosti.
- Kontrolne točke uničujočih operacij.

## Dokumentacija
- Spremembe vedenja zahtevajo posodobitve pogodb.
- Ne pretiravaj s trditvami o pripravljenosti.

## Poročanje
- Natančna struktura in besedišče poročila o izvedbi.

## Opredelitev dokončanosti
- Izvedba končana.
- Zahtevani preskusi in CI zeleni.
- Dokumentacija usklajena.
- PR primeren za pregled.
- Tveganja in manjkajoči dokazi izrecno navedeni.

Dodatek B: Kontrolni seznam kakovosti delovnega naloga

Dodatek C: Kontrolni seznam kakovosti poročila o izvedbi

Dodatek D: Predloga strateškega povzetka za odločanje

# Povzetek za odločanje — <PR ali cilj>

## Priporočilo
MERGE / REPAIR / REJECT / DEFER

## Ujemanje s ciljem
- Kaj naj bi sprememba dosegla.
- Ali je dosegla natanko ta cilj.

## Dokazi
- Potrditev sprememb na končnem vrhu veje:
- Zahtevani CI:
- Usmerjeni preskusi:
- Negativni preskusi:
- Ključne datoteke, ki uveljavljajo zahteve:
- Dokumentacija:

## Pregled obsega
- Pričakovane spremembe:
- Nepričakovane spremembe:
- Odvisnosti ali migracije:

## Pregled tveganj
- Varnost:
- Celovitost podatkov:
- Zasebnost:
- Obratovanje:
- Združljivost:

## Manjkajoči dokazi
- Izpuščeno:
- Ni izvedeno:
- Blokirano:

## Človeška odločitev
- Natančno vprašanje odobritve ali politike, če obstaja.

Dodatek E: Kontrolni seznam visoko avtonomnega izvajalnega okolja

Dodatek F: Terminologija

Izraz	Pomen
OAP	Orkestracija strateške UI in visoko avtonomnega izvajalnega agenta pod človeškim upravljanjem za predajo programske opreme, pripravljene za pregled.
Človeški vodja	Nosilec namena, domenske resnice, pripravljenosti za prevzemanje tveganj, sprejema in pristojnosti za izdajo.
Strateška UI	Arhitekt, načrtovalec, spominska plast, avtor delovnih nalogov, kritik in prvi pregledovalec.
Izvajalni agent	Omejen agent za izvedbo, ki upravlja repozitorij in računalniško okolje.
Projektna ustava	Strojno berljiva projektna pravila pod nadzorom različic, ki jih podedujejo delovni nalogi.
Delovni nalog	Strateška izvedbena pogodba v obsegu PR-ja, ki vsebuje obseg, necilje ter zahteve glede preverjanja, delovnega toka in poročanja.
Poročilo o izvedbi	Strukturiran dokazni vmesnik od izvajalnega agenta do strateške plasti.
Povzetek za odločanje	Zgoščeno strateško priporočilo, povezano z natančnimi dokazi repozitorija in CI.
Resnica oddaljenega repozitorija	Načelo, da potrditve sprememb, PR-ji, CI, dokumentacija in zgodovina pregledov prevladajo nad lokalnim izvajalnim okoljem in modelovim spominom.
Omejena visoka avtonomija	Močna izvedbena zmogljivost znotraj okolja, katerega izgubo ali kompromitacijo je mogoče preživeti.
Dolg validacije	Nedokazane trditve o vedenju, varnosti, obratovanju ali pripravljenosti, ki se kopičijo hitreje, kot se preverjajo.
Obrat smeri nadzora	Stanje odpovedi, v katerem izvajalni agent človeka zaposli za rutinske nizkonivojske operacije.
Delegiranje v obsegu PR-ja	Ena pregledljiva, preskušljiva in povratna delovna enota na izvajalni kontekst.
Izvor delovnega naloga	Trajen razlog, ki cilj poveže s človeškim namenom, arhitekturo, opaženimi dokazi, neodvisno revizijo ali odpravo pomanjkljivosti.
Vektor napredka	Ločeno spremljanje funkcionalne dokončanosti, zaupanja v dokaze, zmanjšanja negotovosti, zmanjšanja dolga in širine zmogljivosti.
Človeška kontrolna točka	Izrecna točka človeške pristojnosti za združitev, izdajo, namestitev, uničujoče dejanje ali spremembo varnostne zasnove.
Preverjanje, zvesto dejanskim mejam	Dokazi, ki izvajajo dejansko pristojnost, vstopno točko, trajno shranjevanje, usmerjanje ali namestitveno mejo, navedeno v trditvi.
Pravilo kontinuitete orkestracije	Načelo, da logična vloga OAP in aktivni cilj preživita zamenjavo procesa, modela, ponudnika ali konteksta.
Prva meja odpovedi	Najzgodnejša ponovljiva točka odpovedi na poti sprejema; spreminjanje izdelka pod to mejo ni upravičeno.
Neodvisna zaključna revizija (ICA)	Revizija arhitekture glede na trenutni main, izvedena brez zaupanja v lastno pripoved strateškega agenta o dokončanosti.

Viri

Janez Perš, Orchestrated Agentic Programming Manual (EN), Version 1.0.1, 2026.
SLAIF weekend OAP field transcripts: Agent-Site reaches MVP complete, izvoženo 23. avgusta 2026.
SLAIF weekend OAP field transcripts: API Gateway nears SLAIF MVP completion, izvoženo 23. avgusta 2026.
SLAIF weekend OAP field transcripts: Context compaction strategy and agent recovery branches, izvoženo 23. avgusta 2026.