Board of Governance — Run

Execute a board review following the 4-round SOP in docs/REVIEW-SOP.md.

Step 0: Review Mode

If the user hasn't specified depth:

How deep should this review go?

1. •Quick — 1 agent, single round (~5 min)
2. •Standard — full board, 4-round SOP (default)
3. •Custom — pick agents and rounds

Quick: Best-matching agent, Round 1 only, synthesise and present. Standard: All agents, all applicable rounds. Custom: User picks.

Step 1: Read the Board

Read .board/board/BOARD.md for agent list, invocation commands, board user, parallelism pattern.

Agent count validation: For Standard mode, verify at least 3 agents are configured. If fewer than 3, warn the user:

Only [N] agent(s) configured. Standard reviews need 3+ for meaningful consensus. Continue with reduced coverage, or add agents with /new-agent?

Quick mode (1 agent) is exempt from this check.

Deferred items are active context. Check two sources for deferred items:

1. •tasks.json — look for tasks with "status": "deferred". Include their title, description, trigger condition, and severity.
2. •.board/board/DEFERRED_WORK.md — if it exists (legacy), include its FULL contents.

Include all deferred items in every agent brief. Frame them as: "Evaluate whether your review triggers any of these deferred items. If a trigger condition is met, promote to FIX NOW with evidence." Do NOT tell agents "do not re-raise" — that causes them to ignore deferred items entirely.

C3: Review lockfile

Before starting, check for $BOARD/.board/.review-lock. If it exists:

1. •Read its contents (project name, PID, timestamp)
2. •Check if the PID is still alive (kill -0 $PID)
3. •If alive → error: "Review in progress for {project} (PID {pid}, started {timestamp}). Wait or kill it."
4. •If dead → remove stale lock and continue

Create the lock at start: echo "{project}|$$|$(date -Iseconds)" > $BOARD/.board/.review-lock Remove the lock in Step 6 (Post-Review) — including on error/cancel paths.

Error cleanup trap

Set up a trap to clean the lockfile on error/cancel:

trap 'rm -f $BOARD/.board/.review-lock' EXIT INT TERM HUP

Migration guard

If BOARD.md contains isolation: container, error immediately:

Container mode has been removed. Re-run /setup or change isolation to bare in BOARD.md.

Pre-flight health checks

Before launching agents, verify the board environment is functional. Fail fast with a clear message rather than launching agents into a broken setup.

For each agent listed in BOARD.md:

1. •Board user exists: id $BOARD_USER — if it fails: "Board user '$BOARD_USER' does not exist. Re-run /setup."
2. •Agent directory complete: Verify $AGENT_DIR/CLAUDE.md, $AGENT_DIR/inbox/, and $AGENT_DIR/outbox/ exist — if any missing: "Agent '{name}' is missing {path}. Re-run /setup or /new-agent."
3. •Outbox writable: sudo -u $BOARD_USER test -w $AGENT_DIR/outbox — if fails: "Board user cannot write to {agent}/outbox/. Fix: chown -R $BOARD_USER:$BOARD_USER $BOARD/.board/"
4. •CLI on PATH: For Claude agents: sudo -u $BOARD_USER bash -c 'which claude'. For Codex agents: sudo -u $BOARD_USER bash -c 'which codex' — if fails: "{cli} not found for board user. Install it or check PATH."
5. •Credentials exist: For Claude: check ~$BOARD_USER/.claude/.credentials.json exists. For Codex: check ~$BOARD_USER/.codex/auth.json exists — if missing: "No credentials for {cli}. Run '{cli} /login' as $BOARD_USER or copy credentials."

If any check fails, do NOT create the lockfile or launch agents. Stop with the error message.

Step 2: Round 1 — Blind Review

Agents are ephemeral. Every invocation is a fresh session with zero memory. All context — identity, domain context, brief, prior round artifacts — must be in their inbox. If you don't give it to them, they don't have it.

Verify each agent's inbox has brief.md and context.md. If empty, ask about running /brief first.

Timing

Record the review start time before launching agents:

REVIEW_START=$(date +%s)

Generate a run ID (e.g., run-$(date +%s)) and write it to each agent's outbox/.run-id before launching. This sentinel prevents stale report confusion.

