Jegyek és delegálás

A jegy a munka egysége, amelyet a Control Center nyomon követ. Szándékosan egy buta artefaktum: cím, törzs, állapot, tulajdonos és egy hely a fában. Nem az a dolog, amin az ügynökök végrehajtódnak — az ügynökmunka a beszélgetésekben él, egy futtatás strukturált kimenete pedig a futtatási naplóban.

A hozzárendelés tulajdonjogot rögzít; semmit nem indít el

Ez az egyetlen legfontosabb dolog, amit a jegyekről helyesen kell érteni.

Az assignedAgentId beállítása kiír egy mezőt, és közzétesz egy TicketAssigned domaineseményt. Ez az esemény audit- és értesítési jelzés, valamint pipeline-eseményindító. Az ügynökhöz rendelés nem indít futtatást. Nincs olyan jegykiosztó, amely az assignedAgentId mezőt figyelné, és felébresztené azt az ügynököt.

A kivétel a csapat: amikor az assignedTeamId be van állítva, a TeamRoutingService kiosztja a csapatvezetőt az üzemeltetési protokollal és a névsorral.

Ha azt szeretné, hogy egy adott ügynök dolgozzon egy jegyen, arra egy beszélgetésben kéri meg, vagy egy pipeline-lépés osztja ki rá, vagy egy másik ügynök delegál neki. A jegy ügynökhöz rendelése és a várakozás az az egyetlen dolog, amely soha nem eredményez munkát.

Tükör és fedvény

Egy jegy lehet tisztán helyi, vagy állhat mögötte külső követőrendszer, és mindkettőt egyetlen soron hordozza.

A tükör — szolgáltató, külső kulcs, URL, cím, leírás, prioritás, címkék, nyers és normalizált állapot, időbélyegek — gyorsítótár, amikor a jegy távoli. Ilyenkor a távoli a hiteles forrás, és egy frissítés teljes egészében újraírja a tükröt.

A fedvény — hozzárendelés, delegálás, térkapcsolat, szülő, projekt, kapcsolt PR-ek — csak a Control Centerben létezik. A követőrendszer semmit nem tud róla, és egy frissítés soha nem nyúl hozzá.

Ez a szétválasztás teszi egyáltalán biztonságossá a szinkronizálást: egy szállítói szinkronizálás tönkreteheti a tükröt anélkül, hogy valaha elvesznének a fölé épült orchestrációs metaadatok.

Az életciklus-gráf az ügynököket köti, nem Önt

Az állapotok így futnak: backlog → open → inProgress → inReview → done, a blocked egy mellékág, a failed / cancelled pedig a többi végállapot.

Az átmenetgráf csak az ügynök- és automatizálási úton érvényesül — MCP-eszközökön és reconcilereken. Egy szabálytalan átmenet ott csak naplózódik és figyelmen kívül marad, így egy zavart ügynök nem léptetheti visszafelé a jegyet egy végállapotból.

A felületen minden felhasználói módosítás force: true értéket ad át, és teljesen megkerüli a gráfot. Egy ember a jegyet bármelyik állapotba átmozgathatja, amelyet a választó felsorol — beleértve egy végállapot újranyitását is. A választó nem kínálja a failed állapotot; azt az ügynökök a fail_ticket hívással állítják be. A gráf az automatizálás védőkorlátja, nem pedig szabály arról, hogyan haladhat a munka.

A TicketWorkflowService minden módosítást egyetlen szűk keresztmetszeten keresztül birtokol: betölti a sort, ellenőrzi, hogy a hívó munkaterületéhez tartozik, és a várt version értékkel ír, így két párhuzamos szerkesztés nem írhatja felül csendben egymást.

A teljes állapottáblázatért, az átmenetekért, a mezőlistáért és a kapcsolattípusokért lásd a Jegyéletciklus oldalt.

Eredet: hogyan jött létre egy jegy

Minden jegynek van egy originKind értéke. Az enumnak öt értéke van — manual, pipelineStep, agentDelegation, externalSync, recovery —, de ma csak kettő íródik: a manual (ez az alapértelmezett a createTicket hívásnál, a delegált gyermekeket is beleértve) és az externalSync (a szinkronizálómotor, szállítói szinkronizáláskor). A TicketWorkflowService.createTicket nem vesz át eredetargumentumot, így a pipelineStep, az agentDelegation és a recovery soha nem kerül rá egy sorra sem.

Védett delegálás

A delegálás az, ahol az egyik ügynök munkát hoz létre egy másiknak, és itt szivároghat ki a jogosultság, ezért az őrök a prompt utasításai helyett a szerveroldalon, egyetlen szűk keresztmetszetnél élnek.

A delegate_task a TicketWorkflowService.delegateGuarded metóduson keresztül halad, amely a szülőláncból kiszámítja a gyermek mélységét és gyökerét, majd lefuttatja mind a négy DelegationGuards ellenőrzést: egy ugrást, amely túllépné a 3-as mélységkorlátot; egy visszaugrást olyan ügynökhöz, aki már benne van a láncban (ciklusdetektálás); egy autonómiaplafont (a delegált térbeli effektív szintje nem haladhatja meg a delegálóét); és egy költségvetési keretet (a delegálás a delegáló fennmaradó hard-stop költségvetését terheli, és nem hozhat létre többet). Az éles összekötés mindkét feloldó portot biztosítja. Az autonómia és a költségvetés ellenőrzése kimarad, ha a from_agent_id hiányzik (a korlátlan, illetve szabályzat nélküli költségvetés is átmegy). Az elutasítás DelegationRefusedException kivételként dobódik, amelynek üzenete szó szerint eljut a delegáló ügynökhöz — hangos elutasítás, soha nem néma, hatás nélküli művelet.

A delegate_ticket a régebbi, őrizetlen testvér: közvetlenül a createTicket metódust hívja, és minden őrt kihagy. Részesítse előnyben a delegate_task eszközt.

Ne keverje össze a delegálás mélységkorlátját (3, a delegate_task láncokon) a beépített harness alügynök-beágyazási korlátjával (2). Ezek különböző mechanizmusok különböző korlátai.

Hierarchia, kapcsolatok és projektek

A szülő- és gyermekjegy-kapcsolatok a tickets.parent_ticket_id mezőn élnek, amelyet a setParent / clearParent birtokol. Ezek nem ticket_links sorok, így mindennek, ami egy jegy kapcsolatait olvassa, mindkét forrást össze kell vonnia.

A ticket_links az egyébként független jegyek közötti irányított éleket tartalmazza:

Kapcsolattípus	Jelentés
blocks	A forrás blokkolja a célt
relatesTo	A két jegy kapcsolatban áll egymással (szimmetrikus)
duplicateOf	A forrás a cél duplikátuma

A projekt a jegyek munkaterületre kiterjedő csoportosítása egy közös cél felé. A projektek csak a Control Centerben léteznek, és soha nem szinkronizálódnak külső szolgáltatóhoz.

Közreműködők

A TicketCollaborator sorokkal kapcsolódik egynél több szereplő egy jegyhez, assignee, collaborator vagy reviewer szerepkörben. Az emberek és az ügynökök egyenrangú sorok — egy principalId és egy collaboratorType —, nincs „a felhasználó” jelentésű kitüntetett érték, és nincs idegen kulcs egyik táblához sem.

Külső szinkronizálás

A Control Center jegye az elsődleges. Egy jegy törlése csak helyben történik, így egy szállító által támogatott jegy, amelyet töröl, nem törlődik a követőrendszerben, és a következő szinkronizáláskor újra megjelenhet. A közreműködők és a gyermekjegyek kaszkádolódnak.

Az adapter hitelesítő adatai a szerver hitelesítőadattáraiból oldódnak fel (a Beállításokban beillesztett Linear-kulcsot vagy GitHub-tokent a következő kérés veszi fel; a környezet csak kezdeti értékkel tölti fel ezeket a tárakat).

Jegyek és pipeline-ok

Egyetlen pipeline-csomópont sem hoz létre, fejez be vagy szakít meg jegyeket — a palettán nincs ilyen lépés, és a motor nem hívja a TicketWorkflowService metódusait. Egy pipeline-eseményindító azonban továbbra is tüzelhet TicketAssigned, TicketCompleted, TicketFailed vagy TicketCancelled eseményre (ez a négy az a jegyesemény, amelyet az EventPayloadMapper valóban leképez). A jegyen nincs pipelineRunId oszlop; a pipeline-hoz kapcsolódás az ügynök futtatási naplójában él.

Lásd még

• Pipeline-ok és automatizálás: a jegyesemények pipeline-t indíthatnak
• Orchestráció: honnan származik a gyermekjegyek DAG-ja
• Az ügynökmodell: kihez van hozzárendelve egy jegy
• Domainesemények: a jegy életciklus-eseményei
• Jegyéletciklus: állapotok, mezők, átmenetek, kapcsolatok
• Jegyek létrehozása és kezelése
• Munka delegálása ügynököknek
• Munka szervezése projektekkel