Baked launcher standard has drifted ahead of the canonical deed ((platforms)); re-bake for v0.5.0

[hyperpolymath]

Finding

launch-scaffolder's baked copy of the launcher standard has drifted ahead of the canonical deed in hyperpolymath/standards.

crates/launcher-common/src/standard.rs embeds BAKED_STANDARD and relies on a (platforms :supported …) clause. Its LauncherStandard::platforms() accessor bails with standard is missing the (platforms) clause. The canonical standards/launcher/launcher-standard_praxis.deed has no (platforms) clause.

Measured. This was a read-only scratch clone at 7bcc971, with the baked file swapped for standards' unmodified origin/main deed:

• cargo test -p launch-scaffolder-common fails 18 tests (cargo: 84 passed; 18 failed).
• 15 go through platforms() and hit the error above.
• 2 (metadata_block::tests::*) hit a second missing clause: (metadata-block) is missing its (encoding) clause.
• the_vendored_standard_is_pinned_by_content fails by construction, because it pins the content.
• LauncherStandard::parse itself succeeds, because platforms() is only evaluated when something calls it.

So the two files are not the same standard. launch-scaffolder enforces two clauses the canonical document never ratified: (platforms) and (metadata-block (encoding …)).

Also owed: re-bake for standard v0.5.0

hyperpolymath/standards#1100 (D224) adds a (js-runtime) clause and bumps :standard-version to 0.5.0. With that deed baked in:

• parse reads spec_version = "0.5.0";
• exactly two tests fail beyond the 18 above (cargo: 82 passed; 20 failed). Both hard-code the old version:
  • standard.rs:471 spec_version_is_standard_version_not_schema_version → assert_eq!(s.spec_version, "0.4.0", …)
  • standard.rs:650 falls_back_to_the_baked_copy_when_no_rung_exists → assert_eq!(s.spec_version, "0.4.0")

Acceptance criteria

• One direction is chosen and recorded. Either upstream (platforms) and (metadata-block (encoding …)) into standards/launcher/launcher-standard_praxis.deed, with a lockstep adoc edit, or drop the dependency on it here. The baked copy must stop carrying clauses the canonical deed lacks.
• BAKED_STANDARD is byte-identical to standards' origin/main deed after feat(launcher-standard): add the (js-runtime) bun/bunx launch route, v0.5.0 (D224) standards#1100 lands, and the content-pin test is updated to that hash.
• The two literal "0.4.0" asserts (standard.rs:471, :650) read the expected version from one place rather than restating it, so the next bump cannot orphan them.
• cargo test -p launch-scaffolder-common is 0 failed against the re-baked copy.
• A regression control exists: a test, or CI step, that fails when the baked copy differs from the canonical deed. That makes this drift detectable rather than discovered by accident.

Correction: the first version of this issue said 17 failures, 16 via platforms(). A name-extraction regex dropped a test whose name contains digits (…_0700_…), and it missed the second clause. The figures above are cargo's own tallies.

Not in scope

The drift predates D224. It is not caused by hyperpolymath/standards#1100, which is why it is filed here rather than folded into that PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YSq3UodR3CjsuAK5yoTzHF