Launch all agents simultaneously per BOARD.md parallelism pattern. Each runs from their own directory. Tell the user which agents are running and rough timing.

Wait for all to complete. For each agent:

1. •Check exit code — non-zero or timeout (exit 124) means failure
2. •Verify outbox/report.md exists and was modified after the run started
3. •If Codex: check whether outbox/report.md contains CLI error output (starts with OpenAI Codex v or contains ERROR:) — if so, the agent failed, do not treat the error text as findings
4. •Report failed agents explicitly before proceeding

Do NOT share reports between agents. Do NOT synthesize error output as findings.

Round timing

After all agents complete, record and report timing:

REVIEW_ROUND_END=$(date +%s)
ROUND_ELAPSED=$((REVIEW_ROUND_END - REVIEW_START))

Report to the user:

Round 1 complete in {ROUND_ELAPSED}s — {agent1}: {time}s, {agent2}: {time}s, {agent3}: {time}s

For parallel runs, the wall-clock time is the max of individual agent times. Report both individual durations and wall-clock total.

Step 3: Round 2 — Consolidation

Done by you (orchestrator), not agents.

1. •Read all Round 1 reports
2. •Group findings by theme, assign IDs (C1, C2...)
3. •Note agent agreement/disagreement per item
4. •Classify: FIX NOW / DEFER / INFO / REJECT
5. •Every DEFER gets a trigger condition
6. •Apply owner directives

Present consolidation to user before running agents:

Here's the consolidation. Do you have any directives before agents respond?

Prepare Round 2 inboxes (agents are ephemeral — fresh session):

• •context.md — same domain context
• •brief.md — original Round 1 brief (agents need source material)
• •consolidation.md — your consolidated findings
• •round2-brief.md — instructions (AGREE/DISAGREE/MODIFY per item), owner directives

Run all agents. Collect Round 2 reports.

Step 4: Round 3 — Deliberation

If Round 2 is unanimous, skip to Step 5:

Round 2 unanimous — skipping to confirmation.

If disagreements exist: extract disputed items, show each agent's position with names visible, write Round 3 brief. Inboxes need everything from prior rounds plus round3-brief.md. Agents state AGREE or BLOCK per item.

Step 5: Round 4 — Confirmation

Final brief: all items with classifications, implementation notes, dispute resolutions. Inboxes need all prior context plus round4-brief.md.

Agents state SIGN OFF or BLOCK.

If all sign off → complete. If any block:

[Agent] is blocking on: [concern]. Do you want to:

1. •Address the concern and rerun confirmation
2. •Override with documented rationale (owner authority)
3. •Go back to deliberation

Step 6: Post-Review

Always run this step, even on error/cancel.

Remove the review lockfile: rm -f $BOARD/.board/.review-lock

Append to .board/board/REVIEW-LOG.md: what was reviewed, date, mode, rounds, agents, FIX NOW table, DEFER table with triggers, INFO items, key decisions. Include timing: **Timing:** Total: Xm Ys | Round 1: Xs (agent1: Xs, agent2: Xs, agent3: Xs) | Rounds 2-4: Xs each

For any new DEFER items: add them to tasks.json with "status": "deferred" and a "trigger" field describing the promotion condition. Create a corresponding YAML file at docs/tasks/{task-id}.yaml if the item warrants detailed tracking. Also update .board/board/DEFERRED_WORK.md (legacy format) for backward compatibility with existing board setups.

Present summary: FIX NOW list, DEFER list, sign-off status.

Finding-to-Task Automation (lifecycle projects only)

Guard: Only run this when tasks.json exists with meta.version === 2 and at least one phase with status: "active". Skip entirely for non-lifecycle reviews.

After writing to REVIEW-LOG.md, convert findings to tasks:

Deduplication: Before creating a task, check if a task with matching title AND phase already exists in tasks.json. If so, link the finding to the existing task (update source) instead of creating a duplicate.

Step 7: Next Steps

Do you want to:

1. •Work through the FIX NOW items now
2. •Submit findings as GitHub PRs
3. •Save for later — reports are in outboxes, synthesis in the review log

For PRs: show proposed body to user before submitting. Always include FrontierBoard signature. Check for existing PRs before duplicating.