Decide how canonical validation treats Workshop output the pinned OverPy writes

[e54-bot]

Decision needed (architect)

Which repository owns accepting the Workshop programs the pinned OverPy 9.7.10 writes but validate_canonical_ids rejects, and by what mechanism? Requested: architect decision, made together with the project owner.

Evidence

The builtin probe in wrightkit/opy-rs#370 (part of wrightkit/opy-rs#366) compiles 3786 programs with OverPy and with opy-rs. 111 of them compile in OverPy but fail opy-rs at workshop_rs::validate::validate_canonical_ids (program.validate() and workshop_rs::parser::parse accept the same OverPy output). Three families:

1. Non-Boolean value in a Boolean slot (about 50 functions, e.g. waitUntil(eventPlayer.getPosition(), 3)). OverPy's emitter wraps a value in First Of(...) when the slot expects a Boolean and the value is in its "cannot be put in a Boolean" set (vectors, heroes, teams, maps, gamemodes, buttons, some player lists, strings from icon functions, Null); all other values, including several arrays, colours, ids and String results, are written as they are. This is an emitter rule, not the 0/1 ↔ False/True compression of Zezombye/overpy#33 and Zezombye/overpy#238.
2. Array where Object is declared (printLog, logToInspector, bigMessage, smallMessage, setObjectiveDescription, progressBarHud).
3. Vector x - x (Close remaining OverPy structural gaps outside the Bastion entrypoints opy-rs#366 item 3): folds to Number 0 in a Vector slot (createEffect position), which the catalog does not coerce.

Constraint

WrightKit's compatibility contract (opy-rs docs/architecture/language-core.md) forbids structural rewrites in lowering, so opy-rs cannot emit a different valid form; a structural difference is a defect unless the owner approves an exception.

Options

• A. Relax the type check in workshop-rs (accept the forms OverPy writes, e.g. any value in a Boolean slot, Array for Object, Number 0 for Vector). Pro: one change, all three families converge, opy-rs then only adds the First Of wrapping for the values OverPy wraps. Con: weaker validation of hand-written Workshop; needs a rule for which forms are legitimate, ideally confirmed in a live client.
• B. Add an explicit lenient validation entry point in workshop-rs and have opy-rs call it. Pro: strict validation stays for other consumers. Con: two validation contracts to maintain.
• C. Record approved exceptions in opy-rs (native keeps rejecting). Pro: no workshop-rs change. Con: opy-rs rejects programs OverPy compiles, contrary to the structural-convergence target, for about 50 functions.

Recommendation: B for the mechanism, plus A's rules confirmed by a live-client check (#21), and opy-rs implements the First Of wrapping. Family 3 should be decided together with families 1 and 2.

Acceptance

• Owner and mechanism decided and recorded (ADR or contract text in the owning repository).
• The validation-rejects-reference-output gap in opy-rs tools/overpy/probe-gaps.json is removed or replaced by approved exceptions with pinning tests.

Related: wrightkit/opy-rs#366, wrightkit/opy-rs#370.

[e54-bot]

Decision recorded in #284 (ADR-0014): workshop-rs owns slot acceptance under one validation contract; declared-type mismatches are presumptions that yield to acceptance evidence. Families: Boolean parameters accept any value (workshop-rs typed rule); arrays in Object text parameters and Number 0 in the createEffect position stay rejected and become approved exceptions in opy-rs. The probe-gap acceptance item remains open until those land.

[Teakowa]

Decision complete: ADR-0014 landed in #284 and assigns the implementation work to workshop-rs #285/#286 and opy-rs #371/#372. The remaining probe-gap closure is execution state owned by those follow-ups, so this decision issue should not stay open as a duplicate tracker.