1.9 KiB
Governed channel handoff
Use this packet only after the source channel has completed and verified its owned outcome:
### Channel handoff
- Handoff ID: <CODE>-HO-<canonical-work-item>-<source>-<destination>-<UTC-minute>
- State: READY | BLOCKED | RETURNED
- Canonical work-item ID: <stable Epic, Feature, Task, or release ID>
- Reader display ID: <project display ID or n/a>
- Source: <source channel>
- Destination: <destination channel mention>
- Completed: <verified source-owned outcome>
- Evidence: <exact messages, records, commits, PRs, CI, or artifacts>
- Requested next action: <one destination-owned action>
- Remaining gates/risks: <explicit list or none>
The destination scans for packets addressed to it, searches its own history for the exact Handoff ID, and processes each ID at most once. Before acting, it verifies the packet evidence and every destination entry gate. A valid packet is acknowledged and continued in the destination's authority boundary. An incomplete or invalid packet is returned as BLOCKED or RETURNED under the same Handoff ID with the missing condition and correct owner. A notification is never lifecycle approval.
The normal forward path is general → scope → architecture → ui-ux when applicable → kanban → delivery → releases → general. Route directly to the actual owner when work begins later, and route backward for defects, contradictions, or missing evidence. General receives final outcomes and cross-cutting exceptions, not every routine transition. Continuations name the parent Handoff ID; never duplicate an already acknowledged transition or copy whole conversations.
A project may add an event-driven dispatcher only through a separately approved project-local authorization and credential contract. The central packet contract does not authorize webhook creation, secret access, scheduler jobs, or automated destination mutation.