Domenehendelser

Hendelsesbuss

DomainEventBus er en prosessintern buss for kringkastet publisering og abonnement. Utgivere kaller publish(event); abonnenter konsumerer en typet on<T>()-strøm. Hver hendelse implementerer DomainEvent og bærer occurredAt.

Bussen kjører inne i cc_server. Enhver utgiver og enhver levende abonnent holder til der. Ingen klient ser denne bussen — serveren videresender en kuratert delmengde som notifications/*-rammer over JSON-RPC, filtrert per abonnent etter arbeidsområdemedlemskap.

Mål	Antall
Konkrete hendelsesklasser	54
Kildefiler (`packages/cc_domain/lib/core/domain/events/`)	14 (pluss `domain_event_bus.dart`)
Abstrakte basisklasser som aldri publiseres direkte	1 (`TaskLifecycleEvent`, et forseglet hierarki)

Hver hendelse i katalogen nedenfor ligger i denne ene mappen; det finnes ingen domenehendelser deklarert andre steder.

Hendelser for arbeidsområde, agent og repo

Hendelse	Nyttelast	Utløses når
`WorkspaceCreated`	`workspaceId`	Arbeidsområdet opprettes
`AgentRunCompleted`	`agentId`, `runId?`, `workspaceId?`, `conversationId?`	En agent fullfører en kjøring (vellykket eller mislykket)
`AgentAwaitingInput`	`workspaceId`, `kind`, `summary`, `spaceId?`, `conversationId?`, `agentId?`, `agentName?`	En agent begynner å vente på et menneske: en godkjenning, et `ask_user`-spørsmål eller en kjøring som står fast på påloggingsinformasjon (`kind` er `approval`, `question` eller `credential`)
`RepoAdded`	`repoId`, `path`, `workspaceId`	Et repo registreres; utløser kodeindeksering i bakgrunnen
`SkillUpdated`	`workspaceId`, `slug`, `origin`, `computedHash`, `scanVerdict?`	En skill installeres eller oppdateres, og bærer verdikten fra leverandørkjedeskanneringen

PR- og gjennomgangshendelser

Den første blokken er PR-ens egen livssyklus. Den andre er overvåkingen av egne PR-er: signaler om en PR du har åpnet, hver med forUserId slik at pollingen kan rute dem til personen de gjelder i stedet for å kringkaste dem.

Hendelse	Nyttelast	Utløses når
`PullRequestPublished`	`prId`, `workspaceId`, `repoOwner`, `repoName`	En agent åpner en PR
`PullRequestStatusChanged`	`status`, `workspaceId`, `prId?`, `repoFullName?`, `prNumber?`	PR slått sammen/lukket/åpnet/gjenåpnet/godkjent
`PrMerged`	`prId`, `workspaceId`, `agentId`	PR-en slås sammen — et smalt signal kun for sammenslåing, beholdt for analyse/varsler
`PrReviewRequested`	`workspaceId`, `repoOwner`, `repoName`, `prNumber`, `prTitle`	GitHub ber om gjennomgang fra serverbrukeren (varselspolling, `review_requested`)
`PrMentioned`	`workspaceId`, `repoOwner`, `repoName`, `prNumber`, `prTitle`	Serverbrukeren nevnes i en PR (varselspolling, `mention`)
`ExternalPrMerged`	`workspaceId`, `repoOwner`, `repoName`, `prNumber`, `prTitle`, `mergedByLogin?`	En eksternt sporet PR (ikke fra en agent) er slått sammen, oppdaget av GitHubs varselspolling; tilordnes varselkategorien `prMerged`
`ExternalPrDetected`	`repoOwner`, `repoName`, `prNumber`, `prTitle`, `author`, `workspaceId?`	PR fra noe annet enn en agent funnet via polling — kun pipeline (driver `external_pr_welcome`), reiser ingen varsling
`PrHeadChanged`	`repoOwner`, `repoName`, `prNumber`, `prTitle`, `previousHeadSha`, `headSha`, `workspaceId`	PR-ens head-SHA har flyttet seg — forfatteren pushet
`ReviewBecameStale`	`workspaceId`, `spaceId`, `repoOwner`, `repoName`, `prNumber`, `prTitle`, `reviewedHeadSha`, `headSha`	En fullført AI-gjennomgang beskriver ikke lenger PR-en den gjennomgikk. Utløses bare når det finnes en gjennomgang for commiten som ble erstattet, slik at den forblir et signal i stedet for en ping ved hver push

Overvåkingen av egne PR-er

Alle seks bærer workspaceId, repoOwner, repoName, prNumber, prTitle og en valgfri forUserId.

Hendelse	Ekstra nyttelast	Utløses når
`PrMergeReadinessChanged`	`ready`, `reason`	En PR du har forfattet, ble klar til sammenslåing, eller sluttet å være det
`PrReviewDecisionChanged`	`decision`, `reviewersRemaining`, `approverLogin?`	En reviewer godkjente, ba om endringer, eller fikk en godkjenning avvist
`PrChecksStatusChanged`	`failing`, `failingCheckName?`, `failingCheckUrl?`	CI ble rødt, eller kom seg igjen
`PrCommentMentioned`	`commentId`, `authorLogin`, `bodyPreview`, `isReviewComment`, `threadId?`, `path?`, `line?`	Noen nevnte deg i en PR-kommentar eller gjennomgangskommentar
`PrThreadReplied`	`commentId`, `authorLogin`, `bodyPreview`, `threadId?`, `path?`, `line?`	Noen svarte i en gjennomgangstråd du er med i
`PrThreadResolved`	`threadId`, `commentId?`, `path?`, `line?`	Noen løste en gjennomgangstråd du er med i

Meldingshendelser

Hendelse	Nyttelast	Utløses når
`MessageReceived`	`spaceId`, `messageId`, `senderName`, `contentPreview`, `isAgentMessage`, `workspaceId?`, `mentions`, `requestedByUserId?`, `senderUserId?`	En ny melding kommer inn
`SpaceCreated`	`spaceId`, `workspaceId`	Et område opprettes
`SpaceDeleted`	`spaceId`, `workspaceId`	Et område slettes
`SpaceProvisioningChanged`	`workspaceId`, `spaceId`, `status`, `step?`	Arbeidsområdet til området går inn i klargjøring, når et steg (klone et repo, sjekke ut en PR, sette opp en agent), eller skifter til klar/mislykt — chatbroen forteller om det på oppgavekortet

Sakshendelser

Hendelse	Nyttelast	Utløses når
`TicketCreated`	`ticketId`, `workspaceId`	En sak opprettes
`TicketAssigned`	`ticketId`, `ticketTitle`, `ticketBody?`, `ticketUrl?`, `assignedAgentId?`, `assigneeType`, `assignedTeamId?`, `workspaceId`	Saken tildeles en prinsipal eller et team
`TicketCompleted`	`ticketId`	Arbeidet fullføres (endelig)
`TicketFailed`	`ticketId`, `errorMessage`	Agenten mislykkes (endelig)
`TicketCancelled`	`ticketId`	Saken avbrytes (endelig)
`TicketStatusChanged`	`ticketId`, `workspaceId`, `from`, `to`	Enhver statusendring
`TicketReassigned`	`ticketId`, `workspaceId`, `fromAgentId?`, `toAgentId?`	Saken omtildeles
`TicketDetailsUpdated`	`ticketId`, `workspaceId`	Tittel, beskrivelse eller prioritet endres

Hendelser i oppgavelivssyklusen

Den samlede strømmen for oppgavelivssyklus — én utsendt agentkjøring, nøklet på kjøringslogg-ID-en sin. Hver hendelse bærer taskId, en monoton seq per oppgave, workspaceId?, agentId? og en phase; radene nedenfor viser bare de ekstra feltene.

Hendelse	Nyttelast	Utløses når
`TaskDispatched`	—	Oppgaven sendes til en backend for utførelse
`TaskRunning`	—	Oppgaven begynte å produsere utdata
`TaskWaitingLocalDirectory`	`lockedPath`, `holderTaskId?`	Oppgaven parkeres — en annen oppgave eier sti-låsen på disken som den trenger
`TaskProgress`	`note?`	Sjekkpunkt for fremdrift midt i kjøringen
`TaskMessage`	`messageType`, `content`	Strømmet melding (text/thinking/tool_use/tool_result/error); rapporteres under fasen `progress`
`TaskCompleted`	`summary?`	Oppgaven fullførtes
`TaskFailed`	`errorMessage`	Oppgaven avsluttet med en feil
`TaskCancelled`	—	Oppgaven avbrutt før fullføring

TaskPhase-enumen har også et queued-medlem, men ingenting publiserer en køet hendelse — det finnes ingen TaskQueued-klasse. Den første observerbare rammen for en oppgave er TaskDispatched.

Pipeline-hendelser

Hendelse	Nyttelast	Utløses når
`PipelineRunCompleted`	`workspaceId`, `pipelineRunId`, `templateId`	Kjøringen fullføres
`PipelineRunCancelled`	`workspaceId`, `pipelineRunId`, `templateId`	Kjøringen avbrytes (av brukeren eller systemet) — en bevisst stopp, ikke en feil
`PipelineRunFailed`	`workspaceId`, `pipelineRunId`, `templateId`, `errorMessage`	Kjøringen mislykkes

Bare endelige overganger publiseres. Det finnes ingen PipelineRunStarted og ingen hendelse per steg: fremdriften til et steg når klientene gjennom kjøringens egne rader og oppgavelivssyklus-strømmen til agenten den sendte ut, ikke gjennom bussen.

Observerbarhetshendelser

Hendelse	Nyttelast	Utløses når
`ActivityLogged`	`id`, `actorType`, `actorId?`, `action`, `entityType`, `entityId?`, `details?`, `workspaceId?`, `runId?`	Oppføring i revisjonssporet opprettes
`BudgetThresholdCrossed`	`scopeType`, `scopeId`, `spentCents`, `budgetCents`, `isHardStop`	Forbruket overstiger terskelen

Identitets- og medlemskapshendelser

Hendelse	Nyttelast	Utløses når
`WorkspaceMemberAdded`	`workspaceId`, `userId`, `role`	En bruker blir med i et arbeidsområde (innløsning av invitasjon eller administratortillegg)
`WorkspaceMemberRemoved`	`workspaceId`, `userId`	Et medlem fjernes — levende økter for den brukeren, avgrenset til arbeidsområdet, må sjekke tilgangen på nytt umiddelbart
`WorkspaceMemberRoleChanged`	`workspaceId`, `userId`, `role`	Rollen til et medlem endres

Medlemskap er hele identitetsflaten på bussen. Oppretting av brukere og tilbakekalling av enheter skjer, men publiseres ikke som domenehendelser — tilbakekalling håndheves direkte mot levende økter i stedet for å rutes gjennom bussen.

Kalender- og møtehendelser

Hendelse	Nyttelast	Utløses når
`CalendarAuthExpired`	`workspaceId`, `accountEmail`	Oppdateringstokenet (OAuth) til en tilkoblet konto er permanent ugyldig (publiseres én gang per frakoblingsepisode)
`MeetingStartingSoon`	`workspaceId`, `eventId`, `title`, `startTime`, `meetingUrl?`	En kalenderhendelse starter innenfor det konfigurerte forhåndsvinduet
`MeetingRecordingStopped`	`workspaceId`, `meetingId`, `title`, `userNotes`, `transcript`, `summaryInstructions?`	Et møteopptak fullføres og utløser den innebygde `meeting_summary`-pipelinen

Stasjonshendelser

Hendelse	Nyttelast	Utløses når
`RigClosedEvent`	`workspaceId`, `rigId`, `reason`	En stasjon forsvant, med lukkeårsaken sin; konsumenter handler bare på `backendFailure` — alle andre årsaker er bestilt eller ledsaget av en `RigReaped`
`RigControlChanged`	`workspaceId`, `rigId`, `controller?`	Et menneske tok eksklusiv kontroll over en stasjon eller ga den tilbake (`controller` null ved frigivelse — hendelsen registrerer ikke hvem som slapp)
`RigReaped`	`workspaceId`, `rigId`, `reason`, `agentId?`	Systemet gjenvant en maskin: inaktivitet, TTL eller utkastelse på grunn av minnepress (rapportert som `idleTimeout`), med den drivende agenten

At en stasjon åpnes, er ikke en hendelse. Oppstarten fullføres og stasjonsraden skifter til klar; ingenting publiseres, så det finnes ingen RigOpened å abonnere på.

Underdomener helt uten hendelser

Flere delsystemer som ser hendelsesdrevne ut fra utsiden, er det ikke. De er listet opp her fordi fraværet deres er en designbeslutning det er verdt å kjenne før du begynner å lete etter en krok:

Underdomene	Hvordan tilstanden flyttes i stedet
Minne	`record_memory_fact` og lignende skriver og returnerer; recall leser. Ingenting publiserer ved et faktum eller en konflikt
Orkestrering	Forslaget, godkjenningen av det og den genererte pipeline-kjøringen er rader og RPC-kall
Plandokumenter	`submit_plan` skriver en revisjon; godkjenning materialiserer en orkestrering. Ingen av dem kunngjøres
Artefakter	`publish_artifact` / `revise_artifact` skriver revisjoner direkte
Godkjenninger	Eskalering håndteres inne i godkjenningsarbeidsflyttjenesten
Sakssynkronisering	Leverandørkoordinatoren abonnerer på sakshendelsene ovenfor; innkommende webhooks brukes direkte
Kalenderoppdatering	En synkronisering legger inn eller oppdaterer hendelser, og klienten leser på nytt; det finnes ingen kringkasting av oppdateringer
Worktree-sammenslåinger	Registreres i `worktree_merge_log` og leses derfra

Abonnenter

Alle abonnentene nedenfor konstrueres inne i runCcServer (eller en tjeneste den bygger). Det finnes ingen abonnent på klientsiden.

Abonnent	Hendelser den konsumerer
`WorkspaceSeeder`	`WorkspaceCreated`
Såing av startsettet med eval-suiter (innebygd)	`WorkspaceCreated`
Klargjøring av chatområde (innebygd)	`SpaceCreated`
`PipelineTriggerDispatcher`	Hver `DomainEvent`; hver aktiverte utløser filtrerer på sin egen type
`SubPipelineResumeListener`	`PipelineRunCompleted`, `PipelineRunFailed`
`PipelineCostRollupListener`	`AgentRunCompleted`
`BudgetEvaluationListener`	`AgentRunCompleted`
`MeetingSummaryReconciler`	`PipelineRunCompleted`, `PipelineRunFailed`, `PipelineRunCancelled` (bare `meeting_summary`-kjøringer)
`PipelineStepResumeListener`	`AgentRunCompleted`
`AgentRunTaskCompleter`	`AgentRunCompleted`
`GoalSupervisor`	`AgentRunCompleted`
`CheckerDispatchListener`	`AgentRunCompleted`
`TeamRoutingService`	`AgentRunCompleted`, `TicketAssigned`
`OrchestrationRunListener`	`PipelineRunCancelled`, `PipelineRunFailed`
`MultiVendorTicketSyncCoordinator`	`TicketCreated`, `TicketAssigned`, `TicketReassigned`, `TicketStatusChanged`, `TicketDetailsUpdated`
`WorktreeGcListener`	`TicketCompleted`, `TicketCancelled`, `SpaceDeleted`, `PrMerged`, `PullRequestStatusChanged`
`ChatBridgeService`	`MessageReceived`, `SpaceProvisioningChanged`
`ActivityLogPersister`	`ActivityLogged`
`RigEventListener`	`RigControlChanged`, `RigReaped`, `RigClosedEvent` — injiserer et varsel i klarspråk på styringskanalen til den drivende agenten
`StaleReviewWatcher`	`PrHeadChanged` — publiserer `ReviewBecameStale` bare når det finnes en fullført gjennomgang for den erstattede commiten
`GitHubPrConversationBridge`	`AgentRunCompleted` — utgående svar i PR-samtaler
`NotificationFeedRecorder`	De tjueto varselklassehendelsene nedenfor
`RemoteEventForwarder`	De tjueto pluss `TicketReassigned` og hver `TaskLifecycleEvent`. De tre medlemskapshendelsene ugyldiggjør bare medlemskapsbufferen per arbeidsområde; de videresendes ikke som rammer
`LocalRpcServer` / `RemoteRelayHost`	`WorkspaceMemberRemoved` — dropper den brukerens tilknyttede arbeidsområdeabonnementer; socketen forblir åpen

TicketAssigned er et revisjons- og varselsignal og en pipeline-utløser. Tildeling til en agent registrerer eierskap og starter ingen kjøring — det finnes ingen saksdispatcher. Tildeling til et team (assignedTeamId satt) er unntaket: TeamRoutingService sender ut teamlederen.

TicketRemoteSyncHandler er deklarert, men konstrueres aldri i produksjonskode, så den abonnerer på ingenting i dag. NotificationEventMapper på klientsiden konstrueres bare i sin egen test — den er resten av den prosessinterne veien fra før klient/server-delingen. Levende toast kommer fra rammene nedenfor.

Varseltilordning

På serveren gjør NotificationFeedRecorder og RemoteEventForwarder disse hendelsene om til notifications/*-rammer (notification_wire.dart). På klienten gjør RpcNotificationMapper → mapNotificationFrame en ramme om til en AppNotification.

Det finnes nøyaktig sytten varselkategorier. Flere hendelser tilordnes mer enn én rammemetode, fordi rammen bærer overgangen (mislykt kontra gjenopprettet) mens kategorien bærer spørsmålet («hva gjør CI?»).

Kategori	Kildehendelse	Rammemetode
`newMessage`	`MessageReceived`	`notifications/message_received` (nevner deg)
`agentRunCompleted`	`MessageReceived`	`notifications/message_received` (`is_agent_message`, nevner deg ikke)
`agentAwaitingInput`	`AgentAwaitingInput`	`notifications/agent_awaiting_input`
`ticketAssigned`	`TicketAssigned`	`notifications/ticket_assigned`
`ticketStatusChanged`	`TicketStatusChanged`	`notifications/ticket_status_changed`
`pullRequestPublished`	`PullRequestPublished`	`notifications/pr_published`
`prMerged`	`PrMerged`	`notifications/pr_merged`
`prMerged`	`ExternalPrMerged`	`notifications/external_pr_merged`
`prMentioned`	`PrMentioned`	`notifications/pr_mentioned`
`prMentioned`	`PrCommentMentioned`	`notifications/pr_comment_mentioned`
`reviewRequested`	`PrReviewRequested`	`notifications/pr_review_requested`
`reviewStale`	`ReviewBecameStale`	`notifications/review_stale`
`prMergeReadiness`	`PrMergeReadinessChanged`	`notifications/pr_ready_to_merge` / `pr_merge_blocked`
`prReviewDecision`	`PrReviewDecisionChanged`	`notifications/pr_approved` / `pr_changes_requested` / `pr_review_dismissed`
`prChecksStatus`	`PrChecksStatusChanged`	`notifications/pr_checks_failed` / `pr_checks_recovered`
`prThreadActivity`	`PrThreadReplied`	`notifications/pr_thread_replied`
`prThreadActivity`	`PrThreadResolved`	`notifications/pr_thread_resolved`
`meetingStartsSoon`	`MeetingStartingSoon`	`notifications/meeting_starting_soon`
`calendarAuthExpired`	`CalendarAuthExpired`	`notifications/calendar_auth_expired`
`rigStatusChanged`	`RigControlChanged`	`notifications/rig_control_changed`
`rigStatusChanged`	`RigReaped`	`notifications/rig_reaped`
`rigStatusChanged`	`RigClosedEvent`	`notifications/rig_closed`

Rammen for stasjons-overtakelse leveres ikke tilbake til den som tok rattet, en frigivelse filtreres ikke (hendelsen registrerer ikke hvem som slapp), og bare en backendFailure-lukking produserer en rig_closed-ramme — de andre årsakene er enten bestilt eller allerede dekket av gjenvinningsrammen.

AgentAwaitingInput publiseres av AgentAwaitingInputPublisher, som overvåker registrene for godkjenninger og blokkert påloggingsinformasjon etter nye oppføringer, og som får beskjed om hvert ask_user-spørsmål fra AgentQuestionService. Én venting er én hendelse; ingenting publiseres når ventingen tar slutt.

De fem kategoriene for egne PR-er bærer forUserId, så de når forfatteren i stedet for alle i arbeidsområdet.

RemoteEventForwarder videresender i tillegg TicketReassigned som notifications/ticket_reassigned og hver TaskLifecycleEvent som notifications/task_<phase>. Ingen av dem tilordnes en varselkategori — de driver levende brukergrensesnitt, ikke varselsenteret. Medlemskapshendelser videresendes ikke som rammer: de ugyldiggjør cachen til videresenderen, og øktvertene dropper arbeidsområdeabonnementene til det fjernede medlemmet.