Add council review tally command

This commit is contained in:
2026-03-19 15:26:11 +08:00
parent dd6a0e31b6
commit 740a7b4acd
7 changed files with 810 additions and 10 deletions
+1
View File
@@ -161,6 +161,7 @@ Suggested flags:
Behavior:
- reads the three reviewer outputs
- parses structured reviewer findings from completed reviewer result messages
- groups proposals by normalized intent
- records supporter count and dissent
- persists grouped recommendations in `orch` storage
+13 -10
View File
@@ -30,9 +30,10 @@ As of now:
- `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
- `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
- 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 behavior
- `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
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 two 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 first three council workflow slices.
## Source Of Truth
@@ -75,9 +76,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` and `orch council wait`
- `Milestone 7: Council Review` is partially complete through `orch council start`, `orch council wait`, and `orch council tally`
The next practical coding target is the next `Milestone 7` slice: `orch council tally`.
The next practical coding target is the final `Milestone 7` slice: `orch council report`.
### Milestone 1: Go Skeleton
@@ -336,31 +337,32 @@ Definition of done:
Status:
- partially complete through `orch council start`
- partially complete through `orch council start`, `orch council wait`, and `orch council tally`
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`
- `orch council wait`
- `orch council tally`
- 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
- CLI integration tests cover council start dispatch, metadata persistence, and council wait wake/timeout behavior
- 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
Remaining:
- `orch council tally`
- `orch council report`
## 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 tally`
2. define how reviewer findings are parsed from completed reviewer outputs into `council_findings`
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
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, so the next meaningful project step is parsing reviewer outputs and implementing tally/report.
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.
## Recommended Driver Choices
@@ -388,6 +390,7 @@ Completed so far:
- orch retry, reassign, cancel, and cleanup coverage
- orch council start dispatch and persistence coverage
- orch council wait wake and timeout coverage
- orch council tally grouping coverage
Still recommended before the codebase grows too much:
@@ -0,0 +1,64 @@
# Orch Council Tally
## Status
- `completed`
## Owner
- codex
## Started At
- `2026-03-19`
## Goal
- implement `orch council tally` so completed reviewer outputs can be parsed, grouped, and persisted as council findings and grouped recommendations
## Scope
- parse reviewer output JSON from completed council reviewer threads
- persist parsed findings into `council_findings`
- group recommendations into `consensus`, `majority`, and `minority` buckets and persist them into `council_groups`
- add integration tests for normal and strict similarity modes
- update the implementation roadmap and archive this workstream when complete
## Checklist
- [x] inspect council tally docs and current council storage
- [x] implement council tally store and CLI command
- [x] add integration coverage for normal and strict tally behavior
- [x] run `go test ./...`
- [x] update `docs/implementation-roadmap.md`
- [x] archive this roadmap with a completion summary
## Files
- `docs/roadmaps/archive/orch-council-tally.md`
- `docs/implementation-roadmap.md`
- `docs/council-review.md`
- `internal/store/council.go`
- `internal/cli/orch/council.go`
- `internal/cli/orch/council_tally.go`
- `internal/cli/orch/integration_test.go`
## Decisions
- read reviewer outputs from the latest `result` message on each reviewer thread
- require reviewer outputs to be valid structured JSON before tallying
- use a simple normalized proposal grouping strategy for v1, with `strict` preserving wording differences and `normal` grouping by normalized intent tokens
## Blockers
- none
## Next Step
- move on to `orch council report`
## Completion Summary
- `orch council tally` now parses structured reviewer output JSON from completed reviewer result messages
- parsed reviewer findings are persisted into `council_findings`, and grouped recommendations are persisted into `council_groups`
- tally supports `normal` and `strict` similarity modes and computes `consensus`, `majority`, and `minority` buckets