feat(spacecraft-steelbore-standard): §15.1 published, §18.4 at release — v2.07

spacecraft-steelbore-standard/SKILL.md

@@ -17,7 +17,7 @@ website: https://Construct.SpacecraftSoftware.org/
 
 # The Steelbore Standard — Compliance Reference
 
-**Version:** 2.06 | **Date:** 2026-09-15 | **Author:** Mohamed Hammad
+**Version:** 2.07 | **Date:** 2026-09-15 | **Author:** Mohamed Hammad
 **Maintainer:** Mohamed Hammad | **Contact:** [Mohamed.Hammad@SpacecraftSoftware.org](mailto:Mohamed.Hammad@SpacecraftSoftware.org)
 **Copyright:** Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** GPL-3.0-or-later
 **Website:** [https://Construct.SpacecraftSoftware.org/](https://Construct.SpacecraftSoftware.org/)
@@ -989,9 +989,15 @@ When writing Rust code that handles time:
 
 ### §15.1 — Project Pages
 
-Each Spacecraft Software project has a dedicated subdomain following the pattern
-`https://<ProjectName>.SpacecraftSoftware.org/`. Use the project-specific URL in all
-project-level outputs; use `https://SpacecraftSoftware.org/` only for umbrella references.
+Each **published** Spacecraft Software project has a dedicated subdomain following the
+pattern `https://<ProjectName>.SpacecraftSoftware.org/`. Use the project-specific URL in
+all project-level outputs; use `https://SpacecraftSoftware.org/` only for umbrella references.
+
+**Published** means the project has a repository under a namespace Spacecraft Software
+controls (§6.4). The qualifier does real work: a working directory is not a project.
+Vendored upstream forks carried under §4.2, scratch and experiment directories, symbolic
+links into other trees, and reference copies all appear in `PROJECTS.md` — which tracks
+what is *on disk* — and none is published by us or has anything to serve at a subdomain.
 
 | Project                    | URL                                              |
 |----------------------------|--------------------------------------------------|
@@ -1021,6 +1027,23 @@ project-level outputs; use `https://SpacecraftSoftware.org/` only for umbrella r
 | Vacuum                     | https://Vacuum.SpacecraftSoftware.org/           |
 | Docs                       | https://Docs.SpacecraftSoftware.org/             |
 | Loran Pages                | https://Loran-Pages.SpacecraftSoftware.org/      |
+| Achernar                   | https://Achernar.SpacecraftSoftware.org/ |
+| Adit                       | https://Adit.SpacecraftSoftware.org/ |
+| Antigravity 2              | https://Antigravity2.SpacecraftSoftware.org/ |
+| Babel                      | https://Babel.SpacecraftSoftware.org/ |
+| Conduit                    | https://Conduit.SpacecraftSoftware.org/ |
+| Majestic                   | https://Majestic-PRD.SpacecraftSoftware.org/ |
+| Majestic (Fable/Rust Fable) | https://Majestic.SpacecraftSoftware.org/ |
+| Majestic (Guile Fable)     | https://Majestic-Guile.SpacecraftSoftware.org/ |
+| Majestic (Rust Kimi)       | https://Majestic-Rust-Kimi.SpacecraftSoftware.org/ |
+| Majestic (Rust Opus)       | https://Majestic-Rust-Steel.SpacecraftSoftware.org/ |
+| Majestic 4                 | https://Majestic4.SpacecraftSoftware.org/ |
+| MajesticOS                 | https://MajesticOS.SpacecraftSoftware.org/ |
+| Packages                   | https://Packages.SpacecraftSoftware.org/ |
+| Projects                   | https://Projects.SpacecraftSoftware.org/ |
+| Reel                       | https://Reel.SpacecraftSoftware.org/ |
+| Specs                      | https://Specs.SpacecraftSoftware.org/ |
+| Theme                      | https://Theme.SpacecraftSoftware.org/ |
 
 When a new project is created, add its subdomain to this table immediately.
 
@@ -1516,13 +1539,23 @@ Rust GUI work (§3.1 already makes Rust the preferred language).
   and record the ratios (§11).
 - **Keyboard:** complete every primary task without a pointing device.
 
-**Remediation for existing projects.** §18 applies to every project immediately on
-adoption of v1.33, so projects predating it are non-compliant until retrofitted.
-Until a project conforms it MUST carry a **dated remediation entry** in
-`PROJECTS.md` recording its accessibility state and intended remediation. An absent
-entry is itself a compliance failure — a project may be unfinished, but it may not
-be silently unfinished. **Projects registered as games (§18.5) are excluded** —
-they owe no remediation entry, because they owe no conformance.
+**Remediation for existing projects.** §18 applies to every project, and a project
+that does not yet conform is not thereby excused. What changed at v2.07 is *when* the
+paper trail falls due.
+
+A project MUST carry a **dated remediation entry** in `PROJECTS.md` — recording its
+accessibility state and intended remediation — from the moment it **cuts a release tag
+or declares itself usable by anyone other than the maintainer**, and until it conforms.
+An absent entry at that point is a compliance failure in its own right: a shipped
+project may be unfinished, but it may not be silently unfinished.
+
+**Before that point the entry is optional**, and this is a correction rather than a
+relaxation. From v1.33 the obligation attached on adoption, so every pre-release
+experiment owed a dated assessment for existing at all — and at v2.06 exactly one
+project carried one while roughly fourteen owed one. A rule breached universally
+reports nothing about the projects that breach it and buries the one that did the work.
+**Projects registered as games (§18.5) are excluded** — they owe no remediation entry,
+because they owe no conformance.
 
 ### §18.5 — Games Carve-Out
 
@@ -1642,7 +1675,7 @@ Before finalising **any** Spacecraft Software artifact, mentally verify:
 - [ ] **§15.3** Third-party work credited in `CREDITS.md` at project/skill root when triggers apply; deeper `references/ATTRIBUTION.md` present where reference content is adapted from external sources
 - [ ] **§17** Development progress tracked and reported continuously as the §17.1 labelled-row block — one 20-cell bar per track, milestone rows then MVP then TODO/PLAN/PRD, only the rows that apply; every row set in `█`/`░` with tight brackets, columns aligned, no ASCII bars
 - [ ] **§17.4** Every turn that hands control back to the user ends with a two-line `TL;DR:` block in simplified English, placed last: a plain statement of completion when the work is finished and verified, or a question mark naming the actual decision when the user's input is required; never substituted for the detail or the §17.1 block
-- [ ] **§18** Accessible mode implemented and off by default; §18.1 toggle honored with correct precedence; status never color-only; no animation or decorative art in accessible mode; TUI ships a linear mode and a non-interactive CLI path; GUI publishes accessible names and roles (AccessKit for Rust); verified with a real screen reader; existing projects carry a dated remediation entry in `PROJECTS.md` until they conform — N/A for projects registered as games (§18.5), which are exempt in full
+- [ ] **§18** Accessible mode implemented and off by default; §18.1 toggle honored with correct precedence; status never color-only; no animation or decorative art in accessible mode; TUI ships a linear mode and a non-interactive CLI path; GUI publishes accessible names and roles (AccessKit for Rust); verified with a real screen reader; a project that has cut a release or declared itself usable carries a dated remediation entry in `PROJECTS.md` until it conforms, and a pre-release project owes none (§18.4) — N/A for projects registered as games (§18.5), which are exempt in full
 - [ ] **§19** Assurance category (A/B/C/D) declared in `README.md`, `AGENTS.md`, and `PROJECTS.md`, with any raised subsystem named; every *Recommended* obligation of §19.3 that is not implemented carries a dated tailoring-register entry (§19.5) in `COMPLIANCE.md` for Category A and B, or in `README.md` for C and D; the three gates of §19.4 passed with their evidence; the §19.6 conformance claim in `README.md` names the standard version, the category, and whether the claim is full or tailored
 - [ ] **§20** Requirements written at the level §19.3 requires (Texinfo `Requirements` node for A and B, `AGENTS.md` list for C); each carries a permanent identifier, rationale, source, priority, verification method, and status; §20.2 verbal forms used, with `shall` carrying obligation; the §20.4 characteristics gate run over each requirement and over the set; no unmeasurable adjective, open-ended clause, or escape hatch in requirement text (§20.5) — N/A for Category D
 - [ ] **§21** Every requirement declares one of the four §21.1 methods; verification evidence meets the §21.2 floor for the category; the traceability matrix is generated by tooling on every CI run, fails on an unverified requirement or an unknown identifier, and ships with the release; independence obtained from a §21.4 mechanism for Category A and B; validation performed at G3 against the needs, on the target platform, from installed packaging, and recorded (§21.5)

spacecraft-steelbore-standard/references/CHANGELOG.md

@@ -12,6 +12,8 @@ activation. The canonical record is the published Standard's own
 `standard/CHANGELOG.md` (extracted from §1 of the document itself in v1.37); this
 file mirrors it and must be synced to the same version and date.
 
+- **v2.07 (2026-09-15):** **Two clauses are narrowed to what they can actually mean: §15.1's subdomain registry now covers *published* projects, and §18.4's remediation entry falls due at release rather than on adoption.** Both were found by measuring the gap between the text and the world, and in both cases the text was describing a different set than anyone had assumed. **§15.1 first.** It read *"Each Spacecraft Software project has a dedicated subdomain"*, and `PROJECTS.md` — which tracks what is on disk — carries ninety-five rows. Reconciling the two literally obliged **sixty-seven** new entries, for a list including vendored upstream forks carried under §4.2 (Redox, Pop, Ventoy-RS, Markitdown, Wiremix, os-prober), bare symbolic links into other trees (`Lattice`, `localai4mobile`, `Result` → a `/nix/store` path), scratch and duplicate directories (`Rget-Temp`, `Majestic 5 (Copy)`), and reference copies (`Filemanager refs`, `Majestic mobile refs`). None is published by us; none has anything to serve at a subdomain. **The table was not sixty-seven rows behind — the rule was describing a set nobody intended.** §15.1 now says *published* and defines it: the project has a repository under a namespace Spacecraft Software controls (§6.4). Seventeen genuine rows are added on that basis, one per distinct controlled repository — Achernar, Adit, Antigravity 2, Babel, Conduit, Reel, the seven Majestic-family repositories, and the meta repositories Packages, Projects, Specs and Theme. `Ferrite_OS` was already registered as `Ferrite`; the vendored `rust-guidelines` fork is excluded as third-party under §4.2. **§18.4 second, and it is a correction rather than a relaxation.** Since v1.33 a project owed a dated accessibility remediation entry from the moment §18 was adopted — for existing at all, including every pre-release experiment. The predictable happened: at v2.06 **exactly one project carried an entry while roughly fourteen owed one.** That is not a standard being enforced, it is a clause being ignored, and a rule breached universally reports nothing about the projects that breach it while burying the one that did the work (Scrubber, whose entry is honest and specific and stays valid). The obligation now attaches where a reader can be harmed — **from a release tag or a declaration of usability** — and is strict from there; before that point it is optional. **Unchanged:** §18 applies to every project as before and a non-conforming project is not excused; §18.5's games exclusion; every pre-existing §15.1 entry; the §15.2 attribution block. §16's §18 bullet is reworded to match. No project conforming at v2.06 becomes non-conformant at v2.07 — both changes remove obligations rather than adding them. This is the skill-side sync of Standard PR #41.
+
 - **v2.06 (2026-09-15):** **§9.1 closes a privacy gap this standard's own published HTML was falling through, and §11.3.1's `success` token is renamed to end a name collision.** §9's three PFA requirements are scoped to an *application*, and a stylesheet shipped with a document is not one — so the HTML at `Standard.SpacecraftSoftware.org` loaded its two §12 fonts from a third-party CDN, disclosing every reader's IP address, User-Agent and Referer on every page view with no notice and no opt-in. **No tracker was involved and no analytics SDK was shipped**, so the letter of the "No Tracking/No Ads" row was satisfied while its purpose plainly was not. That is a scoping defect, not a licence for the behaviour. §9.1 restates the rule as a property of **artifacts** rather than applications: nothing we ship fetches a subresource from a host the project does not control at render time. **The baseline is `local()`, not bundling** — an `@font-face` rule naming `local()` only, backed by the generic `monospace` fallback, uses an installed copy where one exists and degrades to a system font where none does, without ever opening a connection; an artifact needing faithful rendering for every reader may additionally ship the file beside itself, which §12's licence whitelist exists to permit. Bundling is a fidelity choice; the fetch is what is forbidden. Three readings are closed explicitly, each being a way the rule could have been made hollow: a graceful fallback does not cure the fetch, because the request *is* the disclosure; a hyperlink the reader chooses to follow is not a subresource; and an unavoidable dependency must be declared in `README.md` naming the host, the data disclosed, and why no bundled alternative exists. **The rename second.** `Signal Green` named two different colours — `#28C76F` in Steelbore Blue and `#9ECE6A` in Tokyo Night. Token names are one flat namespace to every consumer that resolves a name to a value: `check-palette-css.py` walks all `[palettes.*]` first-writer-wins, so a doubled name checks a stylesheet against the wrong palette's value and still reports success. It was latent only because no stylesheet declared it. **Blue's moves, to `Aurora Green`** — Tokyo Night is registered verbatim under §11.3.5 and its names evoke upstream, while Blue's are uniformly orbital, so the new name fits the set it joins. The hex does not change, so no ratio moves. **On the skill side** this release also ships three things the Standard describes but does not itself contain: a `check-token-names.py` CI gate failing when any token name maps to more than one hex; `spacecraft.css` rebuilt so its header, `@font-face` rules and `:root` block are **generated** from `steelbore.toml` rather than retyped (the `Palette: … v1.34` pin in that header had been wrong since v1.35 because nothing generated it); and the Google Fonts `@import` removed, verified by building the Standard's HTML and confirming zero `googleapis` references in the output. **Unchanged:** §9's three original rows, every palette value, every contrast ratio, the §11.1 role contract, and the palette family and its membership. No project conforming at v2.05 becomes non-conformant at v2.06 on the palette side; the §9.1 obligation is new. This is the skill-side sync of Standard PR #40.
 
 - **v2.05 (2026-09-15):** **§11.3.6 registers a tenth palette — Steelbore Hanzo Steel, the family's first pure-black canvas.** The palette's colours are drawn from the poster art for *Kill Bill Vol. 1*, and it is anchored on **Sumi Black** and **Hanzo Gold**. **The name is the standard's own, deliberately.** §11.3.2 set a precedent for film-derived palette names, but a palette name is published prose in a CC-BY-SA document, and a film title is a trademark this project has no licence to use as a product label. Colours are not protectable and the inspiration is stated plainly in the section; the identifier is not borrowed. **The substantive decision is the red, and §11.3.6 explains it in the text rather than leaving a reader to compare hexes and wonder.** The source art's Venetian red measures **4.03:1** on Sumi Black and **3.39:1** on Scabbard Slate — under the 4.5:1 text floor on the canvas, and far enough under it on the surface that error prose would not have been readable at normal size. It ships deepened, as **Crimson Edge**, for exactly the reason §11.3.4 deepens NavyWhite's status hues: a conforming alternate is not a §11.5 fidelity palette, so nothing obliges it to reproduce a source value that misses the floor. The alternative was considered and rejected — shipping the verbatim red would have bought fidelity to a poster with an `error` token no application could set in body text, and would have made this the only conforming palette whose error role is restricted on all three of its own backgrounds. **The result is a palette with no restricted pairings at all**: every foreground token clears 4.5:1 against canvas, surface, and surface-alt, the weakest being `error` on `surface` at 4.85:1, and `steelbore-hanzosteel-high-contrast` lifts `error` alone to Ember Lift (9.58:1) because every other token already clears 7:1. **A second thing the section states rather than assumes:** three golds carry three distinct roles — `accent`, `warning`, `structure` — separated by luminance rather than hue, which is legible but is precisely the case §18.2.1 exists for, so the text records that every coloured status in this palette carries its `[WARN]` or `[ERROR]` tag. **Counts move throughout**, and they are the bulk of the diff: ten palettes and nineteen themes, eight conforming, six alternates in §11.3, and the §11.6.1 registered set grows from thirteen to **fifteen** — so the arithmetic in that subsection now reads *three of the fifteen were already required, so this adds twelve*. The §16 checklist's §11.6 bullet follows. **Unchanged:** every existing palette, every existing ratio, the §11.1 eleven-role contract, §11.4's one-palette rule and its inverted tie-break, §11.5's two non-adoptable fidelity palettes, and §11.6's two-stage resolution order. `steelbore-navywhite` remains the only light canvas, so §11.6.2's light/dark pairing is untouched and Hanzo Steel pairs to it like every other dark member. No project conforming at v2.04 becomes non-conformant at v2.05. This is the skill-side sync of Standard PR for v2.05; the values themselves land in `steelbore-color-palette`'s `assets/steelbore.toml`, which remains the single source (§11.4). This skill's own frontmatter `description` is unchanged — §11's palette list lives in `references/palettes.md`, not in the description.