Skip to content

Multi-Agent Review Model (v1.5)

Purpose: - Extend the 3-lane delivery model with independent design/governance review lanes. - Reduce blind spots by using cross-model review (different engines) before merge. - Keep this as a documented operating model first; automation comes after validation.

Companion worktree/layout guidance: - Multi_Agent_Lane_Worktrees_v1.md

1. Lanes

Delivery lanes: - A-backend — services/workers/contracts implementation. - B-ui — web UX and e2e. - C-ops — observability/runbooks/platform docs.

Review lanes: - D-arch — architecture/contracts reviewer (doc/api, doc/architecture). - E-governance — process/quality/security reviewer (doc/governance, test/gate posture).

2. Independence Rules

  • A lane must not self-approve its own critical changes.
  • D-arch and E-governance must review each other’s changes before merge.
  • Prefer cross-engine review diversity:
  • implementation by one model, review by another.
  • if unavailable, require an explicit “same-model exception” note in task handoff.

3. Merge Gate Scope

Review is mandatory (D and E) when files include any of: - doc/api/openapi.draft.yaml - doc/api/asyncapi.draft.yaml - doc/architecture/* - doc/governance/* - scripts/ci/*

For non-critical code-only changes, existing role ownership + queue gates remain sufficient.

4. Required Evidence Per Task

Task completion requires: 1. Implementation commit SHA. 2. Reviewer findings (if none, explicit “no findings” with residual risks). 3. Resolution commit SHA (or note “no code changes required”). 4. Queue metadata update: - status=done - completed_at - commit (merged SHA on master)

Findings format: - severity, file reference, short impact statement, fix status.

5. Worktree/Branch Model

Persistent worktrees: - gpuas-A-backendagent/A-backend - gpuas-B-uiagent/B-ui - gpuas-C-opsagent/C-ops - gpuas-D-archagent/D-arch - gpuas-E-governanceagent/E-governance

Role branch policy: - one persistent branch per role; - rebase on origin/master before ff-merge; - queue/git consistency gates required.

  1. Delivery lane claims and implements task.
  2. Delivery lane runs acceptance checks and pushes role branch.
  3. D-arch review pass for contract/architecture impacts.
  4. E-governance review pass for quality/security/gate impacts.
  5. Delivery lane applies fixes (if any), re-runs checks, merges to master.
  6. Queue metadata updated to done with merged SHA.

7. Current Phase Policy

  • Active now: 3 delivery lanes with terminal sprint focus.
  • Review lanes (D, E) run as process overlays first (manual invocation).
  • Do not block active sprint progress on full automation yet.
  • Capture learnings in this doc; automate only stable invariants.

8. Automation Backlog (post-validation)

Planned orchestrator additions: - role-aware reviewer assignment (D + E) for critical scope files. - “no self-approval” enforcement. - required review evidence fields before done. - cross-engine metadata marker in handoff. - reviewer exception path with rationale field.

These are intentionally deferred until the model is exercised for several days.