FABRIC-2.md Section U fourth addendum: user-role tiers, and snakeoil

cert resolves Milestone 7's bootstrapping question for dev/test builds

Three distinct user-role tiers clarified (builder+dev, SDK-only dev,
no-SDK user) -- refines the trust-tier question beyond a simple core/
contrib boundary. More importantly: a snakeoil cert embedded directly
into each build (not loaded as a capsule, not verified against an
external CA at boot) is the actual answer to the CA-bootstrapping
problem Section X's Milestone 7 punch-list surfaced, at least for dev/
test builds -- trust is established at build time, sidestepping the
runtime chicken-and-egg entirely for that case. Two paths into a build
confirmed: snakeoil-signed, or code review + inclusion in the source
repo -- the latter likely makes at least one of Milestone 8's four
spitballed trust-tier directions (signature-authority tiers)
redundant, worth revisiting before picking one.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-2.md

@@ -2738,6 +2738,38 @@ virtio-blk's build-out for comparison.
   QEMU-vs-real-hardware conditional rather than uniformly strict everywhere, which is plausibly
   *why* item 15's assumption was worth stating up front.
 
+**Fourth addendum — user-role tiers, and the snakeoil-cert answer to Milestone 7's
+bootstrapping question, 2026-08-22:**
+
+19. **Three distinct user-role tiers, not just "core" vs. "contrib."** (a) Builder+dev —
+    builds the kernel/toolchain itself and develops capsules (Captain Bob's own role). (b)
+    Dev — uses only the FORTH SDK (`capsules/sdk.4th`) to author capsules, doesn't build the
+    kernel. (c) A user with no SDK at all — presumably runs pre-built capsules only, no
+    authoring capability. This refines the trust-tier question from item 17/spitball above:
+    it's not a single core/contrib boundary, it's at least three capability levels.
+20. **Snakeoil cert, embedded per-build — this resolves Milestone 7's open bootstrapping
+    question, at least for dev/test builds.** Every capsule and named blob gets signed with a
+    "snakeoil" cert (the standard term for a self-signed, non-production dev/test
+    certificate) that is itself embedded directly into each build — not loaded as a capsule
+    at runtime, not verified against an external CA at boot, part of the trusted build
+    process itself. This sidesteps the "how does the CA public key get into the kernel
+    without being just another unverifiable capsule" problem Milestone 7 raised, for the
+    dev/test case specifically: there's no runtime verification-against-external-root step at
+    all for snakeoil-signed content, because trust is established at build time, not boot
+    time. The real external-CA chain from Section U items 10-14 presumably still applies for
+    genuinely distributed/production builds; snakeoil is the dev/test answer, not a
+    replacement for it.
+21. **Two paths into a build, nothing else.** A capsule or named blob makes it into a build
+    only by (a) being signed with the build's own snakeoil cert, or (b) going through code
+    review and inclusion in either the build or the single source repo. This substantially
+    simplifies Milestone 8's still-open trust-tier decision (item 17's spitballed
+    directions) — "in the reviewed source repo" is itself the trust signal for
+    production-track content, rather than needing a separate signature-authority-tier scheme
+    layered on top. Worth revisiting Milestone 8's punch-list items against this before
+    picking one of the four originally-spitballed directions; at least one of them
+    (signature-authority tiers) may now be redundant with "repo inclusion already is the
+    review gate."
+
 ---
 
 ## V. Gap analysis — Artemis home-blocks/thumbdrive/PKI subsystem, 2026-08-22