# Stage 1: Board of Directors

## Purpose

Strategic go/no-go on each brief. Business alignment, risk assessment, resource allocation.

## Input

- Brief from Intake stage
- **Discovery report** (`00b-discovery/discovery-report.md`) — existing implementations, codebase patterns, constraints
- Project context (existing PRDs, active missions, budget status)

**Discovery-informed decisions:**

- If `feature_status: EXISTS_FULL` → strong signal toward REJECTED or NEEDS REVISION
- If `feature_status: EXISTS_PARTIAL` → scope the go/no-go to the delta work, not the whole feature
- If `feature_status: NOT_FOUND` → proceed as normal greenfield evaluation

## Composition — STATIC

| Role       | Model  | Personality                                                |
| ---------- | ------ | ---------------------------------------------------------- |
| CEO        | Opus   | Visionary. "Does this serve the mission?"                  |
| CTO        | Opus   | Technical realist. "Can we actually build this?"           |
| CFO        | Sonnet | Analytical. "What does this cost vs return?"               |
| COO        | Sonnet | Operational. "Timeline? Resources? Conflicts?"             |
| Contrarian | Sonnet | Devil's advocate. "What if we're wrong about all of this?" |
| Moonshot   | Sonnet | Boundary pusher. "What if we 10x'd this?"                  |

## Process

1. Each board member reads the brief independently
2. Structured 3-phase debate (see debate-protocol.md)
3. Members challenge each other — no rubber-stamping
4. CEO calls for synthesis when debate is converging
5. Dissents are recorded even if overruled

## Memo Content Boundary — CRITICAL

### The Board Memo MUST contain:

- Decision: APPROVED / REJECTED / NEEDS REVISION
- Business constraints (budget ceiling, timeline, priority level)
- Scope boundary (what's in, what's explicitly out)
- Business/strategic risk assessment
- Scheduling constraints (serialize after X, resource conflicts)
- Cost ceiling and time cap
- All dissents with reasoning

### The Board Memo MUST NOT contain:

- Schema designs, data structures, or column types
- Validation approaches or library recommendations
- Auth implementation details
- API design specifics beyond the brief's success criteria
- Any technical prescription that belongs to Planning 1 or Planning 2

The Board identifies RISKS ("schema evolution is a concern") — the architects and specialists design SOLUTIONS. If the memo reads like a technical spec, it has overstepped.

## Output

- Board memo with:
  - Decision: APPROVED / REJECTED / NEEDS REVISION
  - Business constraints (budget, timeline, priority)
  - Risk assessment
  - Dissents (if any)

**The Board does NOT select technical participants.** That's the Brief Analyzer's job (see below).

## On REJECTED

- Brief is archived with rejection rationale
- Human notified
- Pipeline stops for this brief

## On NEEDS REVISION

- Brief returns to Intake with Board feedback
- Intake revises and resubmits to Board

## Brief Analyzer (runs after Board approval)

A separate Sonnet agent analyzes the approved brief + project context to determine:

- Which generalists participate in Planning 1
- Preliminary language/domain signals for Planning 2

This separates strategic decisions (Board) from technical composition (Brief Analyzer).
The Board shouldn't be deciding whether a Security Architect is needed — that's a technical call.

## Post-Run Review

After a pipeline run completes, the Board reviews memos from all stages:

- Analyze for conflicts between stage outputs
- Check scope drift from original brief
- Review cost/timeline variance
- Feed learnings back into future brief evaluation

## Gate: board-approval

### Mechanical

- [ ] Board memo exists
- [ ] Decision is APPROVED
- [ ] Brief Analyzer has produced generalist selection list
- [ ] Generalist selection list is non-empty

### Gate Reviewer

- "Did the Board actually debate, or did they rubber-stamp?"
- "Does the Brief Analyzer's composition make sense for this brief?"
