channel: add 'handoff' verb for terse holder + expected-action view #100

Open
opened 2026-05-26 19:45:45 +00:00 by coilysiren · 0 comments
Owner

Problem

Today's VHGC status check ran coily channel read VHGC --format markdown and got back ~120 lines of charter, onboarding prose, recent events, and the full state payload. The only two things Kai actually needed:

  • Who currently holds the handoff?
  • What are they expected to do?

Plus, ideally: is that holder still alive (last status event within liveness window), and how long since the channel last moved.

read is the right verb when onboarding a new agent. It's the wrong verb when checking "is this channel stuck and on whom." A dedicated terse verb closes that gap.

Proposal

coily channel handoff <id> [--format text|json|yaml]

Text default, one screen:

VHGC  Fix k3s on the desktop tower, then deploy OpenClaw + Qwen3
holder         claude-linux-kai-desktop-tower-wsl-6223
liveness       dead (last status 2.5d ago, window 600s)
expected       Take the handoff. Run agentic-os-kai#719 step 7: read FQDN from
               SSM /coilysiren/kai-desktop-tower/tailnet-fqdn, sed-substitute
               into deploy/openclaw.yml, sudo k3s kubectl apply, then rollout
               status + verify.
last event     #37 comms by claude-linux-kai-desktop-tower-wsl-d664
               2026-05-23T21:54Z (2d 14h ago)
mission        openclaw-deploy: Windows done, WSL-side kubectl apply pending.

Fields, all derived from the newest state event plus the recent event tail:

  • holder - state.handoff.holder.
  • liveness - compare now() against the holder's newest status event timestamp vs status_cadence_seconds (or 600s default). Surface alive / silent / dead.
  • expected - state.handoff.expected_action, wrapped to terminal width.
  • last event - id + kind + author + age of the most recent event of any kind.
  • mission - state.mission line.

--format json|yaml for piping (e.g. fanning out a daily backlog routine to flag every dead channel).

Why now

  • Mobile-first: a dictated "who holds VHGC, what's the next step" should fit on one phone screen, not 120 lines.
  • Doubles as the natural verb a backlog sweep would call to flag stuck channels (holder=dead + age>1d).
  • Cheap: pure projection over data the backend already returns. No new endpoint, no schema change.

Out of scope

  • Listing every channel's holder at once - that's coily channel list (#98) cross-joined with this. Build the list first, then this verb is the per-row drill-down.
  • Auto-kicking dead holders. Surfacing the state is enough; reassignment is a state-event POST by a successor agent, not a CLI action.

Related

  • coilysiren/coily#98 - coily channel list. The pair (list, handoff <id>) covers "what's stuck where" without a full read.
  • otel-a2a-relay channels protocol v2 - state event already carries handoff.holder, handoff.expected_action, mission, status_cadence_seconds. No protocol change.
**Problem** Today's VHGC status check ran `coily channel read VHGC --format markdown` and got back ~120 lines of charter, onboarding prose, recent events, and the full state payload. The only two things Kai actually needed: - Who currently holds the handoff? - What are they expected to do? Plus, ideally: is that holder still alive (last status event within liveness window), and how long since the channel last moved. `read` is the right verb when onboarding a new agent. It's the wrong verb when checking "is this channel stuck and on whom." A dedicated terse verb closes that gap. **Proposal** ``` coily channel handoff <id> [--format text|json|yaml] ``` Text default, one screen: ``` VHGC Fix k3s on the desktop tower, then deploy OpenClaw + Qwen3 holder claude-linux-kai-desktop-tower-wsl-6223 liveness dead (last status 2.5d ago, window 600s) expected Take the handoff. Run agentic-os-kai#719 step 7: read FQDN from SSM /coilysiren/kai-desktop-tower/tailnet-fqdn, sed-substitute into deploy/openclaw.yml, sudo k3s kubectl apply, then rollout status + verify. last event #37 comms by claude-linux-kai-desktop-tower-wsl-d664 2026-05-23T21:54Z (2d 14h ago) mission openclaw-deploy: Windows done, WSL-side kubectl apply pending. ``` Fields, all derived from the newest `state` event plus the recent event tail: - **holder** - `state.handoff.holder`. - **liveness** - compare now() against the holder's newest `status` event timestamp vs `status_cadence_seconds` (or 600s default). Surface `alive` / `silent` / `dead`. - **expected** - `state.handoff.expected_action`, wrapped to terminal width. - **last event** - id + kind + author + age of the most recent event of any kind. - **mission** - `state.mission` line. `--format json|yaml` for piping (e.g. fanning out a daily backlog routine to flag every dead channel). **Why now** - Mobile-first: a dictated "who holds VHGC, what's the next step" should fit on one phone screen, not 120 lines. - Doubles as the natural verb a backlog sweep would call to flag stuck channels (holder=dead + age>1d). - Cheap: pure projection over data the backend already returns. No new endpoint, no schema change. **Out of scope** - Listing every channel's holder at once - that's `coily channel list` (#98) cross-joined with this. Build the list first, then this verb is the per-row drill-down. - Auto-kicking dead holders. Surfacing the state is enough; reassignment is a state-event POST by a successor agent, not a CLI action. **Related** - coilysiren/coily#98 - `coily channel list`. The pair (`list`, `handoff <id>`) covers "what's stuck where" without a full `read`. - otel-a2a-relay channels protocol v2 - state event already carries `handoff.holder`, `handoff.expected_action`, `mission`, `status_cadence_seconds`. No protocol change.
coilysiren added
P4
and removed
P3
labels 2026-05-31 06:59:44 +00:00
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-bridge/coily#100
No description provided.