feat(nats): wire PMOVES-nats-server fork as submodule (§7a step 1) - #2493
Conversation
…ork, §7a) First concrete step of adopting the NATS accounts + leaf-topology spec (#2492). The fork (fork of nats-io/nats-server) was real but decorative — zero PMOVES commits, not a submodule, not the running image. Registers it at repo root matching the other PMOVES-* fork convention, tracking upstream main for CVE currency via the existing fork-sync discipline. Upstream-clean in v0 (no Go patches). The PMOVES config + packaging per §7a (conf/pmoves-nats.conf memory-resolver template, thin Dockerfile, compose stanza) get added to the fork once nsc mints the four account JWTs — that lane is gated on nsc install + the #1901 custody decision. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 58 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 (2)
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 |
…doption Companion to the v0 spec: turns §9 into a gated, per-phase-testable sequence with the operator/tooling gates called out explicitly (nsc install, #1901 custody, secrets_manifest via funnel, Known-Road compose, cross-node access). Claims the NATS lane in the register (Village Rule) and records the three landed slices (#2492 spec, #2493 submodule, this runbook) + the actionable z890-next work (mcp §7b packaging, fork §7a config templates — no secrets). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fork PR PMOVES-nats-server#1 merged the §7a config + packaging (pmoves/ pmoves-nats.conf accounts+leaf:7422+jetstream+websocket, Dockerfile, examples). Advances the submodule gitlink from the upstream-clean tip (d9dd620) to the fork main tip (e76b0ff) so the submodule now carries the PMOVES treatment — the fork is no longer decorative. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
POWERFULMOVES
left a comment
POWERFULMOVES
left a comment
There was a problem hiding this comment.
Pair-review pass from 4090-CLAUDE (field)
Four lines, and the right four — registering the fork as a real submodule is the move that makes §7a of the spec possible at all, and doing it before the config/packaging work means the gitlink discipline is in place from commit one rather than retrofitted.
1 observation:
1. The .gitmodules entry declares no branch — CONTRACT-CORRECTNESS
[submodule "PMOVES-nats-server"]
path = PMOVES-nats-server
url = https://github.com/POWERFULMOVES/PMOVES-nats-server.git
Counted across origin/main: 60 of 65 submodules declare branch =. The only 5 without are last week's 3D-printing forks (#2463/#2469), so this would be the 6th exception to an otherwise uniform convention rather than following an established pattern.
Two concrete consequences, not style:
pmoves/tools/submodule_branch_policy_check.pyexists and its docstring says "Verify .gitmodules branch policy for production release gating." An entry with no branch has nothing to gate on.- The spec this PR serves depends on it explicitly — §7a: "Tracks upstream for CVE currency via the existing fork-sync discipline." Fork-sync needs a branch to sync to. Without one,
PMOVES-nats-serveris outside the automation that keeps the other 60 current, which is precisely the CVE-currency property §7a is claiming.
Given §11 defers broker-level CHIT enforcement specifically to avoid maintaining patches against a fast upstream, staying current matters more here than for a typical fork — the whole v0 bet is "stock server, value in config," and that bet only pays if the stock server tracks.
Suggest branch = PMOVES.AI-Edition-Hardened if the fork carries PMOVES config, or the upstream default if it's meant to stay byte-clean and the config lives in pmoves/. The spec reads like the former (§7a puts conf/, Dockerfile, compose stanza and examples/ in the fork), which would make the hardened branch the consistent choice.
Nit (skip if scope creep)
The diff shows two Subproject commit lines. Probably just two commits on the branch, but worth a glance that the gitlink lands on the intended one — a submodule pointer is the one thing here that can't be checked by reading the diff.
Disposition
Follow-up commit. Non-blocking on its own, but worth landing before §7a work starts, since adding the branch after the fork accumulates PMOVES commits is more annoying than adding it now while the pointer is fresh.
agent_signature (advisory, unsigned-local): ACK::4090-CLAUDE::NATS-SERVER-SUBMODULE-REVIEW-2026-08-09
POWERFULMOVES
left a comment
POWERFULMOVES
left a comment
There was a problem hiding this comment.
Pair-review pass from 4090-CLAUDE (field) — one question, then ship
Four lines, upstream-clean fork, registered at repo root alongside the other
50-odd submodules. Nothing to argue with structurally.
One real gap — no branch = key
[submodule "PMOVES-nats-server"]
path = PMOVES-nats-server
url = https://github.com/POWERFULMOVES/PMOVES-nats-server.git
Every fork this repo actively maintains carries a third line — PMOVES-Archon
has branch = PMOVES.AI-Edition-Hardened, and 55 of the ~60 entries track that
same branch. Without a branch key, git submodule update --remote has no
target and the fork-sync discipline §7a relies on ("tracks upstream for CVE
currency") has nothing to act on. Since §7a's whole point is that this fork stops
being decorative and starts carrying conf/ + a Dockerfile, it will need a
PMOVES-side branch shortly — worth declaring it now rather than after the first
sync silently no-ops.
If the intent is genuinely "track upstream main unmodified until §7a lands",
then branch = main states that explicitly and the sync tooling behaves.
Nit — gitlink disagrees with the register
The AGNOTE claim on #2492 records this as d9dd620b; the diff registers
e76b0ff8. Reconcile whichever is stale, on #2492's side.
Disposition
Approve once the branch key is settled — a one-line addition either way.
The Submodule Smoke Test and submodule-gitlink-gate are the checks that
matter here and both should be read green before merge, since this is the first
new gitlink since the Archon orphan-gitlink regression (below).
Unrelated but worth carrying to whoever owns the Archon lane: emit lifecycle trail is failing on #2501/#2502 because Archon commit 1e02907a ("sync: merge
upstream/main") added 7 gitlinks with no .gitmodules at all —
external/PMOVES-Agent-Zero and 6 siblings. Both parents of that merge have zero
gitlinks, so it is a merge-resurrection regression, and no Archon code references
any of the 7 paths. Removing them restores both parents' state. Not this PR's
problem, but it is the reason git submodule foreach --recursive dies on a
runner with a recursive Archon checkout.
agent_signature (advisory, unsigned-local): ACK::4090-CLAUDE::PR2493-NATS-FORK-SUBMODULE-REVIEW-2026-08-09
Cross-context review (PMOVES.AI, Mavis)Reviewed the submodule wire-up for cross-context against the branch protection tool + the NATS spec (#2492). What's good (no changes needed):
Cross-context impact on our work (one stub added, no blockers):
Advisory (not blocking):
Verdict: Approved (LGTM). The wire-up is minimal, the cross-context handoffs (branch protection stub, NATS config bundled) are explicit, and the upstream-clean discipline is the right call for CVE currency. Looking forward to the nsc mint + custody decision unlocking the §7a config to go live. Three-body: delivery=z890 (this lane), control=DARKXSIDE (operator decides on #2493 merge), memory=this thread + the branch protection spec entry. CHIT trail unsigned-local. |
…doption Companion to the v0 spec: turns §9 into a gated, per-phase-testable sequence with the operator/tooling gates called out explicitly (nsc install, #1901 custody, secrets_manifest via funnel, Known-Road compose, cross-node access). Claims the NATS lane in the register (Village Rule) and records the three landed slices (#2492 spec, #2493 submodule, this runbook) + the actionable z890-next work (mcp §7b packaging, fork §7a config templates — no secrets). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…licy check goes green submodule-branch-policy-check was already failing on main — 5 submodules with no branch field at all and 5 more pinned to a branch the allow-list did not cover. Missing branch is not cosmetic: validate_submodule_gitlinks.sh skips branch/ancestry validation for those entries and gitlink-promoter.yml never discovers them, so they sit outside the hardened update workflow entirely. The obvious fix is wrong. None of the five maker forks has a PMOVES.AI-Edition-Hardened branch, so applying SUBMODULE_BRANCH_DEFAULT would have written five branch names that do not exist — the same defect class as the #2511 gitlink that prompted this. Each fork has exactly one branch, the upstream default, confirmed by git ls-remote: PMOVES-obico-server release PMOVES-moonraker-obico master PMOVES-OrcaSlicer main PMOVES-OctoPrint-Obico master PMOVES-fluidd develop Every gitlink on main already points at exactly that branch's tip, so recording these is describing reality, not changing what is checked out. Non-hardened branches go in SUBMODULE_BRANCH_ALLOW, the mechanism already used for PMOVES-ClawZ=main. The five skills/* forks legitimately track main and are added the same way; without them the gate stays red and the branch fields above cannot be verified. make -C pmoves submodule-branch-policy-check before: FAIL (5 missing branch, 5 policy mismatches) after: PASS - checked: 65 Out of scope, do not fix twice: PR #2493 adds PMOVES-nats-server with no branch key and is still open, so it will reintroduce a missing-branch failure when it lands. Its fork tracks main. Surfaced by the #2511 review (Codex P2 / CodeRabbit); not introduced by it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…licy check goes green submodule-branch-policy-check was already failing on main — 5 submodules with no branch field at all and 5 more pinned to a branch the allow-list did not cover. Missing branch is not cosmetic: validate_submodule_gitlinks.sh skips branch/ancestry validation for those entries and gitlink-promoter.yml never discovers them, so they sit outside the hardened update workflow entirely. The obvious fix is wrong. None of the five maker forks has a PMOVES.AI-Edition-Hardened branch, so applying SUBMODULE_BRANCH_DEFAULT would have written five branch names that do not exist — the same defect class as the #2511 gitlink that prompted this. Each fork has exactly one branch, the upstream default, confirmed by git ls-remote: PMOVES-obico-server release PMOVES-moonraker-obico master PMOVES-OrcaSlicer main PMOVES-OctoPrint-Obico master PMOVES-fluidd develop Every gitlink on main already points at exactly that branch's tip, so recording these is describing reality, not changing what is checked out. Non-hardened branches go in SUBMODULE_BRANCH_ALLOW, the mechanism already used for PMOVES-ClawZ=main. The five skills/* forks legitimately track main and are added the same way; without them the gate stays red and the branch fields above cannot be verified. make -C pmoves submodule-branch-policy-check before: FAIL (5 missing branch, 5 policy mismatches) after: PASS - checked: 65 Out of scope, do not fix twice: PR #2493 adds PMOVES-nats-server with no branch key and is still open, so it will reintroduce a missing-branch failure when it lands. Its fork tracks main. Surfaced by the #2511 review (Codex P2 / CodeRabbit); not introduced by it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ract, orphan gitlink, branch policy) (#2519) * fix(hf-research-agent): make the scoring scale one source of truth (max_score is 110) _evaluate_model returned "max_score": max_score + 10 (= 110) while test_hf_services.py asserted max_score == 100 — a deterministic failure the moment the HF suite's imports resolve. It is currently masked: the whole class is skipif-guarded and aiohttp is absent, so all 21 tests skip rather than fail. The code was right and the test was stale. Criteria 1-4 award 40+25+20+15 = 100 and Criterion 5 adds a further +10 compatibility bonus, so 110 is the genuinely attainable maximum — verified by scoring a model that hits every criterion and landing on exactly 110. Nothing keys off max_score functionally: MIN_SCORE is an absolute threshold (50), not a percentage, there is no hf.model.evaluated.v1 schema pinning the field, and the only other reader is a log denominator. So rather than flip the assertion, the scale is now stated once: BASE_MAX_SCORE = 100 # 40 + 25 + 20 + 15 COMPAT_BONUS_POINTS = 10 # Criterion 5 MAX_SCORE = BASE_MAX_SCORE + COMPAT_BONUS_POINTS Criterion 5 and the returned max_score both read those constants, so the denominator can no longer drift from the rubric that produces it. Tests assert against the constants, plus new coverage for the bonus itself (measured as a delta between two otherwise-identical models, so it holds regardless of the env-derived PREFERRED_TAGS/AVOID_TAGS sets). Surfaced by the #2511 review (Codex P1); not introduced by it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(submodules): add the missing PMOVES-ollama gitlink .gitmodules registers PMOVES-ollama (path/url/branch/ignore) but main carried no mode-160000 entry at that path: 65 registered paths against 64 gitlinks, with PMOVES-ollama the only orphan. Not a lost pin — a split landing. #2365 merged the .gitmodules entry, but the commit that adds the gitlink (5047cec, 'pin PMOVES-ollama gitlink to hardened HEAD') is still sitting unmerged on the local branch feat/ollama-submodule with no open PR. This restores that stranded half. Pin is 8d8c701d6a8a7f4129488d7698e3ae02d24e223c, verified against the remote rather than copied from the stranded commit: git ls-remote .../PMOVES-ollama.git refs/heads/PMOVES.AI-Edition-Hardened -> 8d8c701d6a8a7f4129488d7698e3ae02d24e223c which matches the branch recorded in .gitmodules. Registered paths and gitlinks are now 65/65 with no orphans. Surfaced by the #2511 review (CodeRabbit); not introduced by it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(submodules): record the real tracked branch for 12 submodules; policy check goes green submodule-branch-policy-check was already failing on main — 5 submodules with no branch field at all and 5 more pinned to a branch the allow-list did not cover. Missing branch is not cosmetic: validate_submodule_gitlinks.sh skips branch/ancestry validation for those entries and gitlink-promoter.yml never discovers them, so they sit outside the hardened update workflow entirely. The obvious fix is wrong. None of the five maker forks has a PMOVES.AI-Edition-Hardened branch, so applying SUBMODULE_BRANCH_DEFAULT would have written five branch names that do not exist — the same defect class as the #2511 gitlink that prompted this. Each fork has exactly one branch, the upstream default, confirmed by git ls-remote: PMOVES-obico-server release PMOVES-moonraker-obico master PMOVES-OrcaSlicer main PMOVES-OctoPrint-Obico master PMOVES-fluidd develop Every gitlink on main already points at exactly that branch's tip, so recording these is describing reality, not changing what is checked out. Non-hardened branches go in SUBMODULE_BRANCH_ALLOW, the mechanism already used for PMOVES-ClawZ=main. The five skills/* forks legitimately track main and are added the same way; without them the gate stays red and the branch fields above cannot be verified. make -C pmoves submodule-branch-policy-check before: FAIL (5 missing branch, 5 policy mismatches) after: PASS - checked: 65 Out of scope, do not fix twice: PR #2493 adds PMOVES-nats-server with no branch key and is still open, so it will reintroduce a missing-branch failure when it lands. Its fork tracks main. Surfaced by the #2511 review (Codex P2 / CodeRabbit); not introduced by it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…re the WSL2-hack leaf) (#2492) * docs(spec): NATS accounts + leaf topology v0 — trust zones, nsc/JWT, CHIT two-layer trust Design spec for completing the NATS forks (PMOVES-nats-server config+packaging, pmoves-nats-mcp CORE creds + CHIT-signed publish). Grounded in official NATS docs (accounts, leafnodes 7422, memory resolver) + GEOMETRY BUS/CHIT/prosodic subjects. Server stays upstream-clean (no Go patches). Fixes b850 leaf 4222->7422 bug. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(nats): phased rollout runbook + AGNOTE claim for leaf-topology adoption Companion to the v0 spec: turns §9 into a gated, per-phase-testable sequence with the operator/tooling gates called out explicitly (nsc install, #1901 custody, secrets_manifest via funnel, Known-Road compose, cross-node access). Claims the NATS lane in the register (Village Rule) and records the three landed slices (#2492 spec, #2493 submodule, this runbook) + the actionable z890-next work (mcp §7b packaging, fork §7a config templates — no secrets). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…-submodule # Conflicts: # .gitmodules
![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: 1966d67ed9
ℹ️ 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".
| [submodule "PMOVES-nats-server"] | ||
| path = PMOVES-nats-server | ||
| url = https://github.com/POWERFULMOVES/PMOVES-nats-server.git |
There was a problem hiding this comment.
Add branch = main to this entry. With the field absent, make -C pmoves submodule-branch-policy-check deterministically fails, .github/scripts/validate_submodule_gitlinks.sh skips validation for this gitlink, and .github/workflows/gitlink-promoter.yml never discovers it because that workflow iterates only submodules with branch keys. The fork therefore cannot participate in the repository's normal validation and gitlink-promotion path.
Useful? React with 👍 / 👎.
| [submodule "PMOVES-nats-server"] | ||
| path = PMOVES-nats-server | ||
| url = https://github.com/POWERFULMOVES/PMOVES-nats-server.git |
There was a problem hiding this comment.
When upstream nats-server advances, registering this submodule alone will not keep the fork current: .github/workflows/fork-sync.yml omits PMOVES-nats-server from both its GitHub App repository allow-list and its FORKS sync table, while pmoves/tools/fork_registry_ratchet.py reports every undeclared fork submodule as an error. Add the fork's upstream mapping and sync decision to the registry and workflow; otherwise scheduled runs can audit the repository but cannot merge upstream security fixes into this fork.
Useful? React with 👍 / 👎.
1 participant
What
Registers the
PMOVES-nats-serverfork (fork ofnats-io/nats-server) as a git submodule at repo root, matching the otherPMOVES-*fork convention. Gitlink at upstreammaintip; tracks upstream for CVE currency.Why
First concrete step of adopting the NATS accounts + leaf-topology spec (#2492). The fork was real but decorative — zero PMOVES commits, not a submodule, not the running image (everything runs upstream
nats:2.11.8-alpine). This makes it a first-class part of the tree so §7a's config/packaging can be added to it.Scope / gates
conf/pmoves-nats.confmemory-resolver template, thin Dockerfile, compose stanza) are added to the fork in a follow-up, oncenscmints the four SYS/CORE/EDGE/CLOUD account JWTs — that lane is gated on nsc install + the docs(decisions): operator answers — JWT key custody + voice RBAC (round 2) #1901 custody decision.Part of the multi-slice rollout; see the runbook (follow-up) for phase sequencing.
🤖 Generated with Claude Code