feat(engine): add operator-declared network-egress allowlist to AmsPolicySpec

[JSONbored]

Summary

Config-surface half of #7857 (network-egress enforcement for AMS sandboxed execution). Extends .loopover-ams.yml/AmsPolicySpec with a networkAllowlist field (ecosystems: string[], extraHosts: string[]) so an operator can declare additional network-egress allowances for their own AMS attempts, on top of the always-on OS-registry/git-remote defaults #7648 ratified.

Deliberately operator-local only, matching this file's existing scope (never fetched from a target repo). This closes a real trust-boundary gap found while investigating #7857: deriving allowlist contents from the target repo's own manifest would let a malicious repo fabricate a manifest entry to smuggle an attacker-controlled host into its own attempt's allowlist — exactly the class of "repo loosens its own constraints" hole ams-policy-spec.ts's own header already guards every other field against.

Config surface only — no OS-level enforcement yet. No mechanism exists today to actually enforce network egress for AMS sandboxed execution (the coding-agent subprocess shares a network namespace with the whole miner container, no per-attempt isolation). That mechanism is a separate, still-open architecture decision, deliberately deferred and documented on #7857 rather than folded into this PR — landing the trust-boundary-safe declaration surface now means that question doesn't need to be reopened once enforcement is designed later.

Test plan

• npm run typecheck clean (repo-wide)
• New unit tests: test/unit/ams-policy-spec-parser.test.ts — 100% statement/branch/function/line coverage on ams-policy-spec.ts (scoped coverage run)
• Regression tests proving mutation of a resolved spec's allowlist arrays never leaks into the shared DEFAULT_AMS_POLICY_SPEC singleton, including the specific pass-through path where networkAllowlist itself is unset but a sibling field is configured
• npm run build --workspace @loopover/engine clean
• npm run test --workspace @loopover/engine — 660/660 passing (includes a mirrored smoke test for the new field)
• npm run engine-parity:drift-check clean

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	loopover-ui	3066d3a	Commit Preview URL Branch Preview URL	Jul 23 2026, 12:03 PM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.08%. Comparing base (ec3d5e2) to head (3066d3a).
⚠️ Report is 4 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8204      +/-   ##
==========================================
- Coverage   92.09%   92.08%   -0.01%     
==========================================
  Files         773      773              
  Lines       78149    78182      +33     
  Branches    23618    23626       +8     
==========================================
+ Hits        71968    71997      +29     
  Misses       5062     5062              
- Partials     1119     1123       +4     

Flag	Coverage Δ
shard-1	57.57% <12.12%> (-0.03%)	⬇️
shard-2	51.64% <12.12%> (-0.07%)	⬇️
shard-3	52.92% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/loopover-engine/src/ams-policy-spec.ts	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-23 12:19:03 UTC}

4 files · 1 AI reviewer · 2 blockers · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This PR adds a `networkAllowlist` field (curated ecosystems + validated hostnames) to `AmsPolicySpec`, fully following the file's existing tolerant-parse/drop-invalid-entries/deep-clone conventions. The implementation is correct: caps are applied before iteration (bounding warning counts), hostname regex correctly rejects malformed entries, `hasConfiguredPolicyFields` and mutation-isolation from the shared singleton are both handled and tested (including the partial-object and sibling-field edge cases). This is explicitly a config-surface-only change (no enforcement), consistent with its stated scope and the deferred #7857 mechanism design.

Nits — 5 non-blocking

• packages/loopover-engine/src/ams-policy-spec.ts: `AMS_NETWORK_ALLOWLIST_ECOSYSTEMS` is a fixed array literal — adding a new ecosystem later requires touching this file directly, which is fine, but consider a comment pointing to where Decide default network-egress policy for AMS sandboxed execution (deny/allowlist, not open) #7648's category list is authoritatively tracked if that list can grow.
• packages/loopover-engine/src/ams-policy-spec.ts: the external brief flags issue numbers (7857/7648) as 'magic numbers' — these are just doc-comment issue references, not logic constants, so no action needed.
• packages/loopover-engine/src/index.ts is now ~560 lines per the external size-smell report; this PR only adds 3 lines to it (a re-export), so the growth predates this diff and isn't this PR's concern.
• Consider hoisting the repeated `{ ecosystems: [...fallback.ecosystems], extraHosts: [...fallback.extraHosts] }` fallback-clone expression in `normalizeNetworkAllowlist` (ams-policy-spec.ts) into a small local to avoid repeating it three times in one function.
• No functional changes needed; this is a clean, well-tested, appropriately-scoped addition.

Concerns raised — review before merging

• No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked issue. — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked issue. — Link the relevant issue (for example `Closes #123`) before opening the PR.

Decision drivers

• ❌ Code review — 2 blockers (1 reviewer)
• ❌ Gate result — Blocking (Repo-configured hard blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 14 registered-repo PR(s), 14 merged, 242 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 14 PR(s), 242 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 14 PR(s), 242 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Then work through the remaining 2 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review