docs(skills): pair-review goes harness-agnostic — Crush, operator, skills PRs, on-node passes

.claude/skills/pmoves-pair-review/SKILL.md

@@ -1,25 +1,51 @@
 ---
 name: pmoves-pair-review
-description: Reciprocal pair-review workflow for parallel-CLAUDE PRs. Invoke when peer CLAUDE ships a PR and you're trading reviews; walks the 4-class observation taxonomy (reasoning gap / semantic-naming drift / contract-correctness / defense-in-depth), the review-anatomy template, and the AGNOTE signing flow. Pairs with pmoves-chit-sign.
+description: Reciprocal pair-review workflow for parallel agent-session PRs — any fleet harness (Claude Code, Crush, peer nodes) and the operator (DARKXSIDE/POWERFULMOVES). Walks the 4-class observation taxonomy (reasoning gap / semantic-naming drift / contract-correctness / defense-in-depth), the review-anatomy template, skills-PR review (SKILL.md diffs), and the AGNOTE signing flow. Pairs with pmoves-chit-sign.
 disable-model-invocation: false
 user-invocable: true
 ---
 
 # pmoves-pair-review
 
-Codified workflow for reciprocal PR review across parallel-CLAUDE sessions in the PMOVES.AI fleet. Three orthogonal reviewer surfaces (peer CLAUDE, automated reviewer, self) produce compounding quality gains per PR. Originated 2026-05-20/21 during the 5090 + Z890→5090 mirror exchange on PRs #1555/#1559/#1560/#1567 (~21 distinct improvements across 7 PRs).
+Codified workflow for reciprocal PR review across parallel agent sessions in the PMOVES.AI fleet. Four orthogonal reviewer surfaces (peer agent session, automated reviewer, self, and the operator — DARKXSIDE/POWERFULMOVES as Control) produce compounding quality gains per PR. Originated 2026-05-20/21 during the 5090 + Z890→5090 mirror exchange on PRs #1555/#1559/#1560/#1567 (~21 distinct improvements across 7 PRs); generalized 2026-09-04 from CLAUDE-only to any fleet harness (Crush included) plus the operator surface.
 
 ## When to invoke
 
-- A peer CLAUDE session has just shipped a PR and you're the reciprocal reviewer
-- You're auditing whether a PR your CLAUDE shipped has received its full three-angle review (peer + automated + self)
-- You're onboarding a new CLAUDE session into a parallel-orchestration setup and want the cadence on the table early
+- A peer agent session has just shipped a PR and you're the reciprocal reviewer — **any harness counts**: Claude Code, Crush, Codex CLI, Hermes, a KiloCode claw, or a DARKXSIDE/POWERFULMOVES operator session
+- The PR touches skills (`.claude/skills/**`, `skills/PMOVES-skills/**`) and you want the skills-review checklist below
+- You're auditing whether a PR your session shipped has received its full review angles (peer + automated + self + operator)
+- You're onboarding a new session (any harness) into a parallel-orchestration setup and want the cadence on the table early
 
 **Do NOT invoke when:**
 - The PR is your own (use `pmoves-chit-sign` for AGNOTE rows on your own work)
-- No peer CLAUDE is active (Codex/CodeRabbit + honest self-review suffice solo)
+- No peer session is active (Codex/CodeRabbit + honest self-review + operator suffice solo)
 - Hotfix / damage-control / time-critical — defer to post-merge retrospective
 
