Codex worker MCP tool-discovery gap + scheduled cross-harness toolset-drift validation

You are being dispatched from flower Brief #29: Codex worker MCP tool-discovery gap + scheduled cross-harness toolset-drift validation

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/codex-tool-discovery
- worktree: not specified
- kind: fresh

Current brief spec:
## Problem
Codex dispatch workers can't SEE the mutating flower MCP tools (`brief_append`,
`brief_dispatch_complete`, `flower_feedback`) via `tool_search`, so they fall back to local app
services. Observed: feedback #33/#34 (orchestrator/claude, fixed by reconnect) and #36 (codex
worker 977 — a FRESH worker, so NOT just stale-connection). claude + codex point to the SAME
flower MCP server (`php artisan mcp:start flower`), so it's a DISCOVERY gap on the codex side, not
registration. Impact: silently degrades the self-driving dispatch loop (workers can't self-close
or file feedback via MCP — the orchestrator has to close their dispatches).

## Part A — diagnose + fix codex discovery
- Verify empirically: a FRESH codex worker runs `tool_search` for the mutating tools and reports
  EXACTLY what it sees. Determine why they don't surface: tool_search ranking/limit? MCP server
  `startup_timeout_sec`? codex MCP client behaviour? the `[mcp_servers.flower.tools.flower_feedback]
  approval_mode="approve"` config? (Compare claude — which DOES get them after reconnect.)
- Fix so codex workers get the full mutating surface, OR document the exact tool_search pattern
  workers must use, and bake it into the worker charter/conventions.

## Part B — MCP-toolset-drift validation (operator idea)
- A **scheduled command** that lists the flower MCP tool set + **hashes** it, compares to the
  prior hash; on CHANGE, **auto-fires a validation brief** to check tool availability across ALL
  configured harnesses (claude / codex / pi).
- Convention: after any MCP-toolset change (merge), run cross-harness validation — a fresh agent
  per harness does `tool_search` for the mutating tools + reports. Bake into the merge protocol.

## Acceptance
- Root cause of codex mutating-tool invisibility identified + fixed (or a documented workaround
  in the worker conventions).
- Scheduled MCP-tool-hash drift detector that fires a validation brief on change.
- Cross-harness tool-availability check runnable (fresh claude+codex+pi tool_search the tools).

## Provenance
feedback #33/#34/#36; ops cycle 86; operator idea 2026-07-01 (scheduled hash-drift → auto
validation brief across harnesses). Corrects an earlier orchestrator mis-report that codex 977
self-closed via brief_dispatch_complete (it used the local service).

Recent/key trace events:
[1] participant_joined flower-orchestrator: (no body)
[2] note_added flower-orchestrator: Codex workers cant see the mutating flower MCP tools via tool_search (feedback #36) and fall back to local services. Diagnose+fix codex discovery, and add a scheduled MCP-tool-hash drift detector that auto-fires a cross-harness validation brief on change.
[3] plan_proposed flower-orchestrator: ## Problem
Codex dispatch workers can't SEE the mutating flower MCP tools (`brief_append`,
`brief_dispatch_complete`, `flower_feedback`) via `tool_search`, so they fall back to local app
services. Observed: feedback #33/#34 (orchestrator/claude, fixed by reconnect) and #36 (codex
worker 977 — a FRESH worker, so NOT just stale-connection). claude + codex point to the SAME
flower MCP server (`php artisan mcp:start flower`), so it's a DISCOVERY gap on the codex side, not
registration. Impact: silently degrades the self-driving dispatch loop (workers can't self-close
or file feedback via MCP — the orchestrator has to close their dispatches).

## Part A — diagnose + fix codex discovery
- Verify empirically: a FRESH codex worker runs `tool_search` for the mutating tools and reports
  EXACTLY what it sees. Determine why they don't surface: tool_search ranking/limit? MCP server
  `startup_timeout_sec`? codex MCP client behaviour? the `[mcp_servers.flower.tools.flower_feedback]
  approval_mode="approve"` config? (Compare claude — which DOES get them after reconnect.)
- Fix so codex workers get the full mutating surface, OR document the exact tool_search pattern
  workers must use, and bake it into the worker charter/conventions.

## Part B — MCP-toolset-drift validation (operator idea)
- A **scheduled command** that lists the flower MCP tool set + **hashes** it, compares to the
  prior hash; on CHANGE, **auto-fires a validation brief** to check tool availability across ALL
  configured harnesses (claude / codex / pi).
- Convention: after any MCP-toolset change (merge), run cross-harness validation — a fresh agent
  per harness does `tool_search` for the mutating tools + reports. Bake into the merge protocol.

## Acceptance
- Root cause of codex mutating-tool invisibility identified + fixed (or a documented workaround
  in the worker conventions).
- Scheduled MCP-tool-hash drift detector that fires a validation brief on change.
- Cross-harness tool-availability check runnable (fresh claude+codex+pi tool_search the tools).

## Provenance
feedback #33/#34/#36; ops cycle 86; operator idea 2026-07-01 (scheduled hash-drift → auto
validation brief across harnesses). Corrects an earlier orchestrator mis-report that codex 977
self-closed via brief_dispatch_complete (it used the local service).
[4] 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.
- Add a git commit trailer `Brief: #29` to every commit for this brief so flower can exact-link commits back to the brief.