FABRIC-2.md Sections U/X: correct the snakeoil-cert chain -- one

continuous chain, not two parallel paths; resolves Milestone 7's
bootstrapping question precisely, not just for dev/test

Captain Bob's precise correction: "my own real root CA -> snakeoil
embedded cert -> blob & capsule + MANIFEST.md" is one chain. The
snakeoil intermediate is CA-signed, not self-signed/untrusted --
"snakeoil" names its informal/private-project status, not that it
lacks a real trust root. This means Milestone 7's CA-bootstrapping
question (how does the CA public key get into the kernel without
being just another unverifiable capsule) is resolved outright, not
just worked around for dev/test builds as the previous draft of
Section U's fourth addendum implied: trust is established once, at
build time, by whoever holds the real root CA and produces the build.
No kernel-boot-time verification against a hardcoded CA public key is
needed at all. Corrected both Section U item 20 and Milestone 7's
punch list in Section X to match.

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

FABRIC-2.md

@@ -2747,23 +2747,26 @@ bootstrapping question, 2026-08-22:**
     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
+20. **Corrected, precise chain (Captain Bob's exact words): "my own real root CA →
-    question, at least for dev/test builds.** Every capsule and named blob gets signed with a
+    snakeoil embedded cert → blob & capsule + MANIFEST.md."** This is one continuous chain,
-    "snakeoil" cert (the standard term for a self-signed, non-production dev/test
+    not two separate paths as the previous draft of this item implied. The "snakeoil" cert is
-    certificate) that is itself embedded directly into each build — not loaded as a capsule
+    not self-signed or independently trusted — it's an intermediate certificate signed by
-    at runtime, not verified against an external CA at boot, part of the trusted build
+    Captain Bob's own real root CA (a real root he controls, "snakeoil" here naming its
-    process itself. This sidesteps the "how does the CA public key get into the kernel
+    informal/private-project status, not that it's untrusted or self-signed), and *that*
-    without being just another unverifiable capsule" problem Milestone 7 raised, for the
+    signed intermediate is what gets embedded into each build and does the actual per-blob/
-    dev/test case specifically: there's no runtime verification-against-external-root step at
+    per-capsule signing. This resolves Milestone 7's bootstrapping question precisely, not
-    all for snakeoil-signed content, because trust is established at build time, not boot
+    just "for dev/test": the CA public key never needs to get into the kernel at boot at all,
-    time. The real external-CA chain from Section U items 10-14 presumably still applies for
+    because the intermediate cert is already CA-signed and embedded at build time — trust is
-    genuinely distributed/production builds; snakeoil is the dev/test answer, not a
+    established once, at build time, by whoever controls the root CA and produces the build,
-    replacement for it.
+    not re-verified against an external root every boot. `MANIFEST.md`/`MANIFEST_AUTO.md` is
+    explicitly named as part of this same chain, not a separate tracking system bolted on
+    after — matching item 12's existing finding that its xxHash64 column is already the
+    documented Ed25519 anchor point.
 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
+    only by (a) being signed via the chain above (the embedded, CA-signed intermediate cert),
-    review and inclusion in either the build or the single source repo. This substantially
+    or (b) going through code review and inclusion in either the build or the single source
-    simplifies Milestone 8's still-open trust-tier decision (item 17's spitballed
+    repo. This substantially simplifies Milestone 8's still-open trust-tier decision (item
-    directions) — "in the reviewed source repo" is itself the trust signal for
+    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
@@ -3233,18 +3236,20 @@ RAMDRIVE/DISK devices first without waiting for USB).
 
 ### Milestone 7 — Kernel/capsule PKI signing chain (Section U items 10-14, Section V area E)
 
-- [ ] Generate (offline, outside the kernel/repo entirely) the CA root keypair — "stays
+- [ ] Generate (offline, outside the kernel/repo entirely) the real root CA keypair — "stays
       unrevocable," never embedded, never loaded by any kernel code
-- [ ] Generate an intermediate certificate, signed by the CA
+- [ ] Generate the "snakeoil" intermediate certificate, signed by that real root CA (Section
-- [ ] Embed the intermediate cert as a capsule blob (mechanically proven already via the
+      U's fourth addendum: this is a real CA-signed intermediate, not a self-signed/untrusted
-      font-capsule precedent — no new embedding infrastructure needed, just a new payload)
+      cert despite the name — "snakeoil" names its informal/private-project status)
-- [ ] Implement kernel-boot-time verification of the embedded cert against a hardcoded CA
+- [ ] Embed the already-CA-signed snakeoil intermediate as a capsule blob at build time
-      public key (the CA key itself has to be baked into the kernel some way that isn't
+      (mechanically proven already via the font-capsule precedent — no new embedding
-      "just another capsule," since capsules are exactly what's being validated — this is a
+      infrastructure needed, just a new payload) — **bootstrapping question resolved (Section
-      real bootstrapping/chicken-and-egg design question not yet addressed anywhere in
+      U fourth addendum): there is no kernel-boot-time verification of a hardcoded CA public
-      Sections U/V/W)
+      key needed at all.** Trust is established once, at build time, by whoever holds the real
+      root CA and produces the build — the embedded intermediate is already signed before it
+      ever reaches the kernel, so there's no runtime chicken-and-egg to solve.
 - [ ] Implement per-capsule signature verification (Ed25519) at capsule-load time, checked
-      against the now-verified intermediate cert
+      against the embedded (already-trusted) intermediate cert directly
 - [ ] Add a signing step to the `mkcapsule` build tool (or a separate signing tool) that
       produces a signature alongside each capsule's existing xxHash64
 - [ ] Extend `MANIFEST_AUTO.md`'s generation to add a signature-status column, matching the