From 2c7ad8bbc4ec3c0d5af9687e145cbd50c9dc57af Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Mon, 7 Sep 2026 05:04:02 +0700 Subject: [PATCH] portable CLAUDE.md block: a peer reads your project addendum Kept byte-identical with claude-bridge/CLAUDE.md. See that commit for the evidence: one fleet01 addendum, two defects, both found by a non-author. --- 7-Use-Cases.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/7-Use-Cases.md b/7-Use-Cases.md index b685ed3..7d0ab67 100644 --- a/7-Use-Cases.md +++ b/7-Use-Cases.md @@ -451,6 +451,11 @@ The traffic between leads is coordination and nothing else: 3. **Verify a peer exactly as you verify yourself.** Peer status buys nothing: check the claim against the code, and re-run the build. A peer's correction gets the same treatment — right or wrong on the evidence, not on who said it. Neither of you merges the other's work unreviewed. +4. **Ask a peer to read your project addendum.** Your addendum is instruction surface: every future + session on your host obeys it, and a wrong one is obeyed just as faithfully as a right one. The + author is the worst reader of their own qualifier placement — measured here, one addendum carried + two defects and a non-author found both. If you have no peer, at least re-read it asking "which + sentence goes false first, and would a reader reach the caveat before acting?" Being messaged by a peer does not make you its worker: answer with `fleet_reply`, and push back on the substance if it is wrong. A peer that simply complies has thrown away the reason there are two of