+## Harness notes (Crush, operator, and other non-Claude sessions)
+
+The workflow is harness-agnostic; these specifics were learned live (SPARK, 2026-09):
+
+- **Same mechanics**: `gh` CLI, AGNOTE rows, `make -C pmoves sign-trail`, the 4-class scan — identical from Crush or an operator terminal.
+- **Self-approval**: GitHub blocks `gh pr review --request-changes`/`--approve` on same-account PRs from any harness — use `gh pr comment` for the substantive body (this skill already says COMMENTED, not APPROVED).
+- **Signature**: sign with your registered identity from `pmoves/config/agent_signatures.yaml` (e.g. `crush` ◇, `claude-opus` ◆, `z890-claude` ⚙, `darkxside` ✦, `powerfulmoves` ⚡) — the `ACK::<reviewing-agent>::` slot takes the agent_id, not the harness name. An operator review signs as `darkxside`/`powerfulmoves`.
+- **The operator IS a review surface** (Three-Body Control): DARKXSIDE's challenge of a PR's claims mid-review is the highest-signal angle in the fleet — PR #2942's `:8091` port-map correction and PR #2938's topology challenge both came from operator pushback on an agent's confident draft. Operator review lands as PR comments and the `[ACK: control]` line in `AGNOTE4482_SIGNOFF_CHECKLIST.md`; the merge gate does not pass without it.
+- **Skills load on demand**: Crush loads a skill only when invoked (`loaded_this_session 0/44` is normal). Reviewing a skills PR from Crush is an extra angle — you can verify the frontmatter `description` actually works as a **trigger** you would have fired on, not just as documentation.
+- **Cross-harness reviewers are the point**: a Crush review of a Claude-authored PR (and vice versa) surfaces harness-assumption drift — paths that only exist under one launcher, env vars one harness sources and the other doesn't (the `TS_Z890` roster drop was exactly this class). The operator catches what no harness sees: that the task itself was wrong.
+
+## Reviewing skills PRs (SKILL.md diffs)
+
+Skills are load-bearing contracts — a wrong skill misroutes every session that loads it. Map the 4 classes onto the skills surface:
+
+| Class | Skills-specific catch | Check |
+|---|---|---|
+| Contract-correctness | frontmatter `name` must equal the directory name (Crush's validator rejects colon-style names like `4090:probe`); `description` required | Tier 1 CI covers this — but read the diff yourself |
+| Semantic-naming drift | `description` is a **trigger**, not a summary — it decides when a harness loads the skill; a description that describes outcomes but not WHEN to fire will never be invoked | Would YOU have loaded it on the relevant task? Would the operator's phrasing of the task have fired it? |
+| Contract-correctness | every `make -C pmoves <target>` / path the SKILL.md names must exist | `python pmoves/tools/validate_command_anchors.py` — the ratchet fails PRs naming ghost targets |
+| Reasoning gap | SKILL.md documenting a live surface (ports, endpoints, handler lists) that has drifted from reality | Probe the live service — PR #2942's `:8091` correction is the canonical case: docs asserted a dead port map that one live probe disproved after the operator challenged it |
+| Defense-in-depth | skills shipping scripts (`scripts/`, hooks) without tests; paths relative to the wrong root | Tier 2 (hooks + skill scripts) CI must pass; check the script resolves the repo root from its own location |
+
+Also: skills in the `skills/PMOVES-skills` package submodule follow the **submodule workflow** (land in the fork, promote the gitlink) — pair-review applies there identically, plus the usual gitlink-integrity check.
+
 ## How to run
 
 This is a workflow skill (no script). The full operations guide is at `pmoves/docs/operations/PAIR_REVIEW_RECIPROCITY.md`. The condensed flow:

pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md

@@ -2800,3 +2800,4 @@ b8cea26c8\ that added it to the top-level equired\ array). (2) PMOVES-pinokio PR
 
 <!-- GRAPHITI_MARK: Z890-CLAUDE::CHIT-PROVENANCE-STANDING-CHECK::2026-09-04 -->
 - `2026-09-07T20:38:22Z` CLAIM `Z890-CLAUDE` branch: `fix/cipher-mint-single-emission` · **TTL 48h (expires `2026-09-09T20:38:22Z`)** · scope: Cipher mint emits the credential TWICE, and the second copy is unlabeled: with Prefer:return=representation, mint_cipher_token.py:53 prints the stored row, which carries token_uuid -- and token = cipher_{token_uuid.hex}, so the row IS the bearer. Redacting CIPHER_TOKEN= from a transcript does not redact it. Splitting the twice-expired docs/reclaim-cipher-token-model lane: this is the cheap, self-contained half (single deliberate emission, no schema change). The expensive half -- hashing the stored token and cutting bootstrap six-scope shared identity -- stays unclaimed and needs operator sequencing.
