Saker og delegering

En sak er arbeidsenheten Control Center sporer. Den er med vilje et dumt artefakt: en tittel, en beskrivelse, en status, en eier og en plass i et tre. Den er ikke det agentene utfører arbeid mot — agentarbeid lever i samtaler, og den strukturerte utdataen fra en kjøring ligger i kjøreloggen.

Tildeling registrerer eierskap; den sender ikke ut noe

Dette er det ene punktet det er viktigst å få riktig når det gjelder saker.

Å sette assignedAgentId skriver et felt og publiserer en TicketAssigned- domenehendelse. Den hendelsen er et revisjons- og varslingssignal og en pipeline-utløser. Tildeling til en agent starter ingen kjøring. Det finnes ingen utsender for saker som overvåker assignedAgentId og vekker den agenten.

Unntaket er et team: når assignedTeamId er satt, sender TeamRoutingService ut teamlederen med driftsprotokollen og medlemsoversikten.

Hvis du vil at en bestemt agent skal jobbe med en sak, ber du den om det i en samtale, eller et pipeline-steg sender den ut, eller en annen agent delegerer til den. Å tildele en sak til en agent og vente, er det ene som aldri vil føre til arbeid.

Speil og overlegg

En sak kan være rent lokal eller støttet av et eksternt oppfølgingssystem, og den bærer begge på én rad.

Speilet — leverandør, ekstern nøkkel, URL, tittel, beskrivelse, prioritet, etiketter, rå og normalisert status, tidsstempler — er en hurtigbuffer når saken er ekstern. Den eksterne kilden er sannheten der, og en oppdatering skriver speilet på nytt i sin helhet.

Overlegget — tildeling, delegering, områdekobling, overordnet, prosjekt, koblede PR-er — finnes bare i Control Center. Oppfølgingssystemet vet ingenting om det, og en oppdatering rører det aldri.

Det er den todelingen som gjør synkronisering trygt i det hele tatt: en leverandørhenting kan være destruktiv mot speilet uten å miste orkestreringsmetadataen som er lagt oppå.

Livssyklusgrafen binder agenter, ikke deg

Statussene går backlog → open → inProgress → inReview → done, med blocked som en sideløkke og failed / cancelled som de andre sluttilstandene.

Overgangsgrafen håndheves bare på agent- og automatiseringsbanen — MCP-verktøy og avstemmere. En ulovlig overgang der logges og ignoreres, slik at en forvirret agent ikke kan gå en sak baklengs ut av en sluttilstand.

Enhver brukerstyrt endring i brukergrensesnittet sender force: true og omgår grafen helt. Et menneske kan flytte en sak til hvilken som helst status velgeren lister opp — også gjenåpne en sluttilstand. Velgeren tilbyr ikke failed; agenter setter den via fail_ticket. Grafen er et rekkverk for automatisering, ikke en regel om hvordan arbeidet får gå.

TicketWorkflowService eier enhver endring gjennom ett enkelt knutepunkt som laster raden, bekrefter at den tilhører den kallendes arbeidsområde og skriver med en forventet version, slik at to samtidige redigeringer ikke kan overskrive hverandre i stillhet.

For hele statustabellen, overganger, feltlisten og relasjonstypene, se Livssyklus for saker.

Opphav: hvordan en sak ble til

Enhver sak har en originKind. Enumen har fem verdier — manual, pipelineStep, agentDelegation, externalSync, recovery — men bare to skrives i dag: manual (standarden på createTicket, også for delegerte barn) og externalSync (synkroniseringsmotoren, ved en leverandørhenting). TicketWorkflowService.createTicket tar ikke et opphavsargument, så pipelineStep, agentDelegation og recovery havner aldri på en rad.

Beskyttet delegering

Delegering er der en agent skaper arbeid for en annen agent, og det er stedet der privilegier kan lekke, så beskyttelsene ligger på serversiden ved et knutepunkt i stedet for i promptinstruksjoner.

