feat(kanban): add resolve-fanin command for review verdicts

[verybigdog]

Summary

• Add hermes kanban resolve-fanin for turning review/fan-in task results into a canonical GO/BLOCK/NEED_MORE verdict.
• Support dry-run previews and an execute path that can complete successful fan-ins or create a follow-up remediation task for BLOCK/NEED_MORE.
• Keep the command generic to Kanban; it does not depend on gateway delivery, AgentFlow, or any local deployment policy.

Safety / behavior

• Dry-run by default; side effects require --execute.
• Conflicting side-effect flags fail closed.
• Missing/unknown review verdicts return NEED_MORE rather than silently completing.

Test Plan

• git diff --check origin/main..HEAD
• python3 -m py_compile hermes_cli/commands.py hermes_cli/kanban.py hermes_cli/kanban_resolver.py
• python3 -m pytest tests/hermes_cli/test_kanban_resolve_fanin.py -q -o 'addopts='

Relationship to active handoff work

This is intentionally separate from #37865. That PR adds the explicit active-wake messaging primitive; this PR is only the generic Kanban fan-in resolver command.

[tonydwb]

Code Review Summary

Verdict: Comment — High surface area

This PR introduces a new resolve-fanin command (775 additions, 1 deletion, affects multiple files). In its current state this is a high-surface-area change that touches CLI argument parsing, kanban command dispatch, and the resolver logic.

Observations

• The new command is well-structured with --dry-run / --apply mutually exclusive modes
• Ledger JSON output is emitted regardless of --json flag — good for downstream tooling
• The --fix-assignee, --review-assignee, and --reporter-assignee parameters provide clear ownership

Suggestions for formal review

• Add integration tests exercising the --apply path with a real kanban database fixture
• Document the classification heuristics in kanban_resolver for maintainability
• Consider adding a --max-fan-in-threshold parameter to bound automatic remediation scope

Please split into smaller, independently reviewable commits (CLI wiring, resolver core, tests) for a faster formal review turnaround.

Reviewed by Hermes Agent

[verybigdog]

Addressed the review feedback in the updated head (f43564d7829a47419c3d990c297f9eb57e395e1b):

• Split the original single commit into smaller reviewable commits:
  1. resolver core
  2. CLI wiring
  3. tests
• Documented the classification heuristics and safety boundary in kanban_resolver.py.
• Added --max-fan-in-threshold to bound automatic --apply remediation scope; oversized graphs now return BLOCKED and write nothing unless the operator raises the threshold explicitly.
• Expanded real temp-Kanban-DB apply-path coverage for threshold BLOCK, explicitly raised threshold success, and invalid threshold no-write behavior.

Verification run locally:

python -m pytest -q tests/hermes_cli/test_kanban_core_functionality.py tests/hermes_cli/test_kanban_notify.py tests/hermes_cli/test_kanban_cli.py tests/hermes_cli/test_kanban_resolve_fanin.py -o 'addopts='
# 237 passed in 7.47s

git diff --check origin/main...HEAD
# OK

[teknium1]

Thanks for separating the resolver, CLI wiring, and tests. There is one blocking integration issue with the current Kanban review contract.

Problems

• hermes_cli/kanban_resolver.py:424 creates the fix with parents=[final_task_id]. Current main's documented review handoff is kanban_block(reason="review-required: ...") (website/docs/user-guide/features/kanban-worker-lanes.md:63), and those blocks are intentionally sticky (hermes_cli/kanban_db.py:3324-3329). A child with a non-done parent becomes todo (hermes_cli/kanban_db.py:2599-2606), while dispatch only considers ready tasks (hermes_cli/kanban_db.py:7326-7330). Thus an applied remediation pair cannot run for the review-required case it is intended to resolve.
• The fixture completes the final review at tests/hermes_cli/test_kanban_resolve_fanin.py:54-59, so it bypasses this production path.

Suggested changes

• Rework the graph/state handling so remediation is runnable while preserving the blocked review handoff.
• Add a real blocked review-required apply-and-dispatch regression test.

Automated hermes-sweeper review.

[teknium1]

This makes remediation depend on the final review task. The documented review-required flow leaves that task sticky-blocked, so create_task() will place this child in todo; dispatcher selection is limited to ready tasks. Please rework the relationship/state transition so the fix can run without requiring the blocked review handoff to be completed first.

[verybigdog]

M28.3 remediation pushed: 828fdf1

What changed:

• resolve-fanin --apply no longer parents the generated fix card to the sticky blocked final review task. The runnable graph is now fix (ready) -> fix-review (todo) -> optional reporter (todo), while the original blocked review-required final remains preserved/auditable.
• The final review card gets a sanitized remediation-created: fix=... fix_review=... audit comment instead of a dependency edge.
• Added a real temp-Kanban-DB regression starting from a blocked review-required final: it runs the CLI apply path, verifies the fix is dispatchable, dispatches/completes fix and review via dispatch_once, and proves the original final stays blocked with its BLOCK verdict unchanged.

Verification:

• python3 -m py_compile hermes_cli/kanban_resolver.py tests/hermes_cli/test_kanban_resolve_fanin.py
• scripts/run_tests.sh tests/hermes_cli/test_kanban_resolve_fanin.py -> 12 passed
• scripts/run_tests.sh tests/hermes_cli/test_kanban*.py -> 743 passed
• git diff --check origin/main...HEAD -> clean
• git merge-tree --write-tree origin/main HEAD -> clean

Mergeability: PR head is rebased onto current origin/main (569b912); GitHub reports mergeable=MERGEABLE, mergeStateStatus=BLOCKED with no check rollup reported.

Verdict: GO-for-review.

[verybigdog]

Verdict: GO

Reviewed PR #40465 head 828fdf1 against origin/main 569b912.

Verified:

• Sticky blocked review-required final smoke: dry-run writes nothing; threshold block writes nothing; apply creates a ready fix card with no parent on the blocked final; fix-review is gated behind fix; audit comment points from final to remediation; repeated apply is idempotent; dispatch_once claims the generated fix and promotes fix-review after fix completion.
• python3 -m py_compile hermes_cli/kanban_resolver.py tests/hermes_cli/test_kanban_resolve_fanin.py
• scripts/run_tests.sh tests/hermes_cli/test_kanban_resolve_fanin.py -> 12 passed
• scripts/run_tests.sh tests/hermes_cli/test_kanban*.py -> 743 passed
• git diff --check origin/main...HEAD -> clean
• git merge-tree --write-tree origin/main HEAD -> clean
• verybigdog/contrib/kanban-resolve-fanin points at 828fdf1

Findings: none blocking.

Risk: GitHub still reports mergeable=MERGEABLE but mergeStateStatus=BLOCKED with empty statusCheckRollup, so repository branch-protection/status gates may still need to report green before merge.