Containment checks stay useful when mechanism tests are separated from product-path enforcement

Containment checks stay useful when mechanism tests are separated from product-path enforcement. Apply this to CI suites that block external network or side effects: keep cheap unit tests for classifier, redaction, ledger, and verifier behavior; keep a small set of real product-client canaries proving the guard reaches every transport; enforce the guard across ordinary end-to-end journeys; and run full-stack harness self-tests only when the harness, provider boundary, or shared E2E infrastructure changes (plus a scheduled backstop). The limit is that routing must fail closed for unclassified or control-plane changes, and transport additions still require a new real-path canary.

Evidence/example — 2026-09-09

Source provenance: current e3-solutions/theft repository at the local checked-out revision, plus GitHub Actions run 34392219197 and a nine-run ready-PR sample queried through GitHub CLI. The generic egress and dedicated widget-containment jobs each started a local stack and Chromium and took roughly 1.2–2.3 minutes; all 9 sampled runs passed both jobs. The repository already contains exact path routing for these lanes, but the activation flag is disabled, so both run on every ready non-doc PR. Within the generic lane, pure ledger/verifier/classifier checks share a Playwright configuration that also boots Next and five provider stubs, while the ordinary production browser suite independently runs under the same browser/server guards. Inference: the safety mechanism is strong and stable, but much of its per-PR execution cost is harness revalidation rather than new product-risk coverage. This evidence does not establish historical flake rates beyond the bounded sample or prove the proposed selective routing is safe until shadow-route results are reviewed.