Repository navigation
Document consuming the registry #163
Description
User story / Problem statement
A consumer has no instructions. The README describes building the DAR and
running the service out of a working copy; nothing tells a downstream repository
how to depend on this one, what to put in its manifest, what environment the
service needs, where those values come from, or that a private repository means
the install needs git credentials. Separately, several documents describe an
install lifecycle and a CI pipeline that this epic changes, and a document that
is confidently wrong is worse than one that is silent.
Expected outcome
A reader outside this repository can add one dependency line, run one command,
and know exactly which environment variables to set and where their values come
from. A reader inside it finds no sentence that this epic falsified.
Acceptance criteria
Consumer documentation
- The README carries a section giving the dependency line pinned at a tag,
thepnpm execinvocation, the full required and optional environment, and
a pointer to where the template ids and admin party come from - It states the git-credentials precondition and why it exists
- Every command in that section has been run literally as written
Internal documentation
- The command tables in
CLAUDE.mdandARCHITECTURE.mdcarry the two new
commands -
CLAUDE.md's CI paragraph andSPEC.md's pull-request-coverage bullet
describe three checks, not two -
SPEC.md's repository layout lists both new scripts -
SPEC.md's version references say0.2.0and distinguish the npm
consumption tag from the DAR release tag -
SPEC.md's size figures are re-derived, and the sentence names what it
counts
Verification
- The counting words in every edited paragraph (
both,every,all,
only, and the numerals) are re-read against the tree, not only the facts
underneath them - Every path the new prose names exists
- The diff contains only
.mdfiles
Technical notes
- A documentation change has no mutation check and no suite that could detect a
defect, sogit diff --statshowing only.mdfiles is a stronger argument
than a green test run. Say that plainly rather than letting a green summary
imply a suite verified anything. SPEC.mdis written for an external audience evaluating the implementation,
not for someone installing it, so the consumer instructions belong in the
README. WhatSPEC.mdneeds is the version, the third CI check, the two new
scripts, and the size figures.SPEC.md's TypeScript size figures are already stale before this work
starts. It says 1724 service and 4343 test lines; the tree gives 1738 and
4349. The service figure wasfind registry/src -name '*.ts' | xargs wc -lwhen
it was written and has drifted since; the test figure matches no method that
reproduces. Restate both with the command that produced them, rather than
adjusting the old numbers by the delta.- The four optional environment variables are read as
env.PORTand friends
rather than through the required-variable helper, so they never appear as
quoted string literals in the config source. A cross-check of the README's list
against those literals will show exactly four differences, and any fifth is a
real gap. - Two tags will exist and mean different things: the DAR is published at one, the
npm package is consumed at another. Say which is which rather than leaving a
reader to infer it.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
lmcorbalan commentedon Sep 2, 2026
Three things found while doing #159 that land in this issue's scope.
1. The size figures moved again, and here is the pair with the method.
The Technical notes say the tree gives 1738 and 4349. The shebang #159 added to
registry/src/index.tsmakes the service figure 1739. Both numbers reproduce from the same command, which is the one worth naming in the sentence itself:SPEC.md:66-67still says 1724 and 4343. The Daml figures beside them, 976 and 2508, are correct and need no edit. Re-derive rather than adjust by the delta: the 4343 figure matches no counting method that reproduces.2. The published manifest describes a project the tarball does not contain.
npm packnow ships 24 entries:registry/dist,registry/openapi,registry/.env.example,package.json,README.md,LICENSE. Nodaml/, noscripts/, nodeps/. The manifest that travels with it nonetheless carries adescriptionabout a CIP-0056 token, and eight scripts (setup,build,test,test:coverage,smoke,sandbox,seed,clean) that invokedpmor referencedaml/andscripts/paths absent from the package.prepareis the only entry that means anything to an installer.Nothing breaks, since npm runs none of them from an installed tarball, but a consumer reading
node_modules/@bootnodedev/canton-token-forge/package.jsonis told to run commands that cannot run. This is documentation a consumer actually reads, so it belongs here rather than in the packaging work:descriptionnames the registry service, or the decision to leave it describing the Daml project is stated deliberately3.
RUNBOOK.md's release procedure is a doc site this issue does not list.The Technical notes already say two tags will exist and mean different things. Concretely:
release.ymltriggers onv[0-9]*, and its pre-release case only fires for a hyphenated tag, so pushingv0.2.0runs the full DAR release and takes over/releases/latestwith an asset byte-identical tov0.1.0's, becausedaml/canton-token-forge/daml.yamlstays at0.0.1.RUNBOOK.md's "Cutting a release" section still describes av*tag as purely a DAR release.Whether to keep one tag namespace or give DAR releases their own prefix is an open decision that sits outside this issue. If the shared namespace stays, that RUNBOOK section is the sentence that needs the correction, and it is not in the current criteria.