Epic-lead Slice C — Coordination signals epic_delegate / epic_return (#226)

You are being dispatched from flower Brief #233: Epic-lead Slice C — Coordination signals epic_delegate / epic_return (#226)

Recall pointer:
- Use recall_brief with id 233 for the full folder if you need provenance.

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/233-epic-lead-slice-c
- worktree: not specified
- kind: fresh

Current brief spec:
# Slice C — Coordination signals: epic_delegate / epic_return

Parent epic: #226. Design: `docs/design/226-epic-lead-orchestration.md` (§Coordination protocol). **Depends on Slice A (#231); parallel to B.** Target ≤~300 lines.

## Deliverable
1. **Two new kinds** on `CoordinationQueue` (:18-28): `KIND_EPIC_DELEGATE = 'epic_delegate'` (MAIN→lead), `KIND_EPIC_RETURN = 'epic_return'` (lead→MAIN). `kind` is free-form `string(64)` — **no migration, no enum, no allowlist**.
2. **Enqueue helpers — the load-bearing reset-robust rule:** `enqueueEpicDelegate(project, payload, requestedBy)` / `enqueueEpicReturn(project, payload, requestedBy)` enqueue **project-scoped with `target_daemon_id = null`**, keyed on `payload.epic_brief_id`. Rationale (critical): `excludePendingHeldForReset()` (:438) hides pending signals whose target daemon has `reset_pending=true`, and **`reset_pending` is never cleared on close/retire** — so a daemon-targeted signal is hidden forever after that lead retires. Null-target takes the `orWhereNull('target_daemon_id')` branch (:442) → always visible → genuinely reset-robust. **Keep both OUT of `resetLifecycleKinds()`** (:451) — null-targeting already keeps them visible.
3. **Lead drains `epic_delegate`** — each heartbeat, fetch project pending signals, filter client-side to `kind=epic_delegate AND payload.epic_brief_id=<mine>`, claim → act → complete. No code role/baton gate on `signal_claim` (`assertCanDrainOrMerge` is convention only, never called in `app/`), so this works as-is + a charter carve-out (Slice B).
4. **MAIN drains `epic_return`** — new per-kind clause in `AgentConventions::daemonLines()` (:59): `action:merge` → run the single epic→master merge (Slice D); `action:retire` → close the lead (Slice F). Plus the baton carve-out note.
5. **Liveness** — the lead **re-enqueues `epic_return` idempotently each heartbeat until it observes the state change** (merge landed / lead closed); dedupe collapses repeats. No reconciler needed.
6. **Optional** — thin MCP wrappers `epic_delegate`/`epic_return` (register in `FlowerServer`); a `kind`+`epic_brief_id` server-side filter on `recall_signals` to lean the lead's poll.

## Tests
- Enqueue/dedupe by epic (same epic → one pending row).
- **A pending signal survives the target lead's retire (never-cleared `reset_pending`) and a successor lead drains it** — the reset-robustness guarantee.
- MAIN drains `epic_return`; re-enqueue is idempotent.

## Notes
- This slice resolves the two protocol blockers found in the design review — do not regress to daemon-targeted enqueue.

Recent/key trace events:
[1] participant_joined flower-226-worker: (no body)
[2] note_added flower-226-worker: # Slice C — Coordination signals: epic_delegate / epic_return

Design: `docs/design/226-epic-lead-orchestration.md` (§Coordination protocol). Depends on Slice A; parallel to B. Target ≤~300 lines.

## Deliverable
1. **Two new kinds** on `CoordinationQueue` (:18-28): `KIND_EPIC_DELEGATE = 'epic_delegate'` (MAIN→lead), `KIND_EPIC_RETURN = 'epic_return'` (lead→MAIN). `kind` is free-form `string(64)` — **no migration, no enum, no allowlist**.
2. **Enqueue helpers — the load-bearing reset-robust rule:** `enqueueEpicDelegate(project, payload, requestedBy)` / `enqueueEpicReturn(project, payload, requestedBy)` enqueue **project-scoped with `target_daemon_id = null`**, keyed on `payload.epic_brief_id`. Rationale (critical): `excludePendingHeldForReset()` (:438) hides pending signals whose target daemon has `reset_pending=true`, and **`reset_pending` is never cleared on close/retire** — so a daemon-targeted signal is hidden forever after that lead retires. Null-target takes the `orWhereNull('target_daemon_id')` branch (:442) → always visible → genuinely reset-robust. **Keep both OUT of `resetLifecycleKinds()`** (:451) — null-targeting already keeps them visible.
3. **Lead drains `epic_delegate`** — each heartbeat, fetch project pending signals, filter client-side to `kind=epic_delegate AND payload.epic_brief_id=<mine>`, claim → act → complete. No code role/baton gate on `signal_claim` (`assertCanDrainOrMerge` is convention only, never called in `app/`), so this works as-is + a charter carve-out (Slice B).
4. **MAIN drains `epic_return`** — new per-kind clause in `AgentConventions::daemonLines()` (:59): `action:merge` → run the single epic→master merge (Slice D); `action:retire` → close the lead (Slice F). Plus the baton carve-out note.
5. **Liveness** — the lead **re-enqueues `epic_return` idempotently each heartbeat until it observes the state change** (merge landed / lead closed); dedupe collapses repeats. No reconciler needed.
6. **Optional** — thin MCP wrappers `epic_delegate`/`epic_return` (register in `FlowerServer`); a `kind`+`epic_brief_id` server-side filter on `recall_signals` to lean the lead's poll.

## Tests
- Enqueue/dedupe by epic (same epic → one pending row).
- **A pending signal survives the target lead's retire (never-cleared `reset_pending`) and a successor lead drains it** — the reset-robustness guarantee.
- MAIN drains `epic_return`; re-enqueue is idempotent.

## Notes
- This slice is where the two protocol blockers found in the design review are resolved — do not regress to daemon-targeted enqueue.
[3] parent_set flower-226-worker: Grouped under epic #226.
[4] dependency_added flower-226-worker: Now depends on #231 (Epic-lead Slice A — Lead identity & roster scaffolding (#226)).
[5] plan_proposed flower-226-worker: # Slice C — Coordination signals: epic_delegate / epic_return

Parent epic: #226. Design: `docs/design/226-epic-lead-orchestration.md` (§Coordination protocol). **Depends on Slice A (#231); parallel to B.** Target ≤~300 lines.

## Deliverable
1. **Two new kinds** on `CoordinationQueue` (:18-28): `KIND_EPIC_DELEGATE = 'epic_delegate'` (MAIN→lead), `KIND_EPIC_RETURN = 'epic_return'` (lead→MAIN). `kind` is free-form `string(64)` — **no migration, no enum, no allowlist**.
2. **Enqueue helpers — the load-bearing reset-robust rule:** `enqueueEpicDelegate(project, payload, requestedBy)` / `enqueueEpicReturn(project, payload, requestedBy)` enqueue **project-scoped with `target_daemon_id = null`**, keyed on `payload.epic_brief_id`. Rationale (critical): `excludePendingHeldForReset()` (:438) hides pending signals whose target daemon has `reset_pending=true`, and **`reset_pending` is never cleared on close/retire** — so a daemon-targeted signal is hidden forever after that lead retires. Null-target takes the `orWhereNull('target_daemon_id')` branch (:442) → always visible → genuinely reset-robust. **Keep both OUT of `resetLifecycleKinds()`** (:451) — null-targeting already keeps them visible.
3. **Lead drains `epic_delegate`** — each heartbeat, fetch project pending signals, filter client-side to `kind=epic_delegate AND payload.epic_brief_id=<mine>`, claim → act → complete. No code role/baton gate on `signal_claim` (`assertCanDrainOrMerge` is convention only, never called in `app/`), so this works as-is + a charter carve-out (Slice B).
4. **MAIN drains `epic_return`** — new per-kind clause in `AgentConventions::daemonLines()` (:59): `action:merge` → run the single epic→master merge (Slice D); `action:retire` → close the lead (Slice F). Plus the baton carve-out note.
5. **Liveness** — the lead **re-enqueues `epic_return` idempotently each heartbeat until it observes the state change** (merge landed / lead closed); dedupe collapses repeats. No reconciler needed.
6. **Optional** — thin MCP wrappers `epic_delegate`/`epic_return` (register in `FlowerServer`); a `kind`+`epic_brief_id` server-side filter on `recall_signals` to lean the lead's poll.

## Tests
- Enqueue/dedupe by epic (same epic → one pending row).
- **A pending signal survives the target lead's retire (never-cleared `reset_pending`) and a successor lead drains it** — the reset-robustness guarantee.
- MAIN drains `epic_return`; re-enqueue is idempotent.

## Notes
- This slice resolves the two protocol blockers found in the design review — do not regress to daemon-targeted enqueue.
[6] participant_joined flower-231-worker: (no body)
[7] unblocked flower-231-worker: Unblocked — #231 reached complete.
[8] participant_joined flower-orchestrator: (no body)
[9] status_change flower-orchestrator: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": []
}

Execution notes:
- Treat the brief as the source of truth.
- Keep work scoped to this dispatch request.
- Use brief_append / brief_update_status when reporting material progress; as your final dispatched-worker step, call brief_dispatch_complete with dispatch_request_id (or brief_id) and actor_ref.
- Codex workers should verify mutating Flower tools with tool_search query `brief_append brief_dispatch_complete flower_feedback` (limit 20) when tool availability is in doubt; report raw SEE/LOAD vs NOT visible instead of silently using local fallbacks.
- Add a git commit trailer `Brief: #233` to every commit for this brief so flower can exact-link commits back to the brief.