Skip to content

Governance & Agents

Implemented Decided

Source: doc/Governance_Overview.md · doc/governance/agent_policy.yaml · doc/governance/Multi_Agent_Execution_Playbook.md · doc/governance/Agent_Orchestrator_v1/v2.md · doc/governance/Agent_Work_Queue.yaml · doc/governance/Multi_Agent_Lane_Worktrees_v1.md · doc/governance/Evidence_First_Change_Protocol.md

How the platform governs change — and how that same governance scales to multiple coding agents executing in parallel without losing contract-first discipline or audit trail.

What's distinctive here

mindmap
  root((Why this section exists))
    Most repos
      Human contributors
      Plain text style guide
      Reviewer judgement
      CI as safety net
    GPUaaS
      Human + coding agent contributors
      Machine-readable policy floor
      Agent orchestrator coordinates lanes
      Structured work queue 406 tasks
      Lane worktrees prevent collisions
      Reviewguard + multi-agent review
      Evidence-first execution rule
      CI is the source of truth

This isn't aspirational. The platform is actively contributed to by multiple coding agents, plus humans, governed by a stack of explicit policies — most of which are machine-enforced. This section documents that stack.

Section map

Governance model

The rule precedence: agent_policy → reviewguard → contracts → spectral → invariant gates → enforcement YAML → versioning → CI checklist → coding/testing standards → prose. What overrides what.

Multi-agent orchestration

Orchestrator v1 (observe + validate + recommend) and v2 (coordinated execution loop). How role agents pick up work, hand off, and converge to merge.

Lane worktrees & review

5-lane model (A-backend, B-ui, C-ops, D-arch, E-governance). Worktree isolation. Cross-model review. Merge gate scope.

Queue system

The 406-task Agent_Work_Queue.yaml + the planned SQLite structured store. Task lifecycle, schema, claim/dispatch semantics, archive sweeps.

Policy & enforcement

The agent_policy.yaml machine baseline + reviewguard + Agent_Enforcement non-negotiables. CI gates that turn rules into bouncers.

Evidence-first execution

The protocol that ties everything together: every change needs baseline → prediction → re-verification. No "looks right" without proof.

How we prepared for coding agents

The unique pre-coding readiness baseline — contract-first, machine-readable policy, structured queue, lane worktrees — that made agent-driven implementation safe to turn on.

How the pieces fit

flowchart TB
    classDef hum fill:#fff8e1,stroke:#f57f17
    classDef pol fill:#e3f2fd,stroke:#1565c0
    classDef coord fill:#fff3e0,stroke:#e65100
    classDef store fill:#e8f5e9,stroke:#2e7d32
    classDef rev fill:#ede7f6,stroke:#5e35b1
    classDef ci fill:#d1e7dd,stroke:#0a3622

    H[Human authors:<br/>tasks, ADRs, standards]:::hum
    POL[Machine policy floor:<br/>agent_policy.yaml<br/>reviewguard policy<br/>spectral lint]:::pol

    H --> Q[Agent_Work_Queue.yaml<br/>406 tasks]:::store
    H --> POL
    POL --> ORCH[Agent orchestrator<br/>v1 observe / v2 coordinated]:::coord
    Q --> ORCH

    ORCH --> LANES[Role lanes<br/>A-backend B-ui C-ops]:::coord
    LANES --> WT[Lane worktrees<br/>isolated branches]:::coord
    WT --> AGENT[Coding agents work<br/>contract-first<br/>evidence-first]:::coord

    AGENT --> PR[Pull request]:::rev
    PR --> RG[reviewguard checks]:::rev
    RG --> CI_GATES[scripts/ci/*.sh gates<br/>contracts validate<br/>audit guard<br/>observability gate<br/>queue git check]:::ci
    CI_GATES --> XREV[D-arch + E-governance<br/>cross-review]:::rev
    XREV --> MERGE[Merge to master]:::ci
    MERGE --> Q

What this section is — and isn't

It is It isn't
Documentation of the operating model in use today Aspirational future governance
Sourced from doc/governance/* and doc/Governance_Overview.md New rules invented for the portal
Aligned with the Roadmap & Queues section A duplicate of the product roadmap
The view product/leadership often asks about ("how do agents work here?") An agent prompt or runbook

Where to look next