hermes - 💡(How to fix) Fix [Feature]: Kanban task request for approval

Problem or Use Case

• Sometimes I want to launch a Kanban task pipeline and not be bothered until the end unless there is a big problem.
• Sometimes I want to be able to review the spec, but not the individual implementation phases.
• Sometimes I want to review each individual step to make sure myself there is no drift / creep.
• Sometimes I'd want the orchestrator to decide whether it's worth bothering me or not.
• Sometimes I change my mind about whether I want to review a task, after it's been created.

I feel like there is no nice way to alternate between these workflows. It's possible to curate workflow skills to do one of the above somewhat smoothly, but each small variation needs new / rewriting skills and instructions. Also, such instructions tend to get muddy when levels of child tasks get involved. It's also possible to make a CRON job to watch over the pipeline by polling it every few minutes, but that's not an efficient solution (either spammy or hard to observe, stalls the pipeline between job runs, can't guarantee human review for a specific task, usually can't easily switch the policy once kicked off).

Proposed Solution

Attaching an "approval policy" to tasks.

The crucial part: The approval policy is owned by the task creator / orchestrator. The worker does NOT have any say, in fact it may not even be made aware of it.

The policy is composed of:

• Boolean, approval_required
• Optional string, approver_profile: the profile that will check for approval before human is involved (missing/invalid = human directly)
• Optional string, approver_skill: skill for approver to auto-load

Alternatively: type: "human" | "agent" | null, profile, skill

Taken farther but more elegant: 1:N table of task:approver(type: "human" | "agent", profile, skill, status)

Once the worker finishes, a task with required approval is parked into existing "blocked" or existing "review" or a new "approving" column (exact semantics depend on the direction each column is supposed to take) instead of being marked as Done. Again, the worker does not need to know about it, in its perspective, it just finished the task normally.

If there is a configured approver agent, it is woken up, sees the pending task result, and chooses one of:

• Move the task to Done
• Move the task back to Ready with comment
• Escalate to human review (in some implementations this could be moving the task to Blocked)

If there is no configured approver agent (or if the approver is invalid or otherwise fails), the task waits for human review. Human may move it to Done, move it back to Ready with comment, or re-assign for approver agent to decide.

The approval policy can be changed up to the time the task completes: it's checked when the task naturally finishes. In particular, it can be turned on/off and re-assigned at will from the dashboard.

Example template pipeline that should be easy to teach an agent to reliably copy:

• Task 1: "Write a spec, open PR with it", manual approval requested
• Task 2, child of 1: "Create implementation child tasks according to spec, request approval from agent X on each child task", no approval requested

Task 1 finishes (PR with spec opened): Parked for human approval. User iterates or approves.

Task 2 sees the spec, creates and links child tasks (assigning agent X as approver as explicitly instructed). Finishes and moves to Done directly, readying children immediately.

Whenever any child task finishes, agent X decides if the implementation is satisfactory in regards to the spec. If there is an unexpected problem, work halts. Otherwise, the entire pipeline finishes without human intervention.

Adhoc changes to the pipeline are easy to make: e.g. by turning on human approval for task 2 (or instructing the pipeline builder to do it), we can pause to inspect the created child tasks before launching the implementation.

Possible variant / extension:

• Agent approval sensitivity: Instead of a boolean, a number between 0 and 1 indicates task sensitivity / willingness to escalate to human review. Approver rates the safety of the task output, it's compared with the configured sensitivity. High values = escalate more often. Values of 0 and 1 bypass rating completely.

Alternatives Considered

Teach workers to move their task to correct status.

Problems:

• If done through skills: hard to change / maintain / switch
• If done through task instructions: inconsistent, multiple levels of instruction indirection -> dropped / deformed instructions
• Not guaranteed
• Not quickly observable
• Can't easily switch behavior once running

Feature Type

Other

Scope

Large (new module or significant refactor)

Contribution

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

(not reasonable)

Debug Report (optional)