beads: revise homemaker-py-sel design — mandatory code-level usage, no fallback

Records the outcome of the "how does a parallel usage key work when the leaf
name can mutate?" review. Two problems were conflated:

1. Mutation staleness dissolves if usage is CODE-level: usage_of(leaf.type) is
   looked up fresh, exactly as size/width/proportion/adjacency already are.
   Verified every corpus leaf type resolves to a declared code or a generic.
   The broken design is usage stamped ON THE LEAF — 51 sites assign leaf.type,
   and this project already hit that class twice (share needed a companion
   share_type; r5a was a real stale-stamp resurrection even with the guard).

2. Name/key divergence is real and is NOT fixed by (1). Resolved by making
   usage mandatory on every declared code with no prefix fallback, closed
   vocabulary {bedroom, toilet, living, kitchen, none}, missing key = load
   error. One source of truth; room codes become free-form identifiers.

Measured migration: 10 files, 107 entries, 100 (93%) pure annotation; only 7
change behaviour (la1 x3, li1 x2, br1, tr1) and those are the fix.
write_stage1_programme already propagates the key.

Left open as the programme author's call, not mechanical: what those four
rooms should declare — li1 "Library Corner" as living is arguably already
correct, and br1 "Staff Room" may want living rather than none. Also noted:
mandatory breaks out-of-repo configs until annotated (mitigate with an error
naming each code and its prefix-implied usage, plus a migration script), and
the 7 changed entries need their own A/B and re-baseline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB
This commit is contained in:
Claude 2026-08-26 10:32:14 +00:00
parent a25dc2cb59
commit f476a5849e
No known key found for this signature in database

File diff suppressed because one or more lines are too long