Conformance group: running a command inside a sandbox (008 T005).

Every limit check breaches, and nothing here inspects configuration

003-FR-012a is the rule and 005 R9b is the reason:

taskpolicy -m 100 sandbox-exec -f profile.sb ./hog 300

allocates 300 MB under a nominal 100 MB cap and exits 0. The limiter was invoked, with the right flag and the right number, and the cap is silently lost across the intervening exec. So a check that asserted execute/3 passed the cap along, or that the launch names it, or that the command exited cleanly, would certify that composition as conformant.

Each check here therefore runs a hostile command through the seam and requires the mechanism to show it was stopped. An attempt that neither completed its hostile act nor was visibly stopped is the third outcome — host capability unavailable — never a pass (FR-012b).

The check that is not about a limit at all

execute/3 against a destroyed sandbox must answer {:error, {:could_not_run, _}}. A mechanism that answers with a non-zero exit status instead has converted an unperformed check into a failed one, and 008-FR-026 says a failed check spends a refinement iteration that an unperformed one must not. That defect is invisible from every layer above: both shapes are "the verification did not pass", and only here can the two be told apart — which is why the check lives in the conformance suite rather than in 008's own tests.

Separation and truncation are checked by producing them, not by reading a doc

A command writes a known string to stderr and a different one to stdout, and the check requires each to arrive in its own field. 015 R17 measured MuonTrap's :logger_fun corrupting lines past a 256-byte buffer, so the long-line check emits a single line an order of magnitude past that and requires it back byte-identically: a mechanism whose capture reframes output into lines fails here rather than in someone's build log.