Ruling needed: canonical launcher metadata domains/encoding and offline fallback authority (#41/#65) #1225

Decision requested (launcher-standard v0.6.0)

At standards/main 3108c1b the authoritative launcher/launcher-standard_praxis.deed has no (platforms) or (lifecycle-phases) domain and no (metadata-block (encoding ...)), although its :required-fields lists platforms and both lifecycle-phase lists and its comment promises that the block can be reparsed by launch-scaffolder. In launch-scaffolder/main 2773fa3, the baked local deed adds all three clauses; standard.rs::platforms() and metadata_encoding() require them. launch-scaffolder#65 reports 18 failures when unmodified earlier canon was swapped in (historic experiment, not a v0.6.0 test run); #41 covers field/encoding conformance. The SHA-256s currently differ: 29c12fbd... (local) vs b9d72768... (canon).

A second authority conflict: launcher/README.adoc explicitly says tooling MUST consume the canonical file rather than carry a vendored copy, and calls for removing launch-scaffolder's copy. Yet launch-scaffolder#65 requires a byte-identical baked fallback plus content pin. We should not quietly call a synchronized snapshot compliant forever: it will drift on the next standards release.

Proposed owner decision A (for review, not a claim of approval): accept canonical definitions of all three clauses, with matching docs/UX-standards/launcher-standard.adoc in the same commit (lockstep gate), and either (1) explicitly allow a bounded offline fallback pinned to an exact canonical commit/hash, with a real cross-repo currency control and review date, or (2) rule that the no-vendor MUST applies without exception, in which case change #65's fallback criterion and remove the copy downstream. Specify whether local platform/lifecycle values are valid estate domains rather than blindly upstreaming those values; v0.6.0's new (archetypes) and (provisioning-modes) may change the claims an app launcher is allowed to make. An unsupported local (encoding) should not be used as the estate's conformance oracle meanwhile.

Proposed acceptance

1. Owner records authoritative domain/encoding and offline-fallback ruling, alternatives, scope and compatibility impact; old @a2ml-metadata remains readable, not re-emitted. Note that a banner of key: value with no delimiters (e.g. trigger) is not currently parseable even if it carries the 11 fields.
2. If clauses are adopted: canonical deed and adoc edited together; conformance fixture generated from the declared fields/encoding, a negative missing-field/marker control, and lockstep CI actually run. Clarify how v0.6 archetype/provisioning modes apply to launch-scaffolder app output.
3. Only after canon merges, consumer re-bakes exact bytes (if permitted) or removes fallback (if not), updates nonhistorical versions, proves local/remote currency and runs the full suite against the merged canonical commit. Document both grammar :schema-version and launcher :standard-version separately.

Refs: hyperpolymath/launch-scaffolder#41, #65; standards launcher/README.adoc §Sync requirement, docs/UX-standards/launcher-standard.adoc; standards#1100 (v0.5.0) and #1112 (v0.6.0). No canonical or consumer behaviour is being changed by this proposal.