docs(adr): ADR-0028 — Principle II forbids network dependence, not availability

[mbeacom]

What

Resolves an ambiguity in Constitution Principle II and records a single bounded exemption, unblocking feature 010's T093.

The finding

T093 discharges FR-050, whose second conjunct reads "network access is permitted only during dependency installation". That is false while bun test runs with ambient network, and it cannot be made true by effort: the suite contains the two-sided controls that prove the denial mechanism works, and a control that establishes denial cannot itself run under denial.

Wrapping it was attempted on both platforms and fails differently on each, which is what makes the obstruction structural rather than a macOS quirk:

Platform	Result
macOS sandbox-exec	denies loopback outright — 3 tests fail with Failed to start server
Linux unshare --net	brings lo up so that failure does not occur — 11 fail instead, because the denial-proving tests must nest a sandbox inside the one already wrapping them

The real problem is that FR-050 is stricter than the law it cites. Principle II tests dependence in three places and availability in one:

Principle II text	Tests
"MUST require no credentials, no running services, and no network access"	dependence
"Network-dependent tests and runtime behavior are forbidden"	dependence
"a change that makes any post-install gate … require … a network call is a defect"	dependence
"the install exception is limited to bun install --frozen-lockfile"	availability

bun test satisfies all three of the first kind — nothing in the suite reaches the network, and it passes with the network gone — and fails the fourth. FR-050 restated the principle using the fourth reading and presented it as a faithful derivation. So a task has been blocked by a feature requirement that overstates ratified law, with the record of that living in a task comment rather than a decision.

The decision

Principle II's operative test is dependence, not availability. A post-install step is compliant when it neither requires nor uses the network, whether or not one happens to be reachable. This changes no observable behavior — every gate that was green stays green, and no step gains permission to use a network it could not use before.

The bun test step of clean-clone-builds is recorded as the single authorized exemption, bounded by four conditions that must all hold or it lapses:

1. Named where it occurs — an unwrapped step not recorded here is a defect, not an instance of this record
2. Justified by the nesting obstruction, not convenience — if the denial-proving controls leave the suite, the exemption ends with them
3. Every other post-install step stays wrapped; a second exemption requires its own record
4. Ambient availability is permitted; use is not — a test that reaches the network remains a defect under Principle II's binding clauses

FR-050 is amended by reference, the same mechanism ADR-0014 used for ADR-0012 and ADR-0013. Its remainder — no credential, no running service, nothing required by build, test, or generator invocation — stands unchanged and unweakened.

Options recorded, including the one refused

Option D — wrap the step and delete the denial-proving controls is named in the record as considered and refused. It would satisfy the letter by removing the evidence that makes every other wrapped step meaningful, trading real assurance for a green checkbox. It is written down so a future reader can see it was rejected rather than overlooked.

Option B (fix FR-050 silently in the spec) was rejected because Principle II's fourth bullet genuinely supports the stricter reading — this is a choice between two live readings of ratified law, and resolving that inside a feature spec is how a constitutional interpretation gets made by whoever happened to be writing a requirement that day.

Option C (split T093) defers the decision and leaves the next feature citing Principle II with the same ambiguity and the same stall.

Verification

The 13-of-14 figure was counted from the workflow, not asserted. The clean-clone-builds job has 17 steps: 3 pre-install, 14 post-install, of which 13 reference run-network-denied.ts in their run command and exactly one does not — the bun test step this record names.

• adr lint — 28 records, 0 errors, 0 warnings
• adr queue — empty (this record is accepted, ratified by @mbeacom)

Follow-on

The four action items are tracked in the record and land in #98: amend FR-050 to cite this record, close T093 on the runner evidence, name the exemption in the workflow step, and state it as one step of fourteen wherever job coverage is described — never as "every step is denied".

[Copilot]

Pull request overview

Records ADR-0028’s interpretation of Constitution Principle II and a bounded bun test exemption.

Changes:

• Defines network dependence as the operative compliance test.
• Documents the single exemption, constraints, alternatives, and follow-up work.

Suppressed comments (2)

docs/adr/0028-read-principle-ii-as-forbidding-network-dependence-and-exempt-the-step-that-proves-denial.md:87

• This factual claim contradicts the control that motivates the ADR. PR #98's probe deliberately fetches its loopback listener and asserts the unsandboxed result is CONNECTED; this ADR also records that the full suite fails under both denial wrappers. Distinguish external-network dependence from the intentional hermetic loopback access instead of claiming that nothing reaches the network or that the suite passes with it gone.

Three statements test whether a step *depends on* the network. One tests whether
the network is *available to* it. `bun test` satisfies all three of the first
kind — nothing in the suite reaches the network, and it passes with the network
gone — and fails the fourth.

docs/adr/0028-read-principle-ii-as-forbidding-network-dependence-and-exempt-the-step-that-proves-denial.md:99

• The named suite does not satisfy this operative test as written: PR #98's denial control intentionally makes an unsandboxed loopback request, while condition 4 later says any test that reaches the network is a defect. Define the rule in terms of external network/egress with an explicit hermetic-loopback allowance, or make that specific control access part of the exemption; otherwise the ADR immediately classifies its own justification as noncompliant.

**Principle II's operative test is dependence, not availability. A post-install
step is compliant when it neither requires nor uses the network, whether or not
one happens to be reachable. The `bun test` step of `clean-clone-builds` is
recorded as a named, bounded exemption from the availability reading.**

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.