fix(pnpm): keep dependency topology root-local

CHANGELOG.md

@@ -42,6 +42,36 @@ All notable changes to this project will be documented in this file.
   Effect 4 instance through a peer dependency instead of bundling a private
   Effect runtime, preventing cross-major schema AST crashes in LiveStore
   Devtools.
+- **pnpm / dependency identity**: make pnpm the explicit authority for
+  live package dependency edges. Dependency projection and repair may no
+  longer invent nested links by scanning the store or choosing a target by
+  package name; declared compatibility extensions continue through generated
+  `packageExtensions`. Live virtual topology now lives exclusively under each
+  Materialization Root's `node_modules/.pnpm`. Repair discards one root-local
+  graph and reinvokes its
+  canonical pnpm install, eliminating shared graph registries and coordinated
+  multi-root repair. The complete disposable pnpm Store Cache may be shared
+  inside one same-user trust boundary, but it never owns dependency edges.
+  Prepared workspace normalization now relinks injected
+  packages only through pnpm's exact locator mapping. Record the mixed Effect 3
+  / Effect 4 counterexample and
+  add coverage for root-local graph authority and the supported extension path.
+  Replace the flat dependency-materialization glossary with a federated
+  ontology that separates root-owned state, profile identity, graph authority,
+  projections, and storage policy. Remove the unused live profile artifact and
+  storage presets; Nix prepared-dependency and Buck2 evidence retain the existing
+  `profileKey` compatibility boundary. Remove the GVS-only
+  `enableGlobalVirtualStore` and `gvsTypeExtensions` generator APIs.
+- **pnpm / cross-worktree cache reuse**: share pnpm's complete disposable Store
+  Cache (content-addressed files plus its derived index) across mutually trusted
+  local worktrees while keeping GVS disabled and every dependency graph under
+  its own root. Let pnpm's native `auto` import policy select clone, hardlink, or
+  copy, fail closed on Linux when the cache cannot provide same-device zero-copy
+  reuse, keep CI caches job-local, and leave Nix prepared dependencies on their
+  independent content-addressed path. Root repair never prunes the host cache;
+  focused two-root tests prove zero-download reuse, distinct virtual stores,
+  offline rematerialization, native-package isolation, and the explicit
+  same-user hardlink trust boundary.
 - **devenv cli-guard ownership**: drop the remaining self-consumer
   `lib.lowPrio effectTsgo` / `lib.lowPrio pnpmPkg` boilerplate. Passing
   `tsBinPkg` / `pnpmPkg` to the task modules is sufficient because the guards

context/dependency-materialization/.decisions/0001-effect-utils-owns-dependency-materialization-vrs.md

@@ -1,17 +1,15 @@
 # 0001: effect-utils owns dependency materialization VRS
 
-## Decision
+Status: accepted
 
-effect-utils owns the reusable dependency materialization VRS hierarchy. The
-canonical docs live under `context/dependency-materialization/` and cover live
-pnpm materialization, projection, Nix prepared dependencies, store authority,
-Buck2 evidence, and producer observability.
+## Context
 
-dotfiles keeps fleet orchestration, local runner policy, and repo-alignment
-guidance. It does not keep parallel VRS roots for reusable pnpm/Nix dependency
-contracts.
+Reusable pnpm/Nix dependency tooling lives in effect-utils while its largest
+fleet consumer and earlier research lived in dotfiles. Without one intent owner,
+the same materialization behavior accumulated competing terminology, profiles,
+and repair policies in both repositories.
 
-## Rationale
+## Evidence and Argument
 
 The implementation and reusable public API live in effect-utils. Keeping the
 VRS in dotfiles would make private orchestration policy the source of truth for
@@ -22,6 +20,25 @@ The hierarchy also matches the system shape better than two flat documents:
 one root contract defines identity and authority vocabulary, while child VRS
 nodes refine each realization.
 
+## Options
+
+| Option                                | Tradeoffs                                                                                                |
+| ------------------------------------- | -------------------------------------------------------------------------------------------------------- |
+| effect-utils owns reusable DMP intent | Co-locates contract and implementation; downstream fleet docs must reference rather than restate it.     |
+| dotfiles owns DMP intent              | Keeps the original research location but makes private orchestration authoritative for reusable tooling. |
+| duplicate synchronized VRS roots      | Local convenience at the cost of inevitable drift and ambiguous authority.                               |
+
+## Decision
+
+effect-utils owns the reusable dependency materialization VRS hierarchy. The
+canonical docs live under `context/dependency-materialization/` and cover live
+pnpm materialization, projection, Nix prepared dependencies, store authority,
+Buck2 evidence, and producer observability.
+
+dotfiles keeps fleet orchestration, local runner policy, and repo-alignment
+guidance. It does not keep parallel VRS roots for reusable pnpm/Nix dependency
+contracts.
+
 ## Consequences
 
 - effect-utils specs must stay current with implementation changes to pnpm

