# `ExSandbox.Conformance`
[🔗](https://github.com/FoundryStack/ex_sandbox/blob/v1.2.0/lib/ex_sandbox/conformance.ex#L1)

The conformance suite every mechanism is held to (012 T030–T035, FR-010).

    defmodule MyMechanismConformanceTest do
      use ExSandbox.Conformance, mechanism: MyMechanism
    end

It runs under **the consumer's own ExUnit**, in their own project. That shape
is what makes `SC-004` possible: a suite runnable only inside this repository
could never be run against a third-party mechanism at all.

## This suite is authoritative for the capability

If a mechanism needs the suite edited to pass, that is evidence the *contract*
leaked a mechanism assumption. **Fix the contract, not the test.** A suite that
bends to accommodate each mechanism measures nothing, and the guarantee it
claims to enforce quietly becomes whatever the last mechanism could manage.

## There are no exclusions (`FR-011`)

No skip flag, no exclusion tag, no mechanism allowlist. `ExSandbox.ConformanceExclusionsTest`
greps this file's source to keep it that way. The check is blunt on purpose —
the requirement is absolute, so a nuanced check would only be a way to argue
about it.

## The one legitimate non-run, and the trap beside it

A check needing a host capability that is absent reports **host capability
unavailable** — a third outcome, distinct from pass and fail. That is not an
exclusion: the consumer cannot request it, `ExSandbox.Capability` determines it
at runtime, and it is reported rather than hidden.

Research R7a found a fourth state that is worse than any of these, because it
is **indistinguishable from success**:

| Suite observes | Verdict |
|---|---|
| Breach attempted, stopped | ✅ guarantee holds |
| Breach attempted, **not** stopped | ❌ mechanism failed |
| Breach cannot be attempted on this host | ⚠️ capability unavailable |
| Mechanism present, breach **never attempted** | ❌ **not evidence** — unavailable |

The fourth row is `FR-012b`. `005` R9b measured it: `taskpolicy -m 100
sandbox-exec … ./hog 300` allocates 300 MB under a nominal 100 MB cap and
**exits 0**, because the limit is silently lost across the intervening exec.
No error, no warning, nothing observably different from a correct invocation
except that the cap does not exist.

A suite asserting *the limiter was invoked with the right arguments* passes
that. So would one asserting the wrapper appears in the process tree, or that
configuration names the cap. **Every formulation short of "trigger a breach
and observe it stopped" accepts the defect as conformant** (`FR-012a`).

That is why every resource-limit check below breaches the cap.

---

*Consult [api-reference.md](api-reference.md) for complete listing*