metadata-block: REQUIRED_KEYS and the deed's :required-fields disagree in both directions

[hyperpolymath]

The guard asks a different question than its consumer

launcher-common validates launcher metadata blocks against REQUIRED_KEYS (crates/launcher-common/src/metadata_block.rs:40-47). The canonical standard states its own requirement in (metadata-block :required-fields …) (hyperpolymath/standards launcher/launcher-standard_praxis.deed:259). They are not the same set, and neither is a subset of the other.

	REQUIRED_KEYS (Rust)	deed :required-fields
id	✅	✅
type	✅	✅
version	✅	✅
app-name	✅	✅
app-display	✅	✅
runtime-kind	✅	❌ not in the standard
standard-spec-version	✅	❌ not in the standard
generator	✅	❌ not in the standard
app-url	❌	✅ required, unchecked
standards-compliance	❌	✅ required, unchecked
modes	❌	✅ required, unchecked
platforms	❌	✅ required, unchecked
lifecycle-phases-covered	❌	✅ required, unchecked
lifecycle-phases-deferred	❌	✅ required, unchecked

Overlap is 5 of 14. The guard demands three fields the standard never asks for, and silently accepts a block missing six the standard requires. This is the estate's recurring guard-asks-a-different-question-than-its-consumer shape.

There is a second, larger split: the delimiters

The deed's own comment above the clause says the block exists "so it can be re-parsed by launch-scaffolder config and realign". That round-trip does not work today for a hand-written launcher.

• The parser requires a literal # @a2ml-metadata begin / # @a2ml-metadata end pair (metadata_block.rs:109,115) and fields as key = "value", lists as key = [ "a" "b" ].
• The deed specifies neither delimiter nor field syntax — only the field names.
• hyperpolymath/trigger's scripts/trigger-launcher.sh carries a banner comment and plain # key: value lines, no delimiters at all. It satisfies all eleven of the deed's :required-fields and is nonetheless unparseable by this crate.

So a launcher can be fully conformant with the published standard and still be invisible to the tool the standard names as its consumer. That is the defect, more than the key-list mismatch.

Measured

• metadata_block.rs:40-47, :109, :115, :258
• launch-scaffolder/standards/launcher-standard_praxis.deed — byte-identical to canon (diff -q reports no difference), 13,803 B, :standard-version "0.4.0", :standard-date "2026-09-22". So this is a genuine disagreement between two current files, not vendored drift.
• hyperpolymath/trigger scripts/trigger-launcher.sh:18-31 — the eleven fields, colon dialect, no delimiters.

Acceptance criteria

1. A test asserting REQUIRED_KEYS equals the deed's (metadata-block :required-fields …), parsed from the vendored deed at run time — not a second hand-maintained list. Same anti-drift shape as the CURRENT_VERSION assertion in hyperpolymath/standards#983.
2. The three Rust-only keys (runtime-kind, standard-spec-version, generator) are either added to the deed — making them the standard's requirement, which is where a requirement belongs — or demoted out of REQUIRED_KEYS to advisory. Decided, with the reason recorded here.
3. The delimiter and field syntax are specified in the deed rather than living only in the parser, so "conformant with the standard" and "parseable by launch-scaffolder" stop being different properties.
4. A round-trip test proving it: a launcher built to the deed's stated requirements parses cleanly.

Sequencing

⚠ Criterion 3 overlaps #40 (the @a2ml-metadata header compat reader). #40 should land first — it settles what the delimiter becomes, and there is no point specifying the current token in the deed if #40 is about to replace it. This issue then records the field-set half and the round-trip proof.

⛔ Nothing here authorises adding @a2ml-metadata delimiters to downstream launchers. Under the standing A2ML doctrine that would be building on and connecting new things to a dead format.

Refs hyperpolymath/standards#960 · hyperpolymath/standards#983 · #40 · #36

🤖 Generated with Claude Code

https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo