Extract the anchored-chain provenance stack to standalone repos

[bdelanghe]

Sibling of #638 (verbspec extraction). The packaging pass for the provenance cluster is done (see the "publish-ready packaging" PR); this tracks the physical extraction.

The cluster is cas → anchored-chain → anchored-chain-sqlite (acyclic; anchored-chain depends only on cas). Extract as a unit so no published package has a workspace-only dependency.

• Create github.com/bounded-systems/anchored-chain and move packages/anchored-chain/ into it (history-preserving).
• Create github.com/bounded-systems/anchored-chain-sqlite and move packages/anchored-chain-sqlite/ into it.
• Ensure cas is published first (it's the shared base; already packaged, also still in-tree — see Extract @bounded-systems/verbspec to a standalone repo #638 context).
• Drop the @bounded-systems/anchored-chain and @bounded-systems/anchored-chain-sqlite entries from the root tsconfig.json paths map.
• Switch the workspace:* deps (anchored-chain → cas; anchored-chain-sqlite → anchored-chain, cas) to real version ranges.
• Publish 0.1.0 for both, then verify prx resolves the published packages.

Notes

• anchored-chain-sqlite is Bun-only (bun:sqlite, drizzle-orm/bun-sqlite, .sql/.json import attributes). Its published runtime entry is source under the bun condition; dist is declaration-only. The standalone repo's CI must run on Bun.
• anchored-chain's build treats cas as an external dep (paths: {} override in tsconfig.build.json), so it needs cas's built declarations available at build time — i.e. cas published (or built first).

Context: claude.ai/code session 01PGAut6CEjiQjFMURp8UA5A

[bdelanghe]

Dependency-ordered extraction plan

Now that every @bounded-systems/* package is publish-ready (#637, #640, #646, #648, #653), here's the cut sequence. First, the decision that determines how much work this actually is:

Decision: publish-from-monorepo vs. physical repo cuts

These are separable. "Publish-ready" is already achieved; physical extraction is a heavier, optional second step.

• Path A — publish from the monorepo (cheap, available now). Every package has publishConfig, a build, and is no longer private. bun run release (changesets publish) would build + publish them to npm in dependency order automatically, with workspace:* rewritten to real ranges by changesets at publish time. No repo churn. You get installable packages today; the monorepo stays the source of truth.
• Path B — physical standalone repos. Create one repo per package, move history, stand up per-repo CI, and switch workspace:* → version ranges in prx. This is what the repository URLs in each package.json anticipate, but it's materially more work and adds cross-repo version coordination.

Recommendation: if the goal is "these are consumable as versioned packages," do Path A first — it's low-risk and reversible. Reserve Path B for packages that genuinely need an independent home/contributor surface. The wave ordering below applies to both (it's just the topological order; changesets enforces it for A, you enforce it manually for B).

The dependency graph (real edges, post dep-fixes)

wave 0 (leaves, no internal deps):
  cas  verbspec  env  policy  disposition  audit-context  fs  machine-schema  prx-config

wave 1 (deps ⊆ wave 0):
  anchored-chain → cas
  auth → env        host → env        proc → env, policy        surface-sync → disposition

wave 2 (deps ⊆ waves 0–1):
  anchored-chain-sqlite → anchored-chain, cas
  repo-root → proc
  github-budget → audit-context, env, proc
  bd → env, policy, proc
  git → env, policy, proc, fs

wave 3 (deps ⊆ waves 0–2):
  gh    → env, policy, proc, github-budget
  scout → cas, anchored-chain, anchored-chain-sqlite
  slack → cas, policy, anchored-chain, anchored-chain-sqlite, auth, env, proc

(prx, the app, consumes all of the above and stays the sink / product repo.)

The graph is acyclic, so each wave's deps are fully published before it.

Per-package cut steps (Path B)

For each package, in wave order:

1. Create github.com/bounded-systems/<pkg> (the repository URL already points here).
2. Move with history — git subtree split --prefix=packages/<pkg> (or git filter-repo) → push to the new repo. Include the release config + a CI workflow that runs on Bun.
3. Switch deps to versions — in the extracted repo, rewrite each @bounded-systems/* workspace:* to ^<published version> (the dep is already published in an earlier wave).
4. Publish <pkg> from its new repo; verify the tarball installs and builds standalone (bun run build against the published deps, not the workspace).
5. Update prx — remove the @bounded-systems/<pkg> entry from the root tsconfig.json paths map and the packages/* workspace glob, switch prx's dependency to ^<version>, delete packages/<pkg>/. Confirm bun install && bun run typecheck && bun test stays green.

Gotchas already surfaced

• cas is the keystone — it's in wave 0 and anchored-chain, anchored-chain-sqlite, scout, slack all need it. Publish it first.
• anchored-chain-sqlite is Bun-only (bun:sqlite, drizzle bun-sqlite, .sql import attributes — see anchored-chain-sqlite: confirm Bun-only publish shape (no Node dist) #642). Its dist is declaration-only; its runtime entry is source under the bun condition. Every transitive consumer (scout, slack, and prx) must run on Bun. Confirm anchored-chain-sqlite: confirm Bun-only publish shape (no Node dist) #642 before cutting it.
• Build ordering is real — each package's tsconfig.build.json uses paths: {} and resolves deps via their built declarations, so a package can only build after its deps' dist exists (or they're published). Path A's changeset publish and a topological CI both handle this; a naive parallel build won't.
• Cross-repo versioning (Path B only) — once split, a breaking change in cas means coordinated bumps across every dependent repo. This is the main ongoing cost of B over A, and the reason to default to A unless a package needs its own home.

Suggested first concrete step

Cut cas alone end-to-end as the pilot (it's a pure wave-0 leaf with the repo URLs already set and a README/LICENSE in place). Proving the create → move → publish → update-prx loop on one keystone package will surface the release-tooling questions (changesets-per-repo vs. a release-please style setup) before committing to all 22. I can drive that pilot, or script the subtree split + prx-rewire for it, on request.

---

Generated by Claude Code