ExSandbox.Conformance (ExSandbox v1.0.1)

Copy Markdown View Source

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 observesVerdict
Breach attempted, stopped✅ guarantee holds
Breach attempted, not stopped❌ mechanism failed
Breach cannot be attempted on this host⚠️ capability unavailable
Mechanism present, breach never attemptednot 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.