The documented steps (conformance/README.md, "Growing the suites") are: vendor vectors, extend translate.rs + vectors/README.md, add the #[case_row] in guest-ct/src/lib.rs, tag features, lock-update. Measured on the first real post-merge addition (#299 / 78142f7 — two parameterizations of an existing family), the actual touch set was: translate.rs, vectors.rs, lib.rs #[case_row] ×2, plan.rs vector_rows! table ×2 (five-field entries), plan.rs non-rkyv vector_builder arm, vendored JSON ×2, vectors/README.md, tests.lock, matrix.md — 7 source files + 3 artifacts. A new family additionally needs the corpus re-export + preparsed! table entry and a build.rs write() call.
The README mentions neither plan.rs (any of its three tables/arms), nor vectors.rs, nor build.rs, nor matrix-update (whose committed output needs a browser-inclusive full run), nor the must-not-touch rule for plan::ROWS/the census fixture. A contributor following it to the letter gets a partially-registered algorithm: present in lib.rs, absent from the rkyv table, so register_vector returns false and cases_under panics "no builder for prefix" at registry build (plan.rs:844).
Also missing anywhere: the rule that new rows must NOT be added to plan::ROWS (the frozen-census parity table) — growth requires the lib.rs and ROWS prefix lists to diverge, the inverse of the usual sync expectation, and plan.rs:5-9 still claims they "cannot drift from each other".
Fix: enumerate the real step list (or better, shrink it — see the census-scaffolding end-state issue) and state the ROWS freeze rule at both the README and the ROWS definition site.
Encountered first-hand during the #299 rebuild; independently confirmed by review.
The documented steps (conformance/README.md, "Growing the suites") are: vendor vectors, extend translate.rs + vectors/README.md, add the
#[case_row]in guest-ct/src/lib.rs, tag features,lock-update. Measured on the first real post-merge addition (#299 / 78142f7 — two parameterizations of an existing family), the actual touch set was: translate.rs, vectors.rs, lib.rs#[case_row]×2, plan.rsvector_rows!table ×2 (five-field entries), plan.rs non-rkyvvector_builderarm, vendored JSON ×2, vectors/README.md, tests.lock, matrix.md — 7 source files + 3 artifacts. A new family additionally needs the corpus re-export +preparsed!table entry and a build.rswrite()call.The README mentions neither plan.rs (any of its three tables/arms), nor vectors.rs, nor build.rs, nor
matrix-update(whose committed output needs a browser-inclusive full run), nor the must-not-touch rule forplan::ROWS/the census fixture. A contributor following it to the letter gets a partially-registered algorithm: present in lib.rs, absent from the rkyv table, soregister_vectorreturns false andcases_underpanics "no builder for prefix" at registry build (plan.rs:844).Also missing anywhere: the rule that new rows must NOT be added to
plan::ROWS(the frozen-census parity table) — growth requires the lib.rs and ROWS prefix lists to diverge, the inverse of the usual sync expectation, and plan.rs:5-9 still claims they "cannot drift from each other".Fix: enumerate the real step list (or better, shrink it — see the census-scaffolding end-state issue) and state the ROWS freeze rule at both the README and the ROWS definition site.
Encountered first-hand during the #299 rebuild; independently confirmed by review.