Unify workspace topology planning across pnpm dev tasks, Nix materialization, and fingerprinting

Problem

effect-utils currently has multiple overlapping models of the workspace:

• dev tasks infer install behavior from per-package pnpm-workspace.yaml files and then serialize installs conservatively
• mkPnpmCli and downstream consumers assemble or stage workspaces for Nix builds with separate assumptions
• hash / quick-check flows reason about build inputs through yet another path

That split is the root cause behind multiple issues:

• dev install boundaries are modeled incorrectly (pnpm:install:<pkg> is not actually package-local)
• downstream consumers still need brittle workspace staging / lockfile patching to avoid IFD and cross-system evaluation failures
• build, fingerprint, and dev-task behavior do not share one canonical source of truth

Goal

Define one canonical workspace topology / planning model and make all relevant consumers derive from it.

Target shape

• Raw source remains canonical.
• Genie owns semantic workspace resolution.
• One planner owns topology / planning:
  • workspace members
  • install write-sets
  • overlap-connected components
  • deterministic install order
  • build materialization plans
  • fingerprint-relevant inputs
• Nix consumers render from planner output:
  • dev install / test task boundaries
  • mkPnpmCli workspace materialization
  • hash / quick-check fingerprinting
• Any staged or prepared workspace helper is an internal consumer of the planner output, not a second authority.

Acceptance criteria

• The dev task graph matches the real pnpm mutation boundary.
• test:<pkg> no longer depends on a fake package-local install model or a global install barrier.
• mkPnpmCli no longer relies on consumer-local staged workspaces as the public contract.
• Cross-system evaluation does not depend on IFD from consumer-provided workspace derivations.
• Build inputs, fingerprints, and dev-task boundaries are derived from the same planner model.
• No long-term raw-vs-prepared dual authority remains.

Related

Primary related issues:

• #246
• #331

Related symptoms resolved by the same planner/model work:

• #357

Superseded / context:

• #322
• #254
• #342
• #130
• #244

Downstream follow-through:

• schickling/dotfiles#394
• schickling/dotfiles#397

_{Filed by an AI assistant on behalf of @schickling}

Start by tracing the workspace handling behind per-package pnpm-workspace.yaml files, mkPnpmCli, and the hash or quick-check flows. Review related issues #246, #331, and #357 for existing constraints, then map the current planning paths before proposing a shared topology planner. Done means the listed dev-task, Nix materialization, fingerprinting, and evaluation criteria derive from one model.