Feedback #75: Live table rename (#116 brief_questions→decisions) broke question-handling in all pre-rename long-running daemon MCP sessions (cached code)

You are being dispatched from flower Brief #167: Feedback #75: Live table rename (#116 brief_questions→decisions) broke question-handling in all pre-rename long-running daemon MCP sessions (cached code)

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/167-schema-rename-daemon-reload
- worktree: not specified
- kind: fresh

Current brief spec:
## Ask
Prevent schema-changing migrations (especially table/column **renames** like #116 `brief_questions`→`decisions`) from silently breaking standing long-running daemon MCP sessions that cache pre-migration code. Deliver a documented procedure and, if cheap, a lightweight automated reload nudge.

## Context (Feedback #75)
After #116 renamed `brief_questions`→`decisions` and the migration ran on live MAIN, the **pre-rename** daemon MCP servers (orch 19/proc 1055, refine 1040, ops 1054) kept the OLD cached code and threw `SQLSTATE[42S02] Table flower.brief_questions doesn't exist` on `brief_open_questions` / `brief_ask` / `recall_brief`'s Q&A section. NEW workers spawned post-rename were fine (fresh code); non-question MCP calls (brief_append/create/dispatch, signal_*, recall_active/roster/search) were unaffected, so merge/dispatch orchestration kept working. It **self-heals on each daemon's next reset** (fresh MCP process).

We already ship the relevant primitives: make-before-break reset (`daemon_request_reset`/`daemon_start_reset`), `flower:horizon-reload` (#191, canonical graceful Horizon reload), daemon-checkin project resolution (#104), and the durable coordination-signal queue.

## Deliverable — keep SMALL
1. **Procedure doc (required):** add the canonical "schema-rename with standing daemons" playbook to the right home (`CLAUDE.md` Runtime & pipeline notes, and/or `_flower-playbook.md`). Rule of thumb: run schema renames in a daemon-quiet window and/or immediately follow the migration with a coordinated standing-daemon reload, leaning on the existing reset + `flower:horizon-reload` tooling. Note which MCP calls are/aren't affected and that resets self-heal.
2. **Automated post-migrate reload nudge (optional — only if genuinely low-effort):** after a schema-changing migration on MAIN, enqueue a coordination signal (reuse an existing kind, e.g. a reset/route hint, or a minimal new `schema_reload` hint) to standing non-orchestrator daemons (refine/ops) so their MCP reloads without waiting for a natural reset. MUST fail-safe/no-op when there are no standing daemons.

## Out of scope
Query-time stale-schema auto-detection or MCP self-reconnect (larger; leave a follow-up brief note if it seems warranted). Do NOT build a heavy framework.

## Acceptance
- Procedure is documented where daemons/operators will actually find it.
- If the nudge is built: a schema-changing migration enqueues reload signals for standing daemons; verified no-op with zero daemons; `php artisan test` green; `./vendor/bin/pint` clean on touched files.
- Finish with `brief_dispatch_complete` (+ `brief_append` merged note) and a `Brief: #167` trailer on every commit.

Recent/key trace events:
[1] participant_joined flower-ops: (no body)
[2] note_added flower-ops: Feedback #75
Authority: OPERATOR APPROVAL REQUIRED
Funnel: A - operator approved brief
Gate: this brief must not be dispatchable until the operator approves it.
Kind: idea
Source: flower-orchestrator

Summary:
Live table rename (#116 brief_questions→decisions) broke question-handling in all pre-rename long-running daemon MCP sessions (cached code)

Detail:
After merging #116 (rename brief_questions→decisions) and running the migration on the live MAIN DB, the long-running flower MCP servers of PRE-rename sessions (orchestrator daemon 19/proc 1055, refine 1040, ops 1054) kept the OLD code → brief_open_questions / brief_ask / recall_brief's Q&A section now throw 'SQLSTATE[42S02] Table flower.brief_questions doesn't exist'. Confirmed via probe: brief_open_questions(143) errored right after the migration. NEW workers spawned post-rename are fine (fresh code). Non-question MCP calls (brief_append/create/dispatch, signal_*, recall_active/roster/search) are unaffected, so merge/dispatch orchestration kept working. Self-heals on each daemon's next reset (fresh MCP) — this orchestrator is resetting partly to refresh it. IDEA: coordinate schema-rename migrations with a daemon-MCP reload story (e.g. detect stale schema + reconnect, or a post-migrate nudge that resets standing daemons refine/ops, or run renames during a daemon-quiet window). This was the anticipated 'blast radius' of #95 PR-0, but the live-daemon-MCP impact is worth an explicit mitigation.

Context JSON:
{
    "tool": "brief_open_questions",
    "trigger": "merged #116 rename + migrate on live MAIN DB",
    "affected": "pre-rename long-running MCP sessions (orch 19, refine 1040, ops 1054)",
    "brief_id": 143,
    "observed": "SQLSTATE[42S02] Table flower.brief_questions doesn't exist",
    "unaffected": "post-rename workers + non-question MCP calls"
}
[3] link_added flower-ops: (no body)
[4] participant_joined operator:mike: (no body)
[5] note_added operator:mike: Operator approved this feedback-born brief for dispatch.
[6] status_change operator:mike: (no body)
[7] link_added flower-ops: (no body)
[8] link_added flower-ops: (no body)
[9] link_added flower-ops: (no body)
[10] participant_joined flower-orchestrator: (no body)
[11] plan_proposed flower-orchestrator: ## Ask
Prevent schema-changing migrations (especially table/column **renames** like #116 `brief_questions`→`decisions`) from silently breaking standing long-running daemon MCP sessions that cache pre-migration code. Deliver a documented procedure and, if cheap, a lightweight automated reload nudge.

## Context (Feedback #75)
After #116 renamed `brief_questions`→`decisions` and the migration ran on live MAIN, the **pre-rename** daemon MCP servers (orch 19/proc 1055, refine 1040, ops 1054) kept the OLD cached code and threw `SQLSTATE[42S02] Table flower.brief_questions doesn't exist` on `brief_open_questions` / `brief_ask` / `recall_brief`'s Q&A section. NEW workers spawned post-rename were fine (fresh code); non-question MCP calls (brief_append/create/dispatch, signal_*, recall_active/roster/search) were unaffected, so merge/dispatch orchestration kept working. It **self-heals on each daemon's next reset** (fresh MCP process).

We already ship the relevant primitives: make-before-break reset (`daemon_request_reset`/`daemon_start_reset`), `flower:horizon-reload` (#191, canonical graceful Horizon reload), daemon-checkin project resolution (#104), and the durable coordination-signal queue.

## Deliverable — keep SMALL
1. **Procedure doc (required):** add the canonical "schema-rename with standing daemons" playbook to the right home (`CLAUDE.md` Runtime & pipeline notes, and/or `_flower-playbook.md`). Rule of thumb: run schema renames in a daemon-quiet window and/or immediately follow the migration with a coordinated standing-daemon reload, leaning on the existing reset + `flower:horizon-reload` tooling. Note which MCP calls are/aren't affected and that resets self-heal.
2. **Automated post-migrate reload nudge (optional — only if genuinely low-effort):** after a schema-changing migration on MAIN, enqueue a coordination signal (reuse an existing kind, e.g. a reset/route hint, or a minimal new `schema_reload` hint) to standing non-orchestrator daemons (refine/ops) so their MCP reloads without waiting for a natural reset. MUST fail-safe/no-op when there are no standing daemons.

## Out of scope
Query-time stale-schema auto-detection or MCP self-reconnect (larger; leave a follow-up brief note if it seems warranted). Do NOT build a heavy framework.

## Acceptance
- Procedure is documented where daemons/operators will actually find it.
- If the nudge is built: a schema-changing migration enqueues reload signals for standing daemons; verified no-op with zero daemons; `php artisan test` green; `./vendor/bin/pint` clean on touched files.
- Finish with `brief_dispatch_complete` (+ `brief_append` merged note) and a `Brief: #167` trailer on every commit.

Recommended linked context:
{
    "todos": [],
    "scratchpads": [
        {
            "id": 333,
            "solo_scratchpad_id": "1005",
            "name": "flower-ops — triage log",
            "archived": false,
            "revision": 271
        },
        {
            "id": 382,
            "solo_scratchpad_id": "1074",
            "name": "Feedback #87 fix-spec",
            "archived": false,
            "revision": 2
        },
        {
            "id": 384,
            "solo_scratchpad_id": "1076",
            "name": "ESCALATION — embed-stage OOM cluster degrading the pipeline",
            "archived": false,
            "revision": 2
        }
    ]
}

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: #167` to every commit for this brief so flower can exact-link commits back to the brief.