diff --git a/FABRIC.md b/FABRIC.md
index c6a2783..ed15281 100644
--- a/FABRIC.md
+++ b/FABRIC.md
@@ -1508,14 +1508,26 @@ decides where work goes; that remains capability-based routing.
 
    Her mass is still whatever §20.4 resolves for VMs generally. Pinning governs whether she
    can depart, not how much room she takes.
-4. **Does the nesting recurse further?** A VM's Stadium holds patrons; if one of those
-   patrons were itself a VM, the structure is a tree rather than two levels. Nothing
-   currently requires this, and §11 would call it speculative generality — but it should be
-   ruled out deliberately, since the boot order in §6 does not forbid it. Still open as
-   item 1.7. **Not the same question as §8's `contains` chains (item 1.1, resolved)** — those
-   are same-Stadium patron-holds-patron relationships, bounded to depth 5, and do not create
-   a second Stadium. This item is specifically about a patron *being* a VM with its own
-   nested Stadium underneath it.
+4. ~~**Does the nesting recurse further?**~~ **RESOLVED by item 1.7 (§25.2), 2026-08-04.**
+   A VM's Stadium holds patrons; if one of those patrons were itself a VM, the structure is
+   a tree rather than two levels. Nothing currently requires this, and §11 would call it
+   speculative generality — but it should be bounded deliberately, since the boot order in
+   §6 does not forbid it.
+
+   **Not the same question as §8's `contains` chains (item 1.1)** — those are same-Stadium
+   patron-holds-patron relationships, bounded to depth 5, and do not create a second
+   Stadium. This is specifically about a patron *being* a VM with its own nested Stadium
+   underneath it.
+
+   **Resolution: bounded by a Kconfig-tunable cap, default 2 — not a hard "never."**
+   Consistent with how item 1.1 treated its own depth question rather than declaring a
+   permanent architectural prohibition. 2 matches what §21 already decided and what already
+   exists: the outer Stadium (patrons: VMs) and each VM's own inner Stadium (patrons: words,
+   blocks, ACLs, messages). Nothing today drives a third level, so 2 is the honest default,
+   not a padded estimate. The cap is enforced explicitly at VM-birth time — birthing a VM
+   whose own Stadium would sit at a depth beyond the configured cap is refused, the same
+   "explicit refusal over silent/emergent behaviour" discipline item 1.5 used for the outer
+   bound — rather than left as an unstated assumption nothing checks.
 
 ---
 
@@ -2401,9 +2413,15 @@ document and committing that amendment as its own item.*
   > collapse to heat alone, discarding the starved-vs-small diagnostic that's the entire
   > point of §20.4. Full argument in §20.4.
 
-- [ ] **1.7 — Rule out recursion beyond two levels** — deliberately, not by omission.
+- [x] **1.7 — Rule out recursion beyond two levels** — deliberately, not by omission.
   *Refs:* §20.5 #4.
 
+  > **RESOLVED 2026-08-04 — Kconfig-tunable cap, default 2.** Not a hard prohibition:
+  > bounded, same treatment as item 1.1's containment depth. 2 matches §21's already-decided
+  > two-level structure (outer VM Stadium, per-VM inner Stadium). Enforced explicitly at
+  > VM-birth time — a birth that would exceed the configured depth is refused. Full argument
+  > in §20.5 #4.
+
 - [ ] **1.8 — Block content change at migration.** A resident block whose content changed
   has a different hash on the way out. State the hand-off. *Refs:* §24.6 #1.