Problem or Use Case

Problem

When the kanban auto-decomposer fans a triage task into child tasks, the children are created in todo but immediately promoted to ready by a recompute_ready() call at the end of decompose_triage_task(). The dispatcher picks them up on the next tick — no chance for the user to review the task breakdown before work starts.

Some users want a manual dispatch workflow: let the auto-decomposer create the subtask graph, keep the children in todo so they can review each one, then manually promote them to ready when ready. Currently there's no way to achieve this without editing the source.

Additional Context

This feature request was prepared by Erwin's agent (Guts) during a debugging session on the Paros kanban workflow. Erwin uses a manual workflow: the planner profile creates tasks in triage, the auto-decomposer breaks them into subtasks, and then he manually promotes each subtask one at a time — reviewing the worker's output before advancing. The current auto-promotion from todo → ready bypasses this review gate entirely. A config toggle is the minimal intervention that supports both workflows without breaking existing users and the manual-review style.

Proposed Solution

Proposed solution

Add a config option to disable the auto-promotion step after decomposition. Something like:

kanban:
  auto_decompose: true
  decompose_promote_children: false   # new: if false, children stay in todo after decomposition

When decompose_promote_children: true (the default), behavior is unchanged — children go todo → ready and the dispatcher picks them up.

When false, the recompute_ready(conn) call in decompose_triage_task() is skipped. Children stay in todo for user review. They can be manually promoted to ready via the dashboard (drag to Ready column) or via CLI (hermes kanban promote <id>).

The recompute_ready() function still runs in other contexts — when a parent task completes, its dependents still auto-promote from todo to ready. That's correct dependency-resolution behavior. The change is specifically about gating the post-decomposition call behind the new flag.

How It Changes The Flow

New flow with decompose_promote_children: false:

triage ──auto-decompose──→ todo ──[user drags to Ready]──→ ready ──dispatch──→ running

vs. current behavior (unchanged when decompose_promote_children: true):

triage ──auto-decompose──→ todo ──auto-promote──→ ready ──dispatch──→ running

Scope

One config key, one conditional in decompose_triage_task(). The recompute_ready() call on line 2964 of hermes_cli/kanban_db.py is gated by the new flag. Default value is true so existing users see no change. Also add the default in hermes_cli/config.py alongside the existing auto_decompose and auto_decompose_per_tick keys.

Alternatives Considered

1. Unconditional removal — simply delete the recompute_ready() call. Works for the manual workflow but changes default behavior for everyone, which may break existing users who rely on the auto-promotion.

2. Use auto_decompose: false entirely — works if you don't want decomposition either, but forces manual decomposition of every triage task. The proposal here keeps decomposition automatic while making dispatch manual.

Feature Type

Configuration option

Scope

Small (single file, < 50 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)