7-Use-Cases: a blocked lead consults architects, not the operator

The operator set this rule on 2026-09-19: when a decision blocks a lead, it
consults one or more architect members, who are authorized to agree on one
decision and unblock. The operator is not asked.

The paragraph also carries the reason the record is mandatory. The operator's
old notification channel was the block itself -- work stopped, so they found
out. Removing the block removes that signal, so the decision goes on the
ticket, which reaches them whether or not they are at a terminal.

Kept byte-identical with the block in fleet/fleetd CLAUDE.md.

7-Use-Cases.md

@@ -444,6 +444,15 @@ prefer `wait:false` + `fleet_poll` for anything non-trivial: a blocking `fleet_s
 **Delegating does not delegate responsibility.** Workers open PRs; you are the gate. Never delegate
 the merge — and merging on a reviewer's word is delegating it by proxy.
 
+**When a decision blocks you, consult architects — not the operator.** Spawn one or more architect
+members, give them the question and the evidence you have, and act on what they agree. They are
+authorized to settle it, not only to advise. If two of them still disagree after two rounds, they
+return both positions and you decide. Go to the operator only for something outside the fleet's
+authority: money, credentials, or a promise made to someone else. **Then write the decision on the
+ticket.** Taking the operator out of the loop also removes the signal they used to get, because
+that signal was the block itself — work stopped, so they found out. A ticket comment replaces it,
+and it reaches them whether or not they are at a terminal when you decide.
+
 | Intent | Tool |
 |---|---|
 | Confirm your own role | `fleet_whoami` |