FABRIC-3.5.md §XXIX: versioning policy closed; LTS deferred with written criteria

Captain Bob proposed odd-major LTS / even-major working, minor for
release, patch for working builds, CI build number appended later, and
asked directly whether this release is the first fully production-ready
one, inviting disagreement.

Policy closed here; LTS designation deferred, with criteria written down
rather than left to judgement. The disagreement is recorded plainly
because it was asked for, and rests on five findings rather than taste.
§XIV is open and was reproduced live by §XXXI's rerun -- near-simultaneous
thumbdrive attach silently dropped 6 of 9 identities with every device
confirmed present at the host level, which is the identity-attach path
failing silently. It has never booted on real hardware, which is
FABRIC-3's whole topic and what v2.2.0 and v2.5.0 are reserved for. ACL
Phase 8 is the open item. At tag time the reshuffle is brand-new code, and
LTS normally means soaked rather than freshly rewritten. And §XXV.4
expects formal coverage to contract at this tag, which is the wrong
moment to claim maximum stability to a licensee or patent audience.

The precedent is the project's own: §I.2 rolled the version back for
claiming ahead of the real state, and "first fully production ready" is a
much larger claim than 2.0.1 was.

Offers the constructive form instead of a refusal -- make LTS a test, the
same move §XV.2 and §XXVII already used to better effect than judgement.
Five criteria proposed; the first tag meeting them takes the odd major.

Flags three conflicts in the new scheme while closing it: the minor
position already carries QEMU-versus-hardware semantics with v2.5.0
already planned, odd/even major collides with major-means-breaking, and
an odd major lands LITHOS_VERSION on 3.0.0 where the engine string
already lives. Recommends SemVer build metadata for CI numbers rather
than a fourth dotted field, since the SBOM is syft-generated SPDX and
X.Y.Z.N is not valid SemVer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP

FABRIC-3.5.md

@@ -2760,3 +2760,111 @@ be resurrected from memory.
 
 **Every design question is ruled and the release number is set.** What remains is execution,
 one engine-version call, and the close.
