From 9cad4a49b3ac7bfb50af58777ad1abaf49365716 Mon Sep 17 00:00:00 2001 From: UnbreakableMJ Date: Wed, 5 Aug 2026 09:35:14 +0000 Subject: [PATCH] =?UTF-8?q?fix(standard):=20Skill=20Cross-References=20nam?= =?UTF-8?q?ed=20a=20skill=20that=20does=20not=20exist=20=E2=80=94=20v1.44?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The accessibility row pointed at `spacecraft-accessibility`. The skill has been `spacecraft-accessibility-support` since it was added. An agent following the Standard to find the §18 implementation layer would have looked for a directory that is not there, and the failure is silent: a missing skill does not announce itself, it simply never loads, so §18 work would proceed without the reference the Standard directs it to. spacecraft-standard-constitution's own cross-reference table has carried the correct name throughout, so the two documents disagreed and the published one was wrong. A cross-reference is normative content like any other clause, and renaming a skill is a two-repo edit. Every other skill name cited in the document was verified against the catalogue in the same pass; this was the only bad one. No rules change and no section text was touched. makeinfo --no-split: zero errors, zero warnings. reuse lint passes. .md companion regenerated. Co-Authored-By: Claude Opus 5 (1M context) --- CHANGELOG.md | 1 + The_Steelbore_Standard.md | 4 ++-- The_Steelbore_Standard.texi | 6 +++--- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 58b5d19..87d0cd0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,7 @@ Entries are newest-first. Dates are UTC, ISO 8601 (§14). Versioning policy: bum for upstream skill changes, registry updates (§2.1, §15.1), factual corrections to normative content, and brand/identity changes. +- **v1.44 (2026-08-05):** **Skill Cross-References corrected — the accessibility row named a skill that does not exist.** The table pointed at `spacecraft-accessibility`; the skill has been `spacecraft-accessibility-support` since it was added. An agent following the Standard to find the §18 implementation layer would have looked for a directory that is not there, and the failure mode is silent — a missing skill does not announce itself, it simply never loads, so §18 work would proceed without the reference the Standard directs it to. The row now names the skill correctly. Nothing else in the table changed, and every other skill name it cites was verified against the catalogue in the same pass. The drift was pure naming: `spacecraft-standard-constitution`'s own cross-reference table has carried the correct name throughout, so the two documents disagreed and the published one was wrong — a reminder that a cross-reference is normative content like any other clause, and that renaming a skill is a two-repo edit. This entry records a factual correction only; no rule changes, and no section text was touched. - **v1.43 (2026-08-05):** **§3.2.1 published — Platform-Specific Compiler & Linker Flag Caveats.** This section has existed in the `spacecraft-standard-constitution` skill for some time and was **never in the published document**: no version carried it, and neither changelog recorded it. It entered the skill during a rename commit rather than a normative one, so the usual bump-and-record step was skipped and the omission was invisible from either side — the skill looked complete, and the Standard had nothing to be missing. It surfaced only when the `.texi` and the skill were compared section by section. This entry closes that gap; there is **no new rule here**, only a rule that agents have been following from the skill finally appearing in the document that is supposed to be normative. The section states that compiler and linker optimization flags are **not universally portable** across operating systems and distributions — just as systemd-specific settings do not apply to non-systemd distros (GNU Guix System, Void Linux, Gentoo with OpenRC), linker and LTO flags must be adapted to the target platform's toolchain layout. The concrete case is **NixOS / Steelbore OS Bravais**: because NixOS isolates packages in `/nix/store`, GCC's LTO plugin is not on the standard linker search path, so `-flto` **must** be paired with `-fuse-ld=mold` (preferred) or `-fuse-ld=bfd` (fallback) or the build fails to link. The governing rule generalizes it: whenever recommending or applying `-flto`, `-march=native`, or PGO, verify whether the target OS needs supplementary flags or a different linker, and document the OS-specific requirement alongside the flag. This is the platform-specific companion to §3.2's existing requirement that every applied *and* every disabled flag be explicitly noted — §3.2 says record the flag state, §3.2.1 says the correct state is not the same everywhere. §16 needs no new bullet: its §3.2 item already requires flags to be "applied/disabled with explicit notation," which is precisely what §3.2.1 makes platform-aware. - **v1.42 (2026-08-05):** **§13 corrected — a component system per platform, not one for every platform.** §13 required **Material Design** as "the required component system for all graphical applications," a rule written when the graphical surface in scope was Flutter and web. It has been unsatisfiable for native desktop since the day it was written: **GTK 4** ships Adwaita and the GNOME HIG, **Qt 6** ships Fusion and the KDE HIG, and neither has a Material component set to theme — so a GTK or Qt application could not pass the §16 audit gate no matter how it was built, and the only honest options were a permanent filed deviation or an application that matches neither its own toolkit nor Material. Worse, imposing a foreign component system on a native toolkit fights exactly the platform integration §18 depends on: the accessibility bridge, the window manager, the system high-contrast and reduced-motion preferences, and the settings portal are all wired to the toolkit's own vocabulary. §13 is accordingly rewritten around the requirement that actually carries the intent — **every graphical application declares exactly one component system, in its `README.md` beside the §5.2 posture section, and follows it consistently** — with the system determined by the platform rather than by preference: **Material Design** for Flutter, web, mobile, and cross-platform GUI, and for custom-drawn or immediate-mode UI that declares no platform HIG; **GNOME HIG** via libadwaita for GTK 4; **KDE HIG** via Qt Quick Controls or Fusion for Qt 6. Material Design remains the default wherever the platform supplies no system of its own, so nothing that was compliant under v1.41 becomes non-compliant here — the clause is narrowed, never widened. Three things are explicitly unchanged: **§11 binding is unconditional** — whichever system is declared, every palette reference still goes through the named `steelbore` theme (§11.1), because a component system chooses the widget vocabulary and never supplies the colors; **WCAG 2.2 Level AA** remains the contrast floor with the measured pairing stated; and **§18 still governs wherever the two overlap**. The §16 checklist bullet is rewritten from "Material Design UI/UX" to the declare-and-follow form naming all three systems, and the Skill Cross-References table gains `spacecraft-gtk-guidelines` and `spacecraft-qt-guidelines` rows — the two skills that implement this section for the native-desktop toolkits. Both are Rust-first under §3.1 (`gtk-rs` for GTK, CXX-Qt for Qt), so choosing a native desktop toolkit does not become a route around the memory-safe-language preference. - **v1.41 (2026-08-04):** **§3.1.1 added — TypeScript over JavaScript.** §3.1 named Rust as the preferred language and prescribed ASLR+CFI where Rust is not viable, but it had nothing to say about the one runtime where that framing does not apply: JavaScript is already memory-safe, so the memory-safety lever is inert, and the section fell silent exactly where a stability rule was still needed. §3.1.1 supplies it — **type safety is the Priority 1 lever on this runtime**. Where a memory-safe alternative exists (Rust to WebAssembly, Rust or Go on a server, Flutter/Dart for a UI) §3.1 still chooses it; where the JavaScript runtime is genuinely required — a browser page, a Node/Deno/Bun program, an Electron app, an npm-distributed tool, a VS Code extension — the **source language MUST be TypeScript**, and plain JavaScript source becomes a documented exemption rather than a default. Six requirements attach: `"strict": true` plus `noUncheckedIndexedAccess`, `noImplicitOverride`, and `exactOptionalPropertyTypes` (relaxing `strict` is a Priority 1 regression); no `any` and no non-null `!` in production paths (use `unknown` and narrow); `@ts-ignore` prohibited outright in favor of `@ts-expect-error` with a stated reason, which fails the build once the suppression stops being needed; **run-time validation at every trust boundary**, since a type annotation is a compile-time claim and asserting an unverified shape is the silent-failure mode §3.1 already forbids; **`tsc --noEmit` gating CI**, because esbuild, SWC, and Bun strip types without checking them, and a project that only transpiles has not satisfied this section; and loading `spacecraft-typescript-guidelines` before writing or reviewing TypeScript. Emitted `.js` and source maps in a build directory are derived artifacts and out of scope — the rule governs what is authored and committed. Three narrow cases need no filing: a tool's own configuration file that must be `.js` (e.g. `eslint.config.js` where no TypeScript loader exists), a vendored or upstream-derived file carried under §4.2, and generated output. Everything else — including "it is only a small script" — requires a documented technical exemption, on the same footing as the §3.1 memory-safe-language exemption. §16 gains a checklist bullet; the skill cross-reference table gains a TypeScript row. diff --git a/The_Steelbore_Standard.md b/The_Steelbore_Standard.md index 266dc06..289735b 100644 --- a/The_Steelbore_Standard.md +++ b/The_Steelbore_Standard.md @@ -29,7 +29,7 @@ repository](https://github.com/Spacecraft-Software/Standard), newest entry first. It is kept out of this document so the standard reads as the rules *in force* rather than the record of how they got there. -This document is **version 1.43**, updated 2026-08-05 (§14: UTC, ISO +This document is **version 1.44**, updated 2026-08-05 (§14: UTC, ISO 8601). The skill encoding of the standard keeps a parallel history in `spacecraft-standard-constitution/references/CHANGELOG.md` in the [Construct @@ -2136,7 +2136,7 @@ skipping it. | Writing GTK 4 / GNOME desktop code (§13) | `spacecraft-gtk-guidelines` | | Writing Qt 6 / KDE desktop code (§13) | `spacecraft-qt-guidelines` | | Creating IDE / terminal themes | `spacecraft-theme-factory` | -| Implementing or auditing accessibility (§18) | `spacecraft-accessibility` | +| Implementing or auditing accessibility (§18) | `spacecraft-accessibility-support` | | All other Spacecraft Software work | `spacecraft-standard-constitution` | # Concept Index diff --git a/The_Steelbore_Standard.texi b/The_Steelbore_Standard.texi index f5dfa06..5261e15 100644 --- a/The_Steelbore_Standard.texi +++ b/The_Steelbore_Standard.texi @@ -5,10 +5,10 @@ @setfilename The_Steelbore_Standard.info @documentencoding UTF-8 @documentlanguage en -@settitle The Steelbore Standard 1.43 +@settitle The Steelbore Standard 1.44 @c %**end of header -@set VERSION 1.43 +@set VERSION 1.44 @set UPDATED 2026-08-05 @set SUBDOMAIN https://Standard.SpacecraftSoftware.org/ @@ -3777,7 +3777,7 @@ Creating IDE / terminal themes @tab @code{spacecraft-theme-factory} @item Implementing or auditing accessibility (§18) - @tab @code{spacecraft-accessibility} + @tab @code{spacecraft-accessibility-support} @item All other Spacecraft Software work @tab @code{spacecraft-standard-constitution}