A check's children hold no cells of their own: the check's cell is the boundary #20

Found while landing a serial gate on the fork (trevato/forge#1101): with one shard at a time the check still failed the same fifty tests the two-shard run did — every test that deploys an app inside the test's own forge (meter, apps, apps-adversarial, fork-pull-approval, apps-busy, apps-token, web-apps), each waiting 30 to 60 s for a preview or production that never answers. Inside a check cell the host says it can hold a cell, so the forge the tests boot wraps its apps in cells nested in the check's own, and those never come up. The Forgejo runner has no bwrap, runs the same apps as plain processes, and is green: the gate was only ever green where there were no nested cells.

The rule: a cell inside a cell is not a cell. The check's own cell is the boundary; its children run as plain processes. checks/service.ts puts FORGE_CELLS=off in the check step's environment, the cell tests in test/contain.test.ts stand aside when told so (as they already do on a host without bwrap), and a new case in test/checks.test.ts runs a check whose command reads $FORGE_CELLS and proves it is off.

No manifest has to know: once this is live, the FORGE_CELLS=off the fork's forge.json carries for now comes out again.

Nested cells not answering is still a real thing to understand (an app's egress relay inside an already-unshared network namespace is my guess); I did not chase it here, since the gate's children never needed their own cells.

🤖 Generated with Claude Code