context/dependency-materialization/.decisions/0002-effect-utils-owned-bin-projection.md

@@ -1,6 +1,6 @@
 # 0002: effect-utils-owned bin projection
 
-Status: Accepted
+Status: accepted
 
 ## Context
 
@@ -10,6 +10,23 @@ exclude `.bin` entirely. The projection layer needs pnpm-compatible executable
 links without making pnpm lifecycle execution or install-time side effects part
 of the trust boundary.
 
+## Evidence and Argument
+
+- Strict lifecycle-disabled installs can leave missing executable projections.
+- Prepared dependency artifacts deliberately exclude `.bin`, so projection must
+  be recreated rather than archived as dependency data.
+- pnpm's published linker remains useful as a compatibility oracle, but making
+  it runtime authority would couple the stable DMP surface to pnpm internals and
+  Node engine constraints.
+
+## Options
+
+| Option                           | Tradeoffs                                                                       |
+| -------------------------------- | ------------------------------------------------------------------------------- |
+| effect-utils pure projector      | Stable lifecycle-free authority with explicit compatibility responsibility.     |
+| pnpm linker as runtime authority | Maximum upstream behavior reuse but imports unstable internal/runtime coupling. |
+| lifecycle-generated bins         | Delegates behavior but violates the purity boundary.                            |
+
 ## Decision
 
 Effect-utils owns the production bin projector.
@@ -22,17 +39,6 @@ emits projection reports.
 pnpm's published bin-linking packages are used as conformance oracles in tests,
 not as the runtime authority.
 
-## Rationale
-
-- pnpm's current linker package is small but pulls in pnpm internals, logging,
-  manifest readers, workspace readers, command-shim code, and Node engine
-  constraints.
-- The effect-utils boundary needs a stable projection contract independent of
-  pnpm's install implementation details.
-- pnpm behavior still matters for compatibility. The conformance fixture keeps
-  scoped command names, `directories.bin`, path-safety checks, conflict
-  behavior, and missing-target handling visible.
-
 ## Consequences
 
 - The implementation must cover pnpm-compatible bin edge cases intentionally

context/dependency-materialization/.decisions/0003-native-policy-pure-package-artifact.md

@@ -1,6 +1,6 @@
 # 0003 Native Policy Uses Pure Package Artifact
 
-Status: **Accepted**
+Status: accepted
 
 ## Context
 
@@ -9,6 +9,22 @@ may remain dependency data without lifecycle execution. The implementation used
 `fod-accepted-prebuilt`, which tied the public classification to one current
 realization: Nix fixed-output prepared dependencies.
 
+## Evidence and Argument
+
+- The public DMP contract spans live pnpm, Nix, CI, and future Buck2 evidence;
+  `fod-accepted-prebuilt` incorrectly named one current realization.
+- Current accepted prebuilts are still locked and scanned by prepared-deps
+  policy, so the broader name does not weaken the purity gate.
+- The term aligns with DMP-R04 and DMP.NIX.NATIVE-R03.
+
+## Options
+
+| Option                       | Tradeoffs                                                                          |
+| ---------------------------- | ---------------------------------------------------------------------------------- |
+| `pure-package-artifact`      | Names the cross-realization property; requires specs to state each concrete proof. |
+| `fod-accepted-prebuilt`      | Mechanically precise today but leaks Nix FOD realization into the public ontology. |
+| one generic native exception | Simpler vocabulary but erases the purity/build distinction.                        |
+
 ## Decision
 
 Use `pure-package-artifact` as the canonical native dependency policy tag.
@@ -21,15 +37,6 @@ Native package families are classified as:
 | `pure-package-artifact`  | Package contents are accepted as data without lifecycle execution. |
 | `denied-lifecycle-build` | Package requires scripts/builds and is rejected until integrated.  |
 
-## Rationale
-
-- The DMP contract spans live pnpm, Nix prepared deps, CI jobs, and Buck2
-  evidence. A public tag should describe the dependency-materialization
-  boundary, not only the fixed-output derivation mechanism.
-- Current accepted prebuilts are still locked and scanned by prepared-deps
-  policy; that mechanism belongs in the owning spec and implementation details.
-- The term matches DMP-R04 and DMP.NIX.NATIVE-R03.
-
 ## Consequences
 
 - Audit output now asks new gated native package families to be classified as

