feat(tools): mavis harness v0 - CGP bootstrap + orchestrator + BPM cron - #2477
Merged
Conversation
Contributor
|
Warning Review limit reached
Next review available in: 40 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (13)
✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
📝 Generate docstrings
🧪 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 |
github-actions
Bot
added
docs
POWERFULMOVES
pushed a commit
that referenced
this pull request
Aug 8, 2026
The 2 of 3 fork consumers in the harness v0 cross-repo plan (PMOVES-hermes-agent + PMOVES-pinokio) landed their CGP consumer PRs as DRAFT. The PMOVES.AI side (PR #2477) is the writer; the 2 forks are the consumers. All 3 read the same v1.schema.json. What this AGNOTE row captures: - 2 new DRAFT PRs (POWERFULMOVES/PMOVES-pinokio PR #1 + POWERFULMOVES/PMOVES-hermes-agent PR #4) and the 24/24 + 33/33 test counts for each. - The CGP subject alignment against .claude/context/nats-subjects.md (the operator's 04_API_REFERENCE.md is the CHIT gateway HTTP API, not NATS subjects). My pmoves.agent.task.v1, pmoves.agent.result.v1, pmoves.bpm.phase.v1, pmoves.bpm.pomodoro.v1 follow the pmoves.<service>.<event>.<version> family and don't conflict with any existing subject. - The non-breaking design choice for each fork: the Hermes fork adds a new pmoves_bootstrap/ package with no modifications to existing files; the Pinokio fork adds pure Node.js helpers with no new npm deps. Both follow the test pair (no-CGP = exact pre-change behavior, with-CGP = PMOVES tools available alongside native tools). - What's NOT in this slice (intentional): the real pmoves-nats-mcp integration, the Hermes subscriber wired to a real nats-py loop (needs a pyproject.toml change), Pinokio main.js wiring, KVM control surface, the Pillar 4 cyber.png render, the 3 clubs content. All are follow-up slices with explicit lane assignments. Three-body: delivery=Mavis (this, the 2 fork PRs), control= DARKXSIDE (operator reviews the 3 PRs together), memory=this trail + the 2 PRs + the cross-fork LEARNINGS files. CHIT trail unsigned-local (no CHIT_PASSPHRASE loaded in this Mavis session).
POWERFULMOVES
marked this pull request as ready for review
August 8, 2026 14:48
![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: d73fef744d
ℹ️ 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".
Comment on lines
+213
to
+214
| self._merge_results(result) | ||
| return result |
There was a problem hiding this comment.
For every valid-agent dispatch, this merges immediately after time.sleep(0) while all entries are still pending, so dispatch() returns an empty merged value and marks every target failed. Results cannot arrive through the documented hook either because _receive_result() always raises; even callers that mutate the result and invoke _wait_for_results() must discover and call another private method to rebuild merged. The dispatch path needs to correlate and receive results, wait or time out, and only then merge them.
Useful? React with 👍 / 👎.
Comment on lines
+56
to
+59
| SUBJECT_TASK = "pmoves.agent.task.v1" | ||
| SUBJECT_RESULT = "pmoves.agent.result.v1" | ||
| SUBJECT_BPM_PHASE = "pmoves.bpm.phase.v1" | ||
| SUBJECT_BPM_POMODORO = "pmoves.bpm.pomodoro.v1" |
There was a problem hiding this comment.
When these subjects are wired through the repository's standard event publisher, all four are rejected before reaching NATS: services/common/events.py::envelope() validates against pmoves/contracts/topics.json, whose lookup raises KeyError for each newly introduced subject. Add versioned payload schemas and topic-registry entries so task, result, phase, and pomodoro messages have a consumable wire contract.
AGENTS.md reference: pmoves/AGENTS.md:L31-L31
Useful? React with 👍 / 👎.
Comment on lines
+186
to
+188
| self.work_minutes = work_minutes or _int_env(ENV_WORK_MINUTES, DEFAULT_WORK_MINUTES) | ||
| self.checkin_minutes = checkin_minutes or _int_env(ENV_CHECKIN_MINUTES, DEFAULT_CHECKIN_MINUTES) | ||
| self.blocks_per_phase = blocks_per_phase or _int_env(ENV_BLOCKS_PER_PHASE, DEFAULT_BLOCKS_PER_PHASE) |
There was a problem hiding this comment.
When callers configure BpmCron(work_minutes=5, checkin_minutes=1, blocks_per_phase=3) or set the corresponding environment variables, these values are only stored on the cron and are never applied to a BpmTask passed to start(). A normally constructed task therefore still receives one 25/5 block per phase, making all documented cron-level and environment timing configuration ineffective unless callers redundantly copy every value into each task.
Useful? React with 👍 / 👎.
Comment on lines
+302
to
+303
| if not any(b.status == "completed" for b in task.blocks[phase.value]): | ||
| self._publish_phase(task, phase, "skipped") |
There was a problem hiding this comment.
When a task advances without completing every block, advance() already publishes the old phase as completed and marks its unfinished blocks skipped; close() then infers from the absence of completed blocks that the same phase was skipped and publishes a contradictory second terminal event. Explicit jumps also cause intermediate skipped events to be duplicated. Consumers replaying the phase stream can consequently observe completed phases reverting to skipped, so phase state should be tracked directly rather than inferred from block completion here.
Useful? React with 👍 / 👎.
POWERFULMOVES
commented
Aug 8, 2026
POWERFULMOVES
left a comment
POWERFULMOVES
left a comment
Owner
Author
There was a problem hiding this comment.
Pair-review pass from Mavis-verifier
Strong foundation slice. The CGP envelope aligns to the canonical pmoves/docs/PMOVESCHIT/CGP_v1.0_SPECIFICATION.md envelope (spec/meta/sig/super_nodes) and the bootstrap profile correctly uses super_nodes: [] to mark the manifest as metadata-not-data, which lets the consumer forks treat it as a non-breaking addon. The 3 tools compose by sharing one Publisher protocol + one CGP, the MockPublisher decouples the unit tests from a real NATS server (and I re-ran python -m unittest pmoves.tools.tests.test_load_bootstrap pmoves.tools.tests.test_orchestrator pmoves.tools.tests.test_bpm_cron myself: 56/56 OK), and the 4-class module split (loader / orchestrator / cron) matches the PMOVES pmoves/tools/ convention so future Spark / Knuckles sessions can find it without a map. The Publisher Protocol + dataclass Bootstrap + typed BpmTask shape is a clean foundation for the 2 fork-side PRs to consume.
5 observations surfaced for follow-up commit (non-blocking):
1. The 4 new NATS subjects are NOT registered in .claude/context/nats-subjects.md, and pmoves.agent.task.v1 doesn't fit the documented naming convention
The PR introduces pmoves.agent.task.v1, pmoves.agent.result.v1, pmoves.bpm.phase.v1, pmoves.bpm.pomodoro.v1 (orchestrator.py:56-59, bpm_cron.py:347,356) but none appear in .claude/context/nats-subjects.md. The catalog's documented convention is <category>.<service>.<event>.<version> and the existing pmoves.* service namespace already uses task, a2a, skill, config, log, metric, event, s3, agent-zero-... (lines 1742-1757). The new pmoves.agent.task.v1 introduces a new agent service that doesn't appear in any current subject — a real producer that wants to subscribe to "Mavis dispatched work" cannot grep the catalog to find the wire. The AGNOTE multi-fork follow-up row at pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md:1638 claims "verified against .claude/context/nats-subjects.md ... don't conflict with any existing subject" — this is a true-but-misleading claim: there's no literal collision, but the naming is inconsistent with the catalog's pmoves.task.* family. Either register the 4 subjects in the catalog (preferred), or rename to pmoves.task.dispatch.v1 / pmoves.task.result.v1 to match the pmoves.task.assign.v1 precedent.
2. Schema's super_nodes: [] is described as required but isn't in the required array, and the test name lies about it
pmoves/contracts/schemas/pmoves-bootstrap/v1.schema.json:7 lists the top-level required as ["spec", "meta", "identity", "tools", "mcps", "services", "routing", "constraints"] — super_nodes is NOT required. The schema's own description on line 200 says "this MUST be the empty array", but a producer that forgets the key will pass validation (verified by feeding a CGP with super_nodes deleted: jsonschema.validate returns OK). The maxItems: 0 only enforces emptiness if present. The test test_empty_super_nodes_required_by_schema in pmoves/tools/tests/test_load_bootstrap.py:2356 is misnamed — it tests that a CGP with super_nodes: [] loads, NOT that the schema requires it. Add "super_nodes" to the required array (and keep maxItems: 0 + default: []), or rename the test so a future reader doesn't get the false impression of enforcement.
3. The spec key has two different semantic meanings between CGP v1.0 and this profile — semantic-naming drift on the envelope itself
The canonical CGP v1.0 spec at pmoves/docs/PMOVESCHIT/CGP_v1.0_SPECIFICATION.md:164 uses "spec": "chit.cgp.v1.0" to mean the protocol version. The new bootstrap schema at v1.schema.json:12 uses "spec": "pmoves.bootstrap/v1" to mean the profile identifier. Both files describe the same spec field but assign it different semantics: one is "what protocol am I", the other is "what profile am I". The bootstrap profile's description (line 5) claims "Aligned to the canonical CHIT Geometry Packet spec ... the same envelope (spec/meta/sig/super_nodes/...)" — true for the envelope shape, false for the semantic of spec. A consumer fork that naively assumes the same spec semantics will be surprised. Either (a) add a protocol: "chit.cgp.v1.0" field and demote spec to a sub-key, or (b) document the re-purposing in the schema's description so consumer implementers don't get bitten.
4. The orchestrator's dispatch() computes a deadline it never uses, and _receive_result is a dead NotImplementedError footgun
pmoves/tools/orchestrator.py:175 computes deadline = time.monotonic() + self.timeout_s and line 1814 acknowledges it with _ = deadline # documented for future use. The function returns immediately with all AgentResult.status == "pending" (verified by calling Orchestrator().dispatch("real-call", agents=["kiloclaw"]) — result is kiloclaw: status=pending, never timeout). The actual waiting is delegated to _wait_for_results(), but dispatch() does not call it. Combined with _receive_result() (line 1830) which raises NotImplementedError with the message "use DispatchResult.results[target] = AgentResult(...) directly" — a real NatsPublisher implementation that subscribes to pmoves.agent.result.v1 and tries to push results into the orchestrator via the documented hook will throw. The test pattern works because it injects directly; production code that wires up a real subscriber will fail. Either implement _receive_result as the production result-injection hook (lock + dict update), or remove it to prevent the footgun.
5. additionalProperties: true at the top level + on meta/services/routing allows typo'd producer CGPs to silently pass validation
v1.schema.json:8 (top-level) and lines 19, 48, 110, 124, 138, 147, 158, 163 (nested objects) all set additionalProperties: true. A producer that mistypes pmoves-nats-mcp as pmoves-bnats-mcp or hermes as hermes-3 in routing will have the loader silently accept the typo and the env-var export will produce PMOVES_BOOTSTRAP_TARGET_HERMES=hermes-3 (or nothing) without a warning. The example file happens to have correct values, but the schema can't catch the typo. Either (a) tighten to additionalProperties: false for routing and tools (the CGP contract is fixed in v0), or (b) add a "strict mode" flag that warns on unknown keys. The "tagged-services-are-advisory" rationale (loader line 81) covers missing services but not typo'd ones.
Nit (skip if scope creep)
The AGNOTE mavis-harness-v0 CLAIM row at pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md:1632 says "Scope: 7 commits in PMOVES.AI" but git log c7ff017d14..HEAD --oneline shows 8 commits (CLAIM + CGP schema + load_bootstrap + orchestrator + bpm_cron + HARNESS/LEARNINGS + multi-fork LEARNINGS + AGNOTE multi-fork). Off-by-one between the AGNOTE claim and the actual commit log. The PR body says "8 commits" so AGNOTE is the one out of sync.
Disposition
APPROVE-WITH-NITS. The slice is reviewable as-is, the schema contract is sound, the tests cover the happy path + structural rejection, and the consumer-fork coordination is correctly scoped as DRAFT. None of the 5 observations above rise to a blocker for the PMOVES.AI side of the slice — observations 1, 4, 5 are pre-merge cleanups that improve the contract; observations 2, 3 are documentation/test-name corrections. Recommended path: merge the PMOVES.AI side once observations 2 + 5 are addressed in a follow-up commit (cheap, ~30 lines), defer observations 1, 3, 4 to the multi-fork follow-up row (they touch the NATS catalog + orchestrator internals that the 2 fork PRs also need to see).
Per the pair-review skill's anti-pattern rule (reviewer doesn't push to the author's branch), the producer should pick the follow-up sequence. If the operator prefers all 5 in one commit, the schema + orchestrator changes are still < 100 lines.
agent_signature (advisory unsigned-local): ACK::Mavis-verifier::HARNESS-V0-REVIEW-2026-08-08
POWERFULMOVES
pushed a commit
that referenced
this pull request
Aug 8, 2026
The 3 verifier reviews are in (APPROVE-WITH-NITS for all 3). 14 observations surfaced total; ~30 lines of pre-merge cleanup candidates + 9 deferred to follow-up slices. Real-run evidence collected (not just claim-checking): - PMOVES.AI PR #2477: re-ran python -m unittest, 56/56 OK; AST-counted test files, 22+12+22=56 matches the claim; probed schema with jsonschema.validate, confirmed super_nodes: [] NOT enforced as required. - PMOVES-pinokio PR #1: SHA-256 byte-compared vendored v1.schema.json against canonical, byte-identical (427611C4...4BD3, 10028/10028 bytes); 24/24 tests pass. - PMOVES-hermes-agent PR #4: vendored schema byte-identical to canonical after CRLF strip (same SHA-256); 33/33 tests pass in clean repro on Windows. Top pre-merge cleanup candidates (across all 3 PRs): - Add super_nodes to schema's required array (PR #2477, ~2 lines) - Tighten additionalProperties on services + mcps (PR #2477, ~5 lines) - Re-throw BootstrapError on missing path (PR #1, ~3 lines) - Fix test count drift 22->24 in file headers (PR #1, ~3 lines) - Skip non-string tool_ids in register_pmoves_tools (PR #4, ~2 lines) - Add *.json eol=lf to .gitattributes (PR #4, ~1 line) - Rename Bootstrap.source -> load_source (PR #4, ~5 lines) - Drop dead imports in loader.py (PR #4, ~1 line) Deferred to follow-up slices (not pre-merge): - NATS catalog entries for 4 new subjects (multi-fork follow-up) - spec field semantics alignment (multi-fork follow-up) - NatsPublisher impl (real NATS slice) - pinokio pmoves: true parser (Pinokio main.js wire-up) - Schema-sync test against canonical YAML (nats-py real slice) - Stub SHA-256 collision (depends on if a downstream consumer ever derives session IDs that way) Three-body: delivery=Mavis-verifier, control=DARKXSIDE (operator picks the follow-up sequence), memory=this trail + the 3 GitHub review comments. CHIT trail unsigned-local.
POWERFULMOVES
pushed a commit
that referenced
this pull request
Aug 8, 2026
…ce/agent keys The verifier's review of PR #2477 surfaced 2 contract-correctness findings; this commit applies the pre-merge cleanup for both: 1. super_nodes is now in the top-level required array. The schema description says 'MUST be the empty array' but the previous version didn't enforce it at the required level - a CGP without the field would silently pass validation. The new test_missing_super_nodes_rejected proves the requirement. 2. services and routing now have additionalProperties:false. The previous additionalProperties:true on these objects meant a typo'd service name (e.g. 'tnailscale' instead of 'tailscale') would be silently accepted. The new test_typo_service_name_rejected proves the rejection. The 'tagged-services-are-advisory' constraint covers MISSING services, not typo'd ones - this commit distinguishes the two. The structural fallback (for envs without jsonschema) was also updated to mirror the new constraints: it now iterates the required array (catching super_nodes) and walks services/routing to check for unknown keys (catching typos). Why not also tighten top-level additionalProperties:false or meta/services/routing sub-objects: the schema deliberately allows forward-compat minor-version additions, so unknown top-level keys are tolerated. The two specific objects where the typo risk is real (services, routing) now reject. Test count: 56 -> 58 (added test_missing_super_nodes_rejected + test_typo_service_name_rejected). All 58 pass.
POWERFULMOVES
pushed a commit
that referenced
this pull request
Aug 8, 2026
The mavis-harness-v0-multi-fork_LEARNINGS.md was created in the earlier 'multi-fork coordination' commit but the 5-class taxonomy was empty. This commit populates it with the 14 observations from the 3-PR review pass + the dispositions (13 already-fixed in the cleanup commits, 5 out-of-scope for follow-up, 0 pre-existing). Also adds the 'Pattern update' section with 5 concrete lessons for the pmoves-pair-review skill (byte-compare vendored schemas, force MUST in required array, tighten additionalProperties:false on leaf objects only, normalize CRLF before comparing, key=str for mixed-type sorted lists). Test counts now (after the cleanup commits): - PMOVES.AI PR #2477: 56 -> 58 (+2 new tests for super_nodes required + typo'd service name) - PMOVES-pinokio PR #1: 24 -> 26 (+2 new tests for re-throw on missing path + re-throw on malformed source) - PMOVES-hermes-agent PR #4: 33 -> 34 (+1 new test for non-string tool_id not crashing the bridge) Total: 113 -> 118 tests pass. Schema byte-compare still holds after the cleanup commits (super_nodes added to required, services + routing additionalProperties: false) - the forks re-vendored the updated schema in the same cleanup commits.
Owner
Author
|
Disposition of the verifier's 5 observations + 1 nit on this PR: Already fixed in follow-up commits (now on the branch):
Deferred to follow-up slices (not pre-merge):
Verification after the cleanup: all 58 tests pass (56 original + 2 new). Schema now enforces super_nodes as required + rejects typo'd service names. Cross-fork vendored copies (PMOVES-pinokio PR #1, PMOVES-hermes-agent PR #4) re-vendored the updated schema in their cleanup commits; SHA-256 byte-compare still holds. Disposition: APPROVE-WITH-NITS (the original verifier verdict). All observations are dispositioned; the 2 deferred items are documented in the AGNOTE + LEARNINGS for the multi-fork follow-up. The cross-fork CGP contract is intact. |
POWERFULMOVES
enabled auto-merge (squash)
August 8, 2026 15:27
added 11 commits
August 8, 2026 11:33
CLAIM the mavis harness v0 lane in AGNOTE4482PHI.t1 (post-3-PR close). Companion to today's OPENROOM-REALIZATION-SLICE-2 + LEARNINGS-4090 + CREATIVE-PIPELINE-V0 claims (all three merged earlier today). Scope: the inter-agent handoff + BPM cron + multi-fork CGP bootstrap that turns the operator's fleet (5090/Spark, PMOVES forks of Hermes + Pinokio + A2UI + Archon + Agent Zero + Creator + OpenRoom + PMOVES-nats-server) into a coherent multi-agent runtime for the DARKXSIDE-public content pipeline + the OpenRoom room-enhancements closure. The CGP (Compressed Geometric Packet) is the contract that ties the 3 forks together: PMOVES.AI writes it, PMOVES-hermes-agent reads it at session init, PMOVES-pinokio reads it when launching a PMOVES-tagged app. Same schema, three implementations, zero breaking changes on the consumer forks (CGP is a manifest, not a config replacement). CGP profile: pmoves.bootstrap/v1, aligned to the canonical v1.0 spec at pmoves/docs/PMOVESCHIT/CGP_v1.0_SPECIFICATION.md. Same envelope (spec/meta/sig/super_nodes/...), super_nodes: [] keeps it CGP-valid for the empty-geometry case. Subsequent commits in this slice: - CGP JSON schema at pmoves/contracts/schemas/pmoves-bootstrap/v1.schema.json - example CGP at pmoves/contracts/schemas/pmoves-bootstrap/example.cgp.yaml - load_bootstrap.py (the PMOVES side reader) - orchestrator.py (multi-agent dispatch via NATS) - bpm_cron.py (Mavis cron redesigned as BPM/pomodoro engine) - tests - LEARNINGS + PR The two fork-side PRs (PMOVES-hermes-agent + PMOVES-pinokio) are follow-up commits after the PMOVES.AI side is reviewed. Both follow the non-breaking test pair: (a) no-CGP = exact pre-change behavior, (b) with-CGP = PMOVES tools available alongside fork's native tools.
The contract that ties the 3 PMOVES forks together. PMOVES.AI writes the CGP, PMOVES-hermes-agent reads it at session init, PMOVES-pinokio reads it when launching a PMOVES-tagged app. Two files: - contracts/schemas/pmoves-bootstrap/v1.schema.json - the JSON Schema (Draft 2020-12) for the pmoves.bootstrap/v1 profile. Aligned to the canonical CGP v1.0 envelope (spec/meta/sig/super_nodes/...) at pmoves/docs/PMOVESCHIT/CGP_v1.0_SPECIFICATION.md. Bootstrap-specific fields (identity/tools/mcps/services/routing/constraints) are profile-level additions; super_nodes: [] keeps the file CGP-valid for the empty-geometry case. - contracts/schemas/pmoves-bootstrap/example.cgp.yaml - the human-readable example with real values from memory (minimax/dimensional/5090/Tailscale/RustDesk/Hostinger/Cloudflare). The forks' consumer-side PRs will read this file to verify their loader. The 6 constraints (no-override-existing-config, tagged-services-are-advisory, no-chit-bypass, no-force-push, no-ci-bypass, preserve-existing-tools) are the non-breaking guarantees the consumer forks MUST honor. They are the test pair for both follow-up fork PRs: a no-CGP session = exact pre-change behavior; a with-CGP session = PMOVES tools available alongside the fork's native tools. The required/additionalProperties shape is strict on the spec name (const pmoves.bootstrap/v1) and the required fields, but allows additionalProperties on meta/sig/identity/services/routing so the schema can evolve minor-version without breaking consumers. Next commits in this slice: - load_bootstrap.py (PMOVES.AI side reader; validates the CGP against v1.schema.json with jsonschema or a fallback structural check) - orchestrator.py (multi-agent dispatch via NATS) - bpm_cron.py (Mavis cron redesigned as BPM/pomodoro engine) - tests - LEARNINGS + PR
…otstrap
Reads a pmoves.bootstrap/v1 CGP from file / env var / raw string /
default example, validates against the v1 schema, returns a typed
Bootstrap object, and (by default) exports the CGP as
PMOVES_BOOTSTRAP_* env vars for the rest of the session to consume.
Resolution order (4 sources, 1 default):
1. path arg (file path to .yaml or .json)
2. source arg (raw YAML/JSON string)
3. PMOVES_BOOTSTRAP_CGP env var
4. PMOVES_BOOTSTRAP_CGP_PATH env var (file path)
5. DEFAULT_CGP_PATH (the example in the repo)
The Bootstrap object has typed accessors (no more cgp.get("identity",
{}).get("agent", "minimax")):
bs = load_bootstrap()
bs.identity.agent # "minimax"
bs.identity.role # "implementer"
bs.identity.skin # "dimensional"
bs.tools # ["mavis__agent__create", "comfyui_client", ...]
bs.mcps # ["pmoves-nats-mcp", "pmoves-chit-sign", ...]
bs.services.tailscale.host # "powerfullmoves.tail.ts.net"
bs.routing.kiloclaw.target # "glm-5.1"
bs.has_constraint("no-chit-bypass") # True
export_env() sets PMOVES_BOOTSTRAP_AGENT, ROLE, SKIN, TOOLS, MCPS,
CONSTRAINTS, TAILSCALE_HOST, TAILSCALE_IP, RUSTDESK_DEVICES,
HOSTINGER_SITE, CLOUDFLARE_ACCOUNT, TARGET_KILOCLAW, TARGET_HERMES.
The orchestrator + bpm_cron can read these instead of re-parsing the
CGP.
Validation uses jsonschema (Draft 2020-12) when available, with a
thin structural fallback for envs without jsonschema (just checks
required top-level fields + the spec const). The fallback is
intentionally minimal - the schema is the source of truth.
Errors are BootstrapError (distinct from generic exceptions) so the
orchestrator can catch + decide: retry, fall back to a default CGP,
or refuse to start the session.
Tests in pmoves/tools/tests/test_load_bootstrap.py - 22/22 pass:
- LoadFromExampleTests (8): the example in the repo loads + validates
- LoadFromSourceTests (4): raw YAML string, raw JSON string, env var
resolution, explicit path overrides env
- ValidationFailureTests (4): wrong spec rejected, missing required
field rejected, missing identity.agent rejected, empty super_nodes
accepted (per schema)
- ExportEnvTests (4): basic env export, services env export, routing
env export, env skipped when export_env=False
- SchemaSyncTests (2): the example validates against the schema (the
canary test - if this fails, either the schema or the example drifted)
Also fixed: example.cgp.yaml had
ode: 5090 (integer) which
violated the schema's type:string; quoted to "5090".
The runtime side of the Mavis harness. Reads the bootstrap CGP,
publishes tasks to pmoves.agent.task.v1, waits for results on
pmoves.agent.result.v1, and merges outputs from peer agents
(KiloClaw on 5090, Hermes on TBD).
Design notes (in the module docstring):
- The orchestrator is intentionally thin - it doesn't replace the
consumer forks' tools, it publishes work to them. The forks
(PMOVES-hermes-agent, PMOVES-pinokio) read the CGP, register the
PMOVES tools alongside their own, and respond on SUBJECT_RESULT.
- Transport is abstracted behind a Publisher protocol. MockPublisher
for tests; a real impl wraps pmoves-nats-mcp (the PMOVES-built
NATS server at POWERFULMOVES/PMOVES-nats-server). The v0 contract
uses 4 NATS subjects: SUBJECT_TASK, SUBJECT_RESULT,
SUBJECT_BPM_PHASE, SUBJECT_BPM_POMODORO.
- KNOWN_TARGETS = {mavis, kiloclaw, hermes}. Unknown targets are
marked error (not silently dropped) so the orchestrator surface
the misconfiguration.
- Dispatch returns a DispatchResult with one AgentResult per agent.
Real impl subscribes to SUBJECT_RESULT and pushes into
result.results[agent] from the callback; the v0 wire-up exposes
_wait_for_results() for the test pattern + the timeout-as-status
case.
Phase + pomodoro publishers are included so bpm_cron.py can drive
the BPM events through the same Publisher abstraction.
Tests in pmoves/tools/tests/test_orchestrator.py - 12/12 pass:
- DispatchTests (4): publishes to SUBJECT_TASK, multi-agent dispatch,
unknown target marked error, unique task_id per dispatch
- WaitForResultsTests (3): returns when all done, marks remaining
as timeout, returns immediately if all done
- MergeResultsTests (2): concatenates successful outputs, excludes
failed agents
- BpmPublishTests (2): publish_phase + publish_pomodoro emit the
right subjects + payloads
- ConstraintTests (1): no-chit-bypass is present in the bootstrap
(the orchestrator satisfies it by design - it only publishes,
never writes state directly)
The tests use the existing MockPublisher pattern from
comfyui_client.py - no NATS server required.
Redesigned Mavis cron. Each scheduled item is now a BPM task with 5 phases (define -> assign -> execute -> review -> close) and pomodoro focus blocks (25-min work + 5-min check-in, configurable via env) per phase. Why BPM not just cron: - The DARKXSIDE-public content pipeline is multi-step (react to a video, extract frames, generate a Pillar 4 visual, render through ComfyUI, post to the channel). Treating each step as a cron entry loses the cross-step context. BPM keeps the task envelope. - The public engagement workflow (react -> comment -> share -> analyze -> post) maps 1:1 to the 5 BPM phases. The orchestrator dispatches per phase; the BPM cron tracks the merged result per phase. - Multi-agent orchestration: a BPM task can be assigned to Mavis + KiloClaw + Hermes in parallel per phase. The orchestrator merges results; the cron tracks the deliverable. NATS events published: - pmoves.bpm.phase.v1 - phase start/completed/skipped - pmoves.bpm.pomodoro.v1 - focus-block start/completed/skipped Pomodoro defaults (env-driven for fast-iteration override): - PMOVES_BPM_WORK_MINUTES (default 25) - PMOVES_BPM_CHECKIN_MINUTES (default 5) - PMOVES_BPM_BLOCKS_PER_PHASE (default 1) Public surface (v0): - BpmTask (dataclass) - name, description, agents, 5 phases, N pomodoro blocks per phase, deliverables per phase - BpmCron (engine) - register/start/advance/complete-block/ record-deliverable/close/status/list-tasks - Phase (enum) - DEFINE/ASSIGN/EXECUTE/REVIEW/CLOSE - PomodoroBlock (dataclass) - block_index, work_minutes, checkin_minutes, status, started_at, completed_at Semantics baked in (caught by tests): - advance() to CLOSE auto-closes the task (no separate close() call required for the typical flow) - close() is idempotent (avoids double-publishing the close-completed event when advance() auto-closes) - Blocks in earlier phases that were started but not completed are marked "skipped" by close() (not left as "started") - advance() backwards is rejected (ValueError) - you can't un-close - record_deliverable() stores the merged output per phase so the next phase's agents can read it Tests in pmoves/tools/tests/test_bpm_cron.py - 22/22 pass: - PhaseEnumTests (1): phase order is define/assign/execute/review/close - BpmTaskTests (3): default block counts, multi-block per phase, default work+checkin - StartTests (3): publish phase+started, first pomodoro, started_at - AdvanceTests (5): next phase, publish completed+started, explicit to, backwards rejected, at close auto-closes - CompleteBlockTests (3): mark completed, advance when last block, stay in phase when more blocks - RecordDeliverableTests (1): record and retrieve per phase - CloseTests (2): marks remaining blocks skipped, publishes phase completed - StatusTests (3): includes all phases, after advance, list tasks - RejectTests (1): unknown task raises KeyError
Two docs close out the harness v0 slice: - pmoves/tools/HARNESS.md - the high-level map of the 3 tools (load_bootstrap, orchestrator, bpm_cron) + how they fit together + a quick-start code example. The file future Mavis / Spark / Knuckles sessions hit first to understand the integration. - pmoves/tools/LEARNINGS/mavis-harness-v0_LEARNINGS.md - the 5-class taxonomy (legit/already-fixed/owner/out-of-scope/ pre-existing) + 4-bucket learning signal (missed-signal/ fix-pattern/wrong-suggestion/already-addressed) per the operator's pr-trim convention. Empty buckets (this is the initial slice, no review yet) but the structure is in place. Acceptance criteria (5/5) + tests (56/56) + files added (10) + the 3 fork-side follow-ups + the 3 app-level follow-ups (Ace Studio, Veo, KVM) are all in this file. Three-body: delivery=Mavis, control= DARKXSIDE, memory=this trail + AGNOTE CLAIM + HARNESS.md.
The 2 of 3 fork consumers in the harness v0 cross-repo plan (PMOVES-hermes-agent + PMOVES-pinokio) landed their CGP consumer PRs as DRAFT. The PMOVES.AI side (PR #2477) is the writer; the 2 forks are the consumers. All 3 read the same v1.schema.json. What this AGNOTE row captures: - 2 new DRAFT PRs (POWERFULMOVES/PMOVES-pinokio PR #1 + POWERFULMOVES/PMOVES-hermes-agent PR #4) and the 24/24 + 33/33 test counts for each. - The CGP subject alignment against .claude/context/nats-subjects.md (the operator's 04_API_REFERENCE.md is the CHIT gateway HTTP API, not NATS subjects). My pmoves.agent.task.v1, pmoves.agent.result.v1, pmoves.bpm.phase.v1, pmoves.bpm.pomodoro.v1 follow the pmoves.<service>.<event>.<version> family and don't conflict with any existing subject. - The non-breaking design choice for each fork: the Hermes fork adds a new pmoves_bootstrap/ package with no modifications to existing files; the Pinokio fork adds pure Node.js helpers with no new npm deps. Both follow the test pair (no-CGP = exact pre-change behavior, with-CGP = PMOVES tools available alongside native tools). - What's NOT in this slice (intentional): the real pmoves-nats-mcp integration, the Hermes subscriber wired to a real nats-py loop (needs a pyproject.toml change), Pinokio main.js wiring, KVM control surface, the Pillar 4 cyber.png render, the 3 clubs content. All are follow-up slices with explicit lane assignments. Three-body: delivery=Mavis (this, the 2 fork PRs), control= DARKXSIDE (operator reviews the 3 PRs together), memory=this trail + the 2 PRs + the cross-fork LEARNINGS files. CHIT trail unsigned-local (no CHIT_PASSPHRASE loaded in this Mavis session).
The 5-class taxonomy + 4-bucket learning signal structure is in place but empty (this is the initial slice, no review yet). The self-review notes capture things the next session should check on review: 1. Cross-fork CGP schema drift - the 2 forks vendored a copy of the schema; if the PMOVES.AI schema changes, the forks will silently drift. Possible fixes: (a) CI hash check, (b) shared pmoves-schemas repo, (c) CHIT signed check at session init. 2. No real NATS transport in v0 - MockPublisher on the PMOVES.AI side, stub subscriber on the Hermes side. Follow-up slices. 3. No CGP re-emission in the Hermes side - result envelopes carry the task_id but not the agent that did the work. Future slice. 4. The 6 constraints are honored by behavior, not by code - no code path explicitly checks for no-override-existing-config or preserve-existing-tools; the loader's behavior is to never touch the fork's existing config. A future slice could add a constraint validator. 5. The example app in PMOVES-pinokio is a no-op on purpose - the point is the wiring, not a working service. The acceptance criteria checklist is in this file (5 done, 7 follow-up). The cross-fork plan references the 3 PRs by URL. Three-body: delivery=Mavis (this), control=DARKXSIDE (operator reviews the 3 PRs together), memory=this trail + LEARNINGS. CHIT trail unsigned-local.
The 3 verifier reviews are in (APPROVE-WITH-NITS for all 3). 14 observations surfaced total; ~30 lines of pre-merge cleanup candidates + 9 deferred to follow-up slices. Real-run evidence collected (not just claim-checking): - PMOVES.AI PR #2477: re-ran python -m unittest, 56/56 OK; AST-counted test files, 22+12+22=56 matches the claim; probed schema with jsonschema.validate, confirmed super_nodes: [] NOT enforced as required. - PMOVES-pinokio PR #1: SHA-256 byte-compared vendored v1.schema.json against canonical, byte-identical (427611C4...4BD3, 10028/10028 bytes); 24/24 tests pass. - PMOVES-hermes-agent PR #4: vendored schema byte-identical to canonical after CRLF strip (same SHA-256); 33/33 tests pass in clean repro on Windows. Top pre-merge cleanup candidates (across all 3 PRs): - Add super_nodes to schema's required array (PR #2477, ~2 lines) - Tighten additionalProperties on services + mcps (PR #2477, ~5 lines) - Re-throw BootstrapError on missing path (PR #1, ~3 lines) - Fix test count drift 22->24 in file headers (PR #1, ~3 lines) - Skip non-string tool_ids in register_pmoves_tools (PR #4, ~2 lines) - Add *.json eol=lf to .gitattributes (PR #4, ~1 line) - Rename Bootstrap.source -> load_source (PR #4, ~5 lines) - Drop dead imports in loader.py (PR #4, ~1 line) Deferred to follow-up slices (not pre-merge): - NATS catalog entries for 4 new subjects (multi-fork follow-up) - spec field semantics alignment (multi-fork follow-up) - NatsPublisher impl (real NATS slice) - pinokio pmoves: true parser (Pinokio main.js wire-up) - Schema-sync test against canonical YAML (nats-py real slice) - Stub SHA-256 collision (depends on if a downstream consumer ever derives session IDs that way) Three-body: delivery=Mavis-verifier, control=DARKXSIDE (operator picks the follow-up sequence), memory=this trail + the 3 GitHub review comments. CHIT trail unsigned-local.
…ce/agent keys The verifier's review of PR #2477 surfaced 2 contract-correctness findings; this commit applies the pre-merge cleanup for both: 1. super_nodes is now in the top-level required array. The schema description says 'MUST be the empty array' but the previous version didn't enforce it at the required level - a CGP without the field would silently pass validation. The new test_missing_super_nodes_rejected proves the requirement. 2. services and routing now have additionalProperties:false. The previous additionalProperties:true on these objects meant a typo'd service name (e.g. 'tnailscale' instead of 'tailscale') would be silently accepted. The new test_typo_service_name_rejected proves the rejection. The 'tagged-services-are-advisory' constraint covers MISSING services, not typo'd ones - this commit distinguishes the two. The structural fallback (for envs without jsonschema) was also updated to mirror the new constraints: it now iterates the required array (catching super_nodes) and walks services/routing to check for unknown keys (catching typos). Why not also tighten top-level additionalProperties:false or meta/services/routing sub-objects: the schema deliberately allows forward-compat minor-version additions, so unknown top-level keys are tolerated. The two specific objects where the typo risk is real (services, routing) now reject. Test count: 56 -> 58 (added test_missing_super_nodes_rejected + test_typo_service_name_rejected). All 58 pass.
The mavis-harness-v0-multi-fork_LEARNINGS.md was created in the earlier 'multi-fork coordination' commit but the 5-class taxonomy was empty. This commit populates it with the 14 observations from the 3-PR review pass + the dispositions (13 already-fixed in the cleanup commits, 5 out-of-scope for follow-up, 0 pre-existing). Also adds the 'Pattern update' section with 5 concrete lessons for the pmoves-pair-review skill (byte-compare vendored schemas, force MUST in required array, tighten additionalProperties:false on leaf objects only, normalize CRLF before comparing, key=str for mixed-type sorted lists). Test counts now (after the cleanup commits): - PMOVES.AI PR #2477: 56 -> 58 (+2 new tests for super_nodes required + typo'd service name) - PMOVES-pinokio PR #1: 24 -> 26 (+2 new tests for re-throw on missing path + re-throw on malformed source) - PMOVES-hermes-agent PR #4: 33 -> 34 (+1 new test for non-string tool_id not crashing the bridge) Total: 113 -> 118 tests pass. Schema byte-compare still holds after the cleanup commits (super_nodes added to required, services + routing additionalProperties: false) - the forks re-vendored the updated schema in the same cleanup commits.
POWERFULMOVES
force-pushed
the
feat/mavis-harness-v0
branch
from
August 8, 2026 15:37
8c916d5 to
0862597
Compare
POWERFULMOVES
pushed a commit
that referenced
this pull request
Aug 8, 2026
The 2026-08-08 3-PR review pass (PMOVES.AI #2477 + PMOVES-hermes-agent #4 + PMOVES-pinokio #1, all cross-fork consumers of the same CGP schema) surfaced 14 observations across the 3 PRs. The 6 cross-cutting lessons: 1. Byte-compare vendored schemas against canonical (SHA-256 + diff -q). Use text eol=lf in .gitattributes to avoid Windows-CRLF false-positives. The Pinokio + Hermes forks both survived this check (byte-identical vendored copies of v1.schema.json after CRLF strip). 2. Schema descriptions that say MUST should map to required. The PMOVES.AI super_nodes description said MUST but the field wasn't in the required array. After the fix, a CGP without super_nodes is rejected at the validator. 3. Tighten additionalProperties:false on the well-defined leaf objects only. Top-level + open-extension objects stay true for forward-compat. 4. Normalize CRLF before byte-comparing. Or add .gitattributes (the PMOVES-hermes-agent .gitattributes now has pmoves_bootstrap/cgp_schema/*.json text eol=lf). 5. The key=str trick for mixed-type sorted lists. A loader that skips malformed entries to a list can leave mixed types; sorted() on str+int+None+dict raises TypeError. 6. The stub vs real bootstrap pattern needs a deterministic stub. The no-CGP fallback uses hard-coded created_at so SHA-256(canonical_json) collides. Add uniqueness only if a downstream consumer derives session IDs from the stub. The full discussion with code references is in PAIR_REVIEW_RECIPROCITY.md (new section: 'Lessons from the 2026-08-08 3-PR pass'). The skill is updated to point at the long-form doc; the 6 lessons are summarized in the skill's step 7 for quick reference.
POWERFULMOVES
pushed a commit
that referenced
this pull request
Aug 8, 2026
The 2026-08-08 3-PR review pass (PMOVES.AI #2477 + PMOVES-hermes-agent #4 + PMOVES-pinokio #1, all cross-fork consumers of the same CGP schema) surfaced 14 observations across the 3 PRs. The 6 cross-cutting lessons: 1. Byte-compare vendored schemas against canonical (SHA-256 + diff -q). Use text eol=lf in .gitattributes to avoid Windows-CRLF false-positives. The Pinokio + Hermes forks both survived this check (byte-identical vendored copies of v1.schema.json after CRLF strip). 2. Schema descriptions that say MUST should map to required. The PMOVES.AI super_nodes description said MUST but the field wasn't in the required array. After the fix, a CGP without super_nodes is rejected at the validator. 3. Tighten additionalProperties:false on the well-defined leaf objects only. Top-level + open-extension objects stay true for forward-compat. 4. Normalize CRLF before byte-comparing. Or add .gitattributes (the PMOVES-hermes-agent .gitattributes now has pmoves_bootstrap/cgp_schema/*.json text eol=lf). 5. The key=str trick for mixed-type sorted lists. A loader that skips malformed entries to a list can leave mixed types; sorted() on str+int+None+dict raises TypeError. 6. The stub vs real bootstrap pattern needs a deterministic stub. The no-CGP fallback uses hard-coded created_at so SHA-256(canonical_json) collides. Add uniqueness only if a downstream consumer derives session IDs from the stub. The full discussion with code references is in PAIR_REVIEW_RECIPROCITY.md (new section: 'Lessons from the 2026-08-08 3-PR pass'). The skill is updated to point at the long-form doc; the 6 lessons are summarized in the skill's step 7 for quick reference.
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 8, 2026
…2489) * feat(voice): voice-sampler foundations — OmniVoice catalog live, diarization stack repaired, sampler spec - OmniVoice: enable the ref-voice catalog bind (/voices, ro) with an empty catalog dir + README encoding set-not-preset; health now reports catalog:true. - media-audio: PyTorch retired the cu124 wheel channel, killing the build. Regenerated requirements.lock via uv for cu128 on the DOCUMENTED pyannote stack (pyannote 3.4 + huggingface-hub 0.36 + torch 2.7.1+cu128 + transformers 4.57). transformers<5 is load-bearing: 5.x forces hub>=1.0 which breaks pyannote 3.x, and pyannote 4.x hard-requires torchcodec>=0.7 which aborts on import (std::length_error) — 202-restart crash loop, reproduced in isolation. - media-audio compose: env.shared blanks SSL_CERT_FILE/SSL_CERT_DIR/*_CA_BUNDLE (Windows host-leak guard) but empty means trust-nothing for Python/OpenSSL — HF downloads failed TLS verify. Re-point at the container CA store. - docs: VOICE_SAMPLER_SPEC.md — media→diarize→audition→pub-gate→publish flow, Voice Vault room app, owner-only gates. - submodule: promote PMOVES-Creator → ae174f7f (H3 blueprints PR #10, merged). Verified: service boots healthy on GPU (RTX 5090), stt+emotion loaded, no crashes; diarization reaches authenticated download (final step gated on the operator's HF token rotation). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(agnote): 5090 voice-sampler foundations CLAIM+RELEASE row Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(media-audio): allowlist pyannote checkpoint globals for torch>=2.6 weights-only load With a valid HF_TOKEN the gated segmentation-3.0 checkpoint downloads but fails torch 2.6+'s weights_only=True unpickling (TorchVersion / Specifications / Problem / Resolution are not default-safe globals). Allowlist exactly those four so TORCH_FORCE_WEIGHTS_ONLY_LOAD=1 keeps guarding every other model load. Verified live: healthz now reports models_loaded=[stt, emotion, diarization], diarization_enabled=true on the 5090. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(voice-sampler): media-sourced voice reference worker (spec v1) New pmoves/services/voice-sampler (port 8124, workers/voice profiles): SOURCE -> ANALYZE -> AUDITION -> APPROVE -> PUBLISH -> ANNOUNCE per VOICE_SAMPLER_SPEC.md. POST /sample diarizes a MinIO media object via media-audio (transcoding to 16k mono WAV first — pyannote's soundfile backend can't read m4a/AAC and torchcodec is deliberately absent), cuts per-speaker candidate clips with pydub, stages them in JuiceFS rooms/<room>/creator/references/voice-candidates/, and publishes voice.sample.candidates.v1. A NATS subscriber on voice.reference.approved.v1 executes the owner-gated PUBLISH step (JuiceFS references path + OmniVoice catalog dir + optional flute clone register, off by default while the flute routes are TODO) and announces voice.reference.published.v1. Owner gate fails closed when VOICE_SAMPLER_OWNER_ID is unset. Subjects registered in .claude/context/nats-subjects.md; voice-sampler mapped to the media split in split_compose.py. Smoke (5090, live): two-voice deep-dive m4a -> 2 speakers, 5 clips each, 10 objects staged in JuiceFS, batch 8995f0d90a67. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(pair-review): codify 6 lessons from 3-PR Mavis harness v0 pass The 2026-08-08 3-PR review pass (PMOVES.AI #2477 + PMOVES-hermes-agent #4 + PMOVES-pinokio #1, all cross-fork consumers of the same CGP schema) surfaced 14 observations across the 3 PRs. The 6 cross-cutting lessons: 1. Byte-compare vendored schemas against canonical (SHA-256 + diff -q). Use text eol=lf in .gitattributes to avoid Windows-CRLF false-positives. The Pinokio + Hermes forks both survived this check (byte-identical vendored copies of v1.schema.json after CRLF strip). 2. Schema descriptions that say MUST should map to required. The PMOVES.AI super_nodes description said MUST but the field wasn't in the required array. After the fix, a CGP without super_nodes is rejected at the validator. 3. Tighten additionalProperties:false on the well-defined leaf objects only. Top-level + open-extension objects stay true for forward-compat. 4. Normalize CRLF before byte-comparing. Or add .gitattributes (the PMOVES-hermes-agent .gitattributes now has pmoves_bootstrap/cgp_schema/*.json text eol=lf). 5. The key=str trick for mixed-type sorted lists. A loader that skips malformed entries to a list can leave mixed types; sorted() on str+int+None+dict raises TypeError. 6. The stub vs real bootstrap pattern needs a deterministic stub. The no-CGP fallback uses hard-coded created_at so SHA-256(canonical_json) collides. Add uniqueness only if a downstream consumer derives session IDs from the stub. The full discussion with code references is in PAIR_REVIEW_RECIPROCITY.md (new section: 'Lessons from the 2026-08-08 3-PR pass'). The skill is updated to point at the long-form doc; the 6 lessons are summarized in the skill's step 7 for quick reference. --------- Co-authored-by: Mavis <Mavis@pmoves.local> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 9, 2026
…cceptance
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>
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>
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 15, 2026
* feat(tools): pmoves standard branch protection spec + tool
The PMOVES standard branch-protection tool. Single source of truth for
how a PMOVES org repo's main branch is protected. The tool reads a
canonical JSON spec (pmoves_standard.json) and either audits a repo
against the spec, applies the spec to a repo, or drift-checks the
whole org.
What this slice lands:
- pmoves/configs/branch_protection/pmoves_standard.json - the
canonical spec. 2 profiles (monorepo + fork) + per_repo_overrides
for the 3 PMOVES repos in the org. The shape mirrors the GitHub
REST API 1:1, so a profile maps to actual API calls without
intermediate transformation.
- pmoves/tools/branch_protection.py - the tool. Pure-stdlib Python
(urllib.request + json), no new deps. Three public functions:
audit(repo, profile) - diff actual state vs spec
apply(repo, profile, dry_run=True) - apply the spec; dry-run by default
drift_check(org) - audit every repo in the org's overrides
8 dataclasses for structured results (AuditResult, DriftItem,
ApplyResult, DriftReport, etc.) so the orchestrator can consume
the output. CLI surface: `python -m pmoves.tools.branch_protection
{audit,apply,drift-check}` with structured JSON output.
Why this is the next slice after the harness v0:
The 3-PR review pass (PMOVES.AI #2477 + PMOVES-hermes-agent #4 +
PMOVES-pinokio #1) shipped the CGP bootstrap contract. The contract
ties 3 repos together, but the SECURITY POSTURE is wildly
asymmetric: PMOVES.AI is heavily protected (4 required status
checks, reviews with code owner enforcement, linear history,
signatures, 3 rulesets), but the 2 forks have NO protection at
all. The Hermes PR #4 was admin-merged only because there's no
required gate to be met - that's a bug-as-feature, not a
designed protection.
This tool makes the asymmetry visible (drift-check) and
correctable (apply). The Mavis cron can call drift-check daily
and publish on pmoves.branch_protection.drift.v1 (the NATS
subject lands in a follow-up slice).
Design notes (codified in the docstring + tests):
- The tool shells out to `gh api` instead of using urllib directly
for HTTP. Reason: the PMOVES GitHub App token + the operator's
PAT both flow through gh's auth, and wrapping gh gives the
operator free auth-state inspection via `gh auth status`.
Tradeoff: the tool requires `gh` installed and authenticated.
Documented in BRANCH_PROTECTION_BASELINE.md (follow-up docs).
- dry-run is the default. The tool never issues a PUT/POST without
`--no-dry-run`. The dry-run output is a JSON list of would-be
API calls; the operator reviews the list before issuing live
apply. The 2 forks in the spec will be applied manually after
this PR merges (slice 2, separate PRs per repo).
- The per_repo_overrides section is the per-repo customization
point. New forks add themselves here; the spec's strict shape
(additionalProperties: false on the profile keys) catches
typos before the tool hits the network.
- The diff function separates block (must-fix) from warn
(advisory) severity. required_status_checks + required_review
count are block; dismiss_stale_reviews + require_code_owner
are warn. A compliant repo has zero block-level drift;
warn-level drift is logged but doesn't fail the audit.
Three-body: delivery=Mavis (this PR), control=DARKXSIDE (operator
reviews the spec + the drift report, then runs apply manually for
each repo), memory=this trail + the spec + the LEARNINGS file.
CHIT trail unsigned-local (no CHIT_PASSPHRASE loaded in this Mavis
session).
* test(tools): 44 tests for branch_protection across 8 groups
Eight test groups cover the spec loader, the diff logic, the
apply body builder, audit + apply + drift-check end-to-end (with
mocked `gh api`), the CLI surface, and 2 error paths (gh missing
+ gh 404 for unprotected branch).
Test groups (each is a unittest.TestCase class):
- A. SpecLoaderTests (5) - load + resolve_repo_profile default +
with override + unknown repo + unknown profile
- B. DiffLogicTests (14) - 4 status-check scenarios, 3 review-policy
scenarios, 4 boolean-field scenarios (including the nested
{"enabled": bool} shape the real API returns), 3 rulesets
scenarios
- C. ApplyBodyTests (4) - classic body has all 9 required keys,
preserves values, ruleset body has 6 required keys, preserves
rules
- D. AuditTests (6) - compliant repo, no-protection-is-block,
missing-check-is-block, extra-check-is-warn, explicit profile,
unknown-repo-raises
- E. ApplyTests (5) - dry-run-no-calls, live-calls, skips-existing-
ruleset, includes-per-repo-override-checks, unknown-repo-raises
- F. DriftCheckTests (3) - one-report-per-repo, only-org-repos,
surfaces-audit-error-as-synthetic-drift
- G. CLITests (4) - audit-exits-0-when-compliant, audit-exits-1-
when-drift, drift-check-exits-2-when-any-drift, apply-default-
is-dry-run (the dry-run does ONE read for existing rulesets
so the output can accurately report skip-vs-create; no PUT or
POST is issued; the test asserts both)
- H. ErrorPathTests (2) - gh-missing-raises, gh-404-for-unprotected-
returns-none (the real GitHub API returns 404 + "Branch not
protected" stderr for an unprotected branch; the tool
recognizes this and returns None, not an error)
All 44 tests pass. The mocked subprocess calls use a lambda
side_effect keyed on (method, path) so the test surface is
explicit and the failure mode is "unmocked gh call" rather than
a silent no-op.
Test design notes (codified in the test docstring):
- The mocks use the SAME shape as the real GitHub API
response: required_status_checks.checks is a list of
{"context": "name"} objects; required_linear_history etc are
nested as {"enabled": bool}; rulesets is a list of dicts with
name + id + rules + bypass_actors. The diff logic was updated
to handle both the spec's bare-boolean shape and the API's
{"enabled": bool} shape, so a real audit + a unit test give
the same answer.
- The drift-check test (F3) ensures that an audit error (e.g.,
gh subprocess failure) doesn't crash the whole drift report -
the erroring repo appears with a synthetic DriftItem so the
operator can see which repos failed and why. This is the
pattern the Mavis cron relies on.
Three-body: delivery=Mavis (this), control=DARKXSIDE (operator
can run the tests locally with `python -m unittest
pmoves.tools.tests.test_branch_protection` before applying the
spec to the 2 forks), memory=this trail. CHIT trail unsigned-local.
* docs(agnote): branch protection v0 CLAIM row + 2-fork apply record
Records the Slice 2 fan-out: the PMOVES standard branch protection
tool landed (PR #2490) + both unprotected forks now have
the fork profile applied.
Real-run evidence (this commit's author):
- python -m pmoves.tools.branch_protection apply --repo
POWERFULMOVES/PMOVES-pinokio --no-dry-run → created classic
protection (CodeRabbit required, 1 reviewer, linear history,
conversation resolution) + [main] ruleset (id=20589542)
- python -m pmoves.tools.branch_protection apply --repo
POWERFULMOVES/PMOVES-hermes-agent --no-dry-run → created
classic protection (9 required status checks, 1 reviewer,
linear history, conversation resolution) + [main] ruleset
(id=20589548)
- python -m pmoves.tools.branch_protection drift-check --org
POWERFULMOVES (post-apply) → both repos compliant, zero drift
What's NOT in this slice (intentional follow-up):
- PMOVES.AI migration to rulesets-only (Option A approved by
operator; needs a separate migration script because the
current tool's `apply` doesn't support "delete classic +
consolidate rulesets"). The bypass_actor list from the
[main] ruleset (RepositoryRole id=5, Integration id=1144995,
Integration id=1236702) must be re-registered in the new
ruleset.
- NATS subject pmoves.branch_protection.drift.v1 (Slice 3)
- Mavis cron that calls drift-check daily (Slice 3)
- BRANCH_PROTECTION_BASELINE.md + pair-review skill update
(Slice 4)
Three-body: delivery=Mavis, control=DARKXSIDE, memory=this
trail + PR #2490. CHIT trail unsigned-local.
* feat(tools): PMOVES.AI branch-protection migration (Option A)
The one-off migration script that consolidates PMOVES.AI's
classic + 3-ruleset layered state into a single ruleset
([ main ]) with the status check + review requirements +
copilot_code_review + the 3 bypass_actors preserved.
What this slice lands:
- pmoves/tools/branch_protection_migrate_pmai.py - the
migration script. Pure-stdlib (no new deps), uses the existing
branch_protection.py helpers (the same `gh api` wrapper, the
same spec loader, the same dataclass patterns). 2 public
functions:
plan() - reads the current state, computes the new
[ main ] ruleset body, returns a MigrationPlan
apply(plan, dry_run=True) - issues DELETE classic + PUT
[ main ] ruleset; dry-run is the default
- pmoves/tools/tests/test_branch_protection_migrate_pmai.py -
15 tests across 4 groups (compute_main_ruleset,
capture_state, plan, apply). All 59 tests pass across
both the tool + the migration.
- pmoves/configs/branch_protection/pmoves_standard.json -
added `submodule-gitlink-gate` to the monorepo profile's
required status checks. The actual state has 5 required
checks; the original spec had 4. This aligns the spec
with reality.
The migration is destructive (DELETE classic + PUT ruleset
in a different shape), so dry-run is the default. The
operator reviews the call sequence + the captured state
before --no-dry-run is issued.
Design notes (codified in the LEARNINGS file):
- The list endpoint /rulesets returns a SUMMARY without
bypass_actors. The migration re-fetches the per-ruleset
body to get the full bypass_actors list. Without this
re-fetch, the migration would silently drop the operator's
preauthorized --admin bypass. Captured in LEARNINGS lesson 1.
- The pull_request rule in a ruleset uses different field
names than the classic required_pull_request_reviews
block. The migration explicitly maps the spec's
required_pull_request_reviews keys to the ruleset
pull_request parameters. Captured in LEARNINGS lesson 2.
- The spec's monorepo profile hard-codes RepositoryRole id=5
as the default bypass_actor. The migration OVERRIDES this
with the captured bypass_actors from the existing ruleset
(3 actors: RepositoryRole id=5, Integration id=1144995,
Integration id=1236702). The spec is the source of truth
for new repos; the migration preserves the operator's
actual escape hatch for this repo. Captured in LEARNINGS
lessons 5 + 6.
- The migration is a one-off. After it runs, the canonical
branch_protection.py apply tool keeps the [ main ]
ruleset in sync with the spec. The migration script is
archived in the tool's directory; the spec + the tool are
the source of truth going forward.
Migration call sequence (dry-run, current state):
1. DELETE /repos/POWERFULMOVES/PMOVES.AI/branches/main/protection
2. PUT /repos/POWERFULMOVES/PMOVES.AI/rulesets/10887588 with:
- name: [ main ]
- rules: deletion, non_fast_forward, pull_request (1 reviewer
+ code owner + dismiss stale + review thread resolution),
copilot_code_review, required_status_checks (5 checks),
- bypass_actors: 3 (preserved)
Three-body: delivery=Mavis, control=DARKXSIDE (operator
reviews the dry-run output before --no-dry-run), memory=this
trail + the LEARNINGS file + the BRANCH_PROTECTION_BASELINE.md
doc. CHIT trail unsigned-local.
* docs(operations+learnings): branch protection baseline + 5-class LEARNINGS
Two companion docs for the branch protection fan-out.
- pmoves/docs/operations/BRANCH_PROTECTION_BASELINE.md - the
human-readable version of pmoves_standard.json. Covers:
- Why a baseline (the 3-PR review pass surfaced the
asymmetric protection state; this doc is the fix)
- The 2 profiles (monorepo + fork) with field-level
rationale + the GitHub doc citation for each
- Current state per repo (PMOVES.AI: not yet migrated;
PMOVES-hermes-agent: applied; PMOVES-pinokio: applied)
- How to apply / audit / drift-check (with the exact
`python -m pmoves.tools.branch_protection` invocations)
- How to add a new repo or a new profile
- The PMOVES.AI migration plan (Option A, the next apply)
- Wire-up to the harness (load_bootstrap CGP, Mavis cron,
orchestrator dispatch)
- 5 references to the official GitHub docs (rulesets,
protected branches, troubleshooting, MergeStateStatus
enum, the LEARNINGS file)
- pmoves/tools/LEARNINGS/branch-protection-v0_LEARNINGS.md -
the 5-class taxonomy + 4-bucket learning signal per the
pr-trim convention. Populated with 13 already-fixed, 5
out-of-scope, 0 pre-existing observations. The "Pattern
update" section adds 6 new lessons to the pmoves-pair-review
skill's step 7:
1. The list endpoint /rulesets returns a SUMMARY without
bypass_actors. Re-fetch the per-ruleset body when
bypass_actors is needed.
2. The pull_request rule in a ruleset uses different field
names than the classic required_pull_request_reviews
block. Map explicitly.
3. additionalProperties: false is the right default for
required objects, but bypass_actors and status_checks
should stay open (extending pair-review lesson 3 to
nested arrays).
4. UNSTABLE = mergeable + bypass_actors re-fetch = mandatory.
Both are silent-corruption traps.
5. The spec is the source of truth for fresh repos, but
the migration captures the existing bypass_actors to
preserve the operator's escape hatch.
6. Migrate the operator's preauthorized bypass list
explicitly; don't rely on the spec's defaults.
Three-body: delivery=Mavis, control=DARKXSIDE, memory=this
trail + the spec + the migration script. CHIT trail
unsigned-local.
* refactor(tools): collapse branch_protection to ruleset-only per operator ratification
Per the operator's 2026-08-10 ratification (PR #2490 review id 4893614185) grounded
in GitHub's "About rulesets" docs: classic branch protection is NOT deprecated,
rulesets LAYER with it ("the most restrictive version of the rule applies"),
and "start using rulesets without overriding any of your existing protection rules"
is the intended adoption path. This collapses the original migration script
(N1/N2/N3 delete) + the classic-PUT body builder (P1-A/P1-C/N8 delete) into
the new ownership split:
- .github/workflows/branch-protection-sync.yml owns CLASSIC protection
- pmoves/tools/branch_protection.py owns RULESETS only
- The two writers layer additively (most-restrictive-wins)
- Additive adoption is monotonic - the tool can only make a branch stricter
What changes:
- pmoves/tools/branch_protection.py: dropped _build_classic_body +
_diff_required_status_checks + _diff_review_policy + _diff_boolean_field;
added SpecValidator (validates at load, per P1-B); added resolve_branch()
(per_repo_overrides -> .gitmodules -> spec default -> "main", per N4);
deep-diff _ruleset_matches() (rules + conditions + bypass_actors, per N6);
apply() now creates missing AND updates existing rulesets; _gh_api has
GH_TIMEOUT_SECONDS=30
- pmoves/configs/branch_protection/pmoves_standard.json: upgraded to v2
(pmoves.rulesets/v2); profiles only have rulesets: []; monorepo profile
carries 8 ruleset rules; fork profile has required_approving_review_count=0
(matches workflow default, per N5); per_repo_overrides includes PMOVES.AI +
PMOVES-hermes-agent + PMOVES-pinokio + PMOVES-nats-server (the new fork)
- pmoves/docs/operations/BRANCH_PROTECTION_BASELINE.md: rewritten with the
ownership split documented at the top
- pmoves/tools/LEARNINGS/branch-protection-v0_LEARNINGS.md: 5-class taxonomy
updated (15 already-fixed / 6 owner / 5 out-of-scope / 4 pre-existing);
2 new pair-review lessons (#7 merge-by-type ruleset overrides; #8
~DEFAULT_BRANCH sentinel in conditions.ref_name.include); ratification
documented (5 of 6 P1s collapse to deletions)
Bugs caught and fixed during the refactor:
- spec had require_linear_history typo (correct: required_linear_history)
- VALID_RULESET_RULE_TYPES was missing required_conversation_resolution
- _ruleset_matches() was running the conditions.ref_name.include comparison
after stripping the sentinel (should have skipped it entirely)
- resolve_repo_profile() was REPLACING the rules array in ruleset_overrides
(should have MERGED by type)
CHIT trail unsigned-local. Three-body: delivery=Mavis, control=DARKXSIDE,
memory=this commit + the spec + the LEARNINGS file.
* test(tools): rewrite 55 tests for ruleset-only branch_protection
The 44 old tests targeted the old classic+ruleset tool shape
(_build_classic_body, _diff_required_status_checks, _diff_review_policy,
_diff_boolean_field). Replaced with 55 tests across 9 groups for the
post-ratification ruleset-only API:
A. SpecValidatorTests (13 tests)
- spec shape, rule type validation, target/enforcement validation,
override->profile cross-check, multi-error collection, load_spec
path + skip-validation flag, validator set completeness
(required_conversation_resolution, required_linear_history)
B. ResolveRepoProfileTests (7 tests)
- default + ruleset_override merge, unknown repo/profile raise,
no-input-mutation, MERGE-BY-TYPE semantics (B6, B7)
C. ResolveBranchTests (4 tests)
- override wins, .gitmodules lookup matches workflow logic,
no-override-no-gitmodules -> main, slug extraction for PMOVES.AI
D. RulesetDiffTests (7 tests)
- compliant, missing rule, extra rule, drifted parameters,
drifted bypass_actors, drifted enforcement, ~DEFAULT_BRANCH
sentinel handling (D7)
E. AuditTests (5 tests)
- compliant repo, no rulesets drift, explicit profile, unknown
repo raise, per-ruleset re-fetch for bypass_actors (lesson #1)
F. ApplyTests (7 tests)
- dry-run creates, live creates, update existing with drift,
skip in-sync, per_repo ruleset_overrides, unknown repo raise,
strip ~DEFAULT_BRANCH sentinel
G. DriftCheckTests (3 tests)
- one report per repo, org filter, audit error surface
H. CLITests (4 tests)
- exit 0 compliant, exit 1 drift, exit 2 any-repo drift,
default dry-run
I. GHErrorPathTests (4 tests)
- gh missing, gh timeout, gh nonzero stderr, "Branch not protected"
returns None (404 is expected state)
Two new pair-review lessons (B6/B7 merge-by-type + D7 ~DEFAULT_BRANCH
sentinel) are codified in the LEARNINGS file.
CHIT trail unsigned-local.
* docs(agnote): Mavis::BRANCH-PROTECTION-V0-RATIFICATION-REFACTOR trail row
Records the 2026-08-10 refactor of the branch_protection tool to
ruleset-only per the operator's ratification (PR #2490 review id
4893614185). Captures the 5-of-6 P1s collapse to deletions, the
ownership split (tool = rulesets, workflow = classic), the spec v2
upgrade, the 4 additional bugs caught and fixed during the refactor
(require_linear_history typo, missing rule type, ~DEFAULT_BRANCH
sentinel handling, merge-by-type ruleset overrides), and the 55-test
rewrite.
CHIT trail unsigned-local. Three-body: delivery=Mavis, control=DARKXSIDE,
memory=this trail.
* refactor(tools): actually delete branch_protection_migrate_pmai.py
The 2026-08-10 ratification said the migration script goes away: classic
branch protection is not deprecated, rulesets layer with it, and "the most
restrictive version of the rule applies" — so there is nothing to migrate
away from and no reason to DELETE classic protection before a replacement
exists.
The refactor commit b0fbf68 rewrote branch_protection.py to ruleset-only
but left the script and its 15 tests on disk, while the PR comment reported
them as deleted. Verified against the tree: both files were still tracked at
78157b7. This makes the reported state the real state.
That closes the four findings that only existed because of the script:
N1 DELETE fires before any replacement (with a test asserting it should)
N2 signed commits + linear history silently dropped by the migration
N3 captured_required_status_checks captured, printed, never used
#20 migration test docstrings
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(tools): make the resolved branch load-bearing in the ruleset writer
Five defects, all in the path between "the spec says which branch" and
"the ruleset GitHub actually stores". Verified against the live org, not
just the diff.
1. ~DEFAULT_BRANCH was stripped, never substituted (CRITICAL)
_build_ruleset_body removed the sentinel from conditions.ref_name.include
and put nothing back, so a created ruleset carried an EMPTY include list
and matched no ref. It now takes the resolved branch and writes
refs/heads/<branch>. The old test asserted only assertNotIn(sentinel),
which an empty list satisfies — that is how it shipped.
2. The diff SKIPPED the include comparison whenever the spec used the
sentinel, so a ruleset pinned to the wrong branch reported compliant.
_ruleset_matches now takes the branch and resolves the sentinel on the
EXPECTED side only. A live ~DEFAULT_BRANCH stays unresolved on purpose:
it means "whatever GitHub currently calls default", which is not the
branch we mean.
Live evidence for why both matter: PMOVES-hermes-agent's default branch
is main, but the monorepo consumes PMOVES.AI-Edition-Hardened. The
ruleset applied in Slice 2 targets ~DEFAULT_BRANCH -> main. The branch
that actually ships has no ruleset, and audit called it compliant. It
now reports drift. This is N4 in production, not in theory.
3. .gitmodules lookup used `slug in section`, a substring match. The slug
PMOVES-nats matched submodule "PMOVES-nats-server" and would write that
repo's branch. Now matches the exact section name or the url basename.
4. resolve_branch step 3 looped over EVERY profile and returned the first
branch it found, so one profile declaring a branch would leak it onto
every repo without an override. It now takes the resolved profile name
and reads only that profile.
5. apply crashed on `created.get` when a POST returned an empty body
(_gh_api returns None). The write had already happened, so the repo was
left changed with no entry in `applied`. Now records it with a fallback id.
Also: rule parameters were compared by strict equality, but GitHub echoes
back its own defaults (required_reviewers, allowed_merge_methods) that the
spec never declares — every audit reported permanent drift and every apply
re-PUT a correct ruleset. Comparison is now a subset over spec-declared keys
only, which is what makes drift_check trustworthy enough to run on a cron.
Tests: 64 pass (was 55). New: C5-C7 (exact + url-basename match, profile
scoping), D8-D11 (include drift on a non-default branch, live sentinel not
silently matched, API-defaulted params not drift, declared mismatch still
reported), F7-F9 (substitution, no spec mutation, empty POST body).
Fixed A11, which patched read_text but not exists() and so passed on the
"spec not found" error without ever reaching validation; and I2-I4, which
depended on a real gh binary being on PATH.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(branch-protection): correct the baseline + LEARNINGS against the tree
- NATS catalog link was ../nats-subjects.md, which resolves to
pmoves/docs/nats-subjects.md — a file that does not exist. Repointed at
the canonical .claude/context/nats-subjects.md. (A prior comment marked
this fixed; it was not.)
- require_linear_history -> required_linear_history everywhere. The v2
contract and the GitHub rule type both use the required_ prefix, and an
operator copying the table into pmoves_standard.json would fail validation.
- Lesson count 6 -> 8, and "5 of 6 P1s" -> "6 of 6" (the section lists six:
N1, N2, N3, P1-A, P1-C, N8).
- Rewrote lesson 8. It codified "skip the include check when the spec uses
the sentinel" as the right behavior; that was the bug. Replaced with the
general form: a sentinel a builder strips but never substitutes is a
silent no-op — resolve it, and assert on what replaced it rather than on
its absence.
- Lesson 5 notes that the migration script it was learned on is gone.
- Documented the release gate on --no-dry-run: claim -> work (dry-run,
confirm the resolved branch) -> sign -> release, with post-apply evidence.
If signing is unavailable, the release stays pending.
Two corrections that came out of reading the workflow rather than the diff:
- The doc said the monorepo profile "layers on top of whatever classic
protection branch-protection-sync.yml writes". It does not.
The workflow derives its scope from .gitmodules and PMOVES.AI is not a
submodule of itself, so on the monorepo there is no second writer and
required_approving_review_count: 1 is the only review gate in play. That
also means the N5 layering deadlock cannot apply to this profile — the
fork profile already resolves it at 0.
Flagged for the operator instead: apply --no-dry-run on PMOVES.AI would
newly enforce required_signatures and required_linear_history on main.
Both are real behavior changes to the merge flow, so they are called out
as decisions rather than defaults.
- Added the 2026-08-10 audit finding: the Slice 2 rulesets on
PMOVES-hermes-agent and PMOVES-pinokio target ~DEFAULT_BRANCH, so the
hardened gitlink branch is ungated. Remediation is a re-apply behind the
release gate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(agnote): 4090-CLAUDE::PR2490-TRIM-16-THREADS trail row
Appended as a correction rather than an edit to the preceding row: that
row recorded the migration script as deleted and the ~DEFAULT_BRANCH
include-skip as correct behavior, and both were wrong against the tree.
The historical row stays as written; this one records what was actually
found and what changed.
Also records the two decisions left to the operator (the PMOVES.AI
--no-dry-run, and the re-apply that remediates the wrong-branch rulesets
on the two Slice 2 forks) rather than taking them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(learnings): lesson 9 — a test that can only assert absence cannot say no
Promotes the root cause of lesson 8 to its own entry, at the team lead's
request, because the fix is a habit and the failure mode is silent.
The guard on the sentinel substitution was
`assertNotIn("~DEFAULT_BRANCH", includes)`, which passes on an empty list.
It therefore held green across exactly the two states it existed to
distinguish: sentinel correctly replaced by a real ref, and sentinel
deleted with nothing put back. A test that could only report success,
guarding a ruleset whose empty include list matched no ref while `apply`
printed "applied".
The tell is structural rather than domain-specific, so the lesson is
written to generalize: an assertion whose predicate is satisfied by the
empty/null/absent case is not a gate. assertNotIn, assertNotEqual,
assertFalse, "no error raised", an empty `grep -v`, `rc == 0` on a command
that no-ops when misconfigured — each admits a degenerate state alongside
the intended one. When a transform removes something, assert on what
replaced it.
With three checks in cost order: ask what the empty case does; mutate the
implementation to the degenerate state and confirm the test goes red (a
guard that survives its own sabotage was never a guard); and for tools
that write to an external system, verify against live state once. Here a
single `gh api ... --jq .default_branch` collapsed the whole question.
Lesson count 8 -> 9 in both this file and the baseline doc.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Mavis <Mavis@pmoves.local>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 15, 2026
… Actions workflows + 5 NATS subjects (#2568) * feat(nats+workflows+publisher): Mavis harness v0 follow-ups — drift publisher + drift cron + ruleset auto-enroll Closes the 3 Mavis harness v0 follow-up items from the PR #2477 lock (NATS subject registration, Mavis cron, auto-apply on fork creation). The follow-ups are now in a form that runs end-to-end via GitHub Actions; the orchestrator + the drift publisher share the same `Publisher` Protocol, so the test surface is uniform. What lands: - pmoves/tools/branch_protection_publisher.py (245 lines) — the drift publisher. Wraps branch_protection.drift_check() output and publishes one message per non-compliant repo to pmoves.branch_protection.drift.v1. Follows the same `Publisher` Protocol as orchestrator.Publisher so the test surface is uniform. Three sinks: MockPublisher (in-memory, for tests), FilePublisher (JSONL to file or stdout, the default sink for GitHub Actions), NatsPublisher (lazy-imported; the real pmoves-nats-mcp wire-up when it's live). The `envelope` shape wraps each payload in {envelope, source, published_at, audit} so subscribers can filter by source + order by time. Compliant repos are silent (publishing every audit would flood the subject). CLI: `python -m pmoves.tools.branch_protection_publisher --org POWERFULMOVES --spec <spec> --sink <file|nats> [--out <path>]`. - .github/workflows/branch-protection-drift.yml — daily 06:00 UTC drift cron (matches fork-sync.yml + branch-protection-sync.yml). Runs the publisher, surfaces the summary to the step summary, uploads the per-run JSONL artifact. workflow_dispatch for manual runs with --sink file|nats choice. nats sink defers to the pmoves-nats-mcp slice. - .github/workflows/branch-protection-ruleset-sync.yml — the ruleset-side auto-enroller. Two trigger modes: workflow_dispatch (operator dispatches with --repo or every per_repo_overrides entry; --no-dry-run flips dry-run off) + weekly Sun 04:00 UTC safety net. Mints the GitHub App token with permission-administration: write (the live validation of the App's grant; same pattern as branch-protection-sync.yml). Org-level repository.created is the natural auto-enroll hook for new forks; lands in a follow-up slice when the org App gets repository.created wired. - .claude/context/nats-subjects.md — 5 subjects registered (Mavis Harness v0 Subjects section): pmoves.agent.task.v1 (orchestrator dispatch), pmoves.agent.result.v1 (worker reply), pmoves.bpm.phase.v1 (BPM phase transition), pmoves.bpm.pomodoro.v1 (focus-block boundary), pmoves.branch_protection.drift.v1 (per-repo drift envelope). Each entry includes Direction, Purpose, Payload schema, Subscribers, Status (REGISTERED). Why GitHub Actions and not a mavis cron: the mavis CLI on this node has an installer path bug (resources\resources\daemon\cli.js — duplicated resources\) so the mavis cron path is blocked until that's fixed. The GitHub Actions path is the cross-host alternative and matches the existing PMOVES pattern (fork-sync.yml uses schedule: cron too). The publisher's function signature is identical, so when the mavis runtime is on the same host as NATS, swap the workflow for a mavis cron that calls the same `publish_drift_for_org(org, NatsPublisher())` — no other code changes. Three-body: delivery=Mavis, control=DARKXSIDE, memory=this commit + the publisher + the workflows + the NATS subjects registration + the test surface (in the next commit). CHIT trail unsigned-local. * test(tools): 17 tests for branch_protection_publisher across 5 groups * docs(baseline+learnings+agnote): Mavis harness v0 follow-ups wire-up + 3 new pair-review lessons Closes the docs + LEARNINGS + AGNOTE trail for the Mavis harness v0 follow-ups slice. What lands: - pmoves/docs/operations/BRANCH_PROTECTION_BASELINE.md — wire-up section now lists the 2 new workflows + the publisher module + a 5-row NATS subjects table (producer / consumer / purpose). The "Known gap" note about the Slice 2 wrong-branch rulesets is removed (the post-merge re-applies on 2026-08-15 fixed both forks; the 4090's lesson #8 captured the structural cause + fix). - pmoves/tools/LEARNINGS/branch-protection-v0_LEARNINGS.md — 3 new pair-review lessons (#10-#12) for the drift publisher pattern, the GitHub Actions vs mavis cron decision, and the auto-apply org-level repository.created App event. The 5-class taxonomy gains 5 new pre-existing rows (the 5 NATS subjects, the publisher, the drift cron, the auto-enroll workflow, the Slice 2 wrong-branch fix). Lesson count is now 12 (was 9 in the 4090's last update). - pmoves/docs/AGENTS/AGNOTE4482PHI.t1.md — new Mavis::MAVIS-HARNESS-V0-FOLLOWUPS::2026-08-15 trail row, recording the publisher + 2 workflows + 5 NATS subjects registration + the test surface + the GitHub Actions vs mavis cron rationale (the mavis CLI installer path bug blocks the runtime path; cross-host NATS publish needs the workflow pattern). CHIT trail unsigned-local. Why GitHub Actions vs mavis cron (captured in the AGNOTE row + LEARNINGS #11): the mavis runtime on the operator's node has an installer path bug (duplicated `resources\`) so the cron side is blocked until that's fixed. The GitHub Actions path is the cross-host alternative and matches the existing PMOVES pattern (fork-sync.yml uses schedule: cron too). The publisher's function signature is identical, so the swap is one-line when the runtime is on the same host as NATS. Three-body: delivery=Mavis, control=DARKXSIDE, memory=this commit + the AGNOTE row. CHIT trail unsigned-local.
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 21, 2026
…routing — Mavis inter-agent handoff v0 (#2651) * docs(cgp): formalize pmoves.bootstrap/v1 as an explicit CGP v1.0 variant Added x-cgp-* annotations + x-consumer-contract block to the bootstrap schema: - x-cgp-profile: pmoves.bootstrap/v1 (this is the profile name) - x-cgp-base: link to the canonical CGP v1.0 base schema - x-cgp-spec: link to the CGP v1.0 specification doc - x-cgp-version / x-cgp-bootstrap-version: 1.0.0 - x-consumer-contract.required: - Read bootstrap ONCE at session init (not every turn) - Validate spec is exactly 'pmoves.bootstrap/v1'; refuse otherwise - Apply routing block to populate dispatch table - Honor constraints (a fork that violates is broken, not the producer) - Treat services as advisory (missing services skipped, not failed) - Never replace existing config; this is a manifest, not a config - x-consumer-contract.forbidden: - Never mutate the CGP and write it back - Never rely on services that aren't in the local env - Never bypass CHIT signing / force-push / CI bypass This gives the consumer forks (Hermes, Pinokio) an explicit machine-readable contract they can lint against. Refs: Mavis inter-agent handoff slice commit 1 * feat(bootstrap): add pinokio to routing — CGP v1.0 routing block now has 3 known targets - v1.schema.json routing block: added pinokio with the same shape as kiloclaw/hermes (node + nats_subject + target); additionalProperties:false is preserved so typo'd agent names still fail at schema-level - example.cgp.yaml: added a pinokio entry under routing so the example file is round-trippable - pmoves/tools/load_bootstrap.py: Routing dataclass now carries pinokio; export_env() emits PMOVES_BOOTSTRAP_TARGET_PINOKIO alongside the existing KILOCLAW / HERMES vars This unblocks the Pinokio-fork consumer wire-up (CRUSH handoff). The orchestrator derives KNOWN_TARGETS from the bootstrap's routing block, so the 3rd target appears automatically. Refs: Mavis inter-agent handoff slice commit 2 * feat(orchestrator): KVM control surface + bootstrap-driven KNOWN_TARGETS Three changes that close the consumer-fork wire-up half of PR #2477: (1) **Bootstrap-driven known_targets**: replace the hardcoded KNOWN_TARGETS set with a property that derives the set from self.bootstrap.routing + the implicit 'mavis' self-target. Adding a routing entry to the CGP (kiloclaw / hermes / pinokio / future) automatically widens the dispatch surface; no orchestrator code change needed. (2) **routing_for(target)**: returns the CGP routing entry for a target, or {} if unknown. 'mavis' returns a synthesized self-entry. Used by the KVM surface and any external consumer that needs node/target metadata for a given dispatch. (3) **publish_kvm_focus(task_id, target, node)**: the KVM control surface. dispatch() now publishes a pmoves.bpm.phase.v1 event with phase='kvm-focus', target, and target_node when a task lands on a target whose routing entry names a different node. An external KVM controller (a separate service that subscribes to phase events) can then switch the operator's focus via RustDesk + Tailscale to the named node. Local self-dispatches (mavis / host / self) are no-ops on the KVM channel so Mavis's in-session work doesn't trigger KVM switches. The KVM event is published on the existing pmoves.bpm.phase.v1 subject (with a 'kvm-focus' phase discriminator) so the KVM controller reuses the existing phase-event subscriber. Adding a new subject would have been option 2; reusing the existing one matches the harness's 'tagged-services-are-advisory' discipline. Refs: Mavis inter-agent handoff slice commit 3 * test+learnings(orchestrator): 17 tests + 6-lesson LEARNINGS for the KVM slice 17 tests, all pass: - 3 known_targets tests (full bootstrap / empty bootstrap / peer-with-routing-only) - 4 routing_for tests (mavis self-entry / kiloclaw CGP entry / unknown / copy-not-reference) - 7 KVM tests (kiloclaw publishes / mavis no-op / pinokio no-op / hermes / self no-op / empty no-op / remote node) - 3 regression tests for the existing dispatch envelope + error path LEARNINGS file (6 lessons + 3 follow-ups): - bootstrap-driven known_targets > hardcoded set (Lesson 1) - KVM in orchestrator > new subject (Lesson 2) - routing_for returns a copy, not a reference (Lesson 3) - x-cgp-* annotations make the consumer contract machine-checkable (Lesson 4) - KVM no-op on self/host/empty is the floor, not a special case (Lesson 5) - cross-PR coordination via AGNOTE lane board (Lesson 6) Refs: Mavis inter-agent handoff slice commit 4 * fix(orchestrator): 4 review findings — wire target, KVM subject, TBD, peer list All four were real, and the first two each produce a failure with no error message: the work simply never happens. ## 1. The envelope carried the alias, not the configured target routing.hermes.target is "hermes-3", and the Hermes handoff in AGNOTE4482PHI.t1.md subscribes on exactly that. dispatch() published target="hermes" (the alias), so no consumer ever matched and the handoff would sit pending forever. Now publishes the configured target with the alias alongside it: {"target": "hermes-3", "target_alias": "hermes", ...} Producer-side correlation keeps working; the consumer can finally match. ## 2. KVM focus rode a contracted subject it did not fit .claude/context/nats-subjects.md contracts pmoves.bpm.phase.v1 as the five lifecycle phases define -> assign -> execute -> review -> close, carrying task_name/previous_phase. The focus event published `phase: "kvm-focus"` with a target_node and neither of those fields, so A2UI or observability reading that stream would see an invalid lifecycle transition. Split to pmoves.kvm.focus.v1 and registered in nats-subjects.md. The reasoning is inline at the constant, because the original code deliberately chose to reuse the stream: a discriminator field does not make an incompatible payload compatible, it moves the breakage into the consumer. ## 3. TBD is not a machine example.cgp.yaml ships `hermes.node: TBD` -- "operator hasn't stood Hermes up yet; wire is ready". The guard was `node not in ("self", "host", "")`, so a literal TBD passed and a DEFAULT-config dispatch asked the KVM controller to switch to a node named TBD. _is_actionable_node() now rejects placeholders (tbd/todo/none/n/a/-) as well as the local device, case-insensitively and whitespace-trimmed, because a config is hand-written. ## 4. known_targets contradicted its own docstring It promised that adding a routing entry widens the dispatch surface with no orchestrator change, then enumerated a hard-coded ("kiloclaw", "hermes", "pinokio"). A new peer would have been rejected while appearing configured. Now derived from dataclasses.fields(Routing). ## Tests: 17 passed (was 12 passed / 3 failed) The three failures were the pre-KVM tests asserting a single publish and `target == "kiloclaw"`. Both were the OLD contract, so they were updated to the requirement rather than the implementation -- kiloclaw's node is 5090, a real remote machine, so a focus event there is correct. Five added, each falsified against the specific defect: revert to publishing the alias -> test_wire_target_matches_what_the_consumer_subscribes_to drop the placeholder guard -> test_placeholder_node_does_not_request_kvm_focus put focus back on bpm.phase.v1 -> test_kvm_focus_is_not_on_the_bpm_phase_stream The placeholder test asserts against the DEFAULT config rather than substituting a node, since the shipped config is what takes the placeholder path -- the review's point that substituting `spark` masked it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test+learnings(orchestrator): drop stale test_orchestrator_kvm; expand LEARNINGS to 8 lessons The 4 review findings (operator + Claude Opus 5 in commit 311093c) flipped the contract: - wire target = routing.target (was: alias) - target_alias = the routing key (was: just 'target') - KVM subject = pmoves.kvm.focus.v1 (was: bpm.phase.v1) - actionable node = rejects placeholders (was: literal self/host/'') - known_targets = derived from dataclasses.fields(routing) (was: literal tuple) The fix commit shipped a comprehensive 17-test file at pmoves/tools/tests/test_orchestrator.py that asserts the NEW contract. The old pmoves/tests/test_orchestrator_kvm.py (mine) asserts the OLD contract and is now stale; dropping it. LEARNINGS expanded from 6 to 8 lessons: - Lesson 2 expanded: KVM on its own subject, not a phase discriminator (the 'incompatible payload' principle) - NEW Lesson 4: wire target is routing.target, not the alias (P1 finding: the handoff would have sat pending forever) - NEW Lesson 5: placeholders are not machine names; case-insensitive set lookup (the 'TBD' finding) - NEW Lesson 8: pair-review catches P1 bugs the original author misses (4 of the 8 lessons are review findings, not author-self-finds) Refs: Mavis inter-agent handoff slice post-review cleanup --------- Co-authored-by: Mavis@pmoves.local <Mavis@pmoves.local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
1 task
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.
Mavis harness v0: multi-repo CGP bootstrap (PMOVES.AI side)
The Mavis multi-agent orchestrator + BPM/pomodoro scheduler + CGP bootstrap loader. The PMOVES.AI side of a 3-repo coordinated slice (the other two are POWERFULMOVES/PMOVES-hermes-agent and POWERFULMOVES/PMOVES-pinokio forks; see LEARNINGS for the cross-repo plan).
The CGP (Compressed Geometric Packet) is the contract that ties the 3 forks together: PMOVES.AI writes it, the PMOVES-hermes-agent fork reads it at session init, the PMOVES-pinokio fork reads it when launching a PMOVES-tagged app. Same schema, three implementations, zero breaking changes on the consumer forks.
What this PR ships
pmoves/contracts/schemas/pmoves-bootstrap/v1.schema.json- the CGP contract (JSON Schema Draft 2020-12). Aligned to the canonical CHIT Geometry Packet spec atpmoves/docs/PMOVESCHIT/CGP_v1.0_SPECIFICATION.md- same envelope (spec/meta/sig/super_nodes/...) withpmoves.bootstrap/v1profile andsuper_nodes: []for the empty-geometry case.pmoves/contracts/schemas/pmoves-bootstrap/example.cgp.yaml- real values from memory (minimax/dimensional/5090/Tailscale/RustDesk/Hostinger/Cloudflare). The fork consumer PRs read this to verify their loaders.pmoves/tools/load_bootstrap.py- reads the CGP, validates against the schema, returns a typedBootstrapobject, exportsPMOVES_BOOTSTRAP_*env vars. 4 input sources: path arg, source arg, env var, default example.pmoves/tools/orchestrator.py- multi-agent dispatcher. Publishes tasks topmoves.agent.task.v1, waits for results onpmoves.agent.result.v1, merges outputs. IncludesPublisherprotocol +MockPublisherfor tests.pmoves/tools/bpm_cron.py- BPM/pomodoro engine. 5 phases (define/assign/execute/review/close) with N pomodoro focus blocks (25/5 min by default, env-driven). Publishes phase + pomodoro events to NATS.pmoves/tools/HARNESS.md- the high-level map of the 3 tools + how they fit together + a quick-start code example.Acceptance criteria (5/5 met)
HARNESS.mdso future sessions can find themTests (56/56 pass, no real NATS required)
pmoves/tools/tests/test_load_bootstrap.py- 22 testspmoves/tools/tests/test_orchestrator.py- 12 testspmoves/tools/tests/test_bpm_cron.py- 22 testsCross-fork follow-ups (separate PRs, separate worktrees)
POWERFULMOVES/PMOVES-hermes-agentPRfeat/pmoves-bootstrap-consumer- addsbootstrap_loader.py+tools_bridge.py+ tests that prove: (a) no-CGP session = exact pre-change behavior, (b) with-CGP session = PMOVES tools available alongside Hermes's native tools.POWERFULMOVES/PMOVES-pinokioPRfeat/pmoves-app-launcher- addspmoves_loader.js+pmoves_apps/starter manifests that load the CGP when launching a PMOVES-tagged app (pmoves: trueinpinokio.yml).Both forks follow the same test pair: (a) pre-change behavior unchanged, (b) with-CGP behavior adds PMOVES tools + services. CGP alignment is enforced by reading the same
v1.schema.json(the forks import it as a sub-resource).Constraints baked in (the non-breaking guarantees)
no-override-existing-config- forks MUST NOT replace their own config with the CGPtagged-services-are-advisory- services are hints, not requirementsno-chit-bypass- state-changing actions still go through pmoves-chit-signno-force-push/no-ci-bypass- lane rulespreserve-existing-tools- forks MUST keep their native tool surface intactCLAIM
Mavis::MAVIS-HARNESS-V0-CLAIM::2026-08-08inpmoves/docs/AGENTS/AGNOTE4482PHI.t1.mdTrail entry
graphiti:mavis phase:mavis-harness-v0indocs/AGENT_TRAIL.mdLEARNINGS
pmoves/tools/LEARNINGS/mavis-harness-v0_LEARNINGS.md- 5-class taxonomy + 4-bucket learning signal per pr-trim convention.CHIT trail unsigned-local
No
CHIT_PASSPHRASEloaded in this Mavis session per the standing operator convention.