Skip to content

Active work queue

Implemented Designed

Source: doc/governance/Agent_Work_Queue.yaml (16,178 lines, 406 tasks) · doc/Execution_Progress.md (880 lines)

The repo runs on a multi-agent execution model. Work is enumerated in a single YAML queue. The queue is the source of truth for what's being worked on now.

Queue at a glance

pie title Status — 406 tasks total
    "done" : 279
    "todo" : 123
    "blocked" : 4
pie title Role assignment
    "A-backend" : 233
    "B-ui" : 123
    "C-ops" : 50
pie title Priority bucket (filtered to active priorities 1-5)
    "P1 — must-do" : 119
    "P2 — strong intent" : 54
    "P3 — should-do" : 14
    "P4 — nice-to-have" : 8
    "P5 — backlog" : 13

Queue schema

erDiagram
    queue ||--o{ task : "contains"
    task ||--o{ acceptance_check : "must pass"
    task ||--o{ depends_on : "blocked by"

    task {
        text id PK "e.g. A-PROV-SCHED-001 or B-V3-ACK-SUPPRESS-CONTROL-001"
        text title
        text role "A-backend, B-ui, C-ops"
        text status "todo, in_progress, blocked, done"
        int priority "1 highest"
        text owner "agent / engineer lane"
        text branch "agent/<lane>"
        text completed_at "ISO date"
        text commit "git sha when done"
        list depends_on "blocking task ids"
        list acceptance_checks "commands that must pass"
        text notes "context, pre-read, invariants, scope"
    }

Sample task fields (from B-V3-ACK-SUPPRESS-CONTROL-001):

- id: B-V3-ACK-SUPPRESS-CONTROL-001
  title: Add V3 platform AckSuppressControl and wire action queues
  role: B-ui
  status: done
  priority: 1
  owner: B-ui
  branch: agent/B-ui
  completed_at: '2026-05-04'
  commit: 3993e614
  depends_on: []
  acceptance_checks:
  - pnpm --dir packages/web exec vitest run AckSuppressControl
  - pnpm --dir packages/web typecheck
  - ruby scripts/ops/agent_queue_store.rb --queue-file ... validate
  - make queue-git-check
  notes: |
    Context: ...
    Pre-read (required): ...
    Invariants (must not break): ...
    Scope: ...

Task ID conventions

flowchart LR
    ID[Task ID: X-AREA-FEATURE-NNN]
    ID --> X{X}
    X --> A[A — backend]
    X --> B[B — UI]
    X --> C[C — ops]

    ID --> AREA[AREA tag<br/>e.g. PROV, V3, IAM, BILL,<br/>APPS, SLICE, TERM, STORAGE,<br/>OPS, CLEAN, RUNBOOK, ...]
    ID --> FEATURE[Feature-or-component slug]
    ID --> NNN[Three-digit serial]

Examples actually in the queue:

ID pattern Meaning
A-PROV-SCHED-001 Backend, Provisioning Scheduler, first item
B-V3-ACK-SUPPRESS-CONTROL-001 UI, V3 redesign Ack/Suppress control, first item
C-OPS-002 Ops, second item (PKI step-ca staging readiness)
A-CLEAN-001 Backend, cleanup sprint, first item

Lifecycle of a queue task

stateDiagram-v2
    [*] --> todo: queued by author
    todo --> in_progress: agent picks up<br/>(branch agent/<lane>)
    in_progress --> blocked: depends_on or external waiting
    blocked --> in_progress: dependency clears
    in_progress --> done: acceptance checks pass<br/>+ commit recorded
    done --> [*]

    note right of in_progress
      Only one agent claims an id at a time.
      Multi-Agent_Lane_Worktrees_v1.md governs lanes.
    end note

    note right of done
      Cannot be marked done without:
      - acceptance_checks all green
      - completed_at + commit set
      - PR merged
    end note

→ Source: Multi_Agent_Execution_Playbook.md, Multi_Agent_Lane_Worktrees_v1.md, Agent_Queue_Structured_Store_v1.md

Live execution ledger

doc/Execution_Progress.md mirrors the queue but groups by time and phase rather than by task id. It carries:

  • Day-by-day completion notes
  • Phase-mapped checklist progress
  • Active "next queue" of P1 items
  • References to commits, evidence files, and runbooks

Sample entries (paraphrased from 2026-04-14):

timeline
    title 2026-04-14 progress note (excerpt)
    Node-agent lifecycle
        : commit 97697190 — agent lifecycle self-update; CI green
        : platform-control + kind nodes refreshed to current agent
        : remaining fleet reconciliation + read-model telemetry
    Launchable OCI and Compose
        : commit 593a1690 — manifest-owned Compose topology
        : JupyterLab is the proven single-container reference app
        : vllm-openai is the proven single-node Compose reference app
        : Mistral Small 3.2 validated on one H200 via H200 platform-control path

→ Source: Execution_Progress.md

Acceptance-check pattern

Every task carries machine-runnable acceptance checks. CI enforces them on merge.

flowchart LR
    AGENT[Agent finishes work] --> PR[Opens PR]
    PR --> CI[CI pipeline]
    CI --> CHK{Run task<br/>acceptance_checks}
    CHK -- all pass --> RG[reviewguard checks]
    CHK -- any fail --> BLOCK[Block PR<br/>task stays in_progress]
    RG -- pass --> MERGE[Merge → task=done<br/>commit + completed_at recorded]
    RG -- fail --> BLOCK

    classDef ok fill:#d1e7dd,stroke:#0a3622
    classDef block fill:#f8d7da,stroke:#42101e
    class MERGE ok
    class BLOCK block

Acceptance checks typically include:

  • pnpm --dir packages/web typecheck
  • pnpm --dir packages/web exec vitest run <component>
  • go vet ./... && go build ./...
  • make test or make test-integration
  • ruby scripts/ops/agent_queue_store.rb --queue-file doc/governance/Agent_Work_Queue.yaml validate
  • make queue-git-check — queue/branch consistency

Queue invariants (CI-enforced)

mindmap
  root((Queue invariants))
    Structural
      Single source-of-truth file
      YAML schema validated
      Task ids unique
      Status values in enum
    Workflow
      done requires commit + completed_at
      depends_on chain non-circular
      One agent per task at a time
      Status transitions strictly forward
    Consistency
      queue mirrors git branch state
      Lane worktrees match owner
      No orphan acceptance_checks

Scripts:

  • scripts/ci/agent_queue_validate.sh — schema + invariant validation
  • scripts/ci/agent_queue_git_consistency.sh — queue ↔ git branch consistency
  • make queue-git-check — local equivalent

Queue ↔ phase ↔ commit cross-reference

flowchart LR
    A[Agent_Work_Queue.yaml<br/>406 tasks] --> X[task.id maps to<br/>phase in<br/>Implementation_Roadmap.md]
    A --> Y[task.commit maps to<br/>git history]
    A --> Z[task.completed_at appears in<br/>Execution_Progress.md note]
    X & Y & Z --> R[Three-way reconciliation:<br/>queue + git + ledger<br/>must all agree]

    classDef src fill:#fff3cd,stroke:#332701
    classDef out fill:#d1e7dd,stroke:#0a3622
    class A,X,Y,Z src
    class R out

Where to look next