From 351ee1ea6de4eca03877a19c8ac09e8918846481 Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Sat, 12 Sep 2026 15:45:09 +0700 Subject: [PATCH] CLAUDE.md: the ticket is the pull channel, and the brief is write-once MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 5ff209f..6eae178 100644 --- a/CLAUDE.md +++ b/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)