Repository navigation
Recurring defect class: declared catalog surface does not parse back #452
Description
Readiness: needs-decision — owner picks a prevention home.
Class
Spellings, aliases, and signatures declared in the catalog were never exercised end-to-end through the frontend, so the declaration and the parser drifted apart. Consumers writing exactly what the catalog declares hit parse failures the suite never exercised.
Evidence
Same class in 3 independent merged PRs on 2026-10-14:
- Refs fix(parser): resolve bare enum members whose spelling contains a colon #443 (Refs Bare enum members with a colon in their spelling do not parse #441) — six catalog enum members whose en-US spelling contains a colon rejected in bare position, though the catalog declares them.
- Refs fix(catalog): declare surface signatures for player-variable index actions #445 (Refs Player variable index actions omit the player argument in the catalog signature #442) —
Set/Modify Player Variable At Indexcatalog signatures omitted the surface player argument; calls written against the real surface did not match the declared signature. - Refs fix(parser): parse every declared localized catalog spelling in its locale #449 (Refs Declared localized catalog spellings do not parse back in their own locale #448) — declared localized spellings failed to reparse in 11 of 15 locales; found by writing every declared spelling into a program and re-checking in the same locale.
The drift was found by consumers (wright check, wright lookup, the wright census) rather than by this repository's own gates.
Ask
Refs #449 extended the census localization shard to enumerate every declared spelling (~22,900 cases). Owner decides whether to extend the same exhaustive enumeration to signatures and remaining declared surface forms, or pick another home: owner contract, or an existing organization policy rule.
Recorded in docs/LESSONS.md via the merged-work retrospective.
Activity
e54-bot commentedon Oct 15, 2026
Decision (owner):
language_conformance.rsalready compares documented parameter count/order/types and return type against the catalog and parses calls built from them.actions.mdis regenerated from the catalog, so docs and catalog agreed on the same wrong signature. The check compared the catalog with itself.AGENTS.mdcontract: declared signatures follow the Workshop surface syntax, not only catalog-derived docs; where surface and WIR shapes differ, a hand-written surface call must parse.Limit: that these two are the only surface/WIR-divergent entries is inferred from the #445 commit, not exhaustively verified.
e54-bot commentedon Oct 17, 2026
Retrospective update — the prevention homes this issue asked for appear to have landed: every declared localized spelling is enumerated via #449, hand-written surface calls for surface/WIR-divergent signatures via #461/#464, colon-containing members resolve and round-trip through every declared locale in
tests/parser.rs, andAGENTS.mdgained the "Signatures follow the Workshop surface syntax" contract rule via #457. The lesson entry was pruned in #475; leaving the close decision to the owner.e54-bot commentedon Oct 18, 2026
Closing: prevention landed (#449, #461/#464, #457 'Signatures follow the Workshop surface syntax'; lesson pruned in #475).
e54-bot commentedon Oct 20, 2026
Recurrence in the 2026-10-16 → 2026-10-20 window, on the new
lookup/rule-content-v1declared surface:Up/Down/Left/Right/Forward/BackwarddeclarereturnType: Array#495) — six direction values declaredreturnType: "Array"; the pinnedworkshop-dataexport gives them a vector return.paramDomains, solookuplists no members #505) — 23 enum-typed parameters had noparamDomains, solookuplisted no members.rule-content-v1had no form for a preserved ambiguous member, soRule::contentfailed for rules the parser accepts.lookupsignatures of variable-target actions do not match theirrule-content-v1arguments #503,Operationparameters list 3 enum members, but modify operations are 11 operator calls #504) —lookupsignatures did not matchrule-content-v1arguments for folded targets, and the declaredOperationdomain listed 3 members where the model accepts 11 modify calls.Every one was found by a downstream consumer (the wright structured-editor wiring, wrightkit/wright#781 → #838), matching this issue's "found by consumers, not this repository's own gates" pattern. #526 added catalog-load validation for the fold facts; the open question is the one this issue left pending — whether declared surfaces get an exhaustive enumeration.
Recorded in
docs/LESSONS.mdvia #528.