Add council review report command

docs/implementation-roadmap.md

@@ -31,9 +31,10 @@ As of now:
 - `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
 - `orch council wait` now blocks until the three reviewer tasks reach terminal states or a timeout is reached
 - `orch council tally` now parses completed reviewer outputs, persists `council_findings`, groups recommendations into `consensus`, `majority`, and `minority`, and persists `council_groups`
-- 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/wait/tally behavior
+- `orch council report` now reads persisted `council_groups`, renders human-readable markdown reports, writes markdown artifacts, and persists final report metadata in `council_reports`
+- 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/wait/tally/report behavior
 
-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 three council workflow slices.
+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 full v1 council workflow from start through final report generation.
 
 ## Source Of Truth
 
@@ -76,9 +77,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`, `orch council wait`, and `orch council tally`
+- `Milestone 7: Council Review` is complete
 
-The next practical coding target is the final `Milestone 7` slice: `orch council report`.
+The council review v1 surface is now complete, including final report rendering and metadata persistence.
 
 ### Milestone 1: Go Skeleton
 
@@ -337,32 +338,34 @@ Definition of done:
 
 Status:
 
-- partially complete through `orch council start`, `orch council wait`, and `orch council tally`
+- completed
 
 Completed so far:
 
-- council-specific storage now includes run metadata, reviewer assignment rows, reviewer findings/groups tables, and persisted council input references
+- council-specific storage now includes run metadata, reviewer assignment rows, reviewer findings/groups tables, persisted council input references, and final report metadata
 - `orch council start`
 - `orch council wait`
 - `orch council tally`
+- `orch council report`
 - 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`
 - council wait blocks until all three reviewer tasks reach terminal states or timeout
 - council tally parses structured reviewer outputs from completed reviewer result messages and persists grouped recommendations
-- CLI integration tests cover council start dispatch, metadata persistence, council wait wake/timeout behavior, and council tally grouping in `normal` and `strict` modes
+- council report reads grouped recommendations from persisted `council_groups`, supports `--show` bucket filtering, renders markdown report artifacts, and persists report metadata plus artifact paths
+- CLI integration tests cover council start dispatch, metadata persistence, council wait wake/timeout behavior, council tally grouping in `normal` and `strict` modes, and council report default/all/JSON rendering behavior
 
 Remaining:
 
-- `orch council report`
+- none for the v1 council workflow
 
 ## Immediate Next Task
 
 If a new agent is taking over now, the next concrete step should be:
 
-1. continue `Milestone 7: Council Review` with `orch council report`
-2. define the persisted report artifact shape and how markdown output should be rendered from grouped recommendations
-3. keep the authored inbox test-plan set in `docs/tests/inbox/` synchronized if CLI behavior changes during further `orch` work
+1. treat `Milestone 7: Council Review` as complete unless a new user request introduces a new council capability
+2. keep the authored inbox test-plan set in `docs/tests/inbox/` synchronized if future `orch` work changes shared CLI behavior
+3. choose the next milestone explicitly instead of reopening the completed council v1 slice
 
-The inbox implementation and its human-readable test-plan set are already in place, and `orch` now supports the main scheduler loop plus council start/wait/tally, so the next meaningful project step is rendering final council reports.
+The inbox implementation and its human-readable test-plan set are already in place, and `orch` now supports the main scheduler loop plus the complete council start/wait/tally/report workflow, so any next step should be a new milestone rather than unfinished council v1 work.
 
 ## Recommended Driver Choices
 
@@ -391,11 +394,11 @@ Completed so far:
 - orch council start dispatch and persistence coverage
 - orch council wait wake and timeout coverage
 - orch council tally grouping coverage
+- orch council report default markdown, `--show all`, and JSON shape coverage
 
 Still recommended before the codebase grows too much:
 
 - worktree path generation test
-- council tally grouping test
 
 ## Inbox Test Documentation Roadmap