Skip to content

Three export adapters have no system test: export-bazel, export-bazel-distdir, export-sdk #99

Description

@avrabe

REQ-SYSTEST-002 clause 5 says no export adapter ships without a system test. Six ship; three have one.

adapter system gate
export-cargo selfhost.sh — varve's own 250 packages, offline build, negative control
export-crates-vendor selfhost.sh — same
export-vsix deposit-layer.sh — per-platform set, consumer resolves exactly its own
export-bazel none
export-bazel-distdir none
export-sdk none

Why this is filed rather than fixed

The requirement read verified while clause 5 had no enforcement whatsoever — the overclaim this release exists to remove, inside the release. Clean-room review caught it.

The options were: enforce hard (CI red for three adapters until each gets a gate — real work, and unrelated to whatever change happens to trip it), restate the clause as review policy (converts an unmet requirement into a met one by lowering the bar), or ratchet.

Ratchet was chosen. no_new_export_adapter_ships_without_a_system_test enumerates adapters from clap, reads what the gates actually exercise, and compares against a recorded known-uncovered set. It fails when a NEW adapter ships uncovered, and also when an adapter gains coverage while still listed — so the list cannot quietly stop meaning what it says. Verified to bite in both directions.

REQ-SYSTEST-002 is now implemented. It advances to verified when this list is empty.

What each gate needs

  • export-bazel — a real rules_wasm_component registry consumed by an actual Bazel build. Note the related honesty problem: [tool.source].sha256 is emitted as the checksum Bazel enforces and varve never verifies it (now disclaimed in the header and docs). A gate here should assert the disclaimer travels.
  • export-bazel-distdir — zero-network bazel --distdir. Already tracked as feat: v0.10.0 — realms: the pin names its trust universe #27; that issue is this adapter's half of this one.
  • export-sdk — deposit an SDK, export, and RUN the relocated toolchain. The relocation constraint is real (an SDK can only move to a path no longer than the one it was built for), so the gate needs a short destination and should assert the fit check fires on a long one.

The pattern worth noting

The two adapters that DO have gates are the two whose defects were found by those gates — #73 (export-cargo's stub index) was reproduced by selfhost.sh on first contact, and the per-platform payload defect was found by building the real layer. The three without gates are the three whose behaviour we are currently taking on trust.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions