Summary

Two related gaps in the kanban completion-summary path that together break any cron/agent pipeline keying on tasks.result:

1. Dashboard "Complete" button silently bypasses the summary modal on Blocked-lane tickets — completes with summary: null, result_len: 0.
2. No CLI path to backfill result after completion — kanban complete refuses to re-run on done tickets, and there is no kanban edit --result / kanban resummarize subcommand. Recovery currently requires raw SQLite UPDATE.

Reproduction (bug 1)

Hermes commit b816fd4e2, board with a ticket assigned to a non-agent identity (e.g. a human username), in blocked state.

1. Open the ticket detail panel in the dashboard.
2. Click the "Complete" button (NOT drag to a Done lane).
3. Expected: a modal opens with a "Completion summary" textarea.
4. Actual: ticket transitions to done immediately. No modal. tasks.result is NULL.

DB-confirmed event payload on three tickets in the same session (board: minerva):

1777949497 completed {"result_len": 0, "summary": null}

Tickets affected in repro: t_85cb3f55, t_1f9afea6, t_bae7bbe0. The first was completed via the button; the latter two via drag-to-Done. Both paths produced the same null-summary outcome, suggesting the modal is failing to mount rather than the button being miswired.

Reproduction (bug 2)

After bug 1 leaves a ticket in done with result=NULL:

$ hermes kanban --board minerva complete t_85cb3f55 --summary "DECIDED ..."
cannot complete t_85cb3f55 (unknown id or terminal state)

$ hermes kanban --board minerva edit t_85cb3f55 --result "..."
hermes kanban: error: argument kanban_action: invalid choice: 'edit'

The only working recovery path is direct DB write:

con.execute("UPDATE tasks SET result=? WHERE id=?", (summary, task_id))

This is not a path most users should be expected to know about.

Why this matters

We're standing up a cron sweep that reads tasks.result for a DECIDED <date>: ... prefix to auto-reflect human decisions into a wiki. With bug 1, every dashboard-completed ticket arrives with result=NULL and the sweep has nothing to consume. With bug 2, there's no graceful recovery — ops staff have to run raw SQL.

Comments on the ticket ARE preserved through the completion path, but the cron wants structured summary, not free-form comment text.

Suggested fixes

• Bug 1: Investigate why the Completion-summary modal isn't mounting on Complete button click for Blocked-lane (and possibly all-lane) tickets. Possibly a recent regression — worth bisecting against the dashboard JS bundle.
• Bug 1 (defensive): If the modal can't open for some reason, fall back to a confirm dialog rather than silently completing with null summary. Or refuse the complete action and show an error.
• Bug 2: Add hermes kanban edit <task_id> --result <text> (or kanban resummarize <task_id> <text>) to allow backfilling result on done tickets without raw SQL. Should emit an edited event for audit trail.

Environment

• Hermes commit: b816fd4e2
• Host: placer-jy01 (Linux)
• Board: minerva (multi-board scaffolding, post commit 5ec6baa40)
• Browser: dashboard accessed via gateway at default port

Workaround currently in use

CLI is the canonical path until both bugs are fixed:

hermes kanban --board <slug> complete <task_id> \
  --summary "DECIDED <YYYY-MM-DD>: <one-line outcome>. Wiki: <relative-path>"

Documented in the local kanban-orchestrator skill.