Spike: does washr::update_dictionary() preserve extra dictionary columns?

[larnsce]

Milestone: v1.3.0 (attach once the milestone exists). Blocking precondition for the rest of the v1.3.0 milestone. Part of the v1.1 roadmap: docs/roadmap-v1.1.md.

The premortem's adversarial counter-check found that data-raw/dictionary.csv is not a free file: washr generates and regenerates it in the 5-column format, and renders the README dictionary table from those columns. Any schema extension pkgreview mandates would be silently clobbered the next time a contributor reruns the washr dictionary tooling, turning the extension into per-review manual surgery. No dictionary schema work proceeds without this spike.

Correction from the 2026-07-12 cross-repo coherence review: washr::update_dictionary() does not exist yet. It is openwashdata/washr#13, scheduled in washr's v1.2.0 backlog with "extra user columns survive the round-trip" now an acceptance criterion there. This spike therefore has two parts with different preconditions.

Tasks

• Part 1 (runnable today): on a real package, add extra columns (for example unit, allowed_values) to dictionary.csv, rerun the dictionary tooling that exists (washr::setup_dictionary() / washr:::fill_dictionary()), and diff. Document exactly what survives, what is dropped, and what is misaligned.
• Part 2 (blocked on Feature request: updating an existing dictionary washr#13): repeat the round-trip with update_dictionary() once it ships; its acceptance criterion should make this pass by construction. If washr#13 has not shipped when v1.3.0 starts, evaluate Part 1's result alone.
• If columns are dropped and washr will not preserve them: conclude that dictionary schema extensions are off the table and record that decision in this issue and in the roadmap.

Outcome

A documented round-trip result. Pass: extensions (#38, #39) may proceed. Fail with no washr fix committed to a milestone: the v1.3.0 schema extension issue is closed as not planned.

[larnsce]

Part 1 result (washr 1.0.1, run 2026-07-23 on a throwaway copy of fixtures/pkgreviewtest with unit and allowed_values columns added to dictionary.csv):

Round-trip verdict: FAIL on washr 1.0.1. Extra columns do not survive any regeneration path, and the failure is worse than the premortem assumed: the descriptions are destroyed too.

Tooling	Behavior on the extended 7-column dictionary
washr::setup_dictionary()	Refuses when data-raw/dictionary.csv exists ("already exists!" stop). Safe by refusal; cannot clobber.
washr::fill_dictionary() (exported in 1.0.1)	Rebuilds the 5-column frame from data/ and overwrites the CSV unconditionally. unit and allowed_values dropped, and all 10 human-written descriptions wiped to empty. It never reads the existing file; there is no merge.
washr::setup_roxygen()	Read path tolerates the extra columns: descriptions carried into the generated roxygen correctly, extra columns ignored.

So the exposure is asymmetric: reading an extended dictionary is safe today; any rerun of the write tooling on an existing dictionary is total loss (extensions and descriptions alike). The realistic clobber path is a contributor calling fill_dictionary() directly, since setup_dictionary() refuses.

Part 2 remains blocked: update_dictionary() does not exist in washr 1.0.1. openwashdata/washr#13 is OPEN, milestoned washr v1.2.0, with "extra user columns survive the round-trip" recorded there as an acceptance criterion.

Gate decision per the outcome rule: this is a fail WITH a washr fix committed to a milestone, so the schema extension issue (#39) is not closed as not planned; it stays blocked on openwashdata/washr#13. Rerun Part 2 of this spike when washr v1.2.0 ships, before any #39 work starts. #38 waits with it (this spike is the blocking precondition for the v1.3.0 milestone).

Practical mitigation worth folding into the guidebook when #39 proceeds: never rerun fill_dictionary() on an existing dictionary; the descriptions it destroys are the publication floor's most important field.

[larnsce]

Scope shift per #48 decision 7: v1.3.0 is now the org profile layer (#49). This item, #38, and #39 move to v1.4.0, still blocked on this spike.