SubagentStart endpoint + hook: dispatch record and handoff intake #428
Labels
No labels
P0
P1
P2
P3
bug
create
delete
enhancement
filed-by/agent
filed-by/user
frozen
lint-rule
needs-info
needs-triage
next
plugin/cc-architect
plugin/os
plugin/os-adr
plugin/os-aidd-lint
plugin/os-backlog
plugin/os-context
plugin/os-doc-hygiene
plugin/os-sdlc
plugin/os-vault
project/cc-os
ready-for-agent
ready-for-human
recurring
review
update
waiting
wayfinder:grilling
wayfinder:map
wayfinder:map
wayfinder:research
wayfinder:task
wayfinder:task
wontfix
worklist/deviations
worklist/lint-rule
worklist/new-implement-build
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
jared/cc-os#428
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
#428 SubagentStart endpoint + hook: dispatch record and handoff intake
(open)
@jared created 2026-08-18 14:31
Parent
#425
Map: #425
What to build
A SubagentStart hook registered in the plugin hooks manifest with matcher
^os-sdlc:.*$ that posts agent identity (agent_id, agent_type, session_id) to
a new runner Thor command, which inserts a dispatch row against the
session's current implementation and returns the pending handoff for that
agent type; the hook relays it as additionalContext so the agent starts with
its intake. Handoffs are noun-only rows; direction lives on the dispatch
FKs. The per-state brief content-selection logic renders from handoff rows
instead of brief files. Hook stays webhook-thin: parse event, call endpoint,
relay output — no state logic. Run bin/refresh-plugins after plugin-source
edits.
Acceptance criteria
[ ] CLI-seam tests cover dispatch-row creation, handoff fetch by agent type,
and the no-current-implementation loud failure
[ ] a synthetic SubagentStart payload piped through the hook produces the
additionalContext output
[ ] non-os-sdlc agent types never match
Blocked by
#427
Origin
• Trigger: /to-tickets skill on #425 spec
• Improvised this session: none
• Chain: #425 (DESIGN — spec of #425) ← decomposed via /to-tickets user
approval 2026-08-18
• Root candidate: none (this is a decomposition task)
Resolution
Done: New runner Thor command subagent-start SESSION_ID AGENT_TYPE: requires an active implementation for the session (loud failure, exit 3, otherwise), inserts a round dispatch (implementation_id FK, dispatched_at stamped, received_handoff_id when a pending handoff exists) and returns the pending handoff by agent type as JSON. Handoffs are noun-only rows (agent_type, content); direction lives on dispatch FKs. SubagentStart hook registered in hooks.json with matcher ^os-sdlc:.*$ — webhook-thin: parse event, call endpoint, relay stdout as additionalContext (ADR-0128). Round-based intake serves content from handoff rows, not brief files; ticket-driven brief staging untouched. bin/refresh-plugins run.
Evidence: commit
ea8cdfc; full runner suite 298 runs/631 assertions 0 failures; rubocop clean on all touched files; hook tested by piping synthetic SubagentStart JSON (additionalContext asserted) and matcher tested for non-os-sdlc agent typesFollow-ups: captured within map #425: handoff creation path and dispatch completion stamping are the next chain tickets (#429+); handoff consumed/delivered tracking deliberately deferred — no acceptance criterion requires it, revisit only if a later ticket surfaces double-delivery