Future idea: cases-as-exports producer format (via `implements` annotations)

[lann]

Idea

With the WIP implements component feature (🏷️ in the Component Model explainer: annotations declaring that a plain-named export implements a named interface), a suite could be authored as a component with many exports, each implementing a common test-case interface, instead of (or in addition to) exporting the tests aggregation interface:

interface test-case {
    use test-context.{context};
    features: func() -> list<string>;
    run: async func(ctx: borrow<context>) -> result<_, outcome>;
}

Each case is a plain-named instance export annotated implements lann:component-test/test-case. Consumption paths:

1. Synthesized suite: a tool reads the component type and emits an adapter component implementing tests — the runner contract is unchanged; this is purely a producer format.
2. Introspecting host runner: a host runner enumerates and calls the case exports directly, skipping composition.

Why it's attractive

• Static inventory: case names are export names, so wasm-tools component wit suite.wasm is the inventory — no instantiation or all() call. Directly serves the lockfile/inventory workflow.
• Clean layering: adopted incrementally underneath the frozen runner contract; failure costs nothing.
• Graceful degradation on the WIP feature: works today via structural matching of plain-named exports; implements later upgrades detection from structural guessing to a declared, versioned claim. (Type checking ignores the annotation by design.)
• Composition/aggregation model: cases from multiple components can be linked into one suite ("test object files → test binary"), and multi-component suites shrink trap-poisoning blast radius to per-component.

Open questions (decision-forcing, in order)

1. Plain-name grammar vs. hierarchical names. Plain names are constrained labels; stable group/source/case identifiers with / don't fit. Needs a mangling scheme, or hierarchy has to live elsewhere. Export names would become the stable identity the whole reporting stack keys on — this must be settled first.
2. Can features be static? The headline win is execution-free inventory, but features: func() still requires instantiate-and-call. Options: encode in export names (collides with Rust guest SDK: suite authoring crate #1), custom section (invisible to the type system), 🪙 value exports (gated, further from shipping). If features stay dynamic the win shrinks to "names are static".
3. Where does missing-features materialization live? all(missing-features) lets the suite decide how a case degrades; with static enumeration that logic moves to the synthesizer/runner, or run grows a parameter frozen into the per-case interface.

Caveats

• Poisoning is unchanged for a single-component suite: one instance, one memory, one trap takes it all down. Isolation only materializes with multi-component suites (per-group components look like the sweet spot).
• Scale spike needed: ~8000 exports = ~8000 instance entries in the component type and a very large synthesized aggregator; untested territory for wac/wasm-tools. Suggested spike: generate a 1000-export component and push it through composition today.
• Tooling status of implements (WIT syntax, wasm-tools support) unverified as of filing.

Status

Future feature idea — not scheduled. Filed so other design work (naming, lockfile format, results schema, SDK shape) keeps it in mind, particularly anything that would make export-name-as-identity or static-features harder later.

[lann]

Design update relevant to this idea's open questions, after review against the component-webcrypto conformance system:

• Q2 (can features be static?) — resolved, yes, globally. Features are now feature marks (<feature> / !<feature>), pure static metadata carried outside the WIT contract (SDK-emitted custom section + lockfile). test-case no longer has a features() method and all() is parameterless. The headline benefit of this issue — execution-free inventory — is no longer blocked on anything: names via export names (this proposal) or all(), marks via the metadata artifact, for both producer formats.
• Q3 (where does missing-features materialization live?) — dissolved. Applicability is a pure predicate over marks × target manifest, evaluable by any layer (runner, synthesizer, offline tooling) without executing anything; excluded cases are reported not-applicable by the scheduler. Negative-marked cases assert feature decline, replacing suite-side materialization entirely. run is feature-blind.
• Q1 (plain-name grammar vs hierarchical names) — still open, and now the only decision-forcing question left for this producer format.

Also relevant: L1 shrank to name + run(ctx) on the case resource, which converges closely with the per-case interface sketched here — the two producer formats now differ mainly in enumeration mechanism, not case shape.

See README "Feature marks" section and updated design commitments (mark predicate, decline-pair lockfile lint, structural features gate suites not cases, state-is-not-a-feature).

[lann]

Name grammar is now normative (README "Case names"): segments are 1–64 bytes of [a-z0-9._-] (never ./..), /-joined, ≤256 bytes, byte-equality identity, duplicates hard-error. Input for Q1: plain export-name labels can't carry / regardless of grammar choice, so this format needs an escaping layer no matter what; that layer must additionally handle _, ., and digit-first segments (all legal in names, all illegal in labels). Parameter-encoding priorities won over label-compatibility.

[lann]

Grammar tightened: non-leaf segments must be valid WIT labels, so hierarchical prefixes project verbatim into nested instance names — this format's escaping layer shrinks to the leaf segment only (where encoded parameters concentrate: _, ., digit-first remain legal there). Q1 is now substantially smaller: define leaf escaping, prefixes are identity.