context/dependency-materialization/.decisions/0004-strict-prepared-scan-v18.md

@@ -1,6 +1,6 @@
 # 0004 Strict Prepared Scan Uses One Version Bump
 
-Status: **Accepted**
+Status: accepted
 
 ## Context
 
@@ -10,6 +10,23 @@ outputs, and unclassified platform package directories should fail the prepared
 artifact scan. Removing `.bin` changes recursive output hashes, so the
 transition necessarily creates fixed-output hash churn.
 
+## Evidence and Argument
+
+- Prepared artifacts are dependency data; archived `.bin`, package-manager
+  state, and unclassified native output violate that boundary.
+- Removing `.bin` necessarily changes recursive fixed-output hashes, making the
+  transition versioned regardless of rollout shape.
+- Projection and native output already have separate owners, so a parallel
+  lenient policy would preserve ambiguity rather than compatibility.
+
+## Options
+
+| Option                          | Tradeoffs                                                                   |
+| ------------------------------- | --------------------------------------------------------------------------- |
+| one strict v18 boundary         | Converges immediately with mechanical hash churn.                           |
+| report-only transition          | Reduces initial disruption but permits known-impure artifacts indefinitely. |
+| parallel strict/legacy profiles | Supports gradual adoption but doubles policy and hash authority.            |
+
 ## Decision
 
 Use one convergent prepared artifact version bump for the strict scan
@@ -26,15 +43,6 @@ The next strict prepared-deps purity transition:
 Do not introduce a report-only phase, and do not keep old and new scan policies
 active behind profile gates once `v18` lands.
 
-## Rationale
-
-- Prepared dependency artifacts are data artifacts. Carrying a lenient legacy
-  scan beside the strict scan would keep the most important ambiguity alive.
-- The hash churn is real but mechanical. It is better handled as an explicit
-  versioned boundary than as piecemeal report-only drift.
-- Projection and native output ownership are already modeled separately, so the
-  strict scan is the clearest convergence point for the Nix-prepared realization.
-
 ## Consequences
 
 - The implementation milestone that lands strict scan enforcement must also

context/dependency-materialization/.decisions/0005-fod-repair-targets-are-eval-metadata.md

@@ -1,6 +1,6 @@
 # 0005 FOD Repair Targets Are Eval Metadata
 
-Status: **Accepted**
+Status: accepted
 
 ## Context
 
@@ -9,6 +9,22 @@ evidence. A committed per-target witness file would make evidence visible in
 source, but it would duplicate package Nix metadata, the declared hash, the
 install root, and the profile identity already available through evaluation.
 
+## Evidence and Argument
+
+- Nix evaluation already exposes the asserted hash, derivation, install root,
+  profile identity, and freshness inputs at the owning boundary.
+- A checked-in witness would duplicate those fields and introduce another stale
+  authority.
+- Cross-system measurement is run evidence unavailable at pure evaluation time.
+
+## Options
+
+| Option                                      | Tradeoffs                                                               |
+| ------------------------------------------- | ----------------------------------------------------------------------- |
+| evaluated repair metadata plus run evidence | One committed authority with operational measurement kept truthful.     |
+| per-target witness files                    | Easy source review but duplicates Nix metadata and drifts.              |
+| source parsing only                         | Avoids a producer contract but is brittle and loses evaluated identity. |
+
 ## Decision
 
 Expose FOD hash repair targets as evaluated package metadata, and keep measured
@@ -23,17 +39,6 @@ record measured outputs as generated run evidence.
 Do not add checked-in JSON, YAML, or Markdown witness files per prepared
 dependency target.
 
-## Rationale
-
-- Nix fixed-output derivations already place the asserted hash at the
-  derivation boundary; a parallel source file is another stale authority.
-- Evaluated metadata can include the profile key, install root, declared hash,
-  derivation path, freshness inputs, and update path without asking package
-  authors to maintain another artifact.
-- Cross-system measurement is an operation, not a static fact available at
-  evaluation time. Keeping it in run evidence prevents accidental shared-hash
-  collapse while avoiding source churn.
-
 ## Consequences
 
 - Repair tools should discover prepared-deps targets through evaluated package

context/dependency-materialization/.decisions/0006-pure-reuse-with-root-local-graph-authority.md

@@ -0,0 +1,85 @@
+# 0006 Pure Reuse With Root-Local Graph Authority
+
+Status: accepted
+
+## Context
+
+Local development must reuse dependency bytes across many worktrees without
+turning shared storage into dependency identity, lifecycle, or repair authority.
+pnpm can share either its Store Cache alone or also its Global Virtual Store.
+The latter may reuse more topology state but expands the writable/failure scope
+across otherwise independent roots.
+
+## Evidence and Argument
+
+- The [mixed Effect-generation experiment](../01-live-pnpm/.experiments/2026-07-17-shared-gvs-identity-and-repair.md)
+  proved that native shared GVS preserved correct Effect and peer-context
+  identities in both install orders. It also proved that `pnpm install --force`
+  did not repair a missing shared GVS edge; repair required discarding shared
+  `links/` state.
+- The committed [default-gate evidence](../07-verification/evidence/storage-sharing-default-v2.json)
+  proves material package-byte and file-count reuse across real Linux/ext4 and
+  Darwin/APFS workloads.
+- The two-root shared-cache fixture proves zero second-root downloads, offline
+  rematerialization, concurrent cold/offline roots, distinct native-package
+  inodes, and distinct virtual stores.
+- Nix prepared dependencies already demonstrate the stronger reusable-unit
+  shape: declared inputs produce immutable, integrity-addressed output without
+  lifecycle mutation or ambient live-store authority.
+
+The missing evidence is a same-workload comparison of root-local topology with
+shared and identity-partitioned GVS. Current pnpm GVS options also fail the
+strict reuse boundary because consumers share mutable topology and repair
+state. Therefore this decision records the current pnpm compatibility baseline; it
+does not present root-local rematerialization as the long-term ideal.
+
+## Options
+
+| Option                                                                | Tradeoffs                                                                                                                                                                                                   |
+| --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| A. Shared Store Cache with root-local virtual topology                | Maximizes proven package-data reuse while keeping graph mutation and repair independently bounded; repeats some topology materialization.                                                                   |
+| B. Shared Store Cache with one shared GVS                             | May reuse more topology work, but shares writable graph realization and expands one-root repair/fault scope.                                                                                                |
+| C. Shared Store Cache with GVS partitioned by declared graph identity | Narrows coupling relative to B but still shares mutable topology within a partition and adds lifecycle complexity.                                                                                          |
+| D. Fully isolated stores and topology                                 | Simplest isolation, but discards large proven byte/file-count and second-root reuse gains.                                                                                                                  |
+| E. Hermetic Dependency Artifact                                       | Reuses content and topology by complete declared-input identity with immutable, atomic results; requires a producer, compatibility projection, ownership, and GC contract not exposed by current live pnpm. |
+
+## Decision
+
+Keep A as the current pnpm compatibility baseline under DELTA-001, and choose E as the architectural
+target.
+
+Reusable package data must first be deterministic, integrity-addressed, derived
+from declared inputs, lifecycle-free, and immutable by contract. Within that
+eligible layer, share as broadly as the trust and platform evidence allow. Keep
+Dependency Graph, virtual topology, Projection State, and repair authority at
+one Materialization Root so reuse never grants mutation authority.
+
+Move repeated graph/topology work across roots only by replacing mutable shared
+state with a Hermetic Dependency Artifact keyed by the complete lock graph,
+platform, package-manager policy, and all identity-affecting inputs. Publish it
+atomically, mount or project it read-only, and make eviction independent of
+consumers. This follows the property that gives Nix stores and hermetic build
+action caches broad safe reuse; it does not require inventing a second mutable
+package-manager database.
+
+Use DMP.VER-R12 to quantify A, B, and C and to identify topology work worth
+capturing in E. B or C cannot replace A merely by winning a benchmark: a
+challenger must first eliminate cross-root mutable topology and repair authority
+and pass identity, purity, data-safety, concurrency, and bounded-repair gates.
+
+## Consequences
+
+- Managed live pnpm uses a shared whole Store Cache and root-local
+  `node_modules/.pnpm`; GVS is disabled by the current spec. Sharing the cache's
+  mutable pnpm index is a transitional compatibility divergence tracked by
+  [DELTA-001](../.delta/DELTA-001-whole-store-mutable-index.md), not part of the
+  accepted pure reuse target.
+- Direct mutation of imported dependency files and dependency lifecycle scripts
+  remain outside the managed contract. Native/build-sensitive output is
+  isolated or supplied as immutable Nix output.
+- Root repair discards only root-owned graph/projection state and never invents
+  edges or sweeps the host Store Cache.
+- Current GVS remains a measurement subject, not an admissible end state or a
+  synonym for cache reuse or runtime identity.
+- The long-term design should remove repeated pure topology work by publishing
+  immutable graph-addressed artifacts, rather than widening mutation scope.