# step: fleet · wai-rs and fleet_verify.py
# order: 440
# features: fleet
# paths: wai/extensions/fleet.md
# independent: fleet live python3 -I live-conformance/fleet_verify.py live-conformance/fleet
#
# wai.delivery.fleet (extensions/fleet.md): the reference module's unit tests (the enrolment's
# rules, a summary line split only in the relay's form, a row summed across classes told from
# a wrong one, the four coverages) and tests/fleet.rs (vectors.json regenerates byte for byte
# from its seeds and the metering corpus and no other file is there; wai-rs gives every
# vector its stated outcome; every reason of §10 and every reused code refuses a vector; the
# accepted vectors state measured, unmetered and partial energy as §5.4 does; the week's
# records held as a service holds them sign the corpus's report byte for byte; §10 lists
# exactly the reference's codes); and, in the step of every independent verifier above, the
# corpus's second implementation, fleet_verify.py,
# written from the extension's text and sharing no code with wai-rs, which reads per-hop
# records with live_metering_verify.py, checks every signature with WAI's strict Ed25519
# rule, recomputes every line, row, unmetered count and citation, requires every mutated
# copy of the corpus to fail, and drops each of its own checks in turn and requires the
# corpus to catch the weakened verifier; standard library only, run isolated (-I). The
# service and its smoke checks over HTTP run in wai-fleet.yml.
#
# The paths this step brings to the workflow's trigger, and why:
# wai/extensions/fleet.md: tests/fleet.rs requires this extension's §10 to list the codes the
#   reference reports, fleet_verify.py reads that table, and the registry's wire identifiers test
#   reads its sections. Its corpus is generated from the metering corpus, under the paths above.
set -euo pipefail
(cd wai-rs && cargo test --no-default-features --features "$WAI_FEATURES" --lib fleet::)
(cd wai-rs && cargo test --no-default-features --features "$WAI_FEATURES" --test fleet)