Merge #558: the ticket is the pull channel, and the brief is write-once

Docs only, 16 additions / 3 deletions — read by the lead in full, per the
under-50-lines self-review rule in CLAUDE.md.

Verified on the merged tree (main dab697f + 351ee1e): the canonical-block sync
check from the addendum prints `in sync: True`, comparing the MERGED CLAUDE.md
against wiki/7-Use-Cases.md. The wiki side is already pushed and verified by ref:
local wiki HEAD and `git ls-remote origin main` both read 20d2fc0.

CI run 1812 on 351ee1e: success.

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)