feat(scripts): deploy the vendored DARs and run the token registry on 3013

[lmcorbalan]

Summary

Closes #153

dev-stack.sh brought up four services and deployed one built DAR, so the token-forge
side of the stack could not be exercised by anyone who had not wired it up by hand. This
adds the fifth service and the two vendored DARs it needs, and closes PR 1 of the
token-forge migration.

The registry takes its whole non-secret configuration from the KEY=value block
bootstrap prints on stdout, which up now tees and reads back. Nothing is written to
disk, so nothing can go stale between the two scripts. LEDGER_API_TOKEN is the one
variable outside that block, because bootstrap never sees the bearer and supplies it from
.env instead.

Changes

• up deploys vendor/canton-token-forge.dar then vendor/vesting.dar after the built DAR
• up starts the token registry on 3013 and blocks until /readyz returns 2xx
• down stops the registry, and both down and status cover 3010-3013
• A test holds bootstrap's printed keys and dev-stack.sh's REGISTRY_ENV_KEYS together
• A second up restarts a registry left from an earlier run rather than skipping the busy
  port, and fails if anything else holds it
• up hands the resolved participant URL to bootstrap, so an exported
  CANTON_JSON_API_URL moves every step of the run rather than only some of them
• The bearer reaches the registry through the environment instead of env's argv

Deviations

• The contract test lives in scripts/bootstrap-vesting.test.mjs, not the plan's
  bootstrap-registry-env.test.mjs: Seed the DBT instrument admin and config in bootstrap #152's review renamed it to match its sibling source.
• No Services And Ports row was added to architecture.md; Seed the DBT instrument admin and config in bootstrap #152 already landed one.
• README.md gains a Token registry step beyond the plan's DAR-block edit, because the
  README documents the manual loop and the acceptance criteria ask it to name the registry.
• down's fallback matches canton-token-forge/registry/dist, not the plan's
  canton-token-forge-registry. The plan's pattern cannot match the running process: the
  bin is a shim that execs node .../canton-token-forge/registry/dist/index.js, so the
  hyphenated string survives only on the pnpm exec parent that stop_pidfile already
  killed. Left as written, down could leave 3013 held with no diagnostic.
• start_registry restarts a busy port instead of skipping it as wallet-service and vite
  do. Those two are configured from .env and the repo, so an already-running one is the
  process up would have started; the registry is configured from the block bootstrap
  printed this run, and bootstrap mints a fresh admin party and InstrumentConfig every
  time. A leftover therefore serves a superseded instrument while still answering
  /readyz, so skipping it is silently wrong and no readiness probe would catch it.

Known minors

• The "Stack is up" banner hardcodes 3013 while start_registry derives the port from the
  bootstrap block, as do the lsof -iTCP:3010-3013 ranges in down and status. The port
  has one definition, in bootstrap-vesting.mjs, and the shell has no constant to thread.
• Making bootstrap idempotent would make a leftover registry correct rather than needing a
  restart. Better end state, but it changes what Seed the DBT instrument admin and config in bootstrap #152 landed, so it is not in this PR.

Acceptance criteria

• up deploys canton-token-forge.dar before vesting.dar
• The registry starts on 3013, configured from the block bootstrap printed
• LEDGER_API_TOKEN comes from .env, never from that block
• up gates on a 2xx /readyz
• down stops the registry and leaves 3010-3013 free
• A test holds dev-stack.sh's key list and bootstrap's printed keys together
• architecture.md, CLAUDE.md and README.md name the registry and the vendored DARs

Test plan

Automated tests

pnpm test covers scripts/bootstrap-vesting.test.mjs, which now parses dev-stack.sh
for its REGISTRY_ENV_KEYS array and asserts that bootstrap prints every key it reads
exactly once, that LEDGER_API_TOKEN is not among them, and that the five template ids
survive quote-stripping unchanged. Add a registry variable to one file and the test fails
until the other follows.

Full gate run on this branch: lint, typecheck, test, knip, docs:check,
check:anatomy and CI's build step all pass.

Manual verification

1. ./scripts/dev-stack.sh up
2. curl -sS http://localhost:3013/readyz returns {"status":"ready"}
3. curl -sS http://localhost:3013/registry/metadata/v1/info reports an adminId equal to
   the admin line bootstrap printed in that run
4. curl -sS http://localhost:3013/registry/metadata/v1/instruments reports one DBT
   instrument with decimals: 10
5. ./scripts/dev-stack.sh down, then lsof -nP -iTCP:3013 -sTCP:LISTEN reports nothing

The restart path was exercised separately, against a stand-in process launched from a real
canton-token-forge/registry/dist/index.js path so pkill -f matches the same argv it
would in a live run: the leftover is stopped and 3013 frees, while an unrelated listener on
3013 survives, which is the case that now aborts up rather than reusing it.

Steps 2-5 were verified against a live LocalNet. Step 1 could not be: up still prechecks
for dpm, which PR 3 removes, so bootstrap's AmuletVestingFactory half was skipped and
its instrument half run unchanged to produce a real env block. The registry then booted
from that block through the script's own parser, and the teardown was confirmed against a
live process. A successful boot is itself proof the parser strips the block's single
quotes: the registry rejects a template id that still carries one.

Breaking changes

None.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
demo.canton-dappbooster	Ready	Preview	Sep 4, 2026 4:40pm UTC
docs.canton-dappbooster	Ready	Preview	Sep 4, 2026 4:40pm UTC