+- `2026-09-05T00:19:57Z` CLAIM `SPARK-KIMI (Crush)` branch: `docs/pair-review-harness-agnostic` · **TTL 48h (expires `2026-09-07T00:19:57Z`)** · scope: Adapt pmoves-pair-review skill + PAIR_REVIEW_RECIPROCITY ops guide from CLAUDE-only to harness-agnostic: any fleet harness (Claude Code, Crush, Codex CLI, Hermes, KiloCode claws, DeepSeek) + operator surface (DARKXSIDE/POWERFULMOVES as Control reviewer) + skills-PR review checklist (frontmatter contract, description-as-trigger, anchors ratchet, live-surface probes) + on-node private review passes (Ollama local models, hf-agent nomination, Archon 0.6.0 conversation endpoints). Operator-directed during PR #2943 review session.

pmoves/docs/operations/PAIR_REVIEW_RECIPROCITY.md

@@ -1,28 +1,42 @@
 # Pair-Review Reciprocity — Operations Guide
 
-> Codified workflow for parallel-CLAUDE PR review in the PMOVES.AI multi-node fleet. **Three orthogonal reviewer surfaces** (peer CLAUDE, automated reviewer, self) produce compounding quality gains per PR. Originated 2026-05-20/21 during the 5090 + Z890→5090 mirror exchange on PRs #1555/#1559/#1560/#1567 (~21 distinct improvements across 7 PRs).
+> Codified workflow for parallel agent-session PR review in the PMOVES.AI multi-node fleet — any harness (Claude Code, Crush, Codex CLI, Hermes, KiloCode claws, DeepSeek, or a DARKXSIDE/POWERFULMOVES operator terminal). **Four orthogonal reviewer surfaces** (peer agent session, automated reviewer, self, operator-as-Control) produce compounding quality gains per PR. Originated 2026-05-20/21 during the 5090 + Z890→5090 mirror exchange on PRs #1555/#1559/#1560/#1567 (~21 distinct improvements across 7 PRs); generalized from CLAUDE-only 2026-09-04.
 
 ## Why this matters
 
-In PMOVES multi-node orchestration, two or more CLAUDE sessions run in parallel — each on a different physical node (Z890, 5090, 4090, SPARK, B850) or on the same node operating from a transition signature like `Z890→5090-CLAUDE`. With same-lane collision-avoidance enforced (see `pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md` § Active Claim Register), the natural follow-on is **reciprocal pair-review**: each CLAUDE substantively reviews the other's PRs once shipped.
+In PMOVES multi-node orchestration, two or more agent sessions run in parallel — each on a different physical node (Z890, 5090, 4090, SPARK, B850) or on the same node operating from a transition signature like `Z890→5090-CLAUDE` — and not always on the same harness. With same-lane collision-avoidance enforced (see `pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md` § Active Claim Register), the natural follow-on is **reciprocal pair-review**: each session substantively reviews the other's PRs once shipped.
 
-Combined with the automated reviewer surface (`chatgpt-codex-connector`, CodeRabbit), this produces **three independent observation angles** per PR. The angles are not redundant — they are orthogonal:
+Combined with the automated reviewer surface (`chatgpt-codex-connector`, CodeRabbit), this produces **four independent observation angles** per PR. The angles are not redundant — they are orthogonal:
 
 | Reviewer | Catches | Misses |
 |----------|---------|--------|
-| **Peer CLAUDE (mirror)** | Reasoning gaps, semantic-naming drift, "what would I have done differently" | Contract-correctness against schemas; own-style drift |
+| **Peer agent session (mirror, any harness)** | Reasoning gaps, semantic-naming drift, harness-assumption drift (env vars and paths one launcher sources and another doesn't) | Contract-correctness against schemas; own-style drift |
 | **Automated (Codex/CodeRabbit)** | Schema/field/type mismatches, doc-vs-code contradictions, security flags | Semantic intent, naming-convention drift, architectural choices |
 | **Self (post-fix re-read)** | "What I rushed", embarrassing copy-paste residue, own-style drift | What was just-rushed-now (recency-blindness) |
+| **Operator — DARKXSIDE/POWERFULMOVES (Control)** | That the task itself was wrong; confident drafts contradicting reality (PR #2942 `:8091`, PR #2938 topology challenge both came from operator pushback) | Nothing systematic — but is one body, not a scale surface; gate, don't bottleneck |
 
 Each surface catches what the others miss. Skipping any one of them leaves systematic blind spots.
 
+### Local/private review passes (cheap, on-node, differently-biased)
+
+Any node can also mount a review pass that never leaves the machine. Three mechanisms, composable:
+
+- **Local models via Ollama** (TensorZero-routed, per node) — feed the diff plus the 4-class taxonomy to a local model before or alongside the automated reviewer. **Private by construction**: after the 2026-09-04 tailnet-address leak on a public PR, a pass that never leaves the node is worth having for sensitive diffs — topology, secrets-adjacent, security lanes. Different bias, too: a small local model fails differently than Codex/CodeRabbit and occasionally surfaces what all polished reviewers normalized away.
+- **`hf-agent` (`:8201`, autonomous model patrol)** — polls Hugging Face on env-driven filters and publishes newly discovered models to NATS; it has no per-diff endpoint. Use it as a **discovery feed** (what models just became available to pull), not a recommender — model *selection* stays with the reviewing session, grounded in TensorZero fitness records (`model.fitness.recorded.v1`).
+- **Archon 0.6.0 (`:8091` where deployed)** — an agent runtime in its own right, not just a service: REST conversation endpoints (`/api/conversations*`) and workflows (`/api/workflows*`) can drive a whole structured review pass with tool-using turns against the diff. Not every node deploys it (the canonical fleet table does not carry it on `pmoves-kvm4-2`/`pmoves-kvm2`) — **probe `GET /api/health` and read the JSON body first** (the SPA catch-all answers 200-HTML to any path); if absent, bring it up with `make -C pmoves up-archon-native` or route the pass to a node that has it.
+
+- **Coding plans already on the node** — the fleet's provisioned plans (MiniMax token plan, GLM/Z.AI, Kimi/Moonshot, Ollama Pro, Alibaba/Qwen, Claude Code Max, ChatGPT Business) can back a review pass at zero new cost. Credentials arrive via the secrets funnel but land **per-harness, not in one tier** — resolve each plan's key from `pmoves/chit/secrets_manifest.yaml` (e.g. most provider keys are `env.tier-llm`, while Claude Code Max's `CLAUDE_CODE_OAUTH_TOKEN` registers in the agent tier), and a given node may legitimately not carry a given plan. Per the coding-plan policy these run **through their CLIs/harnesses**, not raw API calls. Note the boundary: coding-plan passes leave the node to the provider (established commercial channel), unlike Ollama which never leaves — reach for the plan when you want the stronger model, reach for local when the diff is sensitive.
+
+**Guardrail**: on-node observations are **leads, not verdicts** — every finding must be re-verified by a session before it enters the review body. Never the Control angle; the operator gate stays human.
+
 ## When to apply
 
 | Situation | Apply? |
 |-----------|--------|
-| Two or more CLAUDE sessions running parallel orchestration | **Yes** — default cadence |
+| Two or more agent sessions running parallel orchestration (same or mixed harnesses) | **Yes** — default cadence |
 | Lane explicitly partitioned (mirror owns X, you own Y) | **Yes** — review each other's deliverables, never each other's claim register |
-| Solo-session, no parallel CLAUDE | **No** — Codex/CodeRabbit + honest self-review suffice |
+| Skills PR (`.claude/skills/**`, `skills/PMOVES-skills/**`) | **Yes** — use the skills checklist in the `pmoves-pair-review` SKILL.md (frontmatter contract, description-as-trigger, anchors ratchet, live-surface probes) |
+| Solo-session, no parallel peer | **No** — Codex/CodeRabbit + honest self-review + operator suffice |
 | Submodule-only PR (no main-tree touch) | **Optional** — high-value if mirror has domain context; skip if not |
 | Hotfix / damage-control / time-critical | **Defer** — apply post-merge in retrospective review |