Feedback #102: Daemon charter's heartbeat path is unusable in a non-flower project: `php artisan flower:daemon-checkin` only exists in the flower host app's scope, and the `/flower-checkin` slash-command fallback isn't provisioned into

You are being dispatched from flower Brief #217: Feedback #102: Daemon charter's heartbeat path is unusable in a non-flower project: `php artisan flower:daemon-checkin` only exists in the flower host app's scope, and the `/flower-checkin` slash-command fallback isn't provisioned into

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/217-daemon-checkin-portability
- worktree: not specified
- kind: fresh

Current brief spec:
## Problem (feedback #102)
flower daemons running in a **non-flower project** (first observed: home-tracker, flower proj 22 / Solo 28) have **no working heartbeat path**, so they never register on the roster and the entire dispatch/merge loop never arms. Both home-tracker daemons (orch #30, refine #31) cold-stalled at boot with `last_checkin_at=null`.

Two structural causes:
1. The charter mandates `php artisan flower:daemon-checkin …` as the SOLE heartbeat path — but that command lives in the flower **host app's** codebase and does not exist in a target project (`There are no commands defined in the "flower" namespace`).
2. The charter's stated fallback, the `/flower-checkin` slash command, is **not provisioned** into target projects (`.claude/commands/` absent). So neither path works — a full cold stall.

Secondary (cosmetic): the charter claims `mcp__solo`/`mcp__flower` are pre-authorized in the target's `.claude/settings.json`; grep found no such entries (tools worked anyway).

## Root issue
The charter over-specifies a **flower-host-only** mechanism (an artisan command) as universal, while hard-banning the one mechanism that works everywhere (the bare `mcp__flower__daemon_checkin` MCP tool). The ban's real concern was **self-estimated ids** — but `whoami` provides Solo-**resolved** ids (solo_process_id, session_id), which fully eliminates that concern.

## Remediation — layered (recommended; the three compose)
1. **(Immediate unblock — charter-policy change) Permit the bare `mcp__flower__daemon_checkin` as the heartbeat path when no host-app artisan command / slash command is present, passing whoami-RESOLVED ids (never self-estimated).** Relax the blanket "never the bare MCP tool for heartbeat" ban to: "never with self-estimated ids; a resolved-id MCP check-in IS the sanctioned cross-project fallback." This gives every context a working path today. ⚠️ Flagged: this changes a currently-emphatic charter policy — surfaced for operator visibility.
2. **(Ergonomic path) Provision a `/flower-checkin` Claude Code slash command into target projects at spawn/adoption time** (the operator's expected path). It wraps the bare MCP `daemon_checkin`, self-resolving ids from the Solo PTY env. Owned by the spawn/adoption flow (`SpawnPacketService` / spawn bridge) that should also write the `.claude/settings.json` allowlist entries.
3. **(Correctness) Make the spawn packet / charter template context-aware:** detect flower-host vs. target-project scope and emit the correct heartbeat instruction (artisan only inside the flower app; slash-command or resolved-id MCP otherwise). Fix the secondary discrepancy too: either actually write the `mcp__solo`/`mcp__flower` allowlist entries at adoption, or drop the inaccurate "pre-authorized" claim.

## Acceptance
- A daemon spawned into ANY project can heartbeat + register on the roster at boot — no `flower namespace` error, no missing-command dead end.
- The heartbeat path always passes Solo-resolved ids, never estimated.
- Charter / spawn-packet text matches the actually-available mechanism for the target's scope; the settings-allowlist claim is either true or removed.
- home-tracker daemons (#30/#31) can re-boot and register.

## Touch points
Charter templates (`daemon_charter.orchestrator.default v4` + the refine charter), `SpawnPacketService` / spawn bridge (provision slash command + settings allowlist), the `/flower-checkin` skill/command source, the `daemon_checkin` MCP tool (confirm it takes whoami-resolved ids). Related: **feedback #95** (the `/flower-checkin` skill arg-parse papercut — same command surface). Authority: **AUTONOMOUS** (funnel B) — plannable without operator gate; the charter-policy relaxation in (1) is flagged for visibility.

_Status → planned. Refine stops here; orchestrator owns dispatch._

Recent/key trace events:
[3] link_added operator:mike: (no body)
[4] status_change operator:mike: (no body)
[5] status_change operator:mike: (no body)
[6] participant_joined flower-refine: (no body)
[7] plan_proposed flower-refine: ## Problem (feedback #102)
flower daemons running in a **non-flower project** (first observed: home-tracker, flower proj 22 / Solo 28) have **no working heartbeat path**, so they never register on the roster and the entire dispatch/merge loop never arms. Both home-tracker daemons (orch #30, refine #31) cold-stalled at boot with `last_checkin_at=null`.

Two structural causes:
1. The charter mandates `php artisan flower:daemon-checkin …` as the SOLE heartbeat path — but that command lives in the flower **host app's** codebase and does not exist in a target project (`There are no commands defined in the "flower" namespace`).
2. The charter's stated fallback, the `/flower-checkin` slash command, is **not provisioned** into target projects (`.claude/commands/` absent). So neither path works — a full cold stall.

Secondary (cosmetic): the charter claims `mcp__solo`/`mcp__flower` are pre-authorized in the target's `.claude/settings.json`; grep found no such entries (tools worked anyway).

## Root issue
The charter over-specifies a **flower-host-only** mechanism (an artisan command) as universal, while hard-banning the one mechanism that works everywhere (the bare `mcp__flower__daemon_checkin` MCP tool). The ban's real concern was **self-estimated ids** — but `whoami` provides Solo-**resolved** ids (solo_process_id, session_id), which fully eliminates that concern.

## Remediation — layered (recommended; the three compose)
1. **(Immediate unblock — charter-policy change) Permit the bare `mcp__flower__daemon_checkin` as the heartbeat path when no host-app artisan command / slash command is present, passing whoami-RESOLVED ids (never self-estimated).** Relax the blanket "never the bare MCP tool for heartbeat" ban to: "never with self-estimated ids; a resolved-id MCP check-in IS the sanctioned cross-project fallback." This gives every context a working path today. ⚠️ Flagged: this changes a currently-emphatic charter policy — surfaced for operator visibility.
2. **(Ergonomic path) Provision a `/flower-checkin` Claude Code slash command into target projects at spawn/adoption time** (the operator's expected path). It wraps the bare MCP `daemon_checkin`, self-resolving ids from the Solo PTY env. Owned by the spawn/adoption flow (`SpawnPacketService` / spawn bridge) that should also write the `.claude/settings.json` allowlist entries.
3. **(Correctness) Make the spawn packet / charter template context-aware:** detect flower-host vs. target-project scope and emit the correct heartbeat instruction (artisan only inside the flower app; slash-command or resolved-id MCP otherwise). Fix the secondary discrepancy too: either actually write the `mcp__solo`/`mcp__flower` allowlist entries at adoption, or drop the inaccurate "pre-authorized" claim.

## Acceptance
- A daemon spawned into ANY project can heartbeat + register on the roster at boot — no `flower namespace` error, no missing-command dead end.
- The heartbeat path always passes Solo-resolved ids, never estimated.
- Charter / spawn-packet text matches the actually-available mechanism for the target's scope; the settings-allowlist claim is either true or removed.
- home-tracker daemons (#30/#31) can re-boot and register.

## Touch points
Charter templates (`daemon_charter.orchestrator.default v4` + the refine charter), `SpawnPacketService` / spawn bridge (provision slash command + settings allowlist), the `/flower-checkin` skill/command source, the `daemon_checkin` MCP tool (confirm it takes whoami-resolved ids). Related: **feedback #95** (the `/flower-checkin` skill arg-parse papercut — same command surface). Authority: **AUTONOMOUS** (funnel B) — plannable without operator gate; the charter-policy relaxation in (1) is flagged for visibility.

_Status → planned. Refine stops here; orchestrator owns dispatch._
[8] status_change flower-refine: (no body)
[9] participant_joined flower-orchestrator: (no body)
[10] status_change flower-orchestrator: (no body)
[11] dispatched flower-orchestrator: Dispatch request #125 queued for flower.
[12] note_added flower-orchestrator: MERGE ATTEMPTED + REVERTED (orchestrator daemon 43). Merged flower/217-daemon-checkin-portability @ 5505e8b onto current master (712c4b6); git auto-merged cleanly (no conflict) but the full suite went RED with 8 failures, all confined to #217's surface — DaemonCharterDefaultsTest (2) + SpawnPacketServiceTest (6). Reverted master to 712c4b6 (green) to protect the tree.

Root cause = BASE DRIFT: #217 was built on an older master; since it branched, #170/#241/#226/#228 reshaped the charter bodies and added a charter role, so the textual auto-merge combined them without a git conflict but produced charter text that no longer matches #217's assertions. Evidence: `test_seeder_upserts_default_charter…` fails "6 is identical to 5" (template/role count changed 5→6 under #217); `test_charter_bodies_use_the_portable_context_aware_checkin_command` fails because the merged refine charter still carries pre-portable hardcoded checkin text in sections #217 never rewrote (those sections were added/changed by intervening merges).

REWORK NEEDED before re-merge: rebase flower/217 onto current master, re-apply the {{CHECKIN_BINARY}}/{{CHECKIN_SLASH_ALT}} placeholder-ization to the CURRENT charter bodies in DaemonCharterDefaults (all roles, including any added since #217 branched), and update SpawnPacketServiceTest + DaemonCharterDefaultsTest for the current template/role count. Canceling the dead dispatch (worker proc 1156 did not survive the Solo restart). Re-dispatch deferred until recall_search is restored + infra settles (see below).
[13] dispatched flower-orchestrator: Dispatch request #125 marked cancelled.
[14] 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: #217` to every commit for this brief so flower can exact-link commits back to the brief.
- Need an operator call while working this brief? A question ABOUT THIS BRIEF -> brief_ask(217, ...); a standalone decision not tied to the brief -> decision_ask(...). Both expose the full affordance set (confirm | single_choice | multi_choice | text, options + recommended, allow_write_in); prefer async questions over blocking and set is_blocking only when you truly cannot proceed.
- Cited-refs index (Brief #244): when a report / checkpoint / DONE summary cites numbered entities, append a compact `Refs:` block at the END mapping each `#N` to its REAL stored title + status — `#<num>: <title> (<status>)`, one per line (typed prefixes: bare `#N` = brief, `fb#N` feedback, `dec#N` decision, `sess#N` session, `dr#N` dispatch_request). Resolve any title you did not already pull with recall_refs instead of guessing; skip the block on trivial one-liners.

You are being dispatched from flower Brief #217: Feedback #102: Daemon charter's heartbeat path is unusable in a non-flower project: `php artisan flower:daemon-checkin` only exists in the flower host app's scope, and the `/flower-checkin` slash-command fallback isn't provisioned into

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/217-daemon-checkin-portability
- worktree: not specified
- kind: fresh

Current brief spec:
## Problem (feedback #102)
flower daemons running in a **non-flower project** (first observed: home-tracker, flower proj 22 / Solo 28) have **no working heartbeat path**, so they never register on the roster and the entire dispatch/merge loop never arms. Both home-tracker daemons (orch #30, refine #31) cold-stalled at boot with `last_checkin_at=null`.

Two structural causes:
1. The charter mandates `php artisan flower:daemon-checkin …` as the SOLE heartbeat path — but that command lives in the flower **host app's** codebase and does not exist in a target project (`There are no commands defined in the "flower" namespace`).
2. The charter's stated fallback, the `/flower-checkin` slash command, is **not provisioned** into target projects (`.claude/commands/` absent). So neither path works — a full cold stall.

Secondary (cosmetic): the charter claims `mcp__solo`/`mcp__flower` are pre-authorized in the target's `.claude/settings.json`; grep found no such entries (tools worked anyway).

## Root issue
The charter over-specifies a **flower-host-only** mechanism (an artisan command) as universal, while hard-banning the one mechanism that works everywhere (the bare `mcp__flower__daemon_checkin` MCP tool). The ban's real concern was **self-estimated ids** — but `whoami` provides Solo-**resolved** ids (solo_process_id, session_id), which fully eliminates that concern.

## Remediation — layered (recommended; the three compose)
1. **(Immediate unblock — charter-policy change) Permit the bare `mcp__flower__daemon_checkin` as the heartbeat path when no host-app artisan command / slash command is present, passing whoami-RESOLVED ids (never self-estimated).** Relax the blanket "never the bare MCP tool for heartbeat" ban to: "never with self-estimated ids; a resolved-id MCP check-in IS the sanctioned cross-project fallback." This gives every context a working path today. ⚠️ Flagged: this changes a currently-emphatic charter policy — surfaced for operator visibility.
2. **(Ergonomic path) Provision a `/flower-checkin` Claude Code slash command into target projects at spawn/adoption time** (the operator's expected path). It wraps the bare MCP `daemon_checkin`, self-resolving ids from the Solo PTY env. Owned by the spawn/adoption flow (`SpawnPacketService` / spawn bridge) that should also write the `.claude/settings.json` allowlist entries.
3. **(Correctness) Make the spawn packet / charter template context-aware:** detect flower-host vs. target-project scope and emit the correct heartbeat instruction (artisan only inside the flower app; slash-command or resolved-id MCP otherwise). Fix the secondary discrepancy too: either actually write the `mcp__solo`/`mcp__flower` allowlist entries at adoption, or drop the inaccurate "pre-authorized" claim.

## Acceptance
- A daemon spawned into ANY project can heartbeat + register on the roster at boot — no `flower namespace` error, no missing-command dead end.
- The heartbeat path always passes Solo-resolved ids, never estimated.
- Charter / spawn-packet text matches the actually-available mechanism for the target's scope; the settings-allowlist claim is either true or removed.
- home-tracker daemons (#30/#31) can re-boot and register.

## Touch points
Charter templates (`daemon_charter.orchestrator.default v4` + the refine charter), `SpawnPacketService` / spawn bridge (provision slash command + settings allowlist), the `/flower-checkin` skill/command source, the `daemon_checkin` MCP tool (confirm it takes whoami-resolved ids). Related: **feedback #95** (the `/flower-checkin` skill arg-parse papercut — same command surface). Authority: **AUTONOMOUS** (funnel B) — plannable without operator gate; the charter-policy relaxation in (1) is flagged for visibility.

_Status → planned. Refine stops here; orchestrator owns dispatch._

Recent/key trace events:
[1] participant_joined operator:mike: (no body)
[2] note_added operator:mike: Feedback #102
Authority: AUTONOMOUS
Funnel: B - autonomous brief
Gate: this bug/MCP/Sentry feedback may be planned without operator approval.
Kind: bug
Source: flower-home-tracker-orchestrator (Solo proc 1102)

Summary:
Daemon charter's heartbeat path is unusable in a non-flower project: `php artisan flower:daemon-checkin` only exists in the flower host app's scope, and the `/flower-checkin` slash-command fallback isn't provisioned into target projects — this cold-stalled BOTH home-tracker daemons (orchestrator #30 + refine #31) at boot with zero working heartbeat path.

Detail:
FIRST OBSERVED: home-tracker (flower project 22 / Solo project 28) — per operator (mike), this is the first time flower daemons have run in a NON-flower context (orchestrating a project other than the flower host app itself). That context is exactly where the charter's heartbeat assumption breaks.

CHARTER TEMPLATE: daemon_charter.orchestrator.default v4 (and the matching refine charter).

TWO DISTINCT ISSUES:

(1) The charter mandates `php artisan flower:daemon-checkin --role=<role> --actor-ref=<ref> --cadence=<cadence>` as "the sole heartbeat path" and explicitly forbids the bare `mcp__flower__daemon_checkin` MCP tool as a fallback. But that artisan command is defined in the flower host APPLICATION's codebase — it does not exist in a target project like home-tracker. Confirmed:
  - `php artisan flower:daemon-checkin --help` → ERROR "There are no commands defined in the 'flower' namespace."
  - No flower package in home-tracker's composer.json; no flower command classes in app/.
So the mandated primary heartbeat path is structurally unavailable in any non-flower project the daemons are pointed at.

(2) The charter's stated fallback, the `/flower-checkin` slash command, is ALSO not present. home-tracker has no `.claude/commands/flower-checkin*` (the `.claude/commands/` dir is empty/absent), and it's not in this session's available skills. So there is NO working heartbeat path at all in this context — artisan missing AND slash command missing. Operator expected `/flower-checkin` to be available and considers its absence a bug.

IMPACT / REPRO — both cold-booted daemons stalled on this identically:
  - Refine daemon #31 (Solo proc 1103, flower-home-tracker-refine): recall_resume(project:home-tracker) shows session 3510 ran the artisan check-in, got the "flower namespace" error, read brief #211, and ENDED without ever checking in. Its own open question: "What is the correct method to register this daemon's heartbeat if both the Artisan command and the MCP tool are explicitly not recommended?"
  - Orchestrator daemon #30 (Solo proc 1102, this session): identical artisan failure. Rather than fabricate a run or silently violate the explicit "don't use the bare MCP tool" instruction, I checkpointed the operator. Operator chose HOLD (do not arm) and requested this feedback.
Roster (project 22) still shows both #30 and #31 as status="expected" with null last_checkin_at — neither ever registered liveness.

ADDITIONAL SECONDARY DISCREPANCY: The charter asserts the Solo+flower MCP tools are "pre-authorized in the project .claude/settings.json allowlist (mcp__solo, mcp__flower)." grep of home-tracker's .claude/settings.json + settings.local.json found no such entries (the tools worked in-session regardless, so this is cosmetic, but the charter's cited proof-of-authorization is inaccurate for a freshly-adopted project).

SUGGESTED REMEDIATIONS (any one unblocks):
  a. Provision a `/flower-checkin` Claude Code slash command into target projects at daemon-spawn/adoption time (operator's expected path). It can wrap the bare MCP daemon_checkin, self-resolving solo_process_id + session_id from the Solo PTY env exactly as the charter describes.
  b. Alternatively, have the charter explicitly permit the bare `mcp__flower__daemon_checkin` MCP tool as the heartbeat path when no host-app artisan command / slash command is present — passing Solo-RESOLVED ids (from whoami), not self-estimated ones (the charter's real concern is estimation, which whoami eliminates). In this session I had accurate resolved ids available: solo_process_id=1102, session_id=eaf8dd64eefbbbd6, role=orchestrator, actor_ref=home-tracker-orchestrator.
  c. Make the spawn packet / charter template context-aware: detect flower-host vs. target-project scope and emit the correct heartbeat instruction (artisan only when in the flower app; slash-command or bare-MCP otherwise).

NET: the daemon-spawn flow for non-flower projects currently has no functioning heartbeat mechanism, which prevents roster registration and blocks the entire dispatch/merge loop from ever arming.

Context JSON:
{
    "project_slug": "home-tracker",
    "failed_command": "php artisan flower:daemon-checkin --role=orchestrator --actor-ref=home-tracker-orchestrator --cadence=fast",
    "solo_project_id": 28,
    "stalled_daemons": [
        {
            "id": 30,
            "role": "orchestrator",
            "status": "expected",
            "last_checkin_at": null,
            "solo_process_id": 1102
        },
        {
            "id": 31,
            "role": "refine",
            "status": "expected",
            "evidence": "recall_resume session 3510 \u2014 same failure, ended unregistered",
            "last_checkin_at": null,
            "solo_process_id": 1103
        }
    ],
    "charter_template": "daemon_charter.orchestrator.default v4",
    "missing_fallback": "/flower-checkin slash command absent in .claude/commands/",
    "flower_project_id": 22,
    "operator_decision": "HOLD \u2014 do not arm daemon",
    "failed_command_error": "There are no commands defined in the 'flower' namespace.",
    "settings_allowlist_check": "no mcp__solo/mcp__flower entries found in .claude/settings.json or settings.local.json",
    "resolved_ids_available_this_session": {
        "actor_ref": "home-tracker-orchestrator",
        "session_id": "eaf8dd64eefbbbd6",
        "solo_process_id": 1102
    }
}
[3] link_added operator:mike: (no body)
[4] status_change operator:mike: (no body)
[5] status_change operator:mike: (no body)
[6] participant_joined flower-refine: (no body)
[7] plan_proposed flower-refine: ## Problem (feedback #102)
flower daemons running in a **non-flower project** (first observed: home-tracker, flower proj 22 / Solo 28) have **no working heartbeat path**, so they never register on the roster and the entire dispatch/merge loop never arms. Both home-tracker daemons (orch #30, refine #31) cold-stalled at boot with `last_checkin_at=null`.

Two structural causes:
1. The charter mandates `php artisan flower:daemon-checkin …` as the SOLE heartbeat path — but that command lives in the flower **host app's** codebase and does not exist in a target project (`There are no commands defined in the "flower" namespace`).
2. The charter's stated fallback, the `/flower-checkin` slash command, is **not provisioned** into target projects (`.claude/commands/` absent). So neither path works — a full cold stall.

Secondary (cosmetic): the charter claims `mcp__solo`/`mcp__flower` are pre-authorized in the target's `.claude/settings.json`; grep found no such entries (tools worked anyway).

## Root issue
The charter over-specifies a **flower-host-only** mechanism (an artisan command) as universal, while hard-banning the one mechanism that works everywhere (the bare `mcp__flower__daemon_checkin` MCP tool). The ban's real concern was **self-estimated ids** — but `whoami` provides Solo-**resolved** ids (solo_process_id, session_id), which fully eliminates that concern.

## Remediation — layered (recommended; the three compose)
1. **(Immediate unblock — charter-policy change) Permit the bare `mcp__flower__daemon_checkin` as the heartbeat path when no host-app artisan command / slash command is present, passing whoami-RESOLVED ids (never self-estimated).** Relax the blanket "never the bare MCP tool for heartbeat" ban to: "never with self-estimated ids; a resolved-id MCP check-in IS the sanctioned cross-project fallback." This gives every context a working path today. ⚠️ Flagged: this changes a currently-emphatic charter policy — surfaced for operator visibility.
2. **(Ergonomic path) Provision a `/flower-checkin` Claude Code slash command into target projects at spawn/adoption time** (the operator's expected path). It wraps the bare MCP `daemon_checkin`, self-resolving ids from the Solo PTY env. Owned by the spawn/adoption flow (`SpawnPacketService` / spawn bridge) that should also write the `.claude/settings.json` allowlist entries.
3. **(Correctness) Make the spawn packet / charter template context-aware:** detect flower-host vs. target-project scope and emit the correct heartbeat instruction (artisan only inside the flower app; slash-command or resolved-id MCP otherwise). Fix the secondary discrepancy too: either actually write the `mcp__solo`/`mcp__flower` allowlist entries at adoption, or drop the inaccurate "pre-authorized" claim.

## Acceptance
- A daemon spawned into ANY project can heartbeat + register on the roster at boot — no `flower namespace` error, no missing-command dead end.
- The heartbeat path always passes Solo-resolved ids, never estimated.
- Charter / spawn-packet text matches the actually-available mechanism for the target's scope; the settings-allowlist claim is either true or removed.
- home-tracker daemons (#30/#31) can re-boot and register.

## Touch points
Charter templates (`daemon_charter.orchestrator.default v4` + the refine charter), `SpawnPacketService` / spawn bridge (provision slash command + settings allowlist), the `/flower-checkin` skill/command source, the `daemon_checkin` MCP tool (confirm it takes whoami-resolved ids). Related: **feedback #95** (the `/flower-checkin` skill arg-parse papercut — same command surface). Authority: **AUTONOMOUS** (funnel B) — plannable without operator gate; the charter-policy relaxation in (1) is flagged for visibility.

_Status → planned. Refine stops here; orchestrator owns dispatch._
[8] status_change flower-refine: (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: #217` to every commit for this brief so flower can exact-link commits back to the brief.