fix(workspace): stop apps/loopover-ui silently resolving a stale published @loopover/contract

[JSONbored]

The bug

apps/loopover-ui declared "@loopover/contract": "^0.1.0".

While contract sat at 0.1.0 that range matched the workspace copy, npm linked it, and everything was fine. The moment release-please bumped contract into the engine-and-dependents group at 3.17.0, ^0.1.0 stopped matching — and npm did not fail. It quietly resolved the dependency from the registry, installing the published 0.1.0 tarball into apps/loopover-ui/node_modules while every other consumer used 3.17.0:

"apps/loopover-ui/node_modules/@loopover/contract": {
  "version": "0.1.0",
  "resolved": "https://registry.npmjs.org/@loopover/contract/-/contract-0.1.0.tgz"
}

The website would have built against a contract ~17 minor versions stale — same import specifiers, different schemas and types, no error anywhere.

How it surfaced

As an opaque npm ci failure on the release PR (#9780):

npm error `npm ci` can only install packages when your package.json and
package-lock.json are in sync.
npm error Missing: @loopover/contract@0.1.0 from lock file

That reads like a mechanical lockfile problem. Regenerating the lock "fixes" CI while cementing the bug — the regenerated lock is the one containing the registry fallback above. Worth flagging, since the obvious remedy is the wrong one.

The fix

Pin the private apps to "*" — the one range that means "the workspace copy" and cannot drift — and add workspace-dep-ranges:check to test:ci.

Why the check requires "*" for private packages rather than just checking satisfaction: satisfaction alone cannot see the trap. ^0.1.0 against contract@0.1.0 is perfectly valid today and silently wrong the day contract is bumped, so a satisfaction-only rule would have passed on main and only failed inside a release PR — exactly what happened. A private package is never installed from a registry, so a pinned range buys it nothing and can only rot.

That stricter rule immediately caught a second latent instance: @loopover/discovery-index pinning @loopover/engine to ^3.4.0. Satisfied today, primed to break on the next major.

Published packages keep meaningful ranges — real consumers install them from npm — so for those the check verifies satisfaction instead.

Tests

8 cases, including a regression for the real drift, a regression proving the trap is caught before the bump springs it, and an invariant that this repo's own workspace stays clean. tsc, dead-source-files, import-specifiers, no-hand-written-js, db:migrations:immutable all green.

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-29 10:17:58 UTC}

7 files · 1 AI reviewer · 2 blockers · CI failing · unstable

🛑 Suggested Action - Manual Review

Review summary
This PR adds a small, well-tested workspace lint script (check-workspace-dep-ranges.ts) that requires private workspace packages to use "*" for internal dependencies, catching the exact npm registry-fallback bug described (apps/loopover-ui resolving a stale published @​loopover/contract when its ^0.1.0 range stopped matching the workspace copy). The core logic is straightforward and the test suite directly exercises the incident scenario, the private-package trap-before-the-bump case, and the published-package satisfaction path. The fix is correctly targeted at the workspace-linking layer rather than papering over the lockfile symptom, and wires the new check into test:ci.

Nits — 5 non-blocking

• scripts/check-workspace-dep-ranges.ts:60-75 nests three sequential if/continue blocks per dependency entry; a small early-return helper (e.g. `classifyRange`) would flatten this and read more like the single decision table it actually is.
• The external brief flags `*` as a wildcard accepting any published version, but per the script's own logic these are all `private: true` packages resolved from the workspace, never installed from the registry, so the wildcard is intentional and safe here — worth a one-line comment in package.json itself for anyone auditing dependency ranges without this context.
• package-lock.json changes (contract/engine/ui-kit ranges) are mechanical and consistent with the manifest edits; nothing to flag beyond size, which is expected for a lockfile diff.
• Consider having the script also fail if a PUBLISHED package's range doesn't include headroom for the next expected bump, though that's arguably scope creep beyond this incident's fix.
• scripts/check-workspace-dep-ranges.ts:60 — extract the per-dependency classification (private/invalid-range/satisfies) into a small pure helper to reduce nesting and ease future extension (e.g. adding a check for over-wide ranges on published packages).

Why this is blocked

• 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.

CI checks failing

• Workers Builds: loopover-ui — Workers Builds: loopover-ui

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), 13 merged, 361 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 14 PR(s), 361 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is registered but has no active allocation in the current snapshot.
• Public profile languages: not available
• Official Gittensor activity: 14 PR(s), 361 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 3 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.

Decision record

• action: hold · clause: missing_linked_issue
• config: 4afa0cdac6888c23980095800fb34cfdd2e3a164a015efed5f3b17dab61453a0 · pack: oss-anti-slop · ci: passed
• record: 96ca46a8d2a4829d1869d03ae8dd2941d5b50ed38a47f65e610f435b4466ee04 (schema v5, head 25656d8)

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop	before /	after /	—
/	mobile	before / (mobile)	after / (mobile)	—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

Scroll preview

Route	Before (production)	After (this PR's preview)
/	before / (scroll)	after / (scroll)

A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show.

_{🟩 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

[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	Updated (UTC)
❌ Deployment failed View logs	loopover-ui	7c2d1b0	Jul 29 2026, 09:55 AM

[codecov]

Codecov Report

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

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #9797   +/-   ##
=======================================
  Coverage   90.33%   90.33%           
=======================================
  Files         918      918           
  Lines      113936   113936           
  Branches    26975    26975           
=======================================
  Hits       102926   102926           
  Misses       9681     9681           
  Partials     1329     1329           

Flag	Coverage Δ
backend	95.57% <ø> (ø)
engine	67.87% <ø> (ø)

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

[codecov]

Bundle Report

Bundle size has no change ✅