Add council review start command

docs/implementation-roadmap.md

@@ -28,9 +28,10 @@ As of now:
 - `orch` can create runs, gate tasks through dependencies, dispatch work through `inbox`, reconcile worker thread state back into task state, answer blocked tasks, retry or reassign work, cancel tasks or runs, clean attempt worktrees, and create per-attempt Git worktrees during strict dispatch
 - `orch dispatch` now supports `--repo-path`, `--workspace-root`, and `--strict-worktree`, auto-enables strict worktree mode for code-like tasks inferred from task metadata, resolves committed base revisions, records workspace metadata on attempts, and writes that metadata into inbox task payloads
 - `orch wait` now blocks on run-scoped task events and reconciles inbox state while polling so leader waits can wake on worker progress without manual sleep loops
-- automated integration tests now cover the main `orch` scheduler slice, including dependency gating, dispatch, blocked-answer flow, retry, reassign, cancel, cleanup, strict worktree creation, automatic code-task worktree enablement, dirty-repo rejection rules, and wait wake/timeout behavior
+- `orch council start` now creates a dedicated council run, persists council target input metadata, and dispatches the three fixed reviewer roles through the existing scheduler
+- automated integration tests now cover the main `orch` scheduler slice, including dependency gating, dispatch, blocked-answer flow, retry, reassign, cancel, cleanup, strict worktree creation, automatic code-task worktree enablement, dirty-repo rejection rules, wait wake/timeout behavior, and council start dispatch
 
-This means the project now has a working `orch` core scheduler with automatic worktree selection for code-like tasks, strict worktree-backed dispatch, and the main leader-side control loop, and is ready for council workflows.
+This means the project now has a working `orch` core scheduler with automatic worktree selection for code-like tasks, strict worktree-backed dispatch, the main leader-side control loop, and the first council workflow slice.
 
 ## Source Of Truth
 
@@ -73,8 +74,9 @@ Current implementation status:
 - `Milestone 4: Orch Core Scheduling` is complete for the current non-worktree scheduler scope
 - `Milestone 5: Strict Worktree Support` is complete
 - `Milestone 6: Waiting Primitives` is complete
+- `Milestone 7: Council Review` is partially complete through `orch council start`
 
-The next practical coding target is `Milestone 7: Council Review`.
+The next practical coding target is the next `Milestone 7` slice: `orch council wait`.
 
 ### Milestone 1: Go Skeleton
 
@@ -331,15 +333,32 @@ Definition of done:
 - tally grouped recommendations into `consensus`, `majority`, and `minority`
 - produce stable JSON and a markdown report artifact
 
+Status:
+
+- partially complete through `orch council start`
+
+Completed so far:
+
+- council-specific storage now includes run metadata, reviewer assignment rows, reviewer findings/groups tables, and persisted council input references
+- `orch council start`
+- council start creates a dedicated run, stores council target input metadata, creates reviewer tasks `CR1` through `CR3`, and dispatches the fixed reviewer roles `architecture-reviewer`, `implementation-reviewer`, and `risk-reviewer`
+- CLI integration tests cover council start dispatch and metadata persistence
+
+Remaining:
+
+- `orch council wait`
+- `orch council tally`
+- `orch council report`
+
 ## Immediate Next Task
 
 If a new agent is taking over now, the next concrete step should be:
 
-1. start `Milestone 7: Council Review`
-2. define the persisted storage shape for grouped reviewer recommendations and council wake/tally state
+1. continue `Milestone 7: Council Review` with `orch council wait`
+2. define the council completion check that determines when all reviewer outputs are ready for tally
 3. keep the authored inbox test-plan set in `docs/tests/inbox/` synchronized if CLI behavior changes during further `orch` work
 
-The inbox implementation and its human-readable test-plan set are already in place, and `orch` now supports the main scheduler loop plus automatic worktree selection for code-like tasks, so the next meaningful project step is the council workflow layer.
+The inbox implementation and its human-readable test-plan set are already in place, and `orch` now supports the main scheduler loop plus the first council workflow slice, so the next meaningful project step is finishing council wait, tally, and report.
 
 ## Recommended Driver Choices
 
@@ -365,6 +384,7 @@ Completed so far:
 - orch strict worktree creation and dirty-repo policy coverage
 - orch wait wake and timeout coverage
 - orch retry, reassign, cancel, and cleanup coverage
+- orch council start dispatch and persistence coverage
 
 Still recommended before the codebase grows too much: