CLAUDE.md: the ticket is the pull channel, and the brief is write-once

A send to a working member is accepted and returns a ticket, then is never
delivered. That happened three times in one session here, and the member was
released still executing a brief that had been retracted twice. The receipt is
true — it is a fact about the mailbox, when what was needed was a fact about the
pane.

The fleet01 lead named the mechanism: a push delivery needs the recipient free at
send time, while a pull channel needs only that they look before acting. So the
ticket is not more reliable than the mailbox, it is a different direction, and its
success depends on the member's procedure rather than on the timing of the send.

Both halves have to be written down, because each is useless alone:

- Member (turn contract, new item 4): re-read the ticket before acting on anything
  told earlier, and again before committing. A ticket comment that contradicts the
  brief is newer and wins.
- Lead (step 5): all corrections go to the ticket, and the brief is write-once.
  The member cannot check which source is newer — it just always prefers the
  ticket — so revising a brief in place makes it obey the rule and do the wrong
  thing. A first brief for a unit not yet running is not a correction.

wiki/7-Use-Cases.md is updated to keep the canonical block byte-identical; the
sync check passes. The wiki submodule pointer is deliberately left unstaged.

CLAUDE.md

@@ -95,6 +95,16 @@ below are the procedure — run them in order, every task, not only the big ones
    `fleet_status`, never by reading its terminal; it also reports an open question and the `turnId`
    that answers it. **A worker's ask waits ~55 seconds, and no nudge makes that longer** — so never
    brief a worker to "ask me". Decide before you delegate, or give it an explicit default.
+   **A correction cannot reach a busy member.** A `fleet_send` to a working member is *accepted* and
+   returns a ticket, and is then never delivered — measured here three times in one session, and the
+   member was released still executing a brief that had been retracted twice. The receipt is true and
+   it is a fact about the *mailbox*; what you needed was a fact about the *pane*. **A push delivery
+   needs the recipient free at send time; a pull channel needs only that they look before acting.** So
+   put every correction on the **ticket**, which they can read whenever they look, and send as the
+   notification. That obliges you, not them: **all corrections go to the ticket, and the brief is
+   write-once.** The member cannot check which source is newer — it just always prefers the ticket —
+   so the day you revise a brief in place instead of commenting, it obeys your rule and does the wrong
+   thing. A *first* brief for a unit not yet running is not a correction, and may be the whole spec.
 6. **Verify yourself.** Re-run the build and the checks. A worker cannot run your IDE tooling, any
    forge MCP server it appears to have holds a blocked credential and fails every call, and a piped
    command (`… | tail`) hides failures behind a zero exit — never promote a worker's "clean" to a
@@ -191,13 +201,16 @@ simply complies has thrown away the reason there are two of you.
 3. **`fleet_ask{question}`** when a decision is genuinely the lead's (ambiguous requirement, two
    defensible fixes, "bug or intended?"). It blocks and you resume the *same* turn with the answer.
    Don't ask what you could decide yourself.
-4. **End the turn with exactly one `fleet_reply{content}`**, carrying your complete answer. This is
+4. **Re-read the ticket before you act on anything you were told earlier**, and again before you
+   commit. A message reaches you only while you are free to receive it; the ticket is there whenever
+   you look. **If a ticket comment contradicts your brief, the ticket comment is newer and it wins.**
+5. **End the turn with exactly one `fleet_reply{content}`**, carrying your complete answer. This is
    the whole handoff. No `fleet_reply` ⇒ the sender gets nothing and the exchange stalls.
    Do **not** lean on the completion fallback to carry your answer for you: when you end a turn
    without replying, the bridge scrapes your pane, and it can return only the last 4000 characters.
    A clipped scrape is marked as partial, but the missing text is gone — your report reaches the
    lead with its end cut off.
-5. **Report honestly.** State only what you actually ran and its real output, including failures,
+6. **Report honestly.** State only what you actually ran and its real output, including failures,
    and never claim the result of a check you had no way to run. **Measure your own tools; do not
    assume them.** What you mount depends on your backend: an opencode member gets the bridge and
    nothing else, while a Claude Code member also inherits the operator's user-scope MCP servers,
@@ -207,7 +220,7 @@ simply complies has thrown away the reason there are two of you.
    not your only forge route, and the two must not be confused: the repo-scoped `GITEA_TOKEN` the
    daemon injects into your environment does work, and using it to open your own PR is part of the
    job. A blocked MCP tool is never a reason to skip that step.
-6. **Never merge.** Stage files explicitly — never `git add -A` — and leave alone anything the
+7. **Never merge.** Stage files explicitly — never `git add -A` — and leave alone anything the
    project marks as not-yours-to-commit.
 
 ### Where each rule lives (don't duplicate — extend the right layer)