(sigil env manifest)

Read ordinary Sigil top-level forms. Reading establishes no imports and executes nothing; all forms run later in the bounded child.

A channel is an ordinary Sigil library repository when it has src/. Keep the versioned registry tree as a compatibility source for existing snapshots while channel authors migrate to the normal layout.

The CPU ceiling for a bounded authoring evaluation, in CPU-SECONDS.

It was 5, and 5 was measured to be no margin at all. All figures are CPU-seconds (user+sys, NOT elapsed -- the two diverge precisely under the load where this fails), taken with the dev -O0 compiler, which is the only configuration that can run these commands at all because sigil-test-anchor is declared by the dev and verify configs alone. 16-core box, core-channel's 20 modules:

one process alone 2.41 six concurrent copies 3.87 (1.60x) twelve concurrent copies 7.53 median, range 6.61-8.24 twelve concurrent, at the old 5 9 of 12 SIGKILLed at exactly 5.01

So the old ceiling sat at roughly twice the uncontended cost, and this estate routinely runs a dozen workers. That is why publishing succeeded or failed on machine load rather than on its input, and why the same tree published fine on a quiet box an hour earlier.

30 is 3.6x the worst COLD run ever observed under contention (8.24). The margin is deliberately generous and the asymmetry is the reason: too tight produces a false red on a correct artifact, which has already cost this estate a blocked publish and a security gate that could not run its own setup; too loose lets a runaway loop burn 30 CPU-seconds instead of 5 before being killed. A bound whose job is catching non-termination does not need to be tight.

WHY THE COST IS WHAT IT IS, so the next person does not chase the wrong thing. Almost all of it is INVOKING THE COMPILER AT ALL, not the size of the tree: cold-minus-warm is 1.98 CPU-s for these 20 modules and 2.29 for a fixture with ONE. The one-module case is dearer. So shrinking a channel cannot help -- which is why trimming core-channel from 33 bindings to 16 changed the time not at all.

A PERSISTENT COMPILE STORE WOULD CUT THIS BY ~5x AND IS DELIBERATELY NOT HERE. It was written, measured (0.46 CPU-s warm against 2.41 cold) and withdrawn in adversarial review: promoting a child's cache into a shared store hands a hostile channel.sgl -- which runs arbitrary code in this child -- a way to poison an innocent tree's entry, and keying that store on hash-directory would found a new trust boundary on a function since shown to collide. It is a performance optimisation on a path that runs rarely; the budget above is what actually unblocks publishing. Filed separately with the measurements rather than left as folklore.

The wall-clock ceiling, in seconds. It was 10, against a worst observed cold wall of 8.39 s under twelve-way contention -- a 1.2x margin, which would have become the next false red as soon as the CPU ceiling stopped firing first. It exists to bound a child blocked forever on something that consumes no CPU, so it is sized against wall time rather than as a multiple of the CPU budget. The observed wall/CPU ratio stays at 1.00-1.05 even twelve-way, so 120 against 30 tolerates a 4x ratio before the wall would fire first; above that the refusal still says SETUP-FAILED and still exits 75, it just names the wall rather than the CPU.

Run a prepared WRAPPER in the bounded child and return its exit status. The child's compile cache stays inside WORK, so nothing it produces outlives the run.

Classify a bounded child's exit STATUS. Returns #f when it succeeded, or (CODE . MESSAGE) for the caller to refuse with. SUBJECT names what was being evaluated, e.g. "channel evaluation".

WHY THIS EXISTS AND WHY IT IS NOT COSMETIC. The old code reported EVERY nonzero status other than 124 as "evaluation failed within resource boundary". That one message is wrong in BOTH directions and both directions have been observed:

a CPU-budget SIGKILL reads as a defect in the channel or environment under test -- and since a loaded box is the normal condition here, that false red is the COMMON case;

a genuine defect in the curator's own program -- an unbound variable in channel.sgl exits 1 -- reads as a resource problem. This direction fires on real defects rather than only under load, so it has probably been misleading people longer.

Whoever is shown one of these believes it and debugs the wrong artifact. Resource exhaustion is SETUP-FAILED, not RED (topics/gate-setup-failed-vocabulary).

THE STATUSES ARE ENUMERATED FROM MEASUREMENT, not from memory; each was reproduced on this platform before being named here:

124 timeout fired wall clock 137 128+SIGKILL the ulimit -t CPU ceiling 153 128+SIGXFSZ the ulimit -f file-size ceiling 127 could not exec the child setup, not evaluation

AND THE RESIDUAL DOES NOT ASSERT A CAUSE, which is the correction that matters. An earlier draft of this said "NOT a resource limit" for everything else -- but the address-space (-v) and descriptor (-n) ceilings surface as ordinary allocation and open failures with no distinctive status, so that sentence was false for two of the four limits in this sandbox's own header. Narrowing a misattribution and then claiming MORE confidence than the message you replaced is the same defect in better clothes. The residual now names what it cannot tell apart.

Return the exact local module-source closure reachable from SOURCE's ordinary imports. Each entry is (LOGICAL-PATH HASH PHYSICAL-PATH). LOGICAL-PATH is derived from the module name and explicit root order, never from an absolute checkout spelling. Later -L roots win because they are materialized as overlays in that order below.

Returns (RESULT-DATUM . ((ID VERSION SOURCE-HASH) ...)). The child is CPU/address-space/file/fd/time bounded and starts in an empty directory with only verified materialized channel modules passed through -L.

(No description)