+
+---
+
+## XXIX. Versioning policy closed; the LTS designation deferred with written criteria (2026-09-19)
+
+Captain Bob proposed a revised scheme — **odd major = LTS, even major = working line; minor =
+release; patch = working builds; CI build number appended once CI is exposed** — and asked
+directly whether this release deserves an LTS number as "the very first fully production ready
+version," inviting disagreement and noting the policy should be closed either way.
+
+**Policy: closed here. LTS designation: deferred, with the criteria written down rather than
+left to judgement.** The reasoning below is the disagreement, stated plainly because it was
+asked for.
+
+### XXIX.1 — Why not LTS at this tag: five findings, not an opinion
+
+1. **§XIV is open, and was reproduced live after being filed.** "Concurrent WIREBIND attach
+   detection gap — found live, **NOT fixed**, flagged for later" (2026-09-11). §XXXI then
+   caught it again on the post-Stage-4 rerun: near-simultaneous thumbdrive attach meant **6 of
+   9 identities silently never triggered `WIREBIND: <id> attached` at all**, with QMP
+   `query-block` confirming every device was genuinely present. That is the **identity-attach
+   path** — how humans get into the system — failing silently and reproducibly. It is not a
+   corner case, and "silently" is the part that disqualifies it.
+2. **It has never booted on real hardware.** That is `FABRIC-3.md`'s entire declared topic, and
+   the roadmap reserves `v2.2.0` (amd64 bare-metal) and `v2.5.0` (hardware release) for it.
+   "Production ready" invites the question *production on what?*
+3. **ACL Phase 8 is open** — PKI / thumbdrive, Ed25519 challenge-response, user minting by
+   Zuse: "⬜ **This is the open item — pick up here next**" (`.claude/CLAUDE.md`). That is the
+   last mile of the security story, and the security story is much of the production claim.
+4. **At tag time this reshuffle is brand-new code.** Kernel-Hermes is greenfield C (§XIV.1),
+   Hestia is a new VM, `BIRTH` is newly general, the latch is new. **LTS normally means
+   soaked — years of support promised on something proven.** Declaring it at the moment of a
+   structural rewrite inverts the word. The reshuffle is an excellent reason to tag; it is a
+   poor reason to call the result long-term-stable.
+5. **§XXV.4: formal coverage likely decreases at this tag**, as messaging moves from modelled
+   FORTH to file-scope C statics. For the audience an LTS label is aimed at — licensees,
+   SSRN, patent support — the proof story is load-bearing, and this is the wrong moment to
+   claim maximum stability while the verified boundary contracts.
+
+**And the precedent is this project's own.** `FABRIC-3.md` §I.2 rolled `LITHOS_VERSION` *back*
+from 2.0.1 because the label "got ahead of the real state." **"First fully production ready" is
+a far larger claim than `2.0.1` was.** The same instinct that caught that one should catch this.
+
+### XXIX.2 — The constructive form: make LTS a test, not a judgement
+
+This document has twice turned a judgement into a structural fact and got a better answer both
+times (§XV.2's death, §XXVII's empty floor). Same move here. **Proposed LTS criteria, to be
+ratified as part of the policy:**
+
+A tag may take an **odd (LTS) major** only when **all** hold:
+
+- **Real-hardware boot demonstrated** on at least the amd64 reference board, with logs
+  committed as audit artifacts (the existing acceptance standard, extended off QEMU).
+- **No known-reproducible silent-failure defect open** — §XIV's class specifically: a failure
+  that produces no error and is caught only by inspection.
+- **ACL Phase 8 closed**, or its absence explicitly scoped out of the LTS claim in writing.
+- **The `proof/` boundary restated and not contracted** relative to the prior LTS (§XXV.3).
+- **A soak**: the architecture unchanged for at least one full release cycle before the LTS
+  tag — LTS follows stability, never announces it.
+
+Then **the first tag meeting them takes the odd major**, and nobody has to decide whether it
+feels ready.
+
+**So: `2.1.0` stands as ruled (§XXVIII) — even major, working line, correct under both the old
+and new schemes.** LTS is not refused, only sequenced.
+
+### XXIX.3 — Three conflicts in the new scheme, to resolve while closing it
+
+1. **The minor position is already taken, and by a live plan.** The current policy uses *minor*
+   for QEMU-vs-hardware (`X.0.0` = QEMU release, `X.5.0` = hardware bare-metal release), and
+   **`v2.5.0` is already on the roadmap**. The new scheme wants minor = "release version."
+   Both readings cannot hold. **Adopting the new scheme retires `X.5.0` semantics and must say
+   so explicitly**, or `v2.5.0` becomes ambiguous the day it is cut.
+2. **Odd/even major collides with "major = breaking change."** Binding the major to LTS-ness
+   means a breaking change inside the working line cannot be expressed without also flipping
+   LTS status, and an LTS line cannot take a breaking fix without ceasing to be LTS. Node and
+   the pre-2.6 Linux kernel both used this shape and both paid for it. **Worth choosing
+   deliberately**: either accept that majors no longer signal breakage, or move LTS-ness out of
+   the version number (a tag suffix, a channel name) and leave the major for compatibility.
+3. **`3.x` is already in use, by the other string.** `VERSION ?= 3.1.0` is the embedded engine.
+   If `LITHOS_VERSION` takes an odd major it lands on **3.0.0** — two different `3.x` values in
+   the same generated `include/version.h`. Not fatal, since they are separate fields, but
+   confusing at precisely the moment a release wants to be legible. **Flag before, not after.**
+
+### XXIX.4 — CI build numbers: use SemVer build metadata, not a fourth field
+
+Specific because it interacts with something already shipped. `sbom.spdx` / `sbom.spdx.json` are
+generated by **syft** and consumed as SPDX (§XXVI.2), and SPDX/SemVer tooling parses
+`X.Y.Z+build.N` correctly while `X.Y.Z.N` is not valid SemVer — it sorts wrongly or is rejected
+outright.
+
+**Recommendation: `2.1.0+ci.1234`.** Build metadata is ignored in precedence comparison, which
+is exactly right for a build number: two builds of the same source rank equal, and the SBOM
+stays machine-readable for the licensee and patent audiences it exists for.
+
+### XXIX.5 — What this section rules and what it leaves open
+
+- ✅ **Policy closed** as §XXIX.2–XXIX.4, subject to Captain Bob ratifying the three conflicts
+  in §XXIX.3.
+- ✅ **`2.1.0` stands** (§XXVIII) — even major, working line.
+- 🔶 **LTS deferred, not refused.** Criteria written (§XXIX.2); the first tag meeting them takes
+  the odd major.
+- ⬜ **Captain Bob to rule on §XXIX.3's three conflicts**, and on the engine `VERSION` string
+  (§XXVIII.4).
+
+**The disagreement is narrow and worth stating once more so it is not mistaken for reluctance:
+the work is real and the tag is deserved. What is not yet earned is the word *long-term
+stable*, on code that will be new the day it ships.**