chore(main): release engine-and-dependents libraries - #9780
Conversation
|
Caution 🛑 LoopOver review result - fixes requiredReview updated: 2026-07-29 15:55:20 UTC
Review summary Nits — 4 non-blocking
Why this is blocked
📋 Copy for AI agents — paste into your coding agentCI checks failing
Decision drivers
Context & advisory signals — never blocks the verdict
Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk 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.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Decision record
🟩 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.
|
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
❌ 1 Tests Failed:
View the top 1 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
9fb4376 to
054a865
Compare
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| 🔵 In progress View logs |
loopover-ui | 69c5823 | Jul 29 2026, 01:23 PM |
9edbfbf to
1017e59
Compare
7b84172 to
f6736c7
Compare
…ished contract (#9797) apps/loopover-ui declared "@loopover/contract": "^0.1.0". While contract sat at 0.1.0 that matched the workspace copy and npm linked it. The moment release-please bumped contract into the engine-and-dependents group at 3.17.0, the range stopped matching -- and npm did NOT fail. It 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. The website would have built against a contract ~17 minor versions stale: same import specifiers, different schemas and types, no error anywhere. It surfaced only as an `npm ci` lockfile-sync failure on the release PR (#9780), which reads like a mechanical lockfile problem rather than the dependency bug it is. Pin the private apps to "*" -- the one range that means "the workspace copy" and cannot drift -- and add workspace-dep-ranges:check. The check requires "*" for PRIVATE packages rather than merely checking that a range is satisfied, because satisfaction alone cannot see the trap: `^0.1.0` against contract@0.1.0 is valid today and silently wrong the day contract is bumped. That rule caught a second latent instance, discovery-index pinning engine to ^3.4.0. Published packages keep real ranges (npm consumers need them) and are checked for satisfaction instead.
42959e5 to
79d8277
Compare
Bundle ReportBundle size has no change ✅ |
d30799e to
69c5823
Compare
dbb3c33 to
ac4ed90
Compare
46106d0 to
7479575
Compare
🤖 I have created a release beep boop
contract: 3.17.0
3.17.0 (2026-07-29)
Features
Fixes
engine: 3.17.0
3.17.0 (2026-07-29)
Features
Fixes
mcp: 3.17.0
3.17.0 (2026-07-29)
Features
Fixes
Dependencies
miner: 3.17.0
3.17.0 (2026-07-29)
Features
claim reclaimCLI to expire orphaned soft-claims (#9717) (edf0883), closes #9686Fixes
deny-hookssubcommand (#8933) (1eeaae1), closes #8851runwithloopin fleet-mode manifests (#9524) (6bb8588)Dependencies
This PR was generated with Release Please. See documentation.