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-archandE-governancemust 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-backend → agent/A-backend
- gpuas-B-ui → agent/B-ui
- gpuas-C-ops → agent/C-ops
- gpuas-D-arch → agent/D-arch
- gpuas-E-governance → agent/E-governance
Role branch policy:
- one persistent branch per role;
- rebase on origin/master before ff-merge;
- queue/git consistency gates required.
6. Recommended Flow¶
- Delivery lane claims and implements task.
- Delivery lane runs acceptance checks and pushes role branch.
D-archreview pass for contract/architecture impacts.E-governancereview pass for quality/security/gate impacts.- Delivery lane applies fixes (if any), re-runs checks, merges to master.
- Queue metadata updated to
donewith 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.