chore: pin the floating git dependencies to their locked commits

[eordano]

Eleven manifest entries ride a default-branch HEAD, with only packages-lock.json standing between a fresh resolve and whatever the upstream branch points at that day: UniTask, unity-gltf, client-sdk-unity-web, Unity3D-NSubstitute, chrome-devtool-protocol-unity, Arch.SystemGroups (+ visualiser), REnum, RichTypesUnity, StylizedGrassShader and SuperScrollView.

This pins each one to the exact commit the lock already resolves — zero content change (every SHA is the hash already in packages-lock.json), verified by the untouched lock hashes. What it buys:

• a lost/regenerated lock can no longer silently float a dependency to an unreviewed upstream HEAD;
• manifest and lock agree, so the manifest alone is now an accurate statement of what ships;
• bumping a dep becomes an explicit, reviewable two-line change (manifest ref + lock hash).

Personal-account repos (mikhail-dcl/Arch.SystemGroups, NickKhalow/REnum, NickKhalow/RichTypesUnity, m3taphysics/Arch.SystemGroups.Visualiser) are the highest-value pins here — nothing about their default branches is under org control.

Deliberately untouched (their lines are rewritten by #9478 or pinned by policy): the unity-explorer-packages compat-branch deps, unity-shared-dependencies, and everything already carrying a #tag/#sha.

🤖 Generated with Claude Code

[github-actions]

Build skipped — no changes detected under Explorer/.

[github-actions]

No C# files changed — lint ratchet skipped.

[github-actions]

Slack notification sent to #explorer-ext-contributions for external review.
To re-send, delete this comment and re-add the ext-contribution label.

[github-actions]

Tests: 24372 passed, 0 failed ✅

[claude]

Claude finished @eordano's task in 3m 40s —— View job

---

Security-focused dependency review

• Read the PR diff against origin/dev
• Verify each new manifest pin equals the lock's pre-existing hash (the "zero content change" claim)
• Confirm no hash field in packages-lock.json was modified
• Enumerate git deps still floating after this PR
• Classify remaining non-SHA refs (branch vs tag) — partially blocked, see note
• Check upstream reachability / provenance of the pinned repos — blocked, see note
• Post assessment

---

Step 1 — Dependency changes identified

No dependency is added, removed, or upgraded by this PR. The diff is 22 lines, all of them the version string of an existing git dependency, in Explorer/Packages/manifest.json (11) and the mirrored version field in Explorer/Packages/packages-lock.json (11).

No new binary or native plugin files, no Assets/** or Plugins/** changes, no .asmdef changes, no editor/build/install scripts. (The pre-computed binary-additions list for this PR is also empty.) No workflow or prompt files changed, so Step W does not apply.

Step 1.5 — "Zero content change" claim: verified

I checked all 11 entries against the hash field already present in packages-lock.json on dev. Every one matches on all three sides (manifest ref ≡ lock version ref ≡ lock hash):

package	pinned SHA	lock hash	match
arch.systemgroups.visualiser	e368e96…81d74	e368e96…81d74	✅
com.arch.systemgroups	bd58275…ee56	bd58275…ee56	✅
com.atteneder.gltfast	b9f9f75…968b9	b9f9f75…968b9	✅
com.cysharp.unitask	73d8625…c23e4	73d8625…c23e4	✅
com.decentraland.renum	d39a0d3…8a220	d39a0d3…8a220	✅
com.nickkhalow.chrome-devtool-protocol-unity	5ea7798…7baa	5ea7798…7baa	✅
com.nickkhalow.richtypes	00cbf10…a358b	00cbf10…a358b	✅
decentraland.grassshader	c35c10a…be574	c35c10a…be574	✅
io.livekit.unity	84a79b4…7cf276	84a79b4…7cf276	✅
net.tnrd.nsubstitute	cdd11bb…6ce08	cdd11bb…6ce08	✅
superscrollview	8e1478e…d1465	8e1478e…d1465	✅

Corroborating checks:

• Filtering the lock diff to "hash" lines returns nothing — not one resolved hash moved. [PR]
• The URL syntax is correct in all 11 cases: the #rev fragment comes after the ?path= query string, which is what UPM requires. This was the one thing a mechanical rewrite could plausibly have broken. [PR]
• No other file in the repo (CI yml, scripts, docs) references these git URLs, so nothing else needs updating alongside. [PR]

Conclusion: the resolved dependency graph is byte-identical to dev. Registry/CVE/license/publisher review is not applicable here — every package's risk profile is unchanged, and the change moves strictly in the safe direction (branch HEAD → immutable commit). [Inference]

Step 2/3 — Findings

Three items for human follow-up. None is a defect in the 22 changed lines.

---

MEDIUM — 1. PR description understates the scope: two unity-explorer-packages entries were pinned (likely conflicts with #9478)

The body says the unity-explorer-packages compat-branch deps are "deliberately untouched." Two of them are in fact pinned by this diff:

• Explorer/Packages/manifest.json:48 — decentraland.grassshader → #c35c10a…
• Explorer/Packages/manifest.json:54 — superscrollview → #8e1478e…

Two consequences. First, a reviewer trusting the description will skip exactly those two lines. Second, if #9478 rewrites the unity-explorer-packages lines as the body states, these two are a guaranteed conflict — worth deciding now which PR owns them.

Six sibling entries from the same repo remain floating: manifest.json:11 (com.dcl.gpui-assets), :12 (filebrowserpro), :20 (gurbu.gpui-pro), :21 (gurbu.gpui-pro.terrain), :25 (avpro.video-ultra), :49 (renderfeatures). The lock shows that one repo currently resolved at four different commits (53f8551…, f79125e…, c35c10a…, 8e1478e…) — direct evidence of the per-entry drift this PR is meant to stop. Pinning 2 of 8 leaves most of that surface intact. [PR]

Either fix the description or pin all eight — a partial pin on a shared repo is the confusing middle ground. Fix this →

---

MEDIUM — 2. SHA pins on personal-account repos stop silent substitution but not availability loss

The four highest-value pins by the body's own reasoning — m3taphysics/Arch.SystemGroups.Visualiser, mikhail-dcl/Arch.SystemGroups, NickKhalow/REnum, NickKhalow/RichTypesUnity — are on accounts outside org control. Two things worth stating plainly:

• A bare-SHA ref has no fallback. A force-push plus GC, a repo rename, or a repo deletion turns these into hard, unrecoverable resolve failures, where a branch ref would have kept building (on different code). That trade is the right one — a loud break beats silent drift — but it is a trade, and the only real mitigation is vendoring. Suggested follow-up: fork these four into the decentraland org, or fold them into unity-explorer-packages, and repoint.
• Pinning freezes the current state whatever that state is; it is not evidence the pinned commit was ever reviewed. If nobody has audited what these four repos contain today, this PR does not supply that — it just stops it from changing. [Inference]

---

MEDIUM / UNKNOWN — 3. com.decentraland.renum.sourcegen may be a 12th floating dep

manifest.json:16 is https://github.com/NickKhalow/REnum.git#sourcegen/1.1.4. The body counts anything with a #ref as already safe, but sourcegen/1.1.4 is a slash-containing name that is legal as either a branch or a tag. If it is a branch, it floats exactly like the eleven this PR fixed — and it is on a personal account, the category the body itself calls highest-value. Its lock hash is 6dbce7af5c48df0c682b26d4f78bdbb605c2bfb9.

I could not resolve this: network egress is blocked in this sandbox (git ls-remote, gh api, and WebFetch were all unavailable), so branch-vs-tag is genuinely UNKNOWN and needs a manual git ls-remote https://github.com/NickKhalow/REnum.git 'refs/heads/sourcegen/*'. For the same reason I could not confirm that the eleven pinned SHAs are currently reachable upstream — CI resolving green is the practical check for that.

Separately: GitHub tags are mutable unless protected, so #3.5.0, #v0.2.3, #4.0.0, #7.5.1.a and #sourcegen/1.1.4 are all weaker than a SHA even in the best case. Reasonable as policy, just not equivalent. [Inference]

---

LOW — com.decentraland.unity-shared-dependencies (manifest.json:19) is still a bare git URL; the body says that is intentional.

Summary

item	version	source	type	scope	risk	confidence
11 refs manifest+lock	unchanged content	git	source	runtime + test	LOW	HIGH
grassshader / superscrollview pinned outside stated scope	—	git (org)	source	runtime	MEDIUM	HIGH
6 floating unity-explorer-packages entries (pre-existing)	branch HEAD	git (org, SSH)	source + binary	runtime	MEDIUM	HIGH
4 SHA pins on personal accounts	pinned	git	source	runtime + test	MEDIUM	MEDIUM
renum.sourcegen#sourcegen/1.1.4	branch or tag	git (personal)	source gen	build-time	MEDIUM	LOW

The diff itself is verified safe and is a net supply-chain improvement: I confirmed line-by-line that it changes no resolved dependency content, and it removes eleven default-branch HEADs from the resolve path. NEEDS_ATTENTION below reflects the three follow-ups — the #9478 overlap on lines 48/54, the unverified sourcegen/1.1.4 ref, and the vendoring question on the personal-account repos — not a problem with the change as written. Worth noting for the merge decision: both CI signals on this PR are currently unusable (lint cancelled, tests produced no results), so there is no green build backing the resolve yet.

DEPENDENCY_REVIEW: NEEDS_ATTENTION
• branch chore/pin-floating-git-deps

[decentraland-bot]

Review — PR #9492: chore: pin the floating git dependencies to their locked commits

STEP 2 — Root-cause check: PASS

The problem: 11 git dependencies in manifest.json ride default-branch HEAD with no commit anchor. If packages-lock.json is lost or regenerated, every one of these resolves to whatever HEAD happens to be at that moment — an unreviewed, potentially breaking change.

This PR fixes the root cause by pinning each to the exact commit SHA already present in the lock file. Bumping a dependency becomes an explicit, reviewable two-line change.

STEP 3 — Design & integration: PASS

This is a configuration-only change — no new systems, state, or lifecycle logic. The approach (appending #<sha> to git URLs) is the standard Unity Package Manager mechanism for commit pinning.

SHA verification — all 11 match:
Every commit SHA appended to the manifest URL was cross-checked against the hash field already present in packages-lock.json. All 11 match exactly — confirming zero content change.

Package	SHA (first 12)	Lock hash match
arch.systemgroups.visualiser	e368e96fa814	✅
com.arch.systemgroups	bd58275fb169	✅
com.atteneder.gltfast	b9f9f75c3a00	✅
com.cysharp.unitask	73d86259ce31	✅
com.decentraland.renum	d39a0d38580a	✅
com.nickkhalow.chrome-devtool-protocol-unity	5ea7798478c6	✅
com.nickkhalow.richtypes	00cbf100acd1	✅
decentraland.grassshader	c35c10aabe0f	✅
io.livekit.unity	84a79b486b17	✅
net.tnrd.nsubstitute	cdd11bb74398	✅
superscrollview	8e1478ec9f8f	✅

Scope of deliberately unpinned deps — verified and correct:

• unity-explorer-packages compat-branch deps (gpui-assets, filebrowserpro, gpui-pro, gpui-pro.terrain, avpro, renderfeatures) — rewritten by #9478 (Unity 6000.5.2 upgrade)
• unity-shared-dependencies — left for separate handling
• 8 deps already carrying #tag or #sha — no action needed

The split between what this PR pins and what #9478 handles is clean. The personal-account repos (mikhail-dcl, NickKhalow, m3taphysics) are the highest-value pins since their default branches are not under org control.

STEP 4 — Member audit: N/A

No code members added or changed.

STEP 5 — Line-level review: No issues

• No bugs, no security vulnerabilities, no performance issues
• No secrets or sensitive data committed
• Format is consistent across all 11 entries
• Lock file changes correctly mirror the manifest changes

Security review

• Supply-chain improvement: Pinning prevents silent dependency drift on lock file regeneration. This is a net positive for supply-chain security.
• Personal-account repos: The highest-risk dependencies (repos owned by individual GitHub accounts outside the org) are now pinned.
• No secrets committed: Only commit SHAs appended to public git URLs.
• No new dependencies added: Zero content change — all SHAs were already resolved in the lock file.

STEP 6 — Complexity: SIMPLE

Config-only change (2 JSON files, +22/−22), no runtime code, no ECS/system/component changes.

STEP 7 — QA: NO

No runtime code changes — only package manifest pinning. Zero content change confirmed by matching lock file hashes.

STEP 8 — Non-blocking warnings: None

Main scene not modified. No other warnings.

Git conventions (ADR-6)

• Title: chore: pin the floating git dependencies to their locked commits ✅
• Branch: chore/pin-floating-git-deps ✅

---

REVIEW_RESULT: PASS ✅
COMPLEXITY: SIMPLE
COMPLEXITY_REASON: Config-only change to package manifest and lock file; no runtime code touched.
QA_REQUIRED: NO

---

Reviewed by Jarvis 🤖 · Requested by unknown via Slack