actions/setup wiring for wizen (#85): smoke the installed-tools path

.github/workflows/ci.yml

@@ -111,7 +111,9 @@ jobs:
   # consumer Cargo.lock pins this very commit, the action installs the
   # tools from the checkout (source-path), and its pins gate must hold
   # the fixture to that rev. Asserts the advertised outputs and bin
-  # names on top.
+  # names, then drives the installed binaries over a built suite the
+  # way a consumer's CI would — including the wizen path (#85), which
+  # ships inside the CLI rather than as a separate tool.
   actions-setup-smoke:
     runs-on: ubuntu-latest
     timeout-minutes: 20
@@ -152,3 +154,27 @@ jobs:
           test "${{ steps.setup.outputs.rev }}" = "${{ github.sha }}"
           test -x "${{ steps.setup.outputs.bin }}/component-test"
           test -x "${{ steps.setup.outputs.bin }}/ct-runner"
+
+      - name: Build the synthetic consumer's suite artifact
+        run: cargo build --target wasm32-wasip2 --release -p sample-suite
+
+      - name: Exercise the installed tools on the suite
+        # The post-setup consumer path, via the installed binaries only
+        # (no wac, no wasmtime CLI in this job): wizen the artifact
+        # (#85 — one line in a consumer's CI), hold the committed
+        # lockfile against it (inventory survives pre-init, finding
+        # #22), then reproduce both runner goldens from it — the
+        # host-embed runner and the CLI's composed `run` leg.
+        run: |
+          set -euo pipefail
+          bin="${{ steps.setup.outputs.bin }}"
+          suite=target/wasm32-wasip2/release/sample_suite.wasm
+          wizened="$RUNNER_TEMP/consumer/sample_suite.wizened.wasm"
+          "$bin/component-test" wizen "$suite" -o "$wizened"
+          "$bin/component-test" lock "$wizened" --check components/sample-suite/tests.lock
+          out=$("$bin/ct-runner" "$wizened") && code=0 || code=$?
+          test "$code" -eq 1
+          diff expected/verify-embed-sample.txt <(printf '%s\n' "$out")
+          out=$("$bin/component-test" run --jsonl "$wizened") && code=0 || code=$?
+          test "$code" -eq 1
+          diff expected/verify-compose-sample.jsonl <(printf '%s\n' "$out")

actions/README.md

@@ -32,6 +32,23 @@ fails the run (branch/tag refs skip with a notice).
 `source-path: .` installs from a checkout instead of `--git` (used by
 this repository's own CI smoke, and the local-override analogue).
 
+The installed CLI carries the whole composition/execution surface —
+`wizen` (pre-initialize large suites, #25/#85), `compose-runner`, and
+`run` (embedded reference provider, runner core, and wasmtime) — so a
+consumer pipeline that only needs the composed path installs no wac
+and no wasmtime. Wizening in CI is one line after setup, on the built
+artifact:
+
+```sh
+target/ct-tools/bin/component-test wizen suite.wasm -o suite.wasm
+```
+
+(Run the wizened artifact everywhere downstream — runners and
+`lock --check` alike; mixing artifacts is the failure mode.) There is
+deliberately no `wizen:` input on this action: setup runs before the
+consumer's suite artifacts exist. When a run-suite action materializes
+(below), wizening belongs there as an input.
+
 ### The local half: one canonical `_ct-tools` recipe
 
 CI is only half the bootstrap; local `just` runs need the same tools.
@@ -112,7 +129,8 @@ red. The action adds presentation, never verdict.
 - **run-suite** (execute a suite artifact on a runner kind, upload
   results): deliberately parked until a second consumer exists — the
   generic/specific line for SUT-linked drivers, artifact caches, and
-  browser-leg fallbacks is not knowable from one data point.
+  browser-leg fallbacks is not knowable from one data point. #85's
+  `wizen: true` flag lands here as an input when it exists.
 - **publish-viewer** as a *reusable* action: the viewer deploy is a
   workflow in this repository for now (`.github/workflows/pages.yml`);
   generalizing it needs the same second data point.