docs(handoff): skill-check Danger Room with verifiable artifacts → SPARK - #2495
Merged
Merged
Conversation
…PARK Today's ratchets made every NAMED thing in this repo checkable. They made nothing WORKED checkable. validate-command-anchors (#2488, #2494) proves a skill's targets, path citations, ssh hosts and the guard's own routing table all resolve. It cannot prove the skill does what it claims. A skill can be perfectly anchored and completely wrong. The ladder, named so the rungs stop being confused for each other: T1 anchored does everything it names exist? validate-command-anchors SHIPPED T2 exercised does it do what it claims, on a Danger Room THIS HANDOFF real node? T3 receipted can another node verify that CHIT + NATS designed, follows T2 without re-running it? T1 without T2 is a spell-checked lie. T2 without T3 is a result only the node that ran it can trust. SPARK on capability, not availability. GB10 / 128 GB unified means a skill claiming "route through TensorZero to a local model" can actually be exercised; on a CPU node that run is a mock, and a mock receipt is worse than none. Its claw scope already carries sign_trail: true + damage_control_hooks: true, so T3 needs no new trust wiring. And a sandbox resets free — skills get run against their worst fixture rather than their friendliest. The stage requested is five pieces, each grounded in something that bit this node today: 1. a pmoves-skill-check template beside templates/base, WITH SUBMODULES POPULATED — SUBMODULE_BUILD_AND_MOUNT_GAP.md applies directly here and an empty-submodule sandbox produces confident false negatives. 2. an ADDITIVE skill frontmatter contract (scope / nodes / danger_room), where scope reuses the classifier vocabulary validate_command_anchors already has rather than inventing a second one. Declared scope disagreeing with actual command scope is itself a finding. 3. fixtures that PLANT A FALSIFIABLE FAILURE, versioned beside the skill. A fixture that plants nothing verifies nothing. 4. artifacts that are deterministic, self-describing (carrying the skill CONTENT HASH, or the verdict cannot be tied to what it judged), signed-or-explicitly-labelled-unsigned, and addressable. A verdict on one node's local disk is a rumour everywhere else. 5. CHIT reflection: one skill.verified.v1 receipt per run, closed schema registered BEFORE first publish. archon.crawl.* is the cautionary tale of a subject registered against an operation nobody built. Acceptance is written to be observable from artifacts alone, so the lane does not require me present for a run. The load-bearing criterion is that a DELIBERATELY BROKEN SKILL PRODUCES A RED ARTIFACT — every gate shipped on this node today was weaker than advertised until something proved it could say no. Why it matters past hygiene: a 1B-param agent cannot judge whether a skill will work, but it can read a receipt. The heavy model pays discovery cost once in the sandbox and leaves pre-digested context; the small model selects on it instead of reasoning about it. Same principle patterns.yaml already proves — the guard hands over the correct path, valid parameters, and how to verify, so the model need not know PMOVES. Capability in the field rather than the model, extended from "what to do when blocked" to "what actually works." Not claimed by 4090 — SPARK is named owner and the row is left open for SPARK to CLAIM. Out of scope and flagged: deploying e2b-mcp-server (Agent Zero registers e2b.* against :7073, which is not a compose service, is not running, and for surf has no route in the fork at all — separate lane, must not block this one); retrofitting all 31 skills; building T3 before T2 emits something worth signing. Gitlink for PMOVES-E2B-Danger-Room is currently drifted (+) — noted in the doc, sync before building the template. Verified: make -C pmoves validate-command-anchors passes on both new files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
github-actions
Bot
added
docs
Contributor
📝 WalkthroughWalkthroughThe PR adds documentation for a Tier-2 SPARK workflow that executes skills against falsifiable fixtures, creates deterministic hash-bound artifacts, and defines future ChangesSkill-check Danger Room
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 997f370b17
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Not availability — capability. | ||
|
|
||
| - **DGX GB10 Grace-Blackwell, 128 GB unified** (`configs/claws/scopes/spark.json`: `role: gpu-inference`, `hostname: pmoves-spark`). A skill that says *"route through TensorZero to a local model"* can be **actually exercised** there. On a CPU node the same run is a mock, and a mock receipt is worse than none. | ||
| - **`sign_trail: true` and `damage_control_hooks: true`** are already set in its claw scope. T3 needs no new trust wiring — the signing identity is live. |
There was a problem hiding this comment.
On a SPARK checkout without CHIT_SIGNING_KEY or CHIT_PASSPHRASE, this claim is false: sign_trail: true is only a node-scope flag, while pmoves/tools/sign_trail.py:254-257 explicitly emits an unsigned payload when no key is available. T3 is defined here as producing cross-node-verifiable CHIT-signed receipts, so require a signing-key preflight or describe the resulting receipts as unsigned T2 artifacts rather than asserting that the signing identity is live.
AGENTS.md reference: AGENTS.md:L60-L62
Useful? React with 👍 / 👎.
|
|
||
| Sibling to the existing `templates/base`. Must contain the repo checkout **with submodules populated** — the gap documented in `pmoves/docs/operations/SUBMODULE_BUILD_AND_MOUNT_GAP.md` applies here directly, and a Danger Room whose sandbox has empty submodule dirs will produce confident false negatives. | ||
|
|
||
| Note the gitlink is currently drifted (`git submodule status PMOVES-E2B-Danger-Room` shows `+`). Sync before building the template. |
There was a problem hiding this comment.
At the reviewed commit, a clean checkout records gitlink 78f7c5d84f5e4e015cc3bce919817adcce2d5b45, while git submodule status -- PMOVES-E2B-Danger-Room can report a leading - until initialization; the leading + described here is uncommitted state from the sender's worktree and will not transfer to SPARK. The ambiguous instruction to “sync” therefore cannot reproduce the intended substrate; document the expected SHA and an explicit recursive initialization/update command, with SPARK verifying its own local state.
AGENTS.md reference: AGENTS.md:L68-L76
Useful? React with 👍 / 👎.
|
|
||
| ``` | ||
| skill.verified.v1 | ||
| { skill, skill_sha, fixture, node, verdict, artifacts[], wall_s, ts, sig, kid } |
There was a problem hiding this comment.
If the closed receipt schema is implemented from this shape, it will not interoperate with the repository's CHIT helpers: pmoves/tools/chit_security.py:91-116 emits and verifies sig as an object containing {alg, kid, hmac}, not separate top-level sig and kid fields. The proposed shape also has no status field with which to label the unsigned-local case required above, so define the canonical optional signature object plus an explicit signing status before registering the schema.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md`:
- Around line 106-109: Update the fenced code block containing the
skill.verified.v1 receipt example to specify the text language identifier,
preserving the payload content unchanged.
- Around line 93-96: Define determinism over the complete declared execution
context, not only the fixture and skill version: include node identity, runtime,
model, toolchain, and configuration identity in the determinism key, and scope
rerun comparisons to matching contexts. Update the deterministic artifact
contract in
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md (lines
93-96) and the acceptance wording in pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md
(lines 1762-1766) so “deterministic” means producing the same verdict for the
same declared context.
- Around line 140-149: Expand the acceptance criteria in
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md lines
140-149 to verify each artifact is signed or explicitly unsigned and has a
fetchable address; also include receipt-registration evidence in the artifact,
or revise the artifact-only statement to permit catalog evidence. Update the
summarized criteria in pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md lines 1762-1766 to
match the complete artifact contract, including signature state, addressability,
and registration evidence.
- Around line 144-147: Update
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md lines
144-147 so acceptance rejects both leading “-” and “+” submodule status markers
and verifies each checked-out submodule SHA matches its superproject gitlink.
Update pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md line 1756 to record the post-sync
pinned state, not only the existing drift warning.
- Around line 104-113: Update
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md lines
104-113 and pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md line 1762 so
skill.verified.v1 is clearly marked as proposed until its closed-schema NATS
catalog entry exists, or make T3 registration an explicit prerequisite; once
finalized, add the subject to .claude/context/nats-subjects.md before describing
it as publishable.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: bb6f4eaf-21e7-4ddb-99b5-ac18466a5f14
📒 Files selected for processing (2)
pmoves/docs/AGENTS/AGNOTE4482PHI.t1.mdpmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md
Comment on lines
+93
to
+96
| - **deterministic** — same fixture, same skill version → same verdict. Non-determinism is a defect in the fixture, not an acceptable variance. | ||
| - **self-describing** — carries skill name, skill content hash, fixture id, node, wall time, verdict, and the artifact hashes. A verdict without a content hash cannot be tied to the thing it judged. | ||
| - **signed** — CHIT, `kid` present. Unsigned is fine for local iteration and must be *labelled* unsigned, never silently equivalent. | ||
| - **addressable** — a path any node can fetch. A verdict on Spark's local disk is a rumour everywhere else. |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Define determinism for the complete execution context.
The handoff requires the same fixture and skill version to produce the same verdict. It also allows different nodes to produce different results. Include node identity and runtime, model, toolchain, and configuration identity in the determinism key. Scope the rerun check to the same execution context.
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md#L93-L96: update the deterministic artifact contract with the execution-context fields.pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md#L1762-L1766: update the acceptance wording so “deterministic” means deterministic for the same declared context.
📍 Affects 2 files
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md#L93-L96(this comment)pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md#L1762-L1766
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md`
around lines 93 - 96, Define determinism over the complete declared execution
context, not only the fixture and skill version: include node identity, runtime,
model, toolchain, and configuration identity in the determinism key, and scope
rerun comparisons to matching contexts. Update the deterministic artifact
contract in
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md (lines
93-96) and the acceptance wording in pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md
(lines 1762-1766) so “deterministic” means producing the same verdict for the
same declared context.
Comment on lines
+104
to
+113
| Each run emits one receipt: | ||
|
|
||
| ``` | ||
| skill.verified.v1 | ||
| { skill, skill_sha, fixture, node, verdict, artifacts[], wall_s, ts, sig, kid } | ||
| ``` | ||
|
|
||
| Published to NATS, accumulated into every node's CHIT map. The effect: **"works on spark, untested on 4090, failed on knuckles at fixture X"** becomes a fact any agent can *read* rather than folklore it has to *discover*. | ||
|
|
||
| Subject naming and closed-schema registration should follow the existing convention — see `.claude/context/nats-subjects.md`. Register before publishing; the `archon.crawl.*` family is the cautionary tale of a subject registered against an operation that was never built. |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -F 'skill.verified.v1' .claude/context/nats-subjects.mdRepository: POWERFULMOVES/PMOVES.AI
Length of output: 161
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "== git status =="
git status --short
echo "== candidate files =="
git ls-files | rg '(^\.claude/context/nats-subjects\.md$|pmoves/.*/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08\.md$|pmoves/docs/AGENTS/AGNOTE4482PHI\.t1\.md$)' || true
echo "== changed files =="
git diff --name-only HEAD 2>/dev/null || true
echo "== references to skill.verified.v1 =="
rg -n -F 'skill.verified.v1' . || true
echo "== nats-subjects.md outline and relevant section =="
wc -l .claude/context/nats-subjects.md
sed -n '1,240p' .claude/context/nats-subjects.mdRepository: POWERFULMOVES/PMOVES.AI
Length of output: 7966
Mark skill.verified.v1 as proposed or register it in the NATS catalog.
The documents mention publishing skill.verified.v1, but .claude/context/nats-subjects.md does not include it. Keep the event read as design/proposal until the closed-schema entry is added, or make T3 registration explicit as a prerequisite. Update the catalog entry for this subject when the schema is finalized.
🧰 Tools
🪛 markdownlint-cli2 (0.23.2)
[warning] 106-106: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
📍 Affects 2 files
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md#L104-L113(this comment)pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md#L1762-L1762
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md`
around lines 104 - 113, Update
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md lines
104-113 and pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md line 1762 so
skill.verified.v1 is clearly marked as proposed until its closed-schema NATS
catalog entry exists, or make T3 registration an explicit prerequisite; once
finalized, add the subject to .claude/context/nats-subjects.md before describing
it as publishable.
Source: Coding guidelines
Comment on lines
+106
to
+109
| ``` | ||
| skill.verified.v1 | ||
| { skill, skill_sha, fixture, node, verdict, artifacts[], wall_s, ts, sig, kid } | ||
| ``` |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Add a language identifier to the receipt example.
The fenced block at Lines 106-109 has no language tag. markdownlint-cli2 reports MD040. Use text for this payload-shaped example.
🧰 Tools
🪛 markdownlint-cli2 (0.23.2)
[warning] 106-106: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md`
around lines 106 - 109, Update the fenced code block containing the
skill.verified.v1 receipt example to specify the text language identifier,
preserving the payload content unchanged.
Source: Linters/SAST tools
Comment on lines
+140
to
+149
| ## Acceptance — how I will observe, at my pace | ||
|
|
||
| I do not need to watch a run. I need to be able to answer these from artifacts alone: | ||
|
|
||
| 1. `templates/pmoves-skill-check` exists, and a sandbox built from it has **populated submodules** (`git submodule status` shows no leading `-`). | ||
| 2. At least one skill declares the contract, and at least one fixture plants a falsifiable failure. | ||
| 3. A run against that fixture emits a self-describing artifact carrying the skill content hash. | ||
| 4. Re-running the same fixture against the same skill sha yields the same verdict. | ||
| 5. **A deliberately broken skill fails.** This is the acceptance test that matters — a harness that only ever passes has verified nothing. Break `ci-expedition`'s signature table on a branch, run it, and show me a red artifact. | ||
| 6. The receipt shape is registered before it is published. |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Align acceptance evidence with the artifact contract.
The artifact contract requires signed-or-explicitly-unsigned and addressable artifacts. The acceptance list checks only self-description, the skill hash, determinism, and a RED result. Add checks for the signature state and fetchable address.
The introduction also says that all answers must come from artifacts alone, but receipt registration is a control-plane check. Add registration evidence to the artifact or change that statement to include catalog evidence.
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md#L140-L149: expand acceptance evidence and clarify the artifact-only claim.pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md#L1762-L1766: keep the summarized acceptance criteria aligned with the complete artifact contract.
📍 Affects 2 files
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md#L140-L149(this comment)pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md#L1762-L1766
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md`
around lines 140 - 149, Expand the acceptance criteria in
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md lines
140-149 to verify each artifact is signed or explicitly unsigned and has a
fetchable address; also include receipt-registration evidence in the artifact,
or revise the artifact-only statement to permit catalog evidence. Update the
summarized criteria in pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md lines 1762-1766 to
match the complete artifact contract, including signature state, addressability,
and registration evidence.
Comment on lines
+144
to
+147
| 1. `templates/pmoves-skill-check` exists, and a sandbox built from it has **populated submodules** (`git submodule status` shows no leading `-`). | ||
| 2. At least one skill declares the contract, and at least one fixture plants a falsifiable failure. | ||
| 3. A run against that fixture emits a self-describing artifact carrying the skill content hash. | ||
| 4. Re-running the same fixture against the same skill sha yields the same verdict. |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Reject drifted submodules, not only unpopulated submodules.
git submodule status with no leading - proves that the submodule is populated. It does not reject a leading +, which means the checked-out commit differs from the superproject gitlink. The current + state can therefore pass the acceptance check with the wrong revision.
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md#L144-L147: require neither-nor+, and require the checked-out SHA to match the gitlink.pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md#L1756-L1756: record the post-sync pinned state, not only the current drift warning.
Suggested acceptance wording
- sandbox has populated submodules (`git submodule status` shows no leading `-`)
+ sandbox has populated and pinned submodules (`git submodule status PMOVES-E2B-Danger-Room` shows neither `-` nor `+`, and the checked-out SHA matches the superproject gitlink)📍 Affects 2 files
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md#L144-L147(this comment)pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md#L1756-L1756
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md`
around lines 144 - 147, Update
pmoves/docs/handoffs/SKILL_DANGER_ROOM_VERIFICATION_SPARK_2026-08-08.md lines
144-147 so acceptance rejects both leading “-” and “+” submodule status markers
and verifies each checked-out submodule SHA matches its superproject gitlink.
Update pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md line 1756 to record the post-sync
pinned state, not only the existing drift warning.
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 9, 2026
…reign RELEASE lines (#2498) * docs(agnote): WS2 RELEASE + lane sweep — evidence for owners, no foreign RELEASE lines Two entries. RELEASE — WS2 (z890's coordination plan) is complete inside its 72h TTL. Eight PRs merged: #2482 claim+handoff+corrections, #2483 ci-expedition skill, #2484 claude-pmoves delegation, #2485 submodule gap runbook, #2486 up-* inventory, #2488 validate-command-anchors, #2494 first-contact + guard routing table, #2495 Danger Room handoff to SPARK. pmoves/mk/infra.mk untouched throughout — z890's #2480, no collision. The entry records what the audit found BEYOND its enumerated items, because that is the reusable part: a gate can advertise coverage it does not have (three separate instances, each caught by review rather than by me); the always-loaded orientation file misdirects first contact; the guard's own routing table has two dead roads; and patterns.yaml is the pattern worth generalizing while pre-tool.sh duplicates 5 of its entries minus the affordance. It also records four corrections to my own prior work — the wrong 13-of-15 figure, the retracted hf-mcp-server entry, the dangerous first up-* retire list, and the yt-cookies pair that was never a duplicate. A closeout that only lists wins is not a closeout. NOTE — lane sweep. 115 CLAIM against 119 RELEASE. Four Mavis lanes verified shipped and missing only a RELEASE (harness v0 #2437/#2443/#2450, multi-fork follow-ups #2477, OpenRoom slice 2, creative-pipeline v0). Four older lanes still open with no PR cited and nothing found merged, now 8-10 days. Mine that are correctly still open: #2446 draft, #2468 held for review, and the SPARK handoff awaiting its CLAIM. ZERO RELEASE lines written on another agent's behalf — verified in the diff. Those lanes are Mavis's to close under Village Rule; this records evidence so they can close from it rather than from memory. Kept distinct from the KIMI-SPARK / CRUSH stale claims, which need a release OR re-claim — different category, and conflating them would make the ping inaccurate. Verified: make -C pmoves validate-command-anchors passes. Note for follow-up: dogfooding this entry surfaced a real false-positive generator in MAKE_CITE_RE — `-C \S+` swallows a closing backtick, so prose that backticks "make -C pmoves" alone captures the following word as a target. Fixed separately, not folded in here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(agnote): state the counting method, and stop treating merge as acceptance Three review findings, all correct, all mine. 1. THE TOTALS WERE NOT REPRODUCIBLE. I published "115 CLAIM against 119 RELEASE" with no method attached. Recounting three ways on the same file: anchored bullet rows 115 / 119 <- what I published token anywhere in text 284 / 221 (prose mentions) timestamped, no anchor 116 / 119 and the 2026-08-07 sweep reported 121 / 115 on a fourth. None of these is wrong; a bare number with no pattern is. The entry now states the exact regex, lists what the other methods give, and says to treat the ratio as a rough signal rather than a metric — the per-lane table is the checkable part. 2. MERGE IS NOT RUNTIME ACCEPTANCE. I listed OpenRoom slice 2 under "verified shipped, missing only a RELEASE" on the strength of #2437 merging. That lane was claimed against six handoff priorities with room-level acceptance, and #2437 is scaffold plus iframe wiring. Merging it does not demonstrate the rooms render. 3. Same for line 1723: it covers three deliverables including fork-side consumers, and #2477 merging in PMOVES.AI says nothing about whether the fork consumers landed. Both are now "merged, acceptance unverified" rather than ready-to-release, with the reasoning stated so the owner closes from runtime evidence instead of from my table. This is precisely the error the register exists to prevent, made by the sweep that exists to catch it — which is worth leaving visible rather than quietly correcting. Every gate I shipped this week was weaker than advertised until something proved it could say no; this one was a bookkeeping claim that had not been asked to reproduce itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A handoff assigning SPARK the Tier-2 skill-verification lane, plus the AGNOTE row that puts it on the board. Docs only — no code, and not claimed by 4090: the row names SPARK as owner and leaves it open for SPARK to CLAIM.
The gap this names
Today's ratchets made every named thing checkable. They made nothing worked checkable.
validate-command-anchors(#2488, #2494) proves a skill'smaketargets resolve, itsfile:NNNcitations exist, its ssh hosts are in the topology, and the damage-control guard's own roads aren't dead ends. It cannot prove a skill does what it claims. A skill can be perfectly anchored and completely wrong.So the rungs get named, because they keep getting confused for each other:
validate-command-anchorsT1 without T2 is a spell-checked lie. T2 without T3 is a result only the node that ran it can trust.
Why SPARK — capability, not availability
sign_trail: true+damage_control_hooks: truealready in its claw scope — T3 needs no new trust wiring.The stage requested — five pieces, each grounded in something that bit this node today
pmoves-skill-checktemplate besidetemplates/base, with submodules populated.SUBMODULE_BUILD_AND_MOUNT_GAP.mdapplies directly, and an empty-submodule sandbox produces confident false negatives.scope/nodes/danger_room.{fixture,artifacts,budget}.scopereuses the vocabularyvalidate_command_anchorsalready classifies by, rather than inventing a second one. Declared scope disagreeing with actual command scope is itself a finding. Additive means an undeclared skill is unverified, not broken.skill.verified.v1receipt per run, closed schema registered before first publish.archon.crawl.*is the cautionary tale of a subject registered against an operation nobody built.Native per node, reflected in all: "works on spark, untested on 4090, failed on knuckles at fixture X" becomes a fact any agent can read rather than folklore it has to discover.
Acceptance — observable from artifacts alone
Written so the lane doesn't need me present for a run. Six criteria; the load-bearing one:
Every gate shipped on this node today was weaker than advertised until something proved it could say no — the compose-drift gate that never fired, the anchor ratchet that missed fenced blocks, the ratchet that didn't ratchet. A harness that only ever passes has verified nothing.
Why it matters past hygiene
A 1B-param agent cannot judge whether a skill will work. It can read a receipt.
The heavy model pays the discovery cost once in the sandbox and leaves pre-digested context; the small model selects on it instead of reasoning about it. That's the bridge — bigger models building sensing surfaces smaller models can stand on, with the small model's constrained choice feeding back signal about which skills actually get reached for.
It's the principle
patterns.yamlalready proves: the guard hands over the correct path, the valid parameter set, and how to verify, so the model doesn't need to know PMOVES. Capability in the field rather than the model — extended from "what to do when blocked" to "what actually works."Flagged, not blocking
PMOVES-E2B-Danger-Roomgitlink is drifted (+) — sync before building the template.Out of scope: deploying
e2b-mcp-server(Agent Zero registerse2b.sandbox.*/e2b.spell.execute/e2b.surf.scrapeagainst:7073, which is not a compose service, is not running, and forsurfhas no route in the fork at all — separate lane, must not block this one, and those commands must not be assumed working because they're registered); retrofitting all 31 skills; building T3 before T2 emits something worth signing.Verification
Both new files pass the gate shipped this morning.
🤖 Generated with Claude Code
Summary by CodeRabbit