ADR-006: Generate the registry from the record instead of checking it in

Context

data/registry.yaml is output. build_registry_from_yaml reads research.yaml and produces it; data/REGISTRY.md is rendered from that. Both are committed, and the commit log shows what that costs — five consecutive commits named “Update ML training registry”, each a regeneration, none saying what moved or why.

After ADR-001 the direction is wrong twice over: the file is derived from a source that is no longer the source.

Decision

Proposed. Invert it: build registry.yaml from the record as a release artifact for the frontend, and stop committing it as though a human wrote it. REGISTRY.md is replaced outright by the generated docs/practices index, which carries the same information with working links and a status column that distinguishes records.

This is deliberately not part of the migration that adopted the record. Two things have to be settled first, and neither is settled:

• What the frontend actually consumes. web/scripts/main.js reads the registry; whether it depends on the MLR id shape (ADR-005), on topic_id, or on the topics statistics block has not been checked.
• Whether the artifact ships in the repository or in a release. A generated file in the tree is the shape that produced the churn above.

Until then registry.yaml stays exactly as it is, generated by the existing build from research.yaml, and the record is maintained alongside it. That is a duplicated source of truth for the duration, which is a real cost and the reason this decision exists rather than being left implicit.

Alternatives considered

• Invert it now, in the same change. Makes the migration atomic and makes it a frontend change too, in a pull request that already moves 238 files. The record’s correctness and the frontend’s contract are independent questions and should fail independently.
• Keep both indefinitely. The duplication is only tolerable because it is temporary and stated; as a permanent arrangement it is two records that drift, which is the problem ADR-001 was about.
• Delete registry.yaml and let the frontend break. The site is deployed. No.

Consequences

While this is Proposed, data/ and record/ both describe the same corpus, and an edit to one does not reach the other. Practices should be edited in the record; research.yaml should be treated as frozen except for adding papers, and adding a paper means adding a note too.

The migration script that produced the record can be re-run to check they have not diverged, which is a weak guard and worth having: it fails loudly if research.yaml grows a paper the record does not have.