perf(cli): resolve the dependency graph once per command

[Kamirus]

A single command resolves the dependency graph at several points — local cache sync, lockfile write, requirements check, mops sources — and each one re-walked the whole graph from scratch, re-reading mops.toml and mops.lock every time. On a cold or stale-lock walk that also means re-downloading packages purely to read their manifests.

The walk is now memoized in-process.

Why the key is content, not paths

Commands rewrite their own inputs mid-run: checkIntegrity writes mops.lock, and add/remove/update write mops.toml. A path-keyed memo would happily serve the pre-write graph afterwards. So the key is the content of both files, plus the root dir, the conflict policy and MOPS_ENV.

Local path dependencies are the interesting case: they are live directories, and their manifests are in neither file. Every manifest the walk reads is therefore recorded and re-hashed on a hit — including ones that did not exist, recorded as "" before the existence check, so creating a manifest where there was none also invalidates.

Registry package manifests are deliberately outside the key. Published versions are immutable, so their content cannot change under us — the same assumption the lockfile's graph carry-over already depends on.

How the invalidation was actually verified

A stale memo hit means a silently wrong dependency graph, which would be far worse than the redundant work it removes. So the tests don't assert on timing or call counts — they use a canary: a cached registry package's manifest is outside the key by design, so arming it to declare an extra dependency is invisible to a memo hit and shows up in deps only if a walk genuinely reran. "canary" in deps is a direct hit/miss probe.

Every case below was then mutation-tested — the relevant line was deliberately broken to confirm the test fails, so nothing passes vacuously:

invalidates on	proof
root mops.toml edited	canary appears after appending a dep
mops.lock written mid-command	canary appears after writing even an unusable {} lock
local dep manifest edited, at depth	edited a manifest two levels down, reached only through another local dep
manifest created where none existed	canary appears; moving the record inside the existence check fails this test only
MOPS_ENV changed	./local-dep → ./staging-dep
conflict policy changed	canary appears after setConflictPolicy("ignore")
the walk threw	corrupt a nested manifest, then restore it so the successful key matches exactly — a retained rejection would be handed straight back

Two properties are structural rather than tested: when the lock short-circuits, the result is a pure function of mops.lock, which the key hashes, so an empty localInputs is correct rather than a gap. And checkLockFileLight() — hence the key — already depends on local manifests through localDepsHash, giving local edits a second, independent invalidation path.

One bounded caveat: while a walk is in flight, a concurrent caller shares the promise without re-checking local manifests. Nothing in the CLI resolves concurrently today, so it is unreachable, but it is the one place an edit landing mid-walk would be missed. Worth knowing before anyone parallelises resolution.

Cleanup, since this file was open anyway

The ~85-line cross-major conflict report moved out of the walk into its own function, which leaves the walk doing one thing. It moved character-for-character — every message string, the dependent ordering, the de-duplication and the --conflicts error exit — and resolve.test.ts passes unchanged, including its committed stdout/stderr snapshot.

copyResult now deep-copies graph's inner edge maps. It was shallow, so a caller mutating graph[pkgId][dep] would have written into the memo. No current caller does; the copy is cheap and closes the class.

reportedConflicts survives with a corrected comment. It no longer guards against repeated identical resolves — the memo does that now — but against the narrower case where inputs legitimately change mid-command. Leaving its old comment, which described the 3–5 passes this PR eliminates, would have actively misled the next reader. Whether conflict-reporting semantics should change at all is item 3, deliberately untouched here.

Verification

resolve, cache-resilience, local-path-lock, local-dep-manifest-lock and the new resolve-memo suites: 36/36, snapshot matched. Broader sweep across locked, path-dep-cycle, requirements, legacy-lock-flag, sync-plan, remove, remove-dry-run and outdated also passes.

github-dep-lock.test.ts fails locally with socket hang up fetching github.com/.../archive/<sha>.zip. That is the outage tracked as item 39 — github.com redirects to codeload.github.com, and today the redirect host is failing while codeload returns 200. This PR never touches GitHub archives.

Item 6 in #723.

🤖 Generated with Claude Code

[github-actions]

Cursor AI review

👍 APPROVE — looks safe to merge

Category	Assessment	Details
Summary	✅	In-process memoization of resolveDepsAndGraph keyed on mops.toml/mops.lock content, usesLock, conflict policy, MOPS_ENV, and re-checked local path manifests; conflict reporting extracted without semantic change.
Code Quality	✅	Reuses @noble/hashes like integrity.ts; extracts reportCrossMajorConflicts without new speculative API surface; copyResult deep-copies graph edges to protect the memo.
Consistency	✅	Matches existing module-level CLI state (conflictPolicy, reportedConflicts); changelog under ## Next / Performance; no command/flag/mops.toml schema change requiring docs or skills updates.
Security	✅	Traced install-all → syncLocalCache → checkIntegrity/computeLockFile({skipLock:true}) and checkLockFileLight/getLocalDepsHash dual invalidation; failed walks clear resolveCache; registry immutability assumption matches lock graph carry-over.
Tests	✅	resolve-memo.test.ts canary probes hit/miss for toml/lock/local/create/MOPS_ENV/policy/throw/copy isolation; no snapshot regenerations in this PR; conflict extract leaves prior resolve snapshot behavior intact.
Maintainability	✅	Cache key/invalidation rationale and concurrent in-flight caveat documented at the memo; conflict reporter comment updated for the narrower mid-command case.

Verdict

Decision: APPROVE
Risk: Low
Reason: High-risk path (cli/resolve-packages.ts) but invalidation is content-keyed with local-manifest rechecks, covered by canary tests, and install/lock call sites share walks only when usesLock semantics match. No correctness defects found versus Base.

---

Generated for commit 65b0439

[automation-sa-sre]

Automated approval: the AI review verdict for 65b0439 is APPROVE. See the "Cursor AI review" comment for details.