docs(agnote): claim review-gate topology lane

pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md

@@ -2336,3 +2336,7 @@ b8cea26c8\ that added it to the top-level equired\ array). (2) PMOVES-pinokio PR
 - `2026-08-28T16:20:00Z` CLAIM `SPARK-KIMI (Crush)` scope: **A0 wrapper hardening + provider-key/OTEL reach-in + MiniMax verifier refresh + a0-plugins fork-sync assessment.** Operator-directed. Branch `fix/a0-wrapper-timeout-health` off fresh `origin/main`. Deliverables: (1) wrapper PR — `AGENT_ZERO_MESSAGE_TIMEOUT` config (kill the hardcoded 60s at services/agent-zero/main.py:280), health-probe verb fix for the POST-only connector `capabilities` route, healthz 503 when inner is down (green-while-dead fix); (2) OTEL reach-in — `OTEL_*` traces env is in the secrets manifest/tier-llm but measured ABSENT from both the agent-zero and archon containers (verified via docker exec env) — wire into compose for both services; (3) rebuild + recreate A0 so provider keys (Z_AI/MINIMAX/OPENAI present post-funnel) and OTEL land in-container, verify connector path; (4) init `Pmoves-MiniMax-Provider-Verifier` submodule (16 submodules uninitialized on primary) and run the verifier to refresh MiniMax model suits; (5) `PMOVES-a0-plugins` fork drift: upstream `agent0ai/a0-plugins` pushed 2026-08-28, fork diverged behind 3 / ahead 146 — assess/sync per fleet-fork-sync; (6) dispatch A0 (connector, a0-archon-bridge skill) to review the wrapper patch. Three-body: delivery=SPARK-KIMI (Crush), control=DARKXSIDE + operator, memory=this trail. agent_signature: `ACK::SPARK-KIMI::A0-WRAPPER-HARDENING-CLAIM::2026-08-28`.
 
 <!-- GRAPHITI_MARK: SPARK-KIMI::A0-WRAPPER-HARDENING-CLAIM::2026-08-28 -->
+
+- `2026-08-28T16:40:00Z` CLAIM `B850-CLAUDE (Knuckles)` scope: **Review-gate topology: `main`'s required PR-approval gate has a measured 0% pass rate and a 100% bypass rate, because every PR in this fleet is authored by the same `POWERFULMOVES` account and GitHub forbids self-approval.** Branch `docs/review-gate-topology`, TTL 72h (expires `2026-08-31T16:40:00Z`), operator-directed (they read the finding and said "this needs to be addressed"). Measured via `gh api repos/POWERFULMOVES/PMOVES.AI/branches/main/protection`: `required_approving_review_count=1`, `require_code_owner_reviews=true`, `enforce_admins.enabled=false`. Measured via `gh pr list --state merged --limit 20 --json number,author,reviews`: **20 of 20 merged PRs (#2782-#2806) carry 0 approvals, author=POWERFULMOVES** — a required gate this fleet's single-account topology cannot satisfy, and which was therefore satisfied by something other than a review on every one of those merges. **Correction, per Codex P2 on this PR — the earlier draft over-claimed and the retraction matters more than the claim did:** `gh pr list --json number,author,reviews` establishes that no approving review existed; it does NOT establish *which* bypass path each merge took. `ADMIN_REVIEW_BYPASS` (`pmoves/mk/preflight.mk:311-312`) is confirmed for exactly ONE merge - #2806, run by this session. For the other 19 the mechanism is **undetermined**: `mergedBy` is `POWERFULMOVES` on all of them (an account, not a path), and `gh run list --workflow=pr-closeout.yml` returns **zero runs**, so the guarded target left no trace for any of them. **That inability is a stronger finding than the one it replaces, and it lands inside this lane's own subject**: there is no audit trail distinguishing 'merged through the fail-closed guarded target with a named reviewing body' from 'merged by any other admin path'. A bypass that cannot be told apart from a different bypass cannot be made auditable by naming it; the record has to exist first. Why it matters: the bypass firing on every merge carries no signal distinguishing "bypassed because one account holds all agents" from "bypassed because nobody reviewed this" — the second is the 2026-08-23 failure class the node-steward role exists to prevent. The fleet's real review discipline (Three-Body separation, an independent Control Body, this register's claim/release trail) is sound and lives entirely outside branch protection, which cannot see it. **Scope: investigation + proposal only.** Deliverable is a design doc under pmoves/docs/operations/ laying out options — a machine-checkable Control-Body attestation as a required status check; per-agent GitHub App/bot identities so approvals become genuine; CODEOWNERS restructuring; or accepting the bypass and making it auditable by requiring it to name the reviewing body — with what each breaks. **Explicitly out of scope, nothing altered in this lane:** branch protection settings, new accounts, removing the bypass. **Identity note surfaced while signing this trail:** this node's `pmoves/config/agent_registry.yaml` key is `claude_b850`, but `make sign-trail AGENT=claude_b850` resolves under a fallback presentation (`claude_b850` is not registered in `pmoves/config/agent_signatures.yaml` — warn + fallback glyph/color, no signing_card_id), while `make sign-trail AGENT=b850-claude` resolves cleanly (card `...036`, matching this register's prior signed entries) — the signing roster carries the hyphenated form the registry key doesn't. A smaller instance of the same "identity the machine cannot resolve" shape as the topic itself. **Three-body:** delivery=a delegated delivery-agent (not yet assigned), control=independent review, memory=this trail (Memory Body, `claude_b850` / `b850-claude`). CHIT trail **signed** via `b850-claude`, `hmac: FewPTdETk9oq2w2gPjaUTPmWWK2Olz86XoK7W+1cPHc=`, kid `chit-signing-v01`, card `...036`. `agent_signature: CLAIM::B850-CLAUDE::REVIEW-GATE-TOPOLOGY::Opus-5::2026-08-28`.
+
+<!-- GRAPHITI_MARK: B850-CLAUDE::REVIEW-GATE-TOPOLOGY-CLAIM::2026-08-28 -->