delegate_task går gjennom TicketWorkflowService.delegateGuarded, som beregner barnets dybde og rot fra foreldrekjeden og deretter kjører alle de fire DelegationGuards-kontrollene: et hopp som ville overskride et dybdemaksimum på 3, et hopp tilbake til en agent som allerede er i kjeden (syklusdeteksjon), et autonomitak (delegatens effektive nivå i området må ikke overskride delegatorens) og en budsjettramme (delegering belaster delegatorens gjenværende hardstopp-budsjett og kan ikke lage mer). Produksjonsoppkoblingen leverer begge resolverportene. Autonomi og budsjett hoppes over når from_agent_id er utelatt (ubegrenset / budsjett uten policy går også gjennom). En avvisning kastes som en DelegationRefusedException der meldingen når den delegerende agenten ordrett — en høylytt nektelse, aldri en stille no-op.

delegate_ticket er den eldre, ubeskyttede søsteren: den kaller createTicket direkte og hopper over hver eneste beskyttelse. Foretrekk delegate_task.

Ikke forveksle dybdemaksimumet for delegering (3, på delegate_task-kjeder) med nestingsgrensen for subagenter i det innebygde harnesset (2). De er forskjellige grenser for forskjellige mekanismer.

Hierarki, koblinger og prosjekter

Relasjoner mellom overordnet og undersak ligger på tickets.parent_ticket_id, eid av setParent / clearParent. De er ikke ticket_links-rader, så alt som leser relasjonene til en sak, må slå sammen begge kildene.

ticket_links holder de retningsbestemte kantene mellom ellers urelaterte saker:

Koblingstype	Betydning
blocks	Kilden blokkerer målet
relatesTo	De to sakene er relatert (symmetrisk)
duplicateOf	Kilden er en duplikat av målet

Et prosjekt er en gruppering av saker innenfor ett arbeidsområde, mot et felles mål. Prosjekter finnes bare i Control Center og synkroniseres aldri til en ekstern leverandør.

Samarbeidspartnere

TicketCollaborator-rader er måten mer enn én principal festes til en sak på, med en rolle som assignee, collaborator eller reviewer. Mennesker og agenter er likeverdige rader — en principalId pluss en collaboratorType — uten noen sentinelverdi for «brukeren» og uten fremmednøkkel til noen av tabellene.

Ekstern synkronisering

Saken i Control Center er primær. Å slette en sak er kun lokalt, så en leverandørstøttet sak du sletter, slettes ikke i oppfølgingssystemet og kan dukke opp igjen ved neste synkronisering. Samarbeidspartnere og barnesaker kaskaderer.

Påloggingsinformasjon for adaptere hentes fra serverens lagre for påloggingsinformasjon (en Linear-nøkkel eller GitHub-token limt inn i Innstillinger plukkes opp ved neste forespørsel; miljøet fyller bare disse lagrene med startverdier).

Saker og pipelines

Ingen pipeline-node oppretter, fullfører eller avbryter saker — paletten har ikke noe slikt steg, og motoren kaller ikke TicketWorkflowService. En pipeline-utløser kan likevel fyre på TicketAssigned, TicketCompleted, TicketFailed eller TicketCancelled (de fire er sakshendelsene EventPayloadMapper faktisk mapper). Det finnes ingen pipelineRunId-kolonne på saken; pipeline-koblingen ligger i agentens kjørelogg.

Se også

• Pipelines og automatisering: sakshendelser kan utløse en pipeline
• Orkestrering: hvor en DAG av undersaker kommer fra
• Agentmodellen: hvem en sak er tildelt
• Domenehendelser: hendelsene i sakslivssyklusen
• Livssyklus for saker: statuser, felt, overganger, relasjoner
• Opprett og administrer saker
• Deleger arbeid til agenter
• Organiser arbeid med prosjekter