ADR-008: Retire the registry pipeline and publish the record itself

Context

ADR-006 proposed inverting the registry build — generate data/registry.yaml from the record as an artifact, so web/ could keep consuming it — and left the decision Proposed because the frontend’s contract had not been checked.

Checking it turned out to be answering the wrong question. The pipeline was research.yaml → registry.yaml → REGISTRY.md → a hand-written frontend that fetched the YAML and rendered a table. Every stage of that exists to turn structured data into something a reader can browse, and the record already produces exactly that: docs/practices is the same corpus with working links, per-topic pages, and a status column that distinguishes records. luria site stages the whole record as a browsable vault, with the relative links luria link --fix wrote still resolving, plus a citation graph and backlinks that nothing here maintains by hand.

Inverting the projection would have kept three artifacts alive to feed a fourth that duplicates a view we now generate anyway.

scripts.registry.cli had also become the last thing asserting the old model. It reads the sota: fields and emits recommendations with derived MLR- identifiers (ADR-005), a topic_id slugged from the recommendation text, and a status field that could only ever say standard (ADR-002) — a generator for a schema the record replaced.

Decision

Retire the pipeline rather than invert it.

Deleted: src/scripts/registry/ and its tests, the Build Registry workflow, the build-registry entry point, data/REGISTRY.md, the flat registry section injected into the README, the taxonomy specification that had sat in the LLM README templates since before ADR-003 superseded it, and the web/ frontend with its deploy workflow.

Added: the Pages workflow, which builds luria site and publishes it.

data/research.yaml and data/registry.yaml stay, frozen, with a README saying so. They are not a second source of truth — nothing reads them at build time any more — but they are the import’s provenance, and src/scripts/migration/to_record.py needs them to stay re-runnable. That script is the only thing that makes 238 generated documents auditable without reading all 238.

This needs one repository setting that no file here can set: Settings → Pages → Source must be “GitHub Actions”. Until it is, the Pages build job succeeds and the deploy job fails with “Pages is not enabled”. The previous frontend published from a gh-pages branch, which is a different mechanism and cannot coexist with this one.

Alternatives considered

• ADR-006 as proposed — generate registry.yaml from the record and keep the frontend. Preserves a working site and a public data artifact at the cost of maintaining a projection, a generator for it, and a consumer, all to display what docs/practices displays. Worth reversing to if the YAML artifact turns out to have consumers outside this repository, which is the one thing this decision does not know.
• Keep the frontend, drop only the CLI. The frontend fetches registry.yaml; without a generator that file freezes, and a page serving a snapshot that silently stops updating is worse than no page.
• Delete data/ entirely. The record supersedes every claim in it and git history preserves it. It stays because the migration script’s value is that a reviewer can re-run it, and that is worth two frozen files.

Consequences

The published site changes shape: a Quartz vault of the record rather than a single sortable table. That is a product change, not only an infrastructure one, and it is the part most worth reverting if it disappoints — the frontend is one git revert away for as long as this decision is the most recent one touching it.

data/registry.yaml stops being regenerated, so it will drift from the record the moment a practice is edited. It is labelled frozen for that reason. Anything that was consuming it from outside this repository is now consuming a snapshot; that is the risk this decision accepts.

The five “Update ML training registry” commits that motivated ADR-001’s complaint about churn cannot recur, because the thing that made them no longer exists.