Kanban review status exists but has no first-class request-review transition

[VirtualAgentics]

Summary

Hermes Kanban already has a real review task status and dispatcher support for claiming review -> running tasks, but normal worker/CLI lifecycle paths do not expose a supported way to move a completed implementation task into that review state.

As a result, review workflows are forced into awkward workarounds:

• workers block with free-form review-required: reasons,
• orchestrators create separate reviewer child cards,
• implementer cards are completed as “handoff only” even though the actual work is not accepted yet,
• downstream dependencies have to be manually gated on the reviewer card to avoid premature promotion.

This makes the dashboard’s review column look available, but hard to use correctly from the normal task lifecycle.

Current behaviour

In the current codebase:

• hermes_cli/kanban_db.py includes review in VALID_STATUSES.
• The dispatcher has explicit review-column handling:
  • selects tasks where status = 'review',
  • claims them via claim_review_task(),
  • transitions them from review -> running,
  • spawns a reviewer worker.
• hermes kanban --help exposes no review, request-review, or similar CLI command.
• Worker tools expose kanban_complete and kanban_block, but no kanban_request_review / kanban_submit_for_review tool.
• complete_task() transitions running|ready|blocked -> done, not running -> review.
• hermes kanban stats prints status counts for triage, todo, scheduled, ready, running, blocked, and done, but omits review even though it is a valid status.
• Review dispatch appears PR/SDLC-specific and hard-codes claimed.skills = ["sdlc-review"]; that skill may not exist in all installations and is too narrow for non-PR Kanban review workflows.

Why this matters

The natural Kanban workflow is one card moving through a lifecycle:

todo -> ready -> running/implementation -> review -> running/reviewer -> done

If the reviewer requests changes, the same card should be routed back to the implementer with review comments/evidence:

review -> ready/running implementer fix -> review again

Without a first-class transition into review, users and agents have to model one logical card as multiple physical cards:

• implementer card,
• reviewer card,
• fix card,
• re-review card,
• extra gates for downstream children.

That preserves safety, but it creates board clutter and makes automation brittle. It also makes done ambiguous: an implementation card may be marked done merely to unblock a review handoff, not because the feature is accepted.

For autonomous multi-profile Kanban, this is a governance issue as much as a UX issue. Review gates should be explicit, auditable, and easy for workers to request without relying on prose conventions or manual orchestration.

Expected behaviour

Hermes should provide a first-class request-review lifecycle operation.

Possible CLI shape:

hermes kanban request-review <task_id> \
  --reviewer edith \
  --summary "Implementation complete; targeted tests passing; needs independent review" \
  --metadata '{"changed_files": [...], "tests_run": [...]}'

Possible worker tool shape:

kanban_request_review(
    reviewer="edith",
    summary="Implementation complete; targeted tests passing; needs independent review",
    metadata={
        "changed_files": [...],
        "tests_run": [...],
        "artifacts": [...]
    }
)

The operation should:

1. Validate task ownership when called by a dispatcher-spawned worker.
2. Transition running|ready|blocked -> review.
3. End the implementer’s current run with an outcome like submitted_for_review, not completed.
4. Persist review metadata on the run/event stream.
5. Assign or otherwise route the reviewer profile.
6. Clear the implementer claim so the dispatcher can claim the review phase.
7. Keep downstream child tasks waiting until final reviewer approval moves the card to done.

Reviewer outcomes

The reviewer should have explicit audited outcomes, for example:

Approve:

review/running -> done

Request changes:

review/running -> ready
assignee -> original implementer
comment/review metadata records requested changes

Escalate:

review/running -> blocked
reason/category -> human_required or policy_decision_required

The exact API names are flexible; the key requirement is that review is a first-class state transition, not a prose convention.

Review skill/configuration

Review dispatch should not hard-code a missing or overly specific skill.

Possible options:

• Use a configured default review skill, with a fail-closed check if it is missing.
• Preserve task-requested review skills from the request-review call.
• Default to an existing general review skill such as requesting-code-review where appropriate.
• Allow non-code review workflows, e.g. policy review, memory safety review, ops/config review, or research verification.

Small related CLI/UI bug

hermes kanban stats should include review in the printed status list, since review is part of VALID_STATUSES and is dispatchable.

Prior related issues

• Kanban review-column dispatch lacks a first-class transition path and references missing sdlc-review skill #38783 — exact prior report: “Kanban review-column dispatch lacks a first-class transition path and references missing sdlc-review skill”. Closed administratively with “do not triage from this issue”, so it should not be treated as the active tracker.
• [Feature]: Kanban task request for approval #29457 — broader open feature request for Kanban task approval policy.
• Kanban needs first-class waiting states for human, approval, and review gates #29171 — broader closed/deferred request for first-class waiting states, including review gates.
• Kanban approval comments do not resume work; completed status does not satisfy dependencies #31717 — adjacent issue around approval comments and status/dependency continuation.
• feat(swarm): support custom verifier/synthesizer body + skills #34273 — adjacent issue around custom verifier/reviewer skills in swarm workflows.

This issue is intentionally narrower than the broader approval-policy work: the review status already exists, but the normal lifecycle lacks a supported way to enter and use it.

Acceptance criteria

• Add CLI support for moving a task into review, with reviewer assignment and structured metadata.
• Add a worker tool for requesting review from the current task.
• Add DB tests for running -> review and review metadata persistence.
• Add dispatcher tests proving review tasks are claimed and spawned with an existing/configured review skill.
• Add reviewer outcome tests for approve, request-changes, and escalate/block.
• Ensure downstream dependencies are satisfied only after final approval/done, not after implementation handoff.
• Include review in CLI/dashboard status counts and filters where missing.

Environment

Observed on a local Hermes checkout on the main branch while operating the Kanban board with multiple profiles (u as implementer, edith as reviewer). The issue is visible from source inspection and from live Kanban workflows that currently require extra reviewer/fix cards to represent one logical implementation-review loop.

[alt-glitch]

Duplicate of #38783 (Kanban review-column dispatch lacks a first-class transition path and references missing sdlc-review skill) — same root cause. Related open work: #28798 (dashboard move-to-review), #30967 (human_review status + tools).

[liuhao1024]

This is fixed by #43060 — adds request_review transition (running → review) to kanban.

[liuhao1024]

Fixed in #43060

[ahmadashfq]

We just finished a local upstreamability + overlap pass over related Kanban review-lifecycle work. The current evidence says this area should stay converged on the existing review-transition threads, not grow a fourth competing PR.

Local state we verified:

• the replayable local core candidate still mixes review transition work with parent-wait and liveness/resume changes
• the stacked tool candidate (fix(tools): route kanban review holds truthfully) depends on that mixed core branch rather than standing alone
• both candidates need rebase/cherry-pick isolation before they are suitable for an upstream submission path

Overlap verdict from this pass:

• exact issue thread: Kanban review status exists but has no first-class request-review transition #42896
• exact PR thread to converge on by default: feat(kanban): add request_review transition + review lifecycle #49368
• smaller alternate reference: feat(kanban): add request_review transition (running → review) #43060
• go/no-go: NO-GO for opening any fresh review-transition PR from this local stack right now

Reason: the local work is not yet a clean non-duplicative slice, and upstream already has open review-transition implementations in #43060 and #49368. If this work continues, the non-duplicative path is to reconcile against those PRs first and only re-split if maintainers explicitly ask for a narrower extraction.