diff --git a/.gitignore b/.gitignore index e44e801..aa009bc 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,28 @@ -# Derived deliverables — uploaded as release assets, not version-controlled -The_Steelbore_Standard.odt +# Generated outputs — produced from The_Steelbore_Standard.texi via `make` +# Run: make info → .info make html → .html make md → .md make pdf → .pdf +# On request only: make docx → .docx +The_Steelbore_Standard.info +The_Steelbore_Standard.html +The_Steelbore_Standard.pdf The_Steelbore_Standard.docx +The_Steelbore_Standard.odt + +# TeX auxiliary files +*.aux +*.log +*.toc +*.cp +*.cps +*.fn +*.fns +*.ky +*.kys +*.pg +*.pgs +*.tp +*.tps +*.vr +*.vrs # Agent-local guidance and exports (not for publication) CLAUDE.md diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..fc195b3 --- /dev/null +++ b/Makefile @@ -0,0 +1,40 @@ +# SPDX-FileCopyrightText: 2026 Mohamed Hammad +# SPDX-License-Identifier: GPL-3.0-or-later + +TEXI = The_Steelbore_Standard.texi +INFO = The_Steelbore_Standard.info +HTML = The_Steelbore_Standard.html +MD = The_Steelbore_Standard.md +PDF = The_Steelbore_Standard.pdf +DOCX = The_Steelbore_Standard.docx +CSS = spacecraft.css + +all: info html md + +info: $(INFO) +$(INFO): $(TEXI) + makeinfo --no-split $(TEXI) + +html: $(HTML) +$(HTML): $(TEXI) $(CSS) + texi2any --html --no-split --css-include=$(CSS) $(TEXI) + +md: $(MD) +$(MD): $(TEXI) + texi2any --docbook $(TEXI) -o /tmp/std_docbook.xml + pandoc -f docbook -t gfm /tmp/std_docbook.xml -o $(MD) + +pdf: $(PDF) +$(PDF): $(TEXI) + texi2pdf --texinfo=@afourpaper $(TEXI) + +docx: $(DOCX) +$(DOCX): $(TEXI) + texi2any --docbook $(TEXI) -o /tmp/std_docbook.xml + pandoc -f docbook -t docx /tmp/std_docbook.xml -o $(DOCX) + +clean: + rm -f $(INFO) $(HTML) $(PDF) *.aux *.log *.toc *.cp *.cps \ + *.fn *.fns *.ky *.kys *.pg *.pgs *.tp *.tps *.vr *.vrs + +.PHONY: all info html md pdf docx clean diff --git a/REUSE.toml b/REUSE.toml index f5b7206..bcf72b2 100644 --- a/REUSE.toml +++ b/REUSE.toml @@ -3,7 +3,7 @@ version = 1 # override: the Standard text contains *example* SPDX headers (in §4.3) that must not be # parsed as real license tags — the REUSE.toml annotation is authoritative for these files. [[annotations]] -path = ["The_Steelbore_Standard.md", ".gitignore", "REUSE.toml"] +path = ["The_Steelbore_Standard.texi", "The_Steelbore_Standard.md", ".gitignore", "REUSE.toml"] precedence = "override" SPDX-FileCopyrightText = "2026 Mohamed Hammad " SPDX-License-Identifier = "CC-BY-SA-4.0" diff --git a/The_Steelbore_Standard.md b/The_Steelbore_Standard.md index 4f66467..c1bccaf 100644 --- a/The_Steelbore_Standard.md +++ b/The_Steelbore_Standard.md @@ -1,444 +1,884 @@ ---- -title: The Steelbore Standard -author: Mohamed Hammad -date: 2026-06-22 -version: 1.27 -source-format: odt ---- - - - -# The Steelbore Standard - -**Engineering specification for Steelbore OS and the Spacecraft Software ecosystem** - -**Version:** 1.27 | **Date:** 2026-06-22 | **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:** CC-BY-SA-4.0 -**Website:** +# §1 — Preamble + +The Steelbore Standard defines the engineering principles, compliance +requirements, and design conventions that govern all software produced +under Spacecraft Software. The umbrella encompasses two categories of +work: **Steelbore OS** — the operating system and all OS-specific +artifacts (configurations, themes, OS tooling) — and **independent +Spacecraft Software projects** such as Zamak, Ironway, Ferrocast, and +Caliper, which are designed to work with Steelbore OS but are not +OS-specific and may run on any compliant platform. Both categories are +full citizens of Spacecraft Software and subject to this standard in +full. Where a project-specific specification conflicts with this +standard, the stricter of the two requirements shall prevail. + +**Standard name vs. project naming.** "The Steelbore Standard" is the +canonical, stable name of *this standard*. It is independent of the +projects it governs and of the umbrella organization name — the standard +retains this name regardless of any future renames. The v1.7 umbrella +rename (Steelbore → Spacecraft Software) and the v1.8 reinstatement of +this standard’s name are recorded in the changelog. Versioning of +project codenames (see §2) and versioning of the standard are separate +concerns. + +## Changelog + +- **v1.29 (2026-06-23):** Switch source of truth from GFM Markdown to + Texinfo: `The_Steelbore_Standard.texi` is now the canonical source; + `The_Steelbore_Standard.md` and `The_Steelbore_Standard.html` are + generated outputs. `.docx`/`.odt` produced on request only. + `source-format` updated from `odt` to `texi`. A `Makefile` with + `info`, `html`, `md`, and `pdf` targets drives all derivation. + +- **v1.28 (2026-06-23):** **§2.1:** synced development statuses with + Spacecraft-Software/Projects `PROJECTS.md` — `Aetheric` (was Active) + and `Ferrocast` (was Planning) corrected to **Deprecated**, matching + their `Deprecated` status in the tracker. Per `PROJECTS.md`’s closed + status vocabulary, `Deprecated` means "Superseded by another project; + do not extend." + +- **v1.27 (2026-06-22):** **§15.1:** registered the **Loran Pages** + subdomain (`Loran-Pages.SpacecraftSoftware.org`), paired in the same + change-set with its new row and GitHub-repo/subdomain reference links + in Spacecraft-Software/Projects `PROJECTS.md`. The `loran-pages` repo + — the community catalog of curated Loran help pages (tldr-pages-style: + flat `pages//.md`, a `loran validate` CI gate, and a + deterministic minisign-signed `publish.yml` producer feeding + `loran update`) — was created private with §5.2 posture files and §4.3 + REUSE compliance (pages CC-BY-SA-4.0, tooling GPL-3.0-or-later, + `reuse lint`-clean). + +- **v1.26 (2026-06-21):** **§15.1:** registered the **Vacuum** subdomain + (`Vacuum.SpacecraftSoftware.org`), paired in the same change-set with + its new row and GitHub-repo/subdomain reference links in + Spacecraft-Software/Projects `PROJECTS.md`. The `Vacuum` repo — a Rust + multi-crate disk-space recovery TUI/CLI (parallel scan + a cleaner + catalog: build artifacts, package-manager GC, app caches, large files; + dry-run-first, trash-by-default) — was created private with §5.2 + posture files, an §8 Texinfo manual, the §5.5 packaging trio, and §4.3 + REUSE compliance (`reuse lint`-clean). + +- **v1.25 (2026-06-20):** Rename §3.3 Priority 3 from "Hardened + Security" to "Security by Design" — aligns the priority name with the + Security By Design principle (security built in from the start). + +- **v1.24 (2026-06-19):** Add §8 Documentation (Texinfo) — Texinfo as + first-class technical manual format for user-facing Spacecraft + Software projects, following GNU conventions + (`@dircategory`/`@direntry` for Info directory registration, + `makeinfo`/`texi2pdf` build targets, CC-BY-SA-4.0 default with + GFDL-1.3-or-later as a permitted alternative, packaging integration + for Guix/Nix/PKGBUILD); renumber old §8–§15 → §9–§16 accordingly. + +- **v1.23 (2026-06-19):** **§14.1:** registered the **Docs** subdomain + (`Docs.SpacecraftSoftware.org`), paired in the same change-set with + its updated row and new GitHub-repo link in + Spacecraft-Software/Projects `PROJECTS.md`. The `Docs` repo — a + centralized aggregation of the umbrella’s planning corpus (PRDs, + plans, TODOs, research) organized by project then document type — was + created private with §5.2 posture files and §4.3 REUSE compliance + (CC-BY-SA-4.0 documents, `reuse lint`-clean). + +- **v1.22 (2026-06-18):** **§7 Shell Environment added** — codifies + Nushell, Ion, Brush, and Bash as four equally first-class shell + environments; §7.1 Script Portability Policy mandates POSIX-compatible + scripts by default with Nushell/Ion native variants where needed and + prohibits Bashisms in shared scripts. Current §7–§14 renumbered §8–§15 + accordingly. Compliance checklist updated with §7 bullet. Skill + Cross-References updated with shell-work row. **§14.2:** added email + obfuscation note — `[at]` form permitted in plain-text prose; PKGBUILD + `# Maintainer:` and SPDX headers must retain the full address. + +- **v1.21 (2026-06-17):** **§13.1:** registered subdomains for three + projects present in `PROJECTS.md` but missing from the table — + **Lode** (`Lode.SpacecraftSoftware.org`), **Sonde** + (`Sonde.SpacecraftSoftware.org`), and **Vault** + (`Vault.SpacecraftSoftware.org`). **§3.1 and Skill Cross-References:** + corrected skill reference from `rust-guidelines` to + `microsoft-rust-guidelines` to match the actual skill ID in the + upstream `spacecraft-standard` skill. + +- **v1.20 (2026-06-17):** **§5.5 added:** Package Distribution + Requirements — every released package must ship `packaging/guix.scm` + (GNU Guix Scheme definition), `packaging/default.nix` (Nix + flake/derivation), and `packaging/PKGBUILD` (Arch Linux `makepkg`), + all present and buildable before any release tag is pushed; each file + must pin the exact release version and SHA-256 checksum in the format + native to its package manager, and carry the project’s SPDX two-tag + header per §4.3. **§15** updated with a corresponding `§5.5` + compliance-checklist bullet. + +- **v1.19 (2026-06-16):** **§13.1:** registered the **MCP Servers** + project subdomain (`MCP-Servers.SpacecraftSoftware.org`), paired in + the same change-set with its row and GitHub-repo link in + Spacecraft-Software/Projects `PROJECTS.md`. The `mcp-servers` repo — + MCP (Model Context Protocol) server configuration templates across 12 + coding agents/editors — was onboarded to the umbrella with the §5.2 + posture files (`NOTICE.md`, `CONTRIBUTING.md`, README posture section) + and §4.3 REUSE compliance (`LICENSES/`, `REUSE.toml`, + `reuse lint`-clean). + +- **v1.18 (2026-06-08):** Licensing classification follow-through. (1) + **§4.1.1 added:** license-by-artifact-class table — **software** + (incl. skills) is `GPL-3.0-or-later`/`AGPL-3.0-or-later`; + **documents** (specs, guides, document deliverables, the published + Standard) default to `CC-BY-SA-4.0` (`CC-BY-4.0` for max-reuse cases); + **third-party-derived** artifacts preserve their upstream license per + §4.2. (2) **Skill-license correction:** clarified that skills are + software-class — the published Standard document is `CC-BY-SA-4.0` but + the `spacecraft-standard` skill encoding is `GPL-3.0-or-later` (the + v1.17 skill metadata is corrected back to GPL accordingly). (3) **§4.1 + migration policy (replaces v1.17’s "no forced re-license"):** existing + projects are to be reviewed and relicensed to the best-suited + GPL/AGPL, per project, on signed commits. The Standard and Construct + repos are now REUSE-compliant (`reuse lint`-clean) with `LICENSES/` + directories and `REUSE.toml`. (4) **§2:** added *Equilibrium* and + *Dune* to the endorsed sci-fi naming sources. + +- **v1.17 (2026-06-08):** Licensing & build overhaul. (1) **Standard + relicensed** from `GPL-3.0-or-later` to **`CC-BY-SA-4.0`**, effective + this version forward — GPL suits software, not a prose specification; + CC BY-SA preserves the share-alike copyleft ethos and is purpose-built + for documents. This affects the Standard document itself only; the + projects it governs are unchanged by this point. (2) **§4.1:** project + license is now `GPL-3.0-or-later` **or** `AGPL-3.0-or-later` (AGPL for + network-facing software), prospective with no forced re-license. (3) + **§4.2 added:** explicit upstream-license-compliance clause — preserve + third-party copyright notices, license texts, and `NOTICE`/`AUTHORS` + verbatim; ship upstream licenses in `LICENSES/`. (4) **§4.3:** + SPDX/REUSE compliance per — two-tag headers + (`SPDX-FileCopyrightText` + `SPDX-License-Identifier`), a `LICENSES/` + directory, `.license`/`REUSE.toml` coverage for headerless files + (replacing the old "documents are exempt" rule), and `reuse lint` as + the CI gate. (5) **§3.2:** explicit optimization-flag exception — + flags like LTO that break/destabilize a build on a given + toolchain/platform (e.g., NixOS, cross-compilation) MUST be disabled + and documented, since Stability (P1) outranks Performance (P2). + §5.1/§5.2/§6/§13.2 license references and the §4/§12 + compliance-checklist items updated to match. + +- **v1.16 (2026-06-08):** §12 reframed — UTC Z is now explicitly the + **default and preferred** timezone (not a universal mandate forced + onto every domain). New §12.2.1 documents a domain exception: a + project whose core domain is fundamentally local-time-bound (e.g., + `Mawaqit` prayer-time calculations, sunrise/sunset, local scheduling) + may declare local time as its *primary* representation for that + domain’s data, provided it is documented, the UTC default still + governs the project’s general-purpose machinery (logs, commits, APIs), + and a UTC instant remains derivable via a stored IANA timezone. §12.1 + timezone row and §12.3 updated to reference the new exception and + avoid contradicting it. + +- **v1.15 (2026-06-08):** §2 naming convention expanded — added + explicitly endorsed canonical sources: *The Hitchhiker’s Guide to the + Galaxy*, *Hackers* (1995), Spielberg films, *Ghost in the Shell*, *Æon + Flux*, *Super 8*, *LOST*, the *Cloverfield* franchise, and + robot/android names from any sci-fi film or franchise. §2 now + explicitly frames naming as a fun, playful exercise alongside the + existing space-machine-AI fitness test. + +- **v1.14 (2026-06-03):** §3.2 reframed — Performance is the foremost + priority after Stability, and its default means of achievement is + **multi-core, multi-thread concurrency** (parallelism as the baseline, + designed in from the start), *unless* concurrency would materially + degrade performance (overhead, contention, or inherently serial + workloads), in which case a documented serial/simpler approach is + chosen. §3.2 compliance-checklist bullet revised. + +- **v1.13 (2026-06-03):** §3.1 reframed — Priority 1 is now + **Stability**, not Memory Safety. Memory safety remains the single + most important contributor and primary lever, but Priority 1 now also + mandates robust error handling, fault tolerance / graceful + degradation, and test-verified stability. Cardinal Rule updated to + reference stability (including memory safety); §3.1 + compliance-checklist bullet revised. + +- **v1.12 (2026-05-25):** §6.3 extended: added explicit authorized + signing identity rule — all commits from v1.12 onwards must be signed + with the `Mohamed.Hammad@SpacecraftSoftware.org` Ed25519 SSH key; + committer email and signing key identity must both resolve to that + address. Commits predating this version are exempt. + +- **v1.11 (2026-05-24):** Three normative updates: (1) Copyright notices + updated to `Copyright (C) 2026 Mohamed Hammad & Spacecraft Software` + in all locations. (2) §9.1 added: new apps must expose palette colors + through a named `Steelbore` theme rather than hard-coded hex literals, + enabling clean theme substitution. (3) §12 revised: UTC Z remains the + canonical/mandatory primary format; local time expressed as a UTC + offset may now optionally accompany UTC Z values in display, API + responses, and stored records. + +- **v1.10 (2026-05-20):** Standardized copyright notice to + `Copyright (C) 2026 Mohamed Hammad` in all three locations (YAML + frontmatter masthead, §13 attribution block, and `--version` / About + template in §6). + +- **v1.9 (2026-05-18):** Clarified organizational model in §1: + "Steelbore" now specifically refers to Steelbore OS and OS-specific + artifacts (configurations, themes, tooling); "Spacecraft Software" is + the broader umbrella. Independent projects (Zamak, Ironway, Ferrocast, + Caliper, etc.) are peer citizens of the umbrella — designed to work + with Steelbore OS but OS-agnostic and usable on any compliant + platform. Both categories governed by this standard in full. + +- **v1.8 (2026-05-18):** Standard name reinstated as "The Steelbore + Standard". Primary mandate reaffirmed as the Steelbore OS line; scope + explicitly extended by default to all Spacecraft Software projects + (unless a project’s own spec explicitly carves out an exception). + Subtitle updated to reflect dual scope. Source file renamed + `The_Spacecraft_Software_Standard.md` → `The_Steelbore_Standard.md`. + §13.1: added Standard subdomain entry + (`Standard.SpacecraftSoftware.org`). Umbrella org name and domain + (Spacecraft Software / SpacecraftSoftware.org) unchanged. + +- **v1.7 (2026-05-15):** Umbrella renamed from `Steelbore` to + `Spacecraft Software` per the brand consolidation. Standard’s name + updated to "The Spacecraft Software Standard"; domain to + `SpacecraftSoftware.org`; contact email to + `Mohamed.Hammad@SpacecraftSoftware.org`; §13.1 subdomain pattern to + `.SpacecraftSoftware.org`. Skill ID prefix renamed + (`steelbore-*` → `spacecraft-*`). Subproject codenames unchanged. The + OS line (`Steelbore OS`, `Steelbore OS Bravais`, + `Steelbore OS Lattice`) retains the Steelbore name and is unaffected + by this rename. + +- **v1.6 (2026-05-13):** Synced §2.1 development statuses with + PROJECTS.md — `Bravais` and `Anvil` and `Flux` promoted to Completed; + `Ferrocast` corrected to Planning; `Mawaqit` updated to Planning + (Pending rename). + +- **v1.5 (2026-05-13):** Corrected `Craton` status in §2.1 from `Active` + to `Reserved` — codename is registered but no development has started + yet. + +- **v1.4 (2026-05-13):** Synced §2.1 Legacy Metallurgical Registry with + PROJECTS.md — added five previously unregistered pre-v1.2 codenames: + `Anvil`, `Flux`, `Pearlite`, `Ferrite_OS`, and `Forge`. Expanded §13.1 + subdomain table to include all first-party projects with GitHub + repositories that were missing: Anvil, Construct, Ferrite_OS, Forge, + Ginx, Loran, Pearlite. + +- **v1.3 (2026-05-12):** Added §6.3 (Signed & Verified Commits — + mandatory Ed25519 SSH commit signing with hosting-platform "Verified" + status; the rule extends to programmatic, CI, and assistant-driven + commits and requires rewrites to preserve signatures). Added §13.3 + (Third-Party Attribution — `CREDITS.md` at project/skill root when + external work is substantially built upon, distinct from mechanical + SPDX license metadata). Two new compliance-checklist bullets cover + both additions. + +- **v1.2 (2026-05-11):** Replaced §2 metallurgical naming convention + with Aerospace, Sci-Fi & AI naming (aerospace/astronomy terminology + + franchise references from *2001: A Space Odyssey*, *The Matrix*, + *Terminator*). Preserved pre-v1.2 metallurgical-era names under §2’s + Legacy Registry. Added explicit statement that the standard’s name was + decoupled from project naming and would survive any project or + umbrella rename (subsequently revisited in v1.7’s umbrella rename). + Renamed `Lattice` to `Bravais` (collision with Lattice OS) in registry + and §13.1 subdomain table. Flagged `Mawaqit` as pending rename under + the v1.2 convention. + +- **v1.1 (2026-05-06):** Added §5 Project Posture (personal-hobby + default, general-use carve-out, required posture files). Renumbered + prior §5–§13 to §6–§14. Added posture bullet to compliance checklist. ---- - -## §1 — Preamble - -The Steelbore Standard defines the engineering principles, compliance requirements, and design conventions that govern all software produced under Spacecraft Software. The umbrella encompasses two categories of work: **Steelbore OS** — the operating system and all OS-specific artifacts (configurations, themes, OS tooling) — and **independent Spacecraft Software projects** such as Zamak, Ironway, Ferrocast, and Caliper, which are designed to work with Steelbore OS but are not OS-specific and may run on any compliant platform. Both categories are full citizens of Spacecraft Software and subject to this standard in full. Where a project-specific specification conflicts with this standard, the stricter of the two requirements shall prevail. - -**Standard name vs. project naming.** "The Steelbore Standard" is the canonical, stable name of *this standard*. It is independent of the projects it governs and of the umbrella organization name — the standard retains this name regardless of any future renames. The v1.7 umbrella rename (Steelbore → Spacecraft Software) and the v1.8 reinstatement of this standard's name are recorded in the changelog. Versioning of project codenames (see §2) and versioning of the standard are separate concerns. - -### Changelog - -- **v1.27 (2026-06-22):** **§15.1:** registered the **Loran Pages** subdomain (`Loran-Pages.SpacecraftSoftware.org`), paired in the same change-set with its new row and GitHub-repo/subdomain reference links in Spacecraft-Software/Projects `PROJECTS.md`. The `loran-pages` repo — the community catalog of curated Loran help pages (tldr-pages-style: flat `pages//.md`, a `loran validate` CI gate, and a deterministic minisign-signed `publish.yml` producer feeding `loran update`) — was created private with §5.2 posture files and §4.3 REUSE compliance (pages CC-BY-SA-4.0, tooling GPL-3.0-or-later, `reuse lint`-clean). -- **v1.26 (2026-06-21):** **§15.1:** registered the **Vacuum** subdomain (`Vacuum.SpacecraftSoftware.org`), paired in the same change-set with its new row and GitHub-repo/subdomain reference links in Spacecraft-Software/Projects `PROJECTS.md`. The `Vacuum` repo — a Rust multi-crate disk-space recovery TUI/CLI (parallel scan + a cleaner catalog: build artifacts, package-manager GC, app caches, large files; dry-run-first, trash-by-default) — was created private with §5.2 posture files, an §8 Texinfo manual, the §5.5 packaging trio, and §4.3 REUSE compliance (`reuse lint`-clean). -- **v1.25 (2026-06-20):** Rename §3.3 Priority 3 from "Hardened Security" to "Security by Design" — aligns the priority name with the Security By Design principle (security built in from the start). -- **v1.24 (2026-06-19):** Add §8 Documentation (Texinfo) — Texinfo as first-class technical manual format for user-facing Spacecraft Software projects, following GNU conventions (`@dircategory`/`@direntry` for Info directory registration, `makeinfo`/`texi2pdf` build targets, CC-BY-SA-4.0 default with GFDL-1.3-or-later as a permitted alternative, packaging integration for Guix/Nix/PKGBUILD); renumber old §8–§15 → §9–§16 accordingly. -- **v1.23 (2026-06-19):** **§14.1:** registered the **Docs** subdomain (`Docs.SpacecraftSoftware.org`), paired in the same change-set with its updated row and new GitHub-repo link in Spacecraft-Software/Projects `PROJECTS.md`. The `Docs` repo — a centralized aggregation of the umbrella's planning corpus (PRDs, plans, TODOs, research) organized by project then document type — was created private with §5.2 posture files and §4.3 REUSE compliance (CC-BY-SA-4.0 documents, `reuse lint`-clean). -- **v1.22 (2026-06-18):** **§7 Shell Environment added** — codifies Nushell, Ion, Brush, and Bash as four equally first-class shell environments; §7.1 Script Portability Policy mandates POSIX-compatible scripts by default with Nushell/Ion native variants where needed and prohibits Bashisms in shared scripts. Current §7–§14 renumbered §8–§15 accordingly. Compliance checklist updated with §7 bullet. Skill Cross-References updated with shell-work row. **§14.2:** added email obfuscation note — `[at]` form permitted in plain-text prose; PKGBUILD `# Maintainer:` and SPDX headers must retain the full address. -- **v1.21 (2026-06-17):** **§13.1:** registered subdomains for three projects present in `PROJECTS.md` but missing from the table — **Lode** (`Lode.SpacecraftSoftware.org`), **Sonde** (`Sonde.SpacecraftSoftware.org`), and **Vault** (`Vault.SpacecraftSoftware.org`). **§3.1 and Skill Cross-References:** corrected skill reference from `rust-guidelines` to `microsoft-rust-guidelines` to match the actual skill ID in the upstream `spacecraft-standard` skill. -- **v1.20 (2026-06-17):** **§5.5 added:** Package Distribution Requirements — every released package must ship `packaging/guix.scm` (GNU Guix Scheme definition), `packaging/default.nix` (Nix flake/derivation), and `packaging/PKGBUILD` (Arch Linux `makepkg`), all present and buildable before any release tag is pushed; each file must pin the exact release version and SHA-256 checksum in the format native to its package manager, and carry the project's SPDX two-tag header per §4.3. **§15** updated with a corresponding `§5.5` compliance-checklist bullet. -- **v1.19 (2026-06-16):** **§13.1:** registered the **MCP Servers** project subdomain (`MCP-Servers.SpacecraftSoftware.org`), paired in the same change-set with its row and GitHub-repo link in Spacecraft-Software/Projects `PROJECTS.md`. The `mcp-servers` repo — MCP (Model Context Protocol) server configuration templates across 12 coding agents/editors — was onboarded to the umbrella with the §5.2 posture files (`NOTICE.md`, `CONTRIBUTING.md`, README posture section) and §4.3 REUSE compliance (`LICENSES/`, `REUSE.toml`, `reuse lint`-clean). -- **v1.18 (2026-06-08):** Licensing classification follow-through. (1) **§4.1.1 added:** license-by-artifact-class table — **software** (incl. skills) is `GPL-3.0-or-later`/`AGPL-3.0-or-later`; **documents** (specs, guides, document deliverables, the published Standard) default to `CC-BY-SA-4.0` (`CC-BY-4.0` for max-reuse cases); **third-party-derived** artifacts preserve their upstream license per §4.2. (2) **Skill-license correction:** clarified that skills are software-class — the published Standard document is `CC-BY-SA-4.0` but the `spacecraft-standard` skill encoding is `GPL-3.0-or-later` (the v1.17 skill metadata is corrected back to GPL accordingly). (3) **§4.1 migration policy (replaces v1.17's "no forced re-license"):** existing projects are to be reviewed and relicensed to the best-suited GPL/AGPL, per project, on signed commits. The Standard and Construct repos are now REUSE-compliant (`reuse lint`-clean) with `LICENSES/` directories and `REUSE.toml`. (4) **§2:** added *Equilibrium* and *Dune* to the endorsed sci-fi naming sources. -- **v1.17 (2026-06-08):** Licensing & build overhaul. (1) **Standard relicensed** from `GPL-3.0-or-later` to **`CC-BY-SA-4.0`**, effective this version forward — GPL suits software, not a prose specification; CC BY-SA preserves the share-alike copyleft ethos and is purpose-built for documents. This affects the Standard document itself only; the projects it governs are unchanged by this point. (2) **§4.1:** project license is now `GPL-3.0-or-later` **or** `AGPL-3.0-or-later` (AGPL for network-facing software), prospective with no forced re-license. (3) **§4.2 added:** explicit upstream-license-compliance clause — preserve third-party copyright notices, license texts, and `NOTICE`/`AUTHORS` verbatim; ship upstream licenses in `LICENSES/`. (4) **§4.3:** SPDX/REUSE compliance per — two-tag headers (`SPDX-FileCopyrightText` + `SPDX-License-Identifier`), a `LICENSES/` directory, `.license`/`REUSE.toml` coverage for headerless files (replacing the old "documents are exempt" rule), and `reuse lint` as the CI gate. (5) **§3.2:** explicit optimization-flag exception — flags like LTO that break/destabilize a build on a given toolchain/platform (e.g., NixOS, cross-compilation) MUST be disabled and documented, since Stability (P1) outranks Performance (P2). §5.1/§5.2/§6/§13.2 license references and the §4/§12 compliance-checklist items updated to match. -- **v1.16 (2026-06-08):** §12 reframed — UTC Z is now explicitly the **default and preferred** timezone (not a universal mandate forced onto every domain). New §12.2.1 documents a domain exception: a project whose core domain is fundamentally local-time-bound (e.g., `Mawaqit` prayer-time calculations, sunrise/sunset, local scheduling) may declare local time as its *primary* representation for that domain's data, provided it is documented, the UTC default still governs the project's general-purpose machinery (logs, commits, APIs), and a UTC instant remains derivable via a stored IANA timezone. §12.1 timezone row and §12.3 updated to reference the new exception and avoid contradicting it. -- **v1.15 (2026-06-08):** §2 naming convention expanded — added explicitly endorsed canonical sources: *The Hitchhiker's Guide to the Galaxy*, *Hackers* (1995), Spielberg films, *Ghost in the Shell*, *Æon Flux*, *Super 8*, *LOST*, the *Cloverfield* franchise, and robot/android names from any sci-fi film or franchise. §2 now explicitly frames naming as a fun, playful exercise alongside the existing space-machine-AI fitness test. -- **v1.14 (2026-06-03):** §3.2 reframed — Performance is the foremost priority after Stability, and its default means of achievement is **multi-core, multi-thread concurrency** (parallelism as the baseline, designed in from the start), *unless* concurrency would materially degrade performance (overhead, contention, or inherently serial workloads), in which case a documented serial/simpler approach is chosen. §3.2 compliance-checklist bullet revised. -- **v1.13 (2026-06-03):** §3.1 reframed — Priority 1 is now **Stability**, not Memory Safety. Memory safety remains the single most important contributor and primary lever, but Priority 1 now also mandates robust error handling, fault tolerance / graceful degradation, and test-verified stability. Cardinal Rule updated to reference stability (including memory safety); §3.1 compliance-checklist bullet revised. -- **v1.12 (2026-05-25):** §6.3 extended: added explicit authorized signing identity rule — all commits from v1.12 onwards must be signed with the `Mohamed.Hammad@SpacecraftSoftware.org` Ed25519 SSH key; committer email and signing key identity must both resolve to that address. Commits predating this version are exempt. -- **v1.11 (2026-05-24):** Three normative updates: (1) Copyright notices updated to `Copyright (C) 2026 Mohamed Hammad & Spacecraft Software` in all locations. (2) §9.1 added: new apps must expose palette colors through a named `Steelbore` theme rather than hard-coded hex literals, enabling clean theme substitution. (3) §12 revised: UTC Z remains the canonical/mandatory primary format; local time expressed as a UTC offset may now optionally accompany UTC Z values in display, API responses, and stored records. -- **v1.10 (2026-05-20):** Standardized copyright notice to `Copyright (C) 2026 Mohamed Hammad` in all three locations (YAML frontmatter masthead, §13 attribution block, and `--version` / About template in §6). -- **v1.9 (2026-05-18):** Clarified organizational model in §1: "Steelbore" now specifically refers to Steelbore OS and OS-specific artifacts (configurations, themes, tooling); "Spacecraft Software" is the broader umbrella. Independent projects (Zamak, Ironway, Ferrocast, Caliper, etc.) are peer citizens of the umbrella — designed to work with Steelbore OS but OS-agnostic and usable on any compliant platform. Both categories governed by this standard in full. -- **v1.8 (2026-05-18):** Standard name reinstated as "The Steelbore Standard". Primary mandate reaffirmed as the Steelbore OS line; scope explicitly extended by default to all Spacecraft Software projects (unless a project's own spec explicitly carves out an exception). Subtitle updated to reflect dual scope. Source file renamed `The_Spacecraft_Software_Standard.md` → `The_Steelbore_Standard.md`. §13.1: added Standard subdomain entry (`Standard.SpacecraftSoftware.org`). Umbrella org name and domain (Spacecraft Software / SpacecraftSoftware.org) unchanged. -- **v1.7 (2026-05-15):** Umbrella renamed from `Steelbore` to `Spacecraft Software` per the brand consolidation. Standard's name updated to "The Spacecraft Software Standard"; domain to `SpacecraftSoftware.org`; contact email to `Mohamed.Hammad@SpacecraftSoftware.org`; §13.1 subdomain pattern to `.SpacecraftSoftware.org`. Skill ID prefix renamed (`steelbore-*` → `spacecraft-*`). Subproject codenames unchanged. The OS line (`Steelbore OS`, `Steelbore OS Bravais`, `Steelbore OS Lattice`) retains the Steelbore name and is unaffected by this rename. -- **v1.6 (2026-05-13):** Synced §2.1 development statuses with PROJECTS.md — `Bravais` and `Anvil` and `Flux` promoted to Completed; `Ferrocast` corrected to Planning; `Mawaqit` updated to Planning (Pending rename). -- **v1.5 (2026-05-13):** Corrected `Craton` status in §2.1 from `Active` to `Reserved` — codename is registered but no development has started yet. -- **v1.4 (2026-05-13):** Synced §2.1 Legacy Metallurgical Registry with PROJECTS.md — added five previously unregistered pre-v1.2 codenames: `Anvil`, `Flux`, `Pearlite`, `Ferrite_OS`, and `Forge`. Expanded §13.1 subdomain table to include all first-party projects with GitHub repositories that were missing: Anvil, Construct, Ferrite_OS, Forge, Ginx, Loran, Pearlite. -- **v1.3 (2026-05-12):** Added §6.3 (Signed & Verified Commits — mandatory Ed25519 SSH commit signing with hosting-platform "Verified" status; the rule extends to programmatic, CI, and assistant-driven commits and requires rewrites to preserve signatures). Added §13.3 (Third-Party Attribution — `CREDITS.md` at project/skill root when external work is substantially built upon, distinct from mechanical SPDX license metadata). Two new compliance-checklist bullets cover both additions. -- **v1.2 (2026-05-11):** Replaced §2 metallurgical naming convention with Aerospace, Sci-Fi & AI naming (aerospace/astronomy terminology + franchise references from *2001: A Space Odyssey*, *The Matrix*, *Terminator*). Preserved pre-v1.2 metallurgical-era names under §2's Legacy Registry. Added explicit statement that the standard's name was decoupled from project naming and would survive any project or umbrella rename (subsequently revisited in v1.7's umbrella rename). Renamed `Lattice` to `Bravais` (collision with Lattice OS) in registry and §13.1 subdomain table. Flagged `Mawaqit` as pending rename under the v1.2 convention. -- **v1.1 (2026-05-06):** Added §5 Project Posture (personal-hobby default, general-use carve-out, required posture files). Renumbered prior §5–§13 to §6–§14. Added posture bullet to compliance checklist. - **v1.0 (2026-03-08):** Initial release. ---- +———————————————————————— -## §2 — Aerospace, Sci-Fi & AI Naming Convention +# §2 — Aerospace, Sci-Fi & AI Naming Convention -All **new** project codenames, module identifiers, and public-facing component names **must** draw from one of the following domains: +All **new** project codenames, module identifiers, and public-facing +component names **must** draw from one of the following domains: -- **Real aerospace and astronomy** — orbital mechanics terms, propulsion concepts, named missions/programs, stellar objects and phenomena, observatories. -- **Science-fiction franchises with space / AI / cybernetic themes** — naming is meant to be enjoyable as well as fitting. The following are explicitly endorsed canonical sources: - - *2001: A Space Odyssey*, *The Matrix*, *Terminator* — the original canonical trio - - *The Hitchhiker's Guide to the Galaxy* — also a rich vein for in-jokes (Vogon, Marvin, 42, Babel fish, Heart of Gold) - - *Hackers* (1995) - - Spielberg films (*Close Encounters of the Third Kind*, *E.T. the Extra-Terrestrial*, *A.I. Artificial Intelligence*, *Minority Report*, *Ready Player One*, etc.) - - *Ghost in the Shell* - - *Equilibrium* - - *Dune* - - *Æon Flux* - - *Super 8* - - *LOST* (TV series) - - *Cloverfield* films - - Robot / android names from any sci-fi film or franchise (e.g., HAL, Data, Bishop, T-800, GERTY, TARS, Marvin) +- **Real aerospace and astronomy** — orbital mechanics terms, propulsion + concepts, named missions/programs, stellar objects and phenomena, + observatories. - Other franchises (e.g., *Alien*, *Blade Runner*, *Ex Machina*) remain acceptable if they fit the space-machine-AI register. -- **Generic sci-fi / AI vocabulary** — hyperspace, neural, cybernetic, synthetic, sentinel, oracle, daemon, vector, lattice (the lowercase common noun), etc. +- **Science-fiction franchises with space / AI / cybernetic themes** — + naming is meant to be enjoyable as well as fitting. The following are + explicitly endorsed canonical sources: -| Category | Examples | Domain | -|-----------|-------------------------------------|---------------------------------| -| Projects | Apollo, Discovery, Skynet, Trinity | Missions / Ships / AI Machines | -| Modules | Apogee, HAL, Cortex, Sentinel | Subsystems / AI Cores | -| Utilities | Boost, Throttle, Trace, Telemetry | Operational Verbs / Telemetry | -| Releases | Vega, Pulsar, Quasar, Nebula | Stellar Phenomena | + - *2001: A Space Odyssey*, *The Matrix*, *Terminator* — the original + canonical trio -Names must be **fitting for space-related and futuristic AI machines** — the test is whether the name would feel at home on the hull of a spacecraft or in the boot banner of an AI machine. Reject proposed names that don't pass this test. + - *The Hitchhiker’s Guide to the Galaxy* — also a rich vein for + in-jokes (Vogon, Marvin, 42, Babel fish, Heart of Gold) -### §2.1 — Legacy Metallurgical Registry (pre-v1.2) + - *Hackers* (1995) -Projects named before the v1.2 convention drew from metallurgy, materials science, and industrial forging. These names are **preserved as-is** unless explicitly renamed by the maintainer. The v1.2 convention applies prospectively — no forced back-rename. + - Spielberg films (*Close Encounters of the Third Kind*, *E.T. the + Extra-Terrestrial*, *A.I. Artificial Intelligence*, *Minority + Report*, *Ready Player One*, etc.) -| Codename | Status | Description | -|-------------|-----------------------|----------------------------------------------------------------| -| `Steelbore` | Renamed to Spacecraft Software (umbrella, v1.7) | Former umbrella organization name. Renamed 2026-05-15 under the v1.7 brand consolidation. The OS line (`Steelbore OS`, `Steelbore OS Bravais`, `Steelbore OS Lattice`) retains the Steelbore name. | -| `Aetheric` | Active | Next-generation extensible text editor (Pulsar + Quasar + Nebula IPC). | -| `Zamak` | Active | Rust bootloader (Limine rewrite) | -| `Bravais` | Completed (renamed) | NixOS flake configuration. Renamed from `Lattice` due to collision with Lattice OS. `Bravais` is still a metallurgical-era name (Bravais lattice) and predates the v1.2 convention. | -| `Ferrocast` | Planning | Rust PowerShell rewrite (16-crate workspace) | -| `Craton` | Reserved | Rust universal package manager — codename registered; no work started yet. | -| `Ironway` | Active | Rust OpenTTD rewrite | -| `Caliper` | Active | Rust raster-to-vector tracing engine (CLI+TUI) | -| `Mawaqit` | Planning (**Pending rename**) | Islamic prayer times app (Flutter + Rust CLI + libmawaqit). To be renamed under the v1.2 aerospace/sci-fi/AI convention. | -| `Anvil` | Completed | Rust workspace; benches and CHANGELOG; legacy forging-tool name. | -| `Flux` | Completed | Rust workspace; CHANGELOG and deny.toml; legacy metallurgical-flux name. | -| `Pearlite` | Active | Rust workspace; audit.toml, clippy.toml, CHANGELOG; steel microstructure name. | -| `Ferrite_OS`| Active | Custom OS / DOS-emulation experiments; ferrite (iron-based material) name. | -| `Forge` | Active | Production flavor tooling (forge-cli, forge-build, forge-activate); forging-tool name. | + - *Ghost in the Shell* + + - *Equilibrium* + + - *Dune* + + - *Æon Flux* + + - *Super 8* -Existing legacy-named projects MAY be renamed under the v1.2 convention at the maintainer's discretion — renames are optional. When a rename happens, update this table and §15.1's subdomain table in the same commit. + - *LOST* (TV series) -### §2.2 — Skill IDs are functional, not codenamed + - *Cloverfield* films -Skill directory names and `SKILL.md` `name` fields are **functional identifiers** (e.g., `spacecraft-standard`, `spacecraft-document-format`) and are not subject to the §2 codename convention. §2 reserves codenames for projects/modules/utilities/releases, not for skill identifiers. + - Robot / android names from any sci-fi film or franchise (e.g., HAL, + Data, Bishop, T-800, GERTY, TARS, Marvin) ---- + Other franchises (e.g., *Alien*, *Blade Runner*, *Ex Machina*) remain + acceptable if they fit the space-machine-AI register. -## §3 — Priority Hierarchy (Non-Negotiable Order) +- **Generic sci-fi / AI vocabulary** — hyperspace, neural, cybernetic, + synthetic, sentinel, oracle, daemon, vector, lattice (the lowercase + common noun), etc. -A higher-numbered priority **may never compromise** a lower-numbered one. +| Category | Examples | Domain | +|----|----|----| +| Projects | Apollo, Discovery, Skynet, Trinity | Missions / Ships / AI Machines | +| Modules | Apogee, HAL, Cortex, Sentinel | Subsystems / AI Cores | +| Utilities | Boost, Throttle, Trace, Telemetry | Operational Verbs / Telemetry | +| Releases | Vega, Pulsar, Quasar, Nebula | Stellar Phenomena | -### §3.1 — Priority 1: Stability +Names must be **fitting for space-related and futuristic AI machines** — +the test is whether the name would feel at home on the hull of a +spacecraft or in the boot banner of an AI machine. Reject proposed names +that don’t pass this test. -Software must behave predictably and remain correct under sustained and adverse conditions. Stability is the foremost priority. **Memory safety is the single most important contributor to stability and the primary means of achieving it — but it is not the whole of Priority 1.** +## §2.1 — Legacy Metallurgical Registry (pre-v1.2) + +Projects named before the v1.2 convention drew from metallurgy, +materials science, and industrial forging. These names are **preserved +as-is** unless explicitly renamed by the maintainer. The v1.2 convention +applies prospectively — no forced back-rename. + +| Codename | Status | Description | +|----|----|----| +| `Steelbore` | Renamed to Spacecraft Software (umbrella, v1.7) | Former umbrella organization name. Renamed 2026-05-15 under the v1.7 brand consolidation. The OS line (`Steelbore OS`, `Steelbore OS Bravais`, `Steelbore OS Lattice`) retains the Steelbore name. | +| `Aetheric` | Deprecated | Next-generation extensible text editor (Pulsar + Quasar + Nebula IPC). | +| `Zamak` | Active | Rust bootloader (Limine rewrite) | +| `Bravais` | Completed (renamed) | NixOS flake configuration. Renamed from `Lattice` due to collision with Lattice OS. `Bravais` is still a metallurgical-era name (Bravais lattice) and predates the v1.2 convention. | +| `Ferrocast` | Deprecated | Rust PowerShell rewrite (16-crate workspace) | +| `Craton` | Reserved | Rust universal package manager — codename registered; no work started yet. | +| `Ironway` | Active | Rust OpenTTD rewrite | +| `Caliper` | Active | Rust raster-to-vector tracing engine (CLI+TUI) | +| `Mawaqit` | Planning (**Pending rename**) | Islamic prayer times app (Flutter + Rust CLI + libmawaqit). To be renamed under the v1.2 aerospace/sci-fi/AI convention. | +| `Anvil` | Completed | Rust workspace; benches and CHANGELOG; legacy forging-tool name. | +| `Flux` | Completed | Rust workspace; CHANGELOG and deny.toml; legacy metallurgical-flux name. | +| `Pearlite` | Active | Rust workspace; audit.toml, clippy.toml, CHANGELOG; steel microstructure name. | +| `Ferrite_OS` | Active | Custom OS / DOS-emulation experiments; ferrite (iron-based material) name. | +| `Forge` | Active | Production flavor tooling (forge-cli, forge-build, forge-activate); forging-tool name. | + +Existing legacy-named projects MAY be renamed under the v1.2 convention +at the maintainer’s discretion — renames are optional. When a rename +happens, update this table and §15.1’s subdomain table in the same +commit. + +## §2.2 — Skill IDs are functional, not codenamed + +Skill directory names and `SKILL.md` `name` fields are **functional +identifiers** (e.g., `spacecraft-standard`, +`spacecraft-document-format`) and are not subject to the §2 codename +convention. §2 reserves codenames for +projects/modules/utilities/releases, not for skill identifiers. + +———————————————————————— + +# §3 — Priority Hierarchy (Non-Negotiable Order) + +A higher-numbered priority **may never compromise** a lower-numbered +one. + +## §3.1 — Priority 1: Stability + +Software must behave predictably and remain correct under sustained and +adverse conditions. Stability is the foremost priority. **Memory safety +is the single most important contributor to stability and the primary +means of achieving it — but it is not the whole of Priority 1.** **Memory safety (primary lever):** -- **Preferred language: Rust** — governed by the Spacecraft Software Rust Guidelines. Always load the `microsoft-rust-guidelines` skill before writing any Rust code. -- When Rust is not viable (Flutter/Dart, Zig, etc.), **mandatory mitigations**: - - **ASLR** (Address Space Layout Randomization) on all compiled binaries - - **CFI** (Control-Flow Integrity) wherever the toolchain supports it -- Memory-Safe Languages (MSLs) are always preferred. If an MSL alternative exists, it must be chosen unless a documented technical exemption is filed. +- **Preferred language: Rust** — governed by the Spacecraft Software + Rust Guidelines. Always load the `microsoft-rust-guidelines` skill + before writing any Rust code. + +- When Rust is not viable (Flutter/Dart, Zig, etc.), **mandatory + mitigations**: + + - **ASLR** (Address Space Layout Randomization) on all compiled + binaries + + - **CFI** (Control-Flow Integrity) wherever the toolchain supports it + +- Memory-Safe Languages (MSLs) are always preferred. If an MSL + alternative exists, it must be chosen unless a documented technical + exemption is filed. **Beyond memory safety, stability also requires:** -- **Robust error handling** — failures must be surfaced and handled, never silently swallowed; no panics / `unwrap` / `expect` on untrusted or fallible input in production paths. -- **Fault tolerance and graceful degradation** — components must survive partial failure, degrade gracefully under load or dependency loss, and recover rather than crash. -- **Verified by testing** — stability properties must be backed by tests (unit, integration, and fuzz/property where applicable) gating CI, not asserted by inspection alone. +- **Robust error handling** — failures must be surfaced and handled, + never silently swallowed; no panics / `unwrap` / `expect` on untrusted + or fallible input in production paths. + +- **Fault tolerance and graceful degradation** — components must survive + partial failure, degrade gracefully under load or dependency loss, and + recover rather than crash. + +- **Verified by testing** — stability properties must be backed by tests + (unit, integration, and fuzz/property where applicable) gating CI, not + asserted by inspection alone. + +## §3.2 — Priority 2: Performance -### §3.2 — Priority 2: Performance +Performance is the foremost priority after stability. The default means +of achieving it is **multi-core, multi-thread concurrency** — +parallelism is the expected baseline, not an afterthought — *unless* +concurrency would materially degrade performance (synchronization +overhead, lock contention, or inherently serial / small workloads +outweighing the gains), in which case a simpler or serial approach must +be chosen and the trade-off documented. -Performance is the foremost priority after stability. The default means of achieving it is **multi-core, multi-thread concurrency** — parallelism is the expected baseline, not an afterthought — *unless* concurrency would materially degrade performance (synchronization overhead, lock contention, or inherently serial / small workloads outweighing the gains), in which case a simpler or serial approach must be chosen and the trade-off documented. +- Concurrency must be **designed-in from the start**, never bolted on + retroactively. -- Concurrency must be **designed-in from the start**, never bolted on retroactively. -- Release builds should use CPU-optimized flags — `-march=native`, LTO, PGO — **where the toolchain and target support them reliably.** Any such flag known to break or destabilize builds on a given platform, toolchain, or linker configuration (e.g., LTO under certain NixOS, cross-compilation, or static-linking setups) MUST be disabled and the reason documented. Stability (Priority 1) outranks Performance (Priority 2), so a build-breaking or instability-inducing optimization always yields — never ship a broken build for the sake of a flag. -- Benchmarking is **mandatory** before and after any optimization work; regressions must be documented and justified — and it is the evidence by which the concurrency-vs-serial trade-off above is decided. +- Release builds should use CPU-optimized flags — `-march=native`, LTO, + PGO — **where the toolchain and target support them reliably.** Any + such flag known to break or destabilize builds on a given platform, + toolchain, or linker configuration (e.g., LTO under certain NixOS, + cross-compilation, or static-linking setups) MUST be disabled and the + reason documented. Stability (Priority 1) outranks Performance + (Priority 2), so a build-breaking or instability-inducing optimization + always yields — never ship a broken build for the sake of a flag. -### §3.3 — Priority 3: Security by Design +- Benchmarking is **mandatory** before and after any optimization work; + regressions must be documented and justified — and it is the evidence + by which the concurrency-vs-serial trade-off above is decided. + +## §3.3 — Priority 3: Security by Design - Kernel hardening (XanMod, grsecurity profiles) where applicable. + - Sandboxing and privilege separation for all network-facing components. -- **Post-Quantum Cryptography (PQC) readiness:** all crypto subsystems must support PQC migration paths. Use hybrid schemes (classical + PQC candidate) where library support exists. Adopt NIST-finalized PQC standards within one major release cycle. - - Current targets: **ML-KEM-768**, **ML-DSA-65** (as used in Ferrocast) -- Dependency auditing: `cargo-audit` or equivalent before any third-party crate inclusion. -**Cardinal Rule:** Any optimization that weakens **stability (including memory safety)** or security hardening **must be rejected**, no exceptions. +- **Post-Quantum Cryptography (PQC) readiness:** all crypto subsystems + must support PQC migration paths. Use hybrid schemes (classical + PQC + candidate) where library support exists. Adopt NIST-finalized PQC + standards within one major release cycle. + + - Current targets: **ML-KEM-768**, **ML-DSA-65** (as used in + Ferrocast) + +- Dependency auditing: `cargo-audit` or equivalent before any + third-party crate inclusion. + +**Cardinal Rule:** Any optimization that weakens **stability (including +memory safety)** or security hardening **must be rejected**, no +exceptions. ---- +———————————————————————— -## §4 — Licensing & Compliance +# §4 — Licensing & Compliance -### §4.1 — Project License (GPL-3.0-or-later or AGPL-3.0-or-later) +## §4.1 — Project License (GPL-3.0-or-later or AGPL-3.0-or-later) -- **License:** strong copyleft — each project chooses **`GPL-3.0-or-later`** or **`AGPL-3.0-or-later`**, whichever fits the project better: - - Use **`AGPL-3.0-or-later`** when the software is **network-facing** — anything users interact with primarily over a network (servers, web services, SaaS, hosted APIs, multiplayer/network daemons). AGPL closes the "SaaS loophole" by extending the source-availability obligation to users served over a network. - - Use **`GPL-3.0-or-later`** for everything else (local CLIs, libraries, desktop/TUI apps, OS components, bootloaders). - - GPLv3 and AGPLv3 are mutually compatible by design, so an umbrella mixing both is fine. -- No proprietary, closed-source, or permissive-only license for core project code. -- **Review & migrate (existing projects).** This dual choice is not merely prospective: existing projects are to be **reviewed and relicensed** to whichever of `GPL-3.0-or-later` / `AGPL-3.0-or-later` best fits them (AGPL for network-facing software). Migration is the maintainer's per-project decision, landed on that project's own signed commit; any project that deliberately retains a non-best-fit license must document why. +- **License:** strong copyleft — each project chooses + **`GPL-3.0-or-later`** or **`AGPL-3.0-or-later`**, whichever fits the + project better: -#### §4.1.1 — Artifact license classes + - Use **`AGPL-3.0-or-later`** when the software is **network-facing** + — anything users interact with primarily over a network (servers, + web services, SaaS, hosted APIs, multiplayer/network daemons). AGPL + closes the "SaaS loophole" by extending the source-availability + obligation to users served over a network. -The GPL/AGPL choice above governs **software**. License by artifact class: + - Use **`GPL-3.0-or-later`** for everything else (local CLIs, + libraries, desktop/TUI apps, OS components, bootloaders). + + - GPLv3 and AGPLv3 are mutually compatible by design, so an umbrella + mixing both is fine. + +- No proprietary, closed-source, or permissive-only license for core + project code. + +- **Review & migrate (existing projects).** This dual choice is not + merely prospective: existing projects are to be **reviewed and + relicensed** to whichever of `GPL-3.0-or-later` / `AGPL-3.0-or-later` + best fits them (AGPL for network-facing software). Migration is the + maintainer’s per-project decision, landed on that project’s own signed + commit; any project that deliberately retains a non-best-fit license + must document why. + +### §4.1.1 — Artifact license classes + +The GPL/AGPL choice above governs **software**. License by artifact +class: | Artifact class | Default license | -|----------------|-----------------| +|----|----| | **Software** — code, manifests, build tooling, and **skills** | `GPL-3.0-or-later` (or `AGPL-3.0-or-later` if network-facing, §4.1) | | **Documents** — specifications, prose guides, books, and document deliverables produced per the `spacecraft-document-format` skill, including the published Standard | `CC-BY-SA-4.0` by default (`CC-BY-4.0` permitted when a document is intended for maximal reuse) | | **Third-party-derived artifacts** | Preserve the **upstream** license per §4.2 (e.g., `MIT`, `GFDL-1.3-or-later`) — never relicensed to the project default | -Skills are **software-class** → `GPL-3.0-or-later` (no skill is network-facing, so AGPL does not apply). Note the deliberate split for the Standard itself: the **published Standard document** is `CC-BY-SA-4.0` (it is a document), while its `spacecraft-standard` **skill** encoding is `GPL-3.0-or-later` (it is a skill). +Skills are **software-class** → `GPL-3.0-or-later` (no skill is +network-facing, so AGPL does not apply). Note the deliberate split for +the Standard itself: the **published Standard document** is +`CC-BY-SA-4.0` (it is a document), while its `spacecraft-standard` +**skill** encoding is `GPL-3.0-or-later` (it is a skill). -### §4.2 — Upstream License Compliance (preserve what you build on) +## §4.2 — Upstream License Compliance (preserve what you build on) -When a project incorporates, adapts, or links third-party code, it MUST satisfy that upstream's license in full — independent of the project's own GPL/AGPL choice: +When a project incorporates, adapts, or links third-party code, it MUST +satisfy that upstream’s license in full — independent of the project’s +own GPL/AGPL choice: -- **Preserve verbatim** all upstream copyright notices, license texts, `NOTICE`/`AUTHORS` files, and in-file license headers — never strip, rewrite, or relicense them. -- **Ship** each distinct upstream license text in the project's `LICENSES/` directory (§4.3). -- **Verify compatibility** of the upstream license with the project's GPL/AGPL license before inclusion. -- This is the legal/mechanical obligation; §15.3's `CREDITS.md` is the human-readable narrative counterpart. When both are triggered, both apply. +- **Preserve verbatim** all upstream copyright notices, license texts, + `NOTICE`/`AUTHORS` files, and in-file license headers — never strip, + rewrite, or relicense them. -### §4.3 — SPDX & REUSE Compliance +- **Ship** each distinct upstream license text in the project’s + `LICENSES/` directory (§4.3). -Spacecraft Software follows the **[REUSE specification](https://reuse.software)** for unambiguous, machine-readable license and copyright metadata. Every project MUST be `reuse lint`-clean. +- **Verify compatibility** of the upstream license with the project’s + GPL/AGPL license before inclusion. + +- This is the legal/mechanical obligation; §15.3’s `CREDITS.md` is the + human-readable narrative counterpart. When both are triggered, both + apply. + +## §4.3 — SPDX & REUSE Compliance + +Spacecraft Software follows the **[REUSE +specification](https://reuse.software)** for unambiguous, +machine-readable license and copyright metadata. Every project MUST be +`reuse lint`-clean. **Every file carries two SPDX tags** — copyright *and* license: -``` -// SPDX-FileCopyrightText: 2026 Mohamed Hammad -// SPDX-License-Identifier: GPL-3.0-or-later -``` + // SPDX-FileCopyrightText: 2026 Mohamed Hammad + // SPDX-License-Identifier: GPL-3.0-or-later + +(Substitute the project’s actual license — `GPL-3.0-or-later` or +`AGPL-3.0-or-later` — and the correct comment syntax for the file type.) + +- **Software source files** (`.rs`, `.ts`, `.js`, `.py`, `.sh`, `.ps1`, + `.go`, etc.) and project manifests (`Cargo.toml`, `package.json`, + `flake.nix`, etc.) carry both tags as an inline header. -(Substitute the project's actual license — `GPL-3.0-or-later` or `AGPL-3.0-or-later` — and the correct comment syntax for the file type.) +- **Files that cannot carry an inline header** — documents (`.odt`, + `.ods`, `.odp`, `.docx`, `.xlsx`, `.pptx`, `.pdf`, …), images, binary + assets, generated files — are covered by a `.license` sidecar file + **or** an entry in the repo-root `REUSE.toml`. No file is left + uncovered (this replaces the former blanket "documents are exempt" + rule). + +- **`LICENSES/` directory:** the verbatim text of every license used in + the repo lives in `LICENSES/.txt` (e.g., + `LICENSES/GPL-3.0-or-later.txt`, `LICENSES/AGPL-3.0-or-later.txt`, + plus any upstream licenses per §4.2). A root `LICENSE` file MAY remain + as a pointer for GitHub’s license detection. -- **Software source files** (`.rs`, `.ts`, `.js`, `.py`, `.sh`, `.ps1`, `.go`, etc.) and project manifests (`Cargo.toml`, `package.json`, `flake.nix`, etc.) carry both tags as an inline header. -- **Files that cannot carry an inline header** — documents (`.odt`, `.ods`, `.odp`, `.docx`, `.xlsx`, `.pptx`, `.pdf`, …), images, binary assets, generated files — are covered by a `.license` sidecar file **or** an entry in the repo-root `REUSE.toml`. No file is left uncovered (this replaces the former blanket "documents are exempt" rule). -- **`LICENSES/` directory:** the verbatim text of every license used in the repo lives in `LICENSES/.txt` (e.g., `LICENSES/GPL-3.0-or-later.txt`, `LICENSES/AGPL-3.0-or-later.txt`, plus any upstream licenses per §4.2). A root `LICENSE` file MAY remain as a pointer for GitHub's license detection. - **CI gate:** `reuse lint` MUST pass before shipping. -When writing or reviewing any file, confirm REUSE coverage; when generating a new file, add the two-tag header (or the `.license` sidecar / `REUSE.toml` entry for files that can't carry one). +When writing or reviewing any file, confirm REUSE coverage; when +generating a new file, add the two-tag header (or the `.license` sidecar +/ `REUSE.toml` entry for files that can’t carry one). ---- +———————————————————————— -## §5 — Project Posture +# §5 — Project Posture -Spacecraft Software is a personal hobby project. This posture is the **default** for every project under the umbrella and is non-negotiable. Individual projects may adopt a more open posture (see §5.3) but never a more closed one. +Spacecraft Software is a personal hobby project. This posture is the +**default** for every project under the umbrella and is non-negotiable. +Individual projects may adopt a more open posture (see §5.3) but never a +more closed one. -§4 defines the formal license; this section defines the **stated stance** that sits alongside it. License says what the user *may* do; posture says what they should *expect* from the maintainer. +§4 defines the formal license; this section defines the **stated +stance** that sits alongside it. License says what the user *may* do; +posture says what they should *expect* from the maintainer. -### §5.1 — Default Posture (Personal / Hobby) +## §5.1 — Default Posture (Personal / Hobby) -| Aspect | Default | -|----------------|----------------------------------------------------------------| -| Audience | Maintainer's own use case | -| Pace | Hobby pace; no service-level commitments | -| Warranty | None — provided AS IS | -| Liability | None — see project `NOTICE.md` | -| Contributions | Welcome but not guaranteed to be accepted | -| Forking | Encouraged | -| License | GPL-3.0-or-later or AGPL-3.0-or-later, per §4.1 (formal terms govern in any conflict) | +| Aspect | Default | +|----|----| +| Audience | Maintainer’s own use case | +| Pace | Hobby pace; no service-level commitments | +| Warranty | None — provided AS IS | +| Liability | None — see project `NOTICE.md` | +| Contributions | Welcome but not guaranteed to be accepted | +| Forking | Encouraged | +| License | GPL-3.0-or-later or AGPL-3.0-or-later, per §4.1 (formal terms govern in any conflict) | -### §5.2 — Required Posture Files (per project) +## §5.2 — Required Posture Files (per project) -Every Spacecraft Software project repository **must** ship the following files at its root, derived from the canonical Spacecraft Software templates: +Every Spacecraft Software project repository **must** ship the following +files at its root, derived from the canonical Spacecraft Software +templates: -| File | Purpose | -|-------------------|-------------------------------------------------------------| -| `README.md` | Includes a "Project Posture" section linking to the two below | -| `NOTICE.md` | Full no-warranty / no-liability statement; defers to the project's GPL/AGPL license (§4.1) for binding terms | +| File | Purpose | +|----|----| +| `README.md` | Includes a "Project Posture" section linking to the two below | +| `NOTICE.md` | Full no-warranty / no-liability statement; defers to the project’s GPL/AGPL license (§4.1) for binding terms | | `CONTRIBUTING.md` | Contribution scope, PR-acceptance discretion, sign-off, security reporting, license-of-contributions | -| `LICENSES/` | REUSE license directory (§4.3): verbatim text of every license used (`GPL-3.0-or-later` or `AGPL-3.0-or-later`, plus any upstream licenses per §4.2). A root `LICENSE` MAY remain as a GitHub-detection pointer. | +| `LICENSES/` | REUSE license directory (§4.3): verbatim text of every license used (`GPL-3.0-or-later` or `AGPL-3.0-or-later`, plus any upstream licenses per §4.2). A root `LICENSE` MAY remain as a GitHub-detection pointer. | -Customize only the project name, scope, and any project-specific carve-outs. +Customize only the project name, scope, and any project-specific +carve-outs. -### §5.3 — General-Use Carve-Out +## §5.3 — General-Use Carve-Out A project may declare itself **intended for general use**. When it does: -- The declaration MUST appear in that project's `README.md` posture section. -- The no-warranty / no-liability stance from §5.1 still applies in full — general-use status changes audience and intent, **not** legal terms. -- General-use projects must hold a higher release-quality bar: semantic versioning, maintained `CHANGELOG.md`, deprecation policy, and a documented support window for the current major version. +- The declaration MUST appear in that project’s `README.md` posture + section. + +- The no-warranty / no-liability stance from §5.1 still applies in full + — general-use status changes audience and intent, **not** legal terms. + +- General-use projects must hold a higher release-quality bar: semantic + versioning, maintained `CHANGELOG.md`, deprecation policy, and a + documented support window for the current major version. **General-use registry** (keep in sync with §15.1 subdomain table): -| Project | Posture | -|--------------|---------------| -| Anvil-SSH | General-use | -| (all others) | Personal | +| Project | Posture | +|--------------|-------------| +| Anvil-SSH | General-use | +| (all others) | Personal | -### §5.4 — Maintainer Discretion +## §5.4 — Maintainer Discretion -PR acceptance, feature scope, naming, architecture, and roadmap are at the maintainer's sole discretion. This is stated openly so contributors can calibrate effort accordingly. Rejection reflects fit, not quality. +PR acceptance, feature scope, naming, architecture, and roadmap are at +the maintainer’s sole discretion. This is stated openly so contributors +can calibrate effort accordingly. Rejection reflects fit, not quality. -### §5.5 — Package Distribution Requirements +## §5.5 — Package Distribution Requirements -Every released package **must** ship first-party package definitions for the following package managers, committed alongside the release: +Every released package **must** ship first-party package definitions for +the following package managers, committed alongside the release: -| File | Package manager / format | -|-------------------------|-------------------------------------| +| File | Package manager / format | +|-------------------------|--------------------------------------| | `packaging/guix.scm` | GNU Guix — Scheme package definition | -| `packaging/default.nix` | Nix — Nix flake / derivation | -| `packaging/PKGBUILD` | Arch Linux — `makepkg`-compatible | +| `packaging/default.nix` | Nix — Nix flake / derivation | +| `packaging/PKGBUILD` | Arch Linux — `makepkg`-compatible | **Rules:** -- All three files MUST be present and buildable before a release tag is pushed. -- Each file must reference the exact release version and source archive SHA-256 checksum so that the package can be built reproducibly from the tagged release. Use the format native to each package manager: - - **Guix (`guix.scm`):** `(sha256 (base32 ""))` inside the `origin` stanza. - - **Nix (`default.nix`):** `sha256 = "";` inside the `fetchurl` or `fetchFromGitHub` call. - - **Arch (`PKGBUILD`):** `sha256sums=('')` array variable alongside `source=()`. -- The `packaging/` directory is tracked in the project's version-control repository alongside the source code. -- These files are software-class artifacts and inherit the project's GPL/AGPL license (§4.1); each file must carry the standard SPDX two-tag header (§4.3). -- If a package manager's ecosystem imposes a stricter naming scheme or directory layout, comply with that scheme while still meeting the above requirements. +- All three files MUST be present and buildable before a release tag is + pushed. + +- Each file must reference the exact release version and source archive + SHA-256 checksum so that the package can be built reproducibly from + the tagged release. Use the format native to each package manager: + + - **Guix (`guix.scm`):** `(sha256 (base32 ""))` + inside the `origin` stanza. + + - **Nix (`default.nix`):** `sha256 = "";` inside the + `fetchurl` or `fetchFromGitHub` call. + + - **Arch (`PKGBUILD`):** `sha256sums=('')` array variable + alongside `source=()`. + +- The `packaging/` directory is tracked in the project’s version-control + repository alongside the source code. + +- These files are software-class artifacts and inherit the project’s + GPL/AGPL license (§4.1); each file must carry the standard SPDX + two-tag header (§4.3). + +- If a package manager’s ecosystem imposes a stricter naming scheme or + directory layout, comply with that scheme while still meeting the + above requirements. ---- +———————————————————————— -## §6 — Platform & Systems Requirements +# §6 — Platform & Systems Requirements -### §6.1 — POSIX Compliance +## §6.1 — POSIX Compliance -All CLI tools, daemons, and system utilities must be **POSIX-compliant**. Platform-specific extensions go behind feature flags and must not be required for core functionality. +All CLI tools, daemons, and system utilities must be +**POSIX-compliant**. Platform-specific extensions go behind feature +flags and must not be required for core functionality. -### §6.2 — Post-Quantum Cryptography +## §6.2 — Post-Quantum Cryptography -Crypto subsystems must have migration paths to post-quantum algorithms. Current implementations should use hybrid schemes where library support exists. +Crypto subsystems must have migration paths to post-quantum algorithms. +Current implementations should use hybrid schemes where library support +exists. -### §6.3 — Signed & Verified Commits (Non-Negotiable) +## §6.3 — Signed & Verified Commits (Non-Negotiable) -Every commit pushed to a Spacecraft Software-controlled Git remote **must** be cryptographically signed and show "Verified" on the hosting platform's commit/PR view (GitHub today; Gitway or any future Spacecraft Software host inherits the same rule). +Every commit pushed to a Spacecraft Software-controlled Git remote +**must** be cryptographically signed and show "Verified" on the hosting +platform’s commit/PR view (GitHub today; Gitway or any future Spacecraft +Software host inherits the same rule). **Mandatory rules — violation blocks shipping:** | Rule | Detail | -|------|--------| +|----|----| | All commits signed | `commit.gpgsign=true` configured globally. SSH signing (`gpg.format=ssh`) is the current default; GPG is acceptable. The signing key MUST be registered as a **Signing** key on the hosting platform — Authentication-only keys do not validate signatures. | | Authorized signing identity | All commits from v1.12 onwards must be signed with the `Mohamed.Hammad@SpacecraftSoftware.org` key. The committer email and the signing key identity must both resolve to `Mohamed.Hammad@SpacecraftSoftware.org`. Commits predating v1.12 are exempt from this requirement. | -| Hosting-platform "Verified" required | Every commit on a Spacecraft Software remote must show "Verified" on the platform's commit/PR view. Unsigned or "Unverified" commits MUST be remediated (re-signed via rebase or amend by the original author) before merge to a default branch. | +| Hosting-platform "Verified" required | Every commit on a Spacecraft Software remote must show "Verified" on the platform’s commit/PR view. Unsigned or "Unverified" commits MUST be remediated (re-signed via rebase or amend by the original author) before merge to a default branch. | | Programmatic commits signed too | Bots, CI pipelines, scripted commits, and assistant-driven commits inherit the same rule — no `--no-gpg-sign`, no signing-disabled subshells. The signing pipeline runs unattended. | -| Rewrites preserve signatures | Rebase, amend, cherry-pick, and squash MUST re-sign each resulting commit. Don't push history that lost signatures through rewriting. | -| Local verification is best-effort | `git log --show-signature` may report "No signature" on a given host when `~/.ssh/allowed_signers` is not populated — this is a local-verifier gap, not a signing failure. The hosting platform's "Verified" badge is authoritative. | +| Rewrites preserve signatures | Rebase, amend, cherry-pick, and squash MUST re-sign each resulting commit. Don’t push history that lost signatures through rewriting. | +| Local verification is best-effort | `git log --show-signature` may report "No signature" on a given host when `~/.ssh/allowed_signers` is not populated — this is a local-verifier gap, not a signing failure. The hosting platform’s "Verified" badge is authoritative. | -**Algorithm note:** Ed25519 SSH signing is the current default. §6.2 calls for PQC readiness across the cryptographic surface; commit-signing algorithm migration is gated on hosting-platform support for post-quantum key formats. When GitHub (or Spacecraft Software's own Gitway) accepts PQC signing keys, Spacecraft Software commits migrate accordingly. +**Algorithm note:** Ed25519 SSH signing is the current default. §6.2 +calls for PQC readiness across the cryptographic surface; commit-signing +algorithm migration is gated on hosting-platform support for +post-quantum key formats. When GitHub (or Spacecraft Software’s own +Gitway) accepts PQC signing keys, Spacecraft Software commits migrate +accordingly. ---- +———————————————————————— -## §7 — Shell Environment +# §7 — Shell Environment -Spacecraft Software tooling, documentation, and CI pipelines target **four first-class shell environments**: **Nushell**, **Ion**, **Brush**, and **Bash**. All four are equally supported; none is deprecated or downgraded. +Spacecraft Software tooling, documentation, and CI pipelines target +**four first-class shell environments**: **Nushell**, **Ion**, +**Brush**, and **Bash**. All four are equally supported; none is +deprecated or downgraded. -### §7.1 — Script Portability Policy +## §7.1 — Script Portability Policy | Rule | Detail | -|------|--------| +|----|----| | Default: POSIX-compatible | Shell scripts in source trees, CI pipelines, `Makefile` targets, and documentation examples **must** be written to the POSIX sh subset unless a shell-native feature is required. POSIX scripts run correctly in Bash and Brush without modification. | | Nushell / Ion native variants when needed | When a task cannot be expressed cleanly in POSIX sh (structured data pipelines, typed parameters, Nushell modules), provide a Nushell (`.nu`) and/or Ion-native variant alongside the POSIX version. Do not force POSIX-only idioms that degrade the Nushell or Ion experience. | | No Bashisms in shared scripts | Bash-only extensions (`[[ ]]`, `(( ))`, process substitution `<(...)`, `${var^^}`, indexed arrays) are prohibited in files intended for all four shells. Bash-specific scripts are permitted only when explicitly scoped (e.g., `#!/usr/bin/env bash` shebang, clearly labeled). | | Graceful shell detection | Tools that need runtime shell detection must inform the user or degrade gracefully rather than silently failing in non-Bash environments. | ---- +———————————————————————— -## §8 — Documentation (Texinfo) +# §8 — Documentation (Texinfo) -Spacecraft Software user-facing projects should ship a **Texinfo manual** as the canonical technical reference. Texinfo is the preferred format for reference documentation that accompanies distributed software, following GNU project conventions. +Spacecraft Software user-facing projects should ship a **Texinfo +manual** as the canonical technical reference. Texinfo is the preferred +format for reference documentation that accompanies distributed +software, following GNU project conventions. -### §8.1 — When a Texinfo Manual Is Required +## §8.1 — When a Texinfo Manual Is Required | Project type | Requirement | -|---|---| +|----|----| | CLI / TUI / GUI application with substantive user-facing functionality | **MUST** ship a Texinfo manual covering invocation, options, concepts, and examples | | Library with a public API | **SHOULD** ship a Texinfo reference manual covering all public interfaces | | Simple script / internal tooling | **MAY** skip; a well-structured `README.md` suffices | -### §8.2 — Source Format and File Layout +## §8.2 — Source Format and File Layout - Source files use the `.texi` extension (Texinfo 7.x+). + - Manuals live at `doc/.texi` in the project root. -- The project's top-level `Makefile` must expose three targets: `make info`, `make html`, `make pdf`. -### §8.3 — Required Structural Elements +- The project’s top-level `Makefile` must expose three targets: + `make info`, `make html`, `make pdf`. + +## §8.3 — Required Structural Elements Every Texinfo manual must include the following elements: -| Element | Purpose | -|---|---| +| Element | Purpose | +|------------------------------|--------------------------------------------| | `@dircategory` / `@direntry` | Registers the manual in the Info directory | -| `@copying` block | License statement and copyright notice | -| `@titlepage` | Title, version, author, and copyright | -| `@node Top` + `@top` | Required top-level node for Info readers | -| `@menu` per chapter | Navigation structure | +| `@copying` block | License statement and copyright notice | +| `@titlepage` | Title, version, author, and copyright | +| `@node Top` + `@top` | Required top-level node for Info readers | +| `@menu` per chapter | Navigation structure | -### §8.4 — Output Formats +## §8.4 — Output Formats Build and ship all three output formats: -| Format | Tool | Purpose | -|---|---|---| +| Format | Tool | Purpose | +|---------|-------------------------|-----------------------------------------| | `.info` | `makeinfo` / `texi2any` | Info readers (Emacs, standalone `info`) | -| `.html` | `makeinfo --html` | Project documentation website | -| `.pdf` | `texi2pdf` | Printable reference | +| `.html` | `makeinfo --html` | Project documentation website | +| `.pdf` | `texi2pdf` | Printable reference | -Install `.info` files using `install-info` at package install time so they appear in the system Info directory. +Install `.info` files using `install-info` at package install time so +they appear in the system Info directory. -### §8.5 — Licensing +## §8.5 — Licensing -Texinfo manuals are **document-class** artifacts (§4.1.1) and default to **CC-BY-SA-4.0**. **GFDL-1.3-or-later** is a permitted alternative when the manual is distributed alongside GPL-licensed software and compatibility with GNU documentation collections is desired. Include the chosen license in `LICENSES/` per §4.3. +Texinfo manuals are **document-class** artifacts (§4.1.1) and default to +**CC-BY-SA-4.0**. **GFDL-1.3-or-later** is a permitted alternative when +the manual is distributed alongside GPL-licensed software and +compatibility with GNU documentation collections is desired. Include the +chosen license in `LICENSES/` per §4.3. -### §8.6 — Packaging Integration +## §8.6 — Packaging Integration -Package manifests must install the `.info` file and register it with `install-info`: +Package manifests must install the `.info` file and register it with +`install-info`: | Package manager | Requirements | -|---|---| +|----|----| | **Guix** (`packaging/guix.scm`) | Add `texinfo` as a native input; run `install-info` in the install phase | | **Nix** (`packaging/default.nix`) | Add `texinfo` to `nativeBuildInputs`; standard Autoconf/Make `installPhase` handles `install-info` automatically | | **PKGBUILD** (`packaging/PKGBUILD`) | Add `texinfo` to `makedepends`; `install -Dm644` for `.info` files; call `install-info` in `post_install` | ---- +———————————————————————— -## §9 — Privacy-Friendly Application (PFA) Policy +# §9 — Privacy-Friendly Application (PFA) Policy -Every Spacecraft Software application must satisfy **all three** PFA requirements: +Every Spacecraft Software application must satisfy **all three** PFA +requirements: -| Requirement | Rule | -|--------------------|--------------------------------------------------------------------------| -| No Tracking/No Ads | Zero advertising, tracking, analytics SDKs, or telemetry beacons | -| Minimal Permissions| Only essential permissions; requested lazily at point of use, never eagerly | -| Local Storage | User data stored locally by default; sync is strictly opt-in, E2E encrypted | +| Requirement | Rule | +|----|----| +| No Tracking/No Ads | Zero advertising, tracking, analytics SDKs, or telemetry beacons | +| Minimal Permissions | Only essential permissions; requested lazily at point of use, never eagerly | +| Local Storage | User data stored locally by default; sync is strictly opt-in, E2E encrypted | -When reviewing or designing any feature that touches data handling, permissions, or networking, verify all three PFA requirements are met. +When reviewing or designing any feature that touches data handling, +permissions, or networking, verify all three PFA requirements are met. ---- +———————————————————————— -## §10 — Key Bindings +# §10 — Key Bindings All interactive applications must support **both**: -| Scheme | Requirement | -|-----------|--------------------------------------------------------------------------| -| **CUA** | Standard bindings (Ctrl+C/X/V/Z/S) must work in all text input contexts | -| **Vim** | Modal editing layer (Normal / Insert / Visual mode) as opt-in feature. Minimum: hjkl navigation where full Vim layer is impractical | +| Scheme | Requirement | +|----|----| +| **CUA** | Standard bindings (Ctrl+C/X/V/Z/S) must work in all text input contexts | +| **Vim** | Modal editing layer (Normal / Insert / Visual mode) as opt-in feature. Minimum: hjkl navigation where full Vim layer is impractical | ---- +———————————————————————— -## §11 — Spacecraft Software Color Palette (WCAG-Compliant) +# §11 — Spacecraft Software Color Palette (WCAG-Compliant) -The **only** permitted colors for Spacecraft Software interfaces and documents: +The **only** permitted colors for Spacecraft Software interfaces and +documents: -| Token | Hex | RGB | Role | -|----------------|-----------|------------------|-------------------------------| -| Void Navy | `#000027` | RGB(0, 0, 39) | **Background / Canvas** | -| Molten Amber | `#D98E32` | RGB(217, 142, 50)| Primary Text / Active Readout | -| Steel Blue | `#4B7EB0` | RGB(75, 126, 176)| Primary Accent / Structural | -| Radium Green | `#50FA7B` | RGB(80, 250, 123)| Success / Safe Status | -| Red Oxide | `#FF5C5C` | RGB(255, 92, 92) | Warning / Error Status | -| Liquid Coolant | `#8BE9FD` | RGB(139, 233, 253)| Info / Links | +| Token | Hex | RGB | Role | +|----------------|-----------|--------------------|-------------------------------| +| Void Navy | `#000027` | RGB(0, 0, 39) | **Background / Canvas** | +| Molten Amber | `#D98E32` | RGB(217, 142, 50) | Primary Text / Active Readout | +| Steel Blue | `#4B7EB0` | RGB(75, 126, 176) | Primary Accent / Structural | +| Radium Green | `#50FA7B` | RGB(80, 250, 123) | Success / Safe Status | +| Red Oxide | `#FF5C5C` | RGB(255, 92, 92) | Warning / Error Status | +| Liquid Coolant | `#8BE9FD` | RGB(139, 233, 253) | Info / Links | -**`#000027` (Void Navy) is the mandatory background for ALL Spacecraft Software surfaces.** No alternative background is permitted. This is non-negotiable. +**`#000027` (Void Navy) is the mandatory background for ALL Spacecraft +Software surfaces.** No alternative background is permitted. This is +non-negotiable. -For document/file generation → load the `spacecraft-document-format` skill. For IDE/terminal themes → load the `spacecraft-theme-factory` skill. +For document/file generation → load the `spacecraft-document-format` +skill. For IDE/terminal themes → load the `spacecraft-theme-factory` +skill. -### §11.1 — Steelbore Theme (Application Theming Standard) +## §11.1 — Steelbore Theme (Application Theming Standard) -When building a new Spacecraft Software application (GUI, TUI, or web), all palette -references **must** be accessed through a named theme called **`Steelbore`** rather than -referenced as bare hex literals. The `Steelbore` theme is the canonical color contract: +When building a new Spacecraft Software application (GUI, TUI, or web), +all palette references **must** be accessed through a named theme called +**`Steelbore`** rather than referenced as bare hex literals. The +`Steelbore` theme is the canonical color contract: | Theme token | Maps to palette token | Hex | |--------------|-----------------------|-----------| @@ -449,61 +889,93 @@ referenced as bare hex literals. The `Steelbore` theme is the canonical color co | `error` | Red Oxide | `#FF5C5C` | | `info` | Liquid Coolant | `#8BE9FD` | -**Rationale:** isolating palette references behind the `Steelbore` theme name makes it trivial for end users to substitute a custom theme without touching application logic — swap the theme, not every hex literal. +**Rationale:** isolating palette references behind the `Steelbore` theme +name makes it trivial for end users to substitute a custom theme without +touching application logic — swap the theme, not every hex literal. + +- The theme file/module **must** be named `steelbore` (snake_case) in + the project’s theme registry, configuration layer, or equivalent + (e.g., `themes/steelbore.json`, `steelbore.toml`, a Rust + `Theme::Steelbore` variant). + +- Hard-coding palette hex values directly in UI logic is **forbidden** + for new apps. Use theme tokens exclusively. + +- Existing apps are encouraged but not required to migrate; new apps are + required. + +———————————————————————— -- The theme file/module **must** be named `steelbore` (snake_case) in the project's theme registry, configuration layer, or equivalent (e.g., `themes/steelbore.json`, `steelbore.toml`, a Rust `Theme::Steelbore` variant). -- Hard-coding palette hex values directly in UI logic is **forbidden** for new apps. Use theme tokens exclusively. -- Existing apps are encouraged but not required to migrate; new apps are required. +# §12 — Typography (FOSS-Licensed Fonts Only) ---- +Acceptable font licenses: **OFL, Apache 2.0, Ubuntu Font License, +CC0-1.0** -## §12 — Typography (FOSS-Licensed Fonts Only) +| Context | Font | License | +|-------------|--------------------|---------| +| Headings | Share Tech Mono | OFL | +| Body / Code | Inconsolata | OFL | +| Fallback | monospace (system) | N/A | -Acceptable font licenses: **OFL, Apache 2.0, Ubuntu Font License, CC0-1.0** +Never use proprietary fonts. When suggesting or using fonts in any +Spacecraft Software artifact, verify they are available on Google Fonts +or another FOSS-licensed repository. -| Context | Font | License | -|----------------|-------------------|---------| -| Headings | Share Tech Mono | OFL | -| Body / Code | Inconsolata | OFL | -| Fallback | monospace (system)| N/A | +———————————————————————— -Never use proprietary fonts. When suggesting or using fonts in any Spacecraft Software artifact, verify they are available on Google Fonts or another FOSS-licensed repository. +# §13 — UI/UX Design System ---- +- **Material Design** is the required component system for all graphical + applications. Theme Material components with the §11 color palette. -## §13 — UI/UX Design System +- **WCAG 2.1 Level AA** contrast is the minimum for all color pairings. + Any new color additions must be WCAG-verified before adoption. -- **Material Design** is the required component system for all graphical applications. Theme Material components with the §11 color palette. -- **WCAG 2.1 Level AA** contrast is the minimum for all color pairings. Any new color additions must be WCAG-verified before adoption. -- **Accessibility:** screen readers, keyboard-only navigation, and system accessibility preferences (reduced motion, high contrast) must all be respected. +- **Accessibility:** screen readers, keyboard-only navigation, and + system accessibility preferences (reduced motion, high contrast) must + all be respected. ---- +———————————————————————— -## §14 — Date, Time & Units +# §14 — Date, Time & Units -### §14.1 — Date & Time Format Rules +## §14.1 — Date & Time Format Rules -| Concern | Rule | Example | -|--------------|------------------------------------------------------------------|------------------------------| -| Date format | ISO 8601 only: `YYYY-MM-DD` | `2026-03-08` | -| Time format | 24-hour only: `HH:MM:SS` — AM/PM is **never** permitted | `14:30:00` | -| Timestamp | Combined ISO 8601 UTC: `YYYY-MM-DDTHH:MM:SSZ` | `2026-03-08T14:30:00Z` | -| Timezone | **UTC Z is the default and preferred primary** for general-purpose, cross-system, and machine-readable timestamps. A project whose core domain is inherently local-time-bound (e.g., solar/prayer-time calculations) may declare local time as its primary record instead — a documented exception, not a free choice. See §14.2 and §14.2.1 | `Z` not `+00:00` | -| Duration | ISO 8601 duration format only | `PT1H30M` not "1h 30m" | -| Units | Metric (SI) primary; imperial in parentheses only if locale requires | `100 km (62 mi)` | +| Concern | Rule | Example | +|----|----|----| +| Date format | ISO 8601 only: `YYYY-MM-DD` | `2026-03-08` | +| Time format | 24-hour only: `HH:MM:SS` — AM/PM is **never** permitted | `14:30:00` | +| Timestamp | Combined ISO 8601 UTC: `YYYY-MM-DDTHH:MM:SSZ` | `2026-03-08T14:30:00Z` | +| Timezone | **UTC Z is the default and preferred primary** for general-purpose, cross-system, and machine-readable timestamps. A project whose core domain is inherently local-time-bound (e.g., solar/prayer-time calculations) may declare local time as its primary record instead — a documented exception, not a free choice. See §14.2 and §14.2.1 | `Z` not `+00:00` | +| Duration | ISO 8601 duration format only | `PT1H30M` not "1h 30m" | +| Units | Metric (SI) primary; imperial in parentheses only if locale requires | `100 km (62 mi)` | -Apply these conventions to all generated code, documentation, comments, and any user-facing strings. Never output AM/PM time, non-ISO dates, or imperial-primary units. +Apply these conventions to all generated code, documentation, comments, +and any user-facing strings. Never output AM/PM time, non-ISO dates, or +imperial-primary units. -### §14.2 — UTC Z Timezone Policy +## §14.2 — UTC Z Timezone Policy -**UTC Z is the default and preferred timezone for stored, transmitted, logged, and committed timestamps across Spacecraft Software projects.** It is the convention every project should reach for first — it keeps cross-project tooling, sorting, and interchange simple and unambiguous. Under this default, the `Z` suffix is required on primary timestamps, and local time expressed as a UTC offset (e.g., `2026-05-24T13:34:55+03:00`) may optionally accompany a UTC Z value as a secondary, human-convenience field — but UTC Z remains the authoritative record. +**UTC Z is the default and preferred timezone for stored, transmitted, +logged, and committed timestamps across Spacecraft Software projects.** +It is the convention every project should reach for first — it keeps +cross-project tooling, sorting, and interchange simple and unambiguous. +Under this default, the `Z` suffix is required on primary timestamps, +and local time expressed as a UTC offset (e.g., +`2026-05-24T13:34:55+03:00`) may optionally accompany a UTC Z value as a +secondary, human-convenience field — but UTC Z remains the authoritative +record. -This is a strong default, not a universal mandate forced onto every domain regardless of fit — §14.2.1 documents the exception that lets a project whose domain is genuinely local-time-bound use local time as its primary record instead. +This is a strong default, not a universal mandate forced onto every +domain regardless of fit — §14.2.1 documents the exception that lets a +project whose domain is genuinely local-time-bound use local time as its +primary record instead. -**Rules for projects under the UTC Z default — apply unless a project has filed the §14.2.1 exception:** +**Rules for projects under the UTC Z default — apply unless a project +has filed the §14.2.1 exception:** | Rule | Detail | -|------|--------| +|----|----| | `Z` suffix required | Every **primary** stored/transmitted timestamp MUST end with `Z`. `2026-03-08T14:30:00Z` ✓. A companion local-time field with UTC offset is permitted alongside it. | | No offset notation as replacement | Offset notation (`+03:00`, `-05:00`, etc.) is **forbidden as a replacement** for UTC Z. It is permitted only as an optional companion field alongside a `Z`-suffixed primary. | | No bare local time in data | Local-time timestamps **without** timezone info are **forbidden** in files, databases, logs, API responses, and commits. | @@ -513,45 +985,86 @@ This is a strong default, not a universal mandate forced onto every domain regar ### §14.2.1 — Domain Exception: Inherently Local-Time-Bound Projects -A project whose core domain is fundamentally defined by **local civil or solar time** — not by a moment in absolute (UTC) time — may declare local time as the **primary** representation for that domain's data. Examples: prayer-time calculations (`Mawaqit`), sunrise/sunset tables, local event or business-hours scheduling. For data like this, the meaningful value *is* "06:14 local, at this place" — collapsing it to a UTC instant first and treating that as authoritative would misrepresent what the data actually is. +A project whose core domain is fundamentally defined by **local civil or +solar time** — not by a moment in absolute (UTC) time — may declare +local time as the **primary** representation for that domain’s data. +Examples: prayer-time calculations (`Mawaqit`), sunrise/sunset tables, +local event or business-hours scheduling. For data like this, the +meaningful value *is* "06:14 local, at this place" — collapsing it to a +UTC instant first and treating that as authoritative would misrepresent +what the data actually is. **Conditions for the exception:** -1. **Document it.** The project's README or spec must state explicitly which data uses local time as primary, and the *domain* reason why — not developer or user convenience. -2. **Keep the default everywhere else.** General-purpose machinery within the same project — logs, commit timestamps, internal cross-system APIs, telemetry — still follows the §14.2 UTC Z default. The exception covers the domain data itself, not the whole project. -3. **Preserve UTC derivability.** Store or compute the IANA timezone (e.g., `Africa/Cairo`) alongside the local value, so a UTC instant remains derivable for interchange, comparison, and storage portability. -4. **This is an exception, not an escape hatch.** "Local time is more convenient" or "our users are mostly in one timezone" do not qualify — the domain itself must be inherently local-time-bound. +1. **Document it.** The project’s README or spec must state explicitly + which data uses local time as primary, and the *domain* reason why — + not developer or user convenience. + +2. **Keep the default everywhere else.** General-purpose machinery + within the same project — logs, commit timestamps, internal + cross-system APIs, telemetry — still follows the §14.2 UTC Z + default. The exception covers the domain data itself, not the whole + project. + +3. **Preserve UTC derivability.** Store or compute the IANA timezone + (e.g., `Africa/Cairo`) alongside the local value, so a UTC instant + remains derivable for interchange, comparison, and storage + portability. + +4. **This is an exception, not an escape hatch.** "Local time is more + convenient" or "our users are mostly in one timezone" do not qualify + — the domain itself must be inherently local-time-bound. + +## §14.3 — Local Time as Optional Companion + +**For projects under the UTC Z default** (§14.2), local time expressed +as a UTC offset is permitted as an **optional companion** to the UTC Z +primary value — in human-facing display, in API responses (as an +additional field, never replacing the UTC Z field), and in stored +records where timezone context aids human readers. The UTC Z value is +always present and always authoritative; the local-time companion is +supplemental only. (A project operating under the §14.2.1 domain +exception inverts these roles for its domain data — local time is +primary there, with UTC kept derivable rather than displayed as +authoritative.) + +- The `--absolute-time` flag (defined in `spacecraft-cli-standard` §3) + disables relative-time rendering but always renders as UTC, not local + time. -### §14.3 — Local Time as Optional Companion +- If a future CLI wants to show local time in human mode, it MUST: -**For projects under the UTC Z default** (§14.2), local time expressed as a UTC offset is permitted as an **optional companion** to the UTC Z primary value — in human-facing display, in API responses (as an additional field, never replacing the UTC Z field), and in stored records where timezone context aids human readers. The UTC Z value is always present and always authoritative; the local-time companion is supplemental only. (A project operating under the §14.2.1 domain exception inverts these roles for its domain data — local time is primary there, with UTC kept derivable rather than displayed as authoritative.) + 1. Accept a `--tz ` flag (e.g., `--tz Africa/Cairo`). -- The `--absolute-time` flag (defined in `spacecraft-cli-standard` §3) disables relative-time rendering but always renders as UTC, not local time. -- If a future CLI wants to show local time in human mode, it MUST: - 1. Accept a `--tz ` flag (e.g., `--tz Africa/Cairo`). - 2. Render local time only to stdout in human mode — never in `--json` output. - 3. Always include the UTC value alongside the local rendering. - 4. Never persist or transmit the local-time rendering. -- JSON/machine output (`--format json/jsonl/yaml/csv`) MUST always use UTC + `Z`. + 2. Render local time only to stdout in human mode — never in `--json` + output. + + 3. Always include the UTC value alongside the local rendering. + + 4. Never persist or transmit the local-time rendering. + +- JSON/machine output (`--format json/jsonl/yaml/csv`) MUST always use + UTC + `Z`. -### §14.4 — Duration Format +## §14.4 — Duration Format Durations follow ISO 8601 duration notation: -| Format | Example | Meaning | -|------------|-----------|---------------------| -| `PTnHnMnS` | `PT1H30M` | 1 hour 30 minutes | -| `PnD` | `P7D` | 7 days | -| `PnYnM` | `P1Y6M` | 1 year 6 months | +| Format | Example | Meaning | +|------------|-----------|-------------------| +| `PTnHnMnS` | `PT1H30M` | 1 hour 30 minutes | +| `PnD` | `P7D` | 7 days | +| `PnYnM` | `P1Y6M` | 1 year 6 months | -Prose forms like "1h 30m", "90 minutes", "1.5 hours" are **forbidden** in machine-readable output. They are acceptable in `--help` text only. +Prose forms like "1h 30m", "90 minutes", "1.5 hours" are **forbidden** +in machine-readable output. They are acceptable in `--help` text only. -### §14.5 — Rust Implementation Guidance +## §14.5 — Rust Implementation Guidance When writing Rust code that handles time: | Concern | Rule | -|---------|------| +|----|----| | Crate choice | Use `jiff` (preferred) or `chrono` — never `time` 0.1.x | | UTC type | `jiff::Timestamp` or `chrono::DateTime` for all stored values | | Local type | `chrono::Local` and `jiff::Zoned` (with non-UTC zone) are **forbidden** in serialized output | @@ -560,170 +1073,264 @@ When writing Rust code that handles time: | `SystemTime` | Acceptable for internal durations; convert to UTC ISO 8601 string before any output | | No `NaiveDateTime` in output | `chrono::NaiveDateTime` has no timezone — forbidden in any serialized or logged value | ---- +———————————————————————— -## §15 — Attribution, Maintainer & Contact +# §15 — Attribution, Maintainer & Contact -**Maintainer:** Mohamed Hammad -**Contact:** [Mohamed.Hammad@SpacecraftSoftware.org](mailto:Mohamed.Hammad@SpacecraftSoftware.org) -**Copyright:** Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** CC-BY-SA-4.0 +**Maintainer:** Mohamed Hammad **Contact:** + **Copyright:** Copyright (C) +2026 Mohamed Hammad & Spacecraft Software \| **License:** CC-BY-SA-4.0 **Website:** -### §15.1 — Project Pages - -Each Spacecraft Software project has a dedicated subdomain following the pattern `https://.SpacecraftSoftware.org/`. Use the project-specific URL in all project-level outputs; use `https://SpacecraftSoftware.org/` only for umbrella references. - -| Project | URL | -|----------------------------|--------------------------------------------------| -| Spacecraft Software (main) | | -| The Steelbore Standard | | -| Aetheric | | -| Gitway | | -| Ferrocast | | -| Caliper | | -| Craton | | -| Ironway | | -| Zamak | | -| Bravais | | -| Mawaqit | | -| Flux | | -| Anvil | | -| Construct | | -| Ferrite_OS | | -| Forge | | -| Ginx | | -| Loran | | -| Pearlite | | -| MCP Servers | | -| Lode | | -| Sonde | | -| Vacuum | | -| Vault | | -| Docs | | -| Loran Pages | | - -When a new project is created, add its subdomain to this table immediately. - -### §15.2 — Mandatory Attribution in Project Outputs - -Every Spacecraft Software product **must** surface the following attribution in at least one of: `--help` output, `--version` output, README, or About/Info screen. +## §15.1 — Project Pages + +Each Spacecraft Software project has a dedicated subdomain following the +pattern `https://.SpacecraftSoftware.org/`. Use the +project-specific URL in all project-level outputs; use +`https://SpacecraftSoftware.org/` only for umbrella references. + +| Project | URL | +|----------------------------|-----------------------------------------------| +| Spacecraft Software (main) | | +| The Steelbore Standard | | +| Aetheric | | +| Gitway | | +| Ferrocast | | +| Caliper | | +| Craton | | +| Ironway | | +| Zamak | | +| Bravais | | +| Mawaqit | | +| Flux | | +| Anvil | | +| Construct | | +| Ferrite_OS | | +| Forge | | +| Ginx | | +| Loran | | +| Pearlite | | +| MCP Servers | | +| Lode | | +| Sonde | | +| Vacuum | | +| Vault | | +| Docs | | +| Loran Pages | | + +When a new project is created, add its subdomain to this table +immediately. + +## §15.2 — Mandatory Attribution in Project Outputs + +Every Spacecraft Software product **must** surface the following +attribution in at least one of: `--help` output, `--version` output, +README, or About/Info screen. **Required attribution block:** -``` -Maintained by Mohamed Hammad -Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | License: GPL-3.0-or-later -https://.SpacecraftSoftware.org/ + Maintained by Mohamed Hammad + Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | License: GPL-3.0-or-later + https://.SpacecraftSoftware.org/ -(The License line shows the project's own license — GPL-3.0-or-later or AGPL-3.0-or-later per §4.1.) -``` + (The License line shows the project's own license — GPL-3.0-or-later or AGPL-3.0-or-later per §4.1.) **Per-surface rules:** -| Surface | Required content | -|-------------------|-----------------------------------------------------------------------------------| -| `--version` | Maintainer name, project URL, copyright year | -| `--help` | Project URL and maintainer name (at footer) | -| README | "Maintainer" section: name, `Mohamed.Hammad@SpacecraftSoftware.org`, project URL | -| About / Info (GUI/TUI) | Maintainer name, project URL, copyright year | -| SPDX header | REUSE two-tag header (§4.3): `SPDX-FileCopyrightText` + `SPDX-License-Identifier` (`GPL-3.0-or-later` or `AGPL-3.0-or-later`) | +| Surface | Required content | +|----|----| +| `--version` | Maintainer name, project URL, copyright year | +| `--help` | Project URL and maintainer name (at footer) | +| README | "Maintainer" section: name, `Mohamed.Hammad@SpacecraftSoftware.org`, project URL | +| About / Info (GUI/TUI) | Maintainer name, project URL, copyright year | +| SPDX header | REUSE two-tag header (§4.3): `SPDX-FileCopyrightText` + `SPDX-License-Identifier` (`GPL-3.0-or-later` or `AGPL-3.0-or-later`) | **Specific rules:** -- The contact email is always `Mohamed.Hammad@SpacecraftSoftware.org` — never a personal domain, GitHub handle, or other address. -- The copyright year reflects the year of first release or current year, or a range (e.g., `2025-2026`) when a project spans multiple years. -- Link text for project pages must use the full URL as the display text or a clear label (e.g., `[Gitway](https://Gitway.SpacecraftSoftware.org/)`), never an opaque label. +- The contact email is always `Mohamed.Hammad@SpacecraftSoftware.org` — + never a personal domain, GitHub handle, or other address. + +- The copyright year reflects the year of first release or current year, + or a range (e.g., `2025-2026`) when a project spans multiple years. + +- Link text for project pages must use the full URL as the display text + or a clear label (e.g., + `[Gitway](https://Gitway.SpacecraftSoftware.org/)`), never an opaque + label. + - For CLI `--version` output in human mode, the footer line format is: - ``` - Maintained by Mohamed Hammad - https://.SpacecraftSoftware.org/ - ``` + Maintained by Mohamed Hammad + https://.SpacecraftSoftware.org/ -- For CLI `--version` output in JSON/machine mode, include in `metadata`: +- For CLI `--version` output in JSON/machine mode, include in + `metadata`: - ```json - "maintainer": "Mohamed Hammad ", - "website": "https://.SpacecraftSoftware.org/" - ``` + "maintainer": "Mohamed Hammad ", + "website": "https://.SpacecraftSoftware.org/" -- **Email obfuscation in plain-text prose.** In plain-text prose contexts (README body, CONTRIBUTING.md, human-readable documentation) where the address is not a clickable link, `Mohamed.Hammad [at] SpacecraftSoftware.org` is permitted as a scraper-resistant form. `# Maintainer:` lines in PKGBUILDs and `SPDX-FileCopyrightText` headers **must** always use the full address — those formats are parsed by `makepkg`/`pkgcheck` and `reuse lint` respectively, and obfuscation breaks them. +- **Email obfuscation in plain-text prose.** In plain-text prose + contexts (README body, CONTRIBUTING.md, human-readable documentation) + where the address is not a clickable link, + `Mohamed.Hammad [at] SpacecraftSoftware.org` is permitted as a + scraper-resistant form. `# Maintainer:` lines in PKGBUILDs and + `SPDX-FileCopyrightText` headers **must** always use the full address + — those formats are parsed by `makepkg`/`pkgcheck` and `reuse lint` + respectively, and obfuscation breaks them. -### §15.3 — Third-Party Attribution +## §15.3 — Third-Party Attribution -Spacecraft Software artifacts must give credit where credit is due. When a project or skill **substantially builds on third-party work**, that credit appears in a `CREDITS.md` at the artifact's root — `/CREDITS.md` for projects, `/CREDITS.md` for skills. +Spacecraft Software artifacts must give credit where credit is due. When +a project or skill **substantially builds on third-party work**, that +credit appears in a `CREDITS.md` at the artifact’s root — +`/CREDITS.md` for projects, `/CREDITS.md` for +skills. -`CREDITS.md` is the inbound counterpart to §15.2's outbound attribution: §15.2 tells consumers who maintains Spacecraft Software; §15.3 tells consumers whose work Spacecraft Software stands on. +`CREDITS.md` is the inbound counterpart to §15.2’s outbound attribution: +§15.2 tells consumers who maintains Spacecraft Software; §15.3 tells +consumers whose work Spacecraft Software stands on. **Triggers** (any one obligates a `CREDITS.md`): -- Content adapted, derived, or copied verbatim from an external source under any license (permissive or copyleft). -- A library, framework, or specification whose ideas or implementation form a substantial conceptual basis for the artifact, beyond routine dependency use. -- Named prior art, research, or design work whose insights were borrowed. +- Content adapted, derived, or copied verbatim from an external source + under any license (permissive or copyleft). + +- A library, framework, or specification whose ideas or implementation + form a substantial conceptual basis for the artifact, beyond routine + dependency use. + +- Named prior art, research, or design work whose insights were + borrowed. **Not triggered by** (license metadata alone suffices): -- Routine package-manager dependencies whose `LICENSE` files are surfaced mechanically via Cargo, npm, pip, Nix, etc. -- Well-known standards and specifications (POSIX, RFC, ISO, GFM, ODF, OOXML) that the artifact conforms to but does not redistribute. +- Routine package-manager dependencies whose `LICENSE` files are + surfaced mechanically via Cargo, npm, pip, Nix, etc. + +- Well-known standards and specifications (POSIX, RFC, ISO, GFM, ODF, + OOXML) that the artifact conforms to but does not redistribute. + - Public-domain conventions and common idioms. **Required content per credited work:** -| Field | Required | Example | -|------------|----------|--------------------------------------------------| -| Name | Yes | `Microsoft Pragmatic Rust Guidelines` | -| Author(s) | Yes | `Microsoft Corporation` | -| License | Yes | `MIT License` | -| Source URL | Yes | `https://github.com/microsoft/rust-guidelines` | -| Scope | Yes | One-line description of what was adapted/used | +| Field | Required | Example | +|------------|----------|------------------------------------------------| +| Name | Yes | `Microsoft Pragmatic Rust Guidelines` | +| Author(s) | Yes | `Microsoft Corporation` | +| License | Yes | `MIT License` | +| Source URL | Yes | `https://github.com/microsoft/rust-guidelines` | +| Scope | Yes | One-line description of what was adapted/used | -A skill MAY keep a deeper, scope-limited attribution file inside its `references/` directory (typically `references/ATTRIBUTION.md`) when the credit applies specifically to adapted reference content. The root `CREDITS.md` remains canonical and should link down to any such deeper file. +A skill MAY keep a deeper, scope-limited attribution file inside its +`references/` directory (typically `references/ATTRIBUTION.md`) when the +credit applies specifically to adapted reference content. The root +`CREDITS.md` remains canonical and should link down to any such deeper +file. -SPDX headers (§4) cover license compliance mechanically; `CREDITS.md` is the human-readable narrative — who, what, and how the upstream work shaped the Spacecraft Software artifact. +SPDX headers (§4) cover license compliance mechanically; `CREDITS.md` is +the human-readable narrative — who, what, and how the upstream work +shaped the Spacecraft Software artifact. ---- +———————————————————————— -## §16 — Compliance Checklist (Audit Gate) +# §16 — Compliance Checklist (Audit Gate) Before finalising **any** Spacecraft Software artifact, mentally verify: -- [ ] **§2** Aerospace/Sci-Fi/AI naming convention applied to all **new** identifiers; legacy (pre-v1.2) names preserved unless explicitly renamed -- [ ] **§3.1** Stability: memory safety (Rust, or ASLR+CFI documented); robust error handling, fault tolerance, and test-verified -- [ ] **§3.2** Performance: multi-core/multi-thread concurrency by default (or serial trade-off documented); concurrency designed-in; benchmarking before/after +- [ ] **§2** Aerospace/Sci-Fi/AI naming convention applied to all + **new** identifiers; legacy (pre-v1.2) names preserved unless + explicitly renamed + +- [ ] **§3.1** Stability: memory safety (Rust, or ASLR+CFI documented); + robust error handling, fault tolerance, and test-verified + +- [ ] **§3.2** Performance: multi-core/multi-thread concurrency by + default (or serial trade-off documented); concurrency designed-in; + benchmarking before/after + - [ ] **§3.3** Hardened security; PQC readiness addressed -- [ ] **§4.1** License is `GPL-3.0-or-later` or `AGPL-3.0-or-later` (AGPL for network-facing; per §4.1) -- [ ] **§4.2** Upstream copyright notices, license texts, and `NOTICE`/`AUTHORS` preserved verbatim; upstream licenses shipped in `LICENSES/` -- [ ] **§4.3** REUSE-compliant: two-tag SPDX header (`SPDX-FileCopyrightText` + `SPDX-License-Identifier`) on every file (or `.license` sidecar / `REUSE.toml` entry); `LICENSES/` directory present; `reuse lint` passes -- [ ] **§5** Project Posture: README/NOTICE/CONTRIBUTING present; default personal-hobby stance applied; general-use carve-outs declared in project README -- [ ] **§5.5** Package distribution: `packaging/guix.scm`, `packaging/default.nix`, and `packaging/PKGBUILD` present, buildable, and carrying correct version + SHA-256 checksum (in each package manager's native format) before any release tag is pushed + +- [ ] **§4.1** License is `GPL-3.0-or-later` or `AGPL-3.0-or-later` + (AGPL for network-facing; per §4.1) + +- [ ] **§4.2** Upstream copyright notices, license texts, and + `NOTICE`/`AUTHORS` preserved verbatim; upstream licenses shipped in + `LICENSES/` + +- [ ] **§4.3** REUSE-compliant: two-tag SPDX header + (`SPDX-FileCopyrightText` + `SPDX-License-Identifier`) on every file + (or `.license` sidecar / `REUSE.toml` entry); `LICENSES/` directory + present; `reuse lint` passes + +- [ ] **§5** Project Posture: README/NOTICE/CONTRIBUTING present; + default personal-hobby stance applied; general-use carve-outs declared + in project README + +- [ ] **§5.5** Package distribution: `packaging/guix.scm`, + `packaging/default.nix`, and `packaging/PKGBUILD` present, buildable, + and carrying correct version + SHA-256 checksum (in each package + manager’s native format) before any release tag is pushed + - [ ] **§6.1** POSIX-compliant CLI/system tools -- [ ] **§7** Shell scripts are POSIX-compatible; Nushell/Ion native variants provided where shell-native idioms are required; no Bashisms in shared scripts -- [ ] **§8** Texinfo manual present for user-facing programs (`doc/.texi`); builds to `.info`, `.html`, and `.pdf`; `install-info` hook present in all three package manifests (§5.5) — N/A for scripts and internal tooling -- [ ] **§9** PFA: no tracking, minimal permissions, local storage default + +- [ ] **§7** Shell scripts are POSIX-compatible; Nushell/Ion native + variants provided where shell-native idioms are required; no Bashisms + in shared scripts + +- [ ] **§8** Texinfo manual present for user-facing programs + (`doc/.texi`); builds to `.info`, `.html`, and `.pdf`; + `install-info` hook present in all three package manifests (§5.5) — + N/A for scripts and internal tooling + +- [ ] **§9** PFA: no tracking, minimal permissions, local storage + default + - [ ] **§10** CUA + Vim-like key bindings planned/implemented -- [ ] **§11** Spacecraft Software color palette used; Void Navy background mandatory; new apps expose colors via a named `Steelbore` theme (§11.1) — no bare hex literals in UI logic + +- [ ] **§11** Spacecraft Software color palette used; Void Navy + background mandatory; new apps expose colors via a named `Steelbore` + theme (§11.1) — no bare hex literals in UI logic + - [ ] **§12** FOSS-licensed fonts only (Share Tech Mono / Inconsolata) + - [ ] **§13** Material Design UI/UX; WCAG 2.1 AA verified -- [ ] **§14** ISO 8601 dates; 24h time; UTC Z is the default primary timestamp (companion local time with UTC offset permitted, never a replacement) — unless the project filed the §14.2.1 domain exception for inherently local-time-bound data; ISO 8601 durations; metric units -- [ ] **§15** Attribution present: maintainer name (`Mohamed Hammad`), contact (`Mohamed.Hammad@SpacecraftSoftware.org`), and project URL in `--version` / README / About -- [ ] **§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 -- [ ] **§6.3** All commits to Spacecraft Software Git remotes cryptographically signed with the `Mohamed.Hammad@SpacecraftSoftware.org` key and showing "Verified" on the hosting platform; rewrites preserve signatures; programmatic and assistant-driven commits signed too -If any item is not applicable to the current artifact type (e.g., color palette for a pure Rust library), note it as N/A rather than silently skipping it. +- [ ] **§14** ISO 8601 dates; 24h time; UTC Z is the default primary + timestamp (companion local time with UTC offset permitted, never a + replacement) — unless the project filed the §14.2.1 domain exception + for inherently local-time-bound data; ISO 8601 durations; metric units + +- [ ] **§15** Attribution present: maintainer name (`Mohamed Hammad`), + contact (`Mohamed.Hammad@SpacecraftSoftware.org`), and project URL in + `--version` / README / About + +- [ ] **§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 + +- [ ] **§6.3** All commits to Spacecraft Software Git remotes + cryptographically signed with the + `Mohamed.Hammad@SpacecraftSoftware.org` key and showing "Verified" on + the hosting platform; rewrites preserve signatures; programmatic and + assistant-driven commits signed too ---- +If any item is not applicable to the current artifact type (e.g., color +palette for a pure Rust library), note it as N/A rather than silently +skipping it. -## Skill Cross-References +———————————————————————— -| Task | Load this skill | -|---------------------------------------|----------------------------------------------------| -| Writing any Rust code | `microsoft-rust-guidelines` | -| Writing or reviewing shell scripts | `spacecraft-cli-shell` + `spacecraft-cli-preference` | -| Generating DOCX / ODT / PDF documents | `spacecraft-document-format` | -| Authoring a Texinfo manual | `spacecraft-standard` (§8) | -| Creating IDE / terminal themes | `spacecraft-theme-factory` | -| All other Spacecraft Software work | `spacecraft-standard` | +# Skill Cross-References ---- +| Task | Load this skill | +|----|----| +| Writing any Rust code | `microsoft-rust-guidelines` | +| Writing or reviewing shell scripts | `spacecraft-cli-shell` + `spacecraft-cli-preference` | +| Generating DOCX / ODT / PDF on demand | `spacecraft-document-format` | +| Authoring or building a Texinfo manual | `spacecraft-texinfo` | +| Creating IDE / terminal themes | `spacecraft-theme-factory` | +| All other Spacecraft Software work | `spacecraft-standard` | -*— Built by Spacecraft Software —* +# Concept Index diff --git a/The_Steelbore_Standard.texi b/The_Steelbore_Standard.texi new file mode 100644 index 0000000..acbb558 --- /dev/null +++ b/The_Steelbore_Standard.texi @@ -0,0 +1,2218 @@ +\input texinfo @c -*- texinfo -*- +@c SPDX-FileCopyrightText: 2026 Mohamed Hammad +@c SPDX-License-Identifier: CC-BY-SA-4.0 +@c %**start of header +@setfilename The_Steelbore_Standard.info +@documentencoding UTF-8 +@documentlanguage en +@settitle The Steelbore Standard 1.29 +@c %**end of header + +@set VERSION 1.29 +@set UPDATED 2026-06-23 +@set SUBDOMAIN https://Standard.SpacecraftSoftware.org/ + +@copying +This manual is The Steelbore Standard (version @value{VERSION}, updated @value{UPDATED}). + +Copyright @copyright{} 2026 Mohamed Hammad & Spacecraft Software. + +@quotation +This document is licensed under the Creative Commons Attribution-ShareAlike +4.0 International License (CC-BY-SA-4.0). To view a copy of this licence, +visit @url{https://creativecommons.org/licenses/by-sa/4.0/}. +@end quotation +@end copying + +@dircategory Spacecraft Software +@direntry +* The Steelbore Standard: (The_Steelbore_Standard). Engineering specification for Spacecraft Software. +@end direntry + +@titlepage +@title The Steelbore Standard +@subtitle Engineering specification for Steelbore OS and the Spacecraft Software ecosystem +@subtitle For version @value{VERSION} (@value{UPDATED}) +@author Mohamed Hammad +@page +@vskip 0pt plus 1filll +@insertcopying + +Maintained by Mohamed Hammad +@email{Mohamed.Hammad@@SpacecraftSoftware.org}. +@* +@uref{@value{SUBDOMAIN}} +@end titlepage + +@contents + +@ifnottex +@node Top +@top The Steelbore Standard + +@insertcopying +@end ifnottex + +@menu +* Preamble:: §1 — Preamble and changelog. +* Naming Convention:: §2 — Aerospace, Sci-Fi & AI naming. +* Priority Hierarchy:: §3 — Non-negotiable priority order. +* Licensing:: §4 — Licensing & compliance. +* Project Posture:: §5 — Posture, required files, packaging. +* Platform Requirements:: §6 — Build, release & signed commits. +* Shell Environment:: §7 — First-class shell environments. +* Documentation:: §8 — Texinfo documentation standard. +* PFA Policy:: §9 — Privacy-friendly application policy. +* Key Bindings:: §10 — CUA + Vim key binding requirements. +* Color Palette:: §11 — WCAG-compliant color palette. +* Typography:: §12 — FOSS-licensed font requirements. +* UI/UX Design System:: §13 — Material Design & accessibility. +* Date Time Units:: §14 — ISO 8601, UTC Z, metric units. +* Attribution:: §15 — Maintainer, project pages, credits. +* Compliance Checklist:: §16 — Audit gate checklist. +* Skill Cross-References:: Skill cross-reference table. +* Concept Index:: Alphabetical concept index. +@end menu + +@node Preamble +@chapter §1 — Preamble +The Steelbore Standard defines the engineering principles, compliance +requirements, and design conventions that govern all software produced +under Spacecraft Software. The umbrella encompasses two categories of +work: @strong{Steelbore OS} --- the operating system and all OS-specific +artifacts (configurations, themes, OS tooling) --- and +@strong{independent Spacecraft Software projects} such as Zamak, +Ironway, Ferrocast, and Caliper, which are designed to work with +Steelbore OS but are not OS-specific and may run on any compliant +platform. Both categories are full citizens of Spacecraft Software and +subject to this standard in full. Where a project-specific specification +conflicts with this standard, the stricter of the two requirements shall +prevail. + +@strong{Standard name vs. project naming.} "The Steelbore Standard" is +the canonical, stable name of @emph{this standard}. It is independent of +the projects it governs and of the umbrella organization name --- the +standard retains this name regardless of any future renames. The v1.7 +umbrella rename (Steelbore → Spacecraft Software) and the v1.8 +reinstatement of this standard's name are recorded in the changelog. +Versioning of project codenames (see §2) and versioning of the standard +are separate concerns. + +@menu +* Changelog:: +@end menu + +@node Changelog +@section Changelog +@itemize +@item +@strong{v1.29 (2026-06-23):} Switch source of truth from GFM Markdown to +Texinfo: @file{The_Steelbore_Standard.texi} is now the canonical source; +@file{The_Steelbore_Standard.md} and @file{The_Steelbore_Standard.html} are +generated outputs. @file{.docx}/@file{.odt} produced on request only. +@code{source-format} updated from @code{odt} to @code{texi}. A +@file{Makefile} with @code{info}, @code{html}, @code{md}, and @code{pdf} +targets drives all derivation. +@item +@strong{v1.28 (2026-06-23):} @strong{§2.1:} synced development statuses +with Spacecraft-Software/Projects @code{PROJECTS.md} --- @code{Aetheric} +(was Active) and @code{Ferrocast} (was Planning) corrected to +@strong{Deprecated}, matching their @code{Deprecated} status in the +tracker. Per @code{PROJECTS.md}'s closed status vocabulary, +@code{Deprecated} means "Superseded by another project; do not extend." +@item +@strong{v1.27 (2026-06-22):} @strong{§15.1:} registered the +@strong{Loran Pages} subdomain +(@code{Loran-Pages.SpacecraftSoftware.org}), paired in the same +change-set with its new row and GitHub-repo/subdomain reference links in +Spacecraft-Software/Projects @code{PROJECTS.md}. The @code{loran-pages} +repo --- the community catalog of curated Loran help pages +(tldr-pages-style: flat @code{pages//.md}, a +@code{loran validate} CI gate, and a deterministic minisign-signed +@code{publish.yml} producer feeding @code{loran update}) --- was created +private with §5.2 posture files and §4.3 REUSE compliance (pages +CC-BY-SA-4.0, tooling GPL-3.0-or-later, @code{reuse lint}-clean). +@item +@strong{v1.26 (2026-06-21):} @strong{§15.1:} registered the +@strong{Vacuum} subdomain (@code{Vacuum.SpacecraftSoftware.org}), paired +in the same change-set with its new row and GitHub-repo/subdomain +reference links in Spacecraft-Software/Projects @code{PROJECTS.md}. The +@code{Vacuum} repo --- a Rust multi-crate disk-space recovery TUI/CLI +(parallel scan + a cleaner catalog: build artifacts, package-manager GC, +app caches, large files; dry-run-first, trash-by-default) --- was +created private with §5.2 posture files, an §8 Texinfo manual, the §5.5 +packaging trio, and §4.3 REUSE compliance (@code{reuse lint}-clean). +@item +@strong{v1.25 (2026-06-20):} Rename §3.3 Priority 3 from "Hardened +Security" to "Security by Design" --- aligns the priority name with the +Security By Design principle (security built in from the start). +@item +@strong{v1.24 (2026-06-19):} Add §8 Documentation (Texinfo) --- Texinfo +as first-class technical manual format for user-facing Spacecraft +Software projects, following GNU conventions +(@code{@@dircategory}/@code{@@direntry} for Info directory registration, +@code{makeinfo}/@code{texi2pdf} build targets, CC-BY-SA-4.0 default with +GFDL-1.3-or-later as a permitted alternative, packaging integration for +Guix/Nix/PKGBUILD); renumber old §8--§15 → §9--§16 accordingly. +@item +@strong{v1.23 (2026-06-19):} @strong{§14.1:} registered the +@strong{Docs} subdomain (@code{Docs.SpacecraftSoftware.org}), paired in +the same change-set with its updated row and new GitHub-repo link in +Spacecraft-Software/Projects @code{PROJECTS.md}. The @code{Docs} repo +--- a centralized aggregation of the umbrella's planning corpus (PRDs, +plans, TODOs, research) organized by project then document type --- was +created private with §5.2 posture files and §4.3 REUSE compliance +(CC-BY-SA-4.0 documents, @code{reuse lint}-clean). +@item +@strong{v1.22 (2026-06-18):} @strong{§7 Shell Environment added} --- +codifies Nushell, Ion, Brush, and Bash as four equally first-class shell +environments; §7.1 Script Portability Policy mandates POSIX-compatible +scripts by default with Nushell/Ion native variants where needed and +prohibits Bashisms in shared scripts. Current §7--§14 renumbered §8--§15 +accordingly. Compliance checklist updated with §7 bullet. Skill +Cross-References updated with shell-work row. @strong{§14.2:} added +email obfuscation note --- @code{[at]} form permitted in plain-text +prose; PKGBUILD @code{# Maintainer:} and SPDX headers must retain the +full address. +@item +@strong{v1.21 (2026-06-17):} @strong{§13.1:} registered subdomains for +three projects present in @code{PROJECTS.md} but missing from the table +--- @strong{Lode} (@code{Lode.SpacecraftSoftware.org}), @strong{Sonde} +(@code{Sonde.SpacecraftSoftware.org}), and @strong{Vault} +(@code{Vault.SpacecraftSoftware.org}). @strong{§3.1 and Skill +Cross-References:} corrected skill reference from @code{rust-guidelines} +to @code{microsoft-rust-guidelines} to match the actual skill ID in the +upstream @code{spacecraft-standard} skill. +@item +@strong{v1.20 (2026-06-17):} @strong{§5.5 added:} Package Distribution +Requirements --- every released package must ship +@code{packaging/guix.scm} (GNU Guix Scheme definition), +@code{packaging/default.nix} (Nix flake/derivation), and +@code{packaging/PKGBUILD} (Arch Linux @code{makepkg}), all present and +buildable before any release tag is pushed; each file must pin the exact +release version and SHA-256 checksum in the format native to its package +manager, and carry the project's SPDX two-tag header per §4.3. +@strong{§15} updated with a corresponding @code{§5.5} +compliance-checklist bullet. +@item +@strong{v1.19 (2026-06-16):} @strong{§13.1:} registered the @strong{MCP +Servers} project subdomain (@code{MCP-Servers.SpacecraftSoftware.org}), +paired in the same change-set with its row and GitHub-repo link in +Spacecraft-Software/Projects @code{PROJECTS.md}. The @code{mcp-servers} +repo --- MCP (Model Context Protocol) server configuration templates +across 12 coding agents/editors --- was onboarded to the umbrella with +the §5.2 posture files (@code{NOTICE.md}, @code{CONTRIBUTING.md}, README +posture section) and §4.3 REUSE compliance (@code{LICENSES/}, +@code{REUSE.toml}, @code{reuse lint}-clean). +@item +@strong{v1.18 (2026-06-08):} Licensing classification follow-through. +(1) @strong{§4.1.1 added:} license-by-artifact-class table --- +@strong{software} (incl. skills) is +@code{GPL-3.0-or-later}/@code{AGPL-3.0-or-later}; @strong{documents} +(specs, guides, document deliverables, the published Standard) default +to @code{CC-BY-SA-4.0} (@code{CC-BY-4.0} for max-reuse cases); +@strong{third-party-derived} artifacts preserve their upstream license +per §4.2. (2) @strong{Skill-license correction:} clarified that skills +are software-class --- the published Standard document is +@code{CC-BY-SA-4.0} but the @code{spacecraft-standard} skill encoding is +@code{GPL-3.0-or-later} (the v1.17 skill metadata is corrected back to +GPL accordingly). (3) @strong{§4.1 migration policy (replaces v1.17's +"no forced re-license"):} existing projects are to be reviewed and +relicensed to the best-suited GPL/AGPL, per project, on signed commits. +The Standard and Construct repos are now REUSE-compliant +(@code{reuse lint}-clean) with @code{LICENSES/} directories and +@code{REUSE.toml}. (4) @strong{§2:} added @emph{Equilibrium} and +@emph{Dune} to the endorsed sci-fi naming sources. +@item +@strong{v1.17 (2026-06-08):} Licensing & build overhaul. (1) +@strong{Standard relicensed} from @code{GPL-3.0-or-later} to +@strong{@code{CC-BY-SA-4.0}}, effective this version forward --- GPL +suits software, not a prose specification; CC BY-SA preserves the +share-alike copyleft ethos and is purpose-built for documents. This +affects the Standard document itself only; the projects it governs are +unchanged by this point. (2) @strong{§4.1:} project license is now +@code{GPL-3.0-or-later} @strong{or} @code{AGPL-3.0-or-later} (AGPL for +network-facing software), prospective with no forced re-license. (3) +@strong{§4.2 added:} explicit upstream-license-compliance clause --- +preserve third-party copyright notices, license texts, and +@code{NOTICE}/@code{AUTHORS} verbatim; ship upstream licenses in +@code{LICENSES/}. (4) @strong{§4.3:} SPDX/REUSE compliance per +@url{https://reuse.software} --- two-tag headers +(@code{SPDX-FileCopyrightText} + @code{SPDX-License-Identifier}), a +@code{LICENSES/} directory, @code{.license}/@code{REUSE.toml} coverage +for headerless files (replacing the old "documents are exempt" rule), +and @code{reuse lint} as the CI gate. (5) @strong{§3.2:} explicit +optimization-flag exception --- flags like LTO that break/destabilize a +build on a given toolchain/platform (e.g., NixOS, cross-compilation) +MUST be disabled and documented, since Stability (P1) outranks +Performance (P2). §5.1/§5.2/§6/§13.2 license references and the §4/§12 +compliance-checklist items updated to match. +@item +@strong{v1.16 (2026-06-08):} §12 reframed --- UTC Z is now explicitly +the @strong{default and preferred} timezone (not a universal mandate +forced onto every domain). New §12.2.1 documents a domain exception: a +project whose core domain is fundamentally local-time-bound (e.g., +@code{Mawaqit} prayer-time calculations, sunrise/sunset, local +scheduling) may declare local time as its @emph{primary} representation +for that domain's data, provided it is documented, the UTC default still +governs the project's general-purpose machinery (logs, commits, APIs), +and a UTC instant remains derivable via a stored IANA timezone. §12.1 +timezone row and §12.3 updated to reference the new exception and avoid +contradicting it. +@item +@strong{v1.15 (2026-06-08):} §2 naming convention expanded --- added +explicitly endorsed canonical sources: @emph{The Hitchhiker's Guide to +the Galaxy}, @emph{Hackers} (1995), Spielberg films, @emph{Ghost in the +Shell}, @emph{Æon Flux}, @emph{Super 8}, @emph{LOST}, the +@emph{Cloverfield} franchise, and robot/android names from any sci-fi +film or franchise. §2 now explicitly frames naming as a fun, playful +exercise alongside the existing space-machine-AI fitness test. +@item +@strong{v1.14 (2026-06-03):} §3.2 reframed --- Performance is the +foremost priority after Stability, and its default means of achievement +is @strong{multi-core, multi-thread concurrency} (parallelism as the +baseline, designed in from the start), @emph{unless} concurrency would +materially degrade performance (overhead, contention, or inherently +serial workloads), in which case a documented serial/simpler approach is +chosen. §3.2 compliance-checklist bullet revised. +@item +@strong{v1.13 (2026-06-03):} §3.1 reframed --- Priority 1 is now +@strong{Stability}, not Memory Safety. Memory safety remains the single +most important contributor and primary lever, but Priority 1 now also +mandates robust error handling, fault tolerance / graceful degradation, +and test-verified stability. Cardinal Rule updated to reference +stability (including memory safety); §3.1 compliance-checklist bullet +revised. +@item +@strong{v1.12 (2026-05-25):} §6.3 extended: added explicit authorized +signing identity rule --- all commits from v1.12 onwards must be signed +with the @code{Mohamed.Hammad@@SpacecraftSoftware.org} Ed25519 SSH key; +committer email and signing key identity must both resolve to that +address. Commits predating this version are exempt. +@item +@strong{v1.11 (2026-05-24):} Three normative updates: (1) Copyright +notices updated to +@code{Copyright (C) 2026 Mohamed Hammad & Spacecraft Software} in all +locations. (2) §9.1 added: new apps must expose palette colors through a +named @code{Steelbore} theme rather than hard-coded hex literals, +enabling clean theme substitution. (3) §12 revised: UTC Z remains the +canonical/mandatory primary format; local time expressed as a UTC offset +may now optionally accompany UTC Z values in display, API responses, and +stored records. +@item +@strong{v1.10 (2026-05-20):} Standardized copyright notice to +@code{Copyright (C) 2026 Mohamed Hammad} in all three locations (YAML +frontmatter masthead, §13 attribution block, and @code{--version} / +About template in §6). +@item +@strong{v1.9 (2026-05-18):} Clarified organizational model in §1: +"Steelbore" now specifically refers to Steelbore OS and OS-specific +artifacts (configurations, themes, tooling); "Spacecraft Software" is +the broader umbrella. Independent projects (Zamak, Ironway, Ferrocast, +Caliper, etc.) are peer citizens of the umbrella --- designed to work +with Steelbore OS but OS-agnostic and usable on any compliant platform. +Both categories governed by this standard in full. +@item +@strong{v1.8 (2026-05-18):} Standard name reinstated as "The Steelbore +Standard". Primary mandate reaffirmed as the Steelbore OS line; scope +explicitly extended by default to all Spacecraft Software projects +(unless a project's own spec explicitly carves out an exception). +Subtitle updated to reflect dual scope. Source file renamed +@code{The_Spacecraft_Software_Standard.md} → +@code{The_Steelbore_Standard.md}. §13.1: added Standard subdomain entry +(@code{Standard.SpacecraftSoftware.org}). Umbrella org name and domain +(Spacecraft Software / SpacecraftSoftware.org) unchanged. +@item +@strong{v1.7 (2026-05-15):} Umbrella renamed from @code{Steelbore} to +@code{Spacecraft Software} per the brand consolidation. Standard's name +updated to "The Spacecraft Software Standard"; domain to +@code{SpacecraftSoftware.org}; contact email to +@code{Mohamed.Hammad@@SpacecraftSoftware.org}; §13.1 subdomain pattern +to @code{.SpacecraftSoftware.org}. Skill ID prefix renamed +(@code{steelbore-*} → @code{spacecraft-*}). Subproject codenames +unchanged. The OS line (@code{Steelbore OS}, +@code{Steelbore OS Bravais}, @code{Steelbore OS Lattice}) retains the +Steelbore name and is unaffected by this rename. +@item +@strong{v1.6 (2026-05-13):} Synced §2.1 development statuses with +PROJECTS.md --- @code{Bravais} and @code{Anvil} and @code{Flux} promoted +to Completed; @code{Ferrocast} corrected to Planning; @code{Mawaqit} +updated to Planning (Pending rename). +@item +@strong{v1.5 (2026-05-13):} Corrected @code{Craton} status in §2.1 from +@code{Active} to @code{Reserved} --- codename is registered but no +development has started yet. +@item +@strong{v1.4 (2026-05-13):} Synced §2.1 Legacy Metallurgical Registry +with PROJECTS.md --- added five previously unregistered pre-v1.2 +codenames: @code{Anvil}, @code{Flux}, @code{Pearlite}, +@code{Ferrite_OS}, and @code{Forge}. Expanded §13.1 subdomain table to +include all first-party projects with GitHub repositories that were +missing: Anvil, Construct, Ferrite_OS, Forge, Ginx, Loran, Pearlite. +@item +@strong{v1.3 (2026-05-12):} Added §6.3 (Signed & Verified Commits --- +mandatory Ed25519 SSH commit signing with hosting-platform "Verified" +status; the rule extends to programmatic, CI, and assistant-driven +commits and requires rewrites to preserve signatures). Added §13.3 +(Third-Party Attribution --- @code{CREDITS.md} at project/skill root +when external work is substantially built upon, distinct from mechanical +SPDX license metadata). Two new compliance-checklist bullets cover both +additions. +@item +@strong{v1.2 (2026-05-11):} Replaced §2 metallurgical naming convention +with Aerospace, Sci-Fi & AI naming (aerospace/astronomy terminology + +franchise references from @emph{2001: A Space Odyssey}, @emph{The +Matrix}, @emph{Terminator}). Preserved pre-v1.2 metallurgical-era names +under §2's Legacy Registry. Added explicit statement that the standard's +name was decoupled from project naming and would survive any project or +umbrella rename (subsequently revisited in v1.7's umbrella rename). +Renamed @code{Lattice} to @code{Bravais} (collision with Lattice OS) in +registry and §13.1 subdomain table. Flagged @code{Mawaqit} as pending +rename under the v1.2 convention. +@item +@strong{v1.1 (2026-05-06):} Added §5 Project Posture (personal-hobby +default, general-use carve-out, required posture files). Renumbered +prior §5--§13 to §6--§14. Added posture bullet to compliance checklist. +@item +@strong{v1.0 (2026-03-08):} Initial release. +@end itemize + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Naming Convention +@chapter §2 — Aerospace, Sci-Fi & AI Naming Convention +All @strong{new} project codenames, module identifiers, and +public-facing component names @strong{must} draw from one of the +following domains: + +@itemize +@item +@strong{Real aerospace and astronomy} --- orbital mechanics terms, +propulsion concepts, named missions/programs, stellar objects and +phenomena, observatories. + +@item +@strong{Science-fiction franchises with space / AI / cybernetic themes} +--- naming is meant to be enjoyable as well as fitting. The following +are explicitly endorsed canonical sources: + +@itemize +@item +@emph{2001: A Space Odyssey}, @emph{The Matrix}, @emph{Terminator} --- +the original canonical trio +@item +@emph{The Hitchhiker's Guide to the Galaxy} --- also a rich vein for +in-jokes (Vogon, Marvin, 42, Babel fish, Heart of Gold) +@item +@emph{Hackers} (1995) +@item +Spielberg films (@emph{Close Encounters of the Third Kind}, @emph{E.T. +the Extra-Terrestrial}, @emph{A.I. Artificial Intelligence}, +@emph{Minority Report}, @emph{Ready Player One}, etc.) +@item +@emph{Ghost in the Shell} +@item +@emph{Equilibrium} +@item +@emph{Dune} +@item +@emph{Æon Flux} +@item +@emph{Super 8} +@item +@emph{LOST} (TV series) +@item +@emph{Cloverfield} films +@item +Robot / android names from any sci-fi film or franchise (e.g., HAL, +Data, Bishop, T-800, GERTY, TARS, Marvin) +@end itemize + +Other franchises (e.g., @emph{Alien}, @emph{Blade Runner}, @emph{Ex +Machina}) remain acceptable if they fit the space-machine-AI register. + +@item +@strong{Generic sci-fi / AI vocabulary} --- hyperspace, neural, +cybernetic, synthetic, sentinel, oracle, daemon, vector, lattice (the +lowercase common noun), etc. + +@end itemize + +@multitable {Utilities} {Apollo, Discovery, Skynet, Trinity} {Missions / Ships / AI Machines} +@headitem +Category + @tab Examples + @tab Domain +@item +Projects + @tab Apollo, Discovery, Skynet, Trinity + @tab Missions / Ships / AI Machines +@item +Modules + @tab Apogee, HAL, Cortex, Sentinel + @tab Subsystems / AI Cores +@item +Utilities + @tab Boost, Throttle, Trace, Telemetry + @tab Operational Verbs / Telemetry +@item +Releases + @tab Vega, Pulsar, Quasar, Nebula + @tab Stellar Phenomena +@end multitable + +Names must be @strong{fitting for space-related and futuristic AI +machines} --- the test is whether the name would feel at home on the +hull of a spacecraft or in the boot banner of an AI machine. Reject +proposed names that don't pass this test. + +@menu +* Legacy Registry:: +* Skill IDs:: +@end menu + +@node Legacy Registry +@section §2.1 — Legacy Metallurgical Registry (pre-v1.2) +Projects named before the v1.2 convention drew from metallurgy, +materials science, and industrial forging. These names are +@strong{preserved as-is} unless explicitly renamed by the maintainer. +The v1.2 convention applies prospectively --- no forced back-rename. + +@multitable {@code{Ferrite_OS}} {Renamed to Spacecraft Software (umbrella, v1.7)} {Former umbrella organization name. Renamed 2026-05-15 under the v1.7 brand consolidation. The OS line (@code{Steelbore OS}, @code{Steelbore OS Bravais}, @code{Steelbore OS Lattice}) retains the Steelbore name.} +@headitem +Codename + @tab Status + @tab Description +@item +@code{Steelbore} + @tab Renamed to Spacecraft Software (umbrella, v1.7) + @tab Former umbrella organization name. Renamed 2026-05-15 under the +v1.7 brand consolidation. The OS line (@code{Steelbore OS}, +@code{Steelbore OS Bravais}, @code{Steelbore OS Lattice}) retains the +Steelbore name. +@item +@code{Aetheric} + @tab Deprecated + @tab Next-generation extensible text editor (Pulsar + Quasar + Nebula +IPC). +@item +@code{Zamak} + @tab Active + @tab Rust bootloader (Limine rewrite) +@item +@code{Bravais} + @tab Completed (renamed) + @tab NixOS flake configuration. Renamed from @code{Lattice} due to +collision with Lattice OS. @code{Bravais} is still a metallurgical-era +name (Bravais lattice) and predates the v1.2 convention. +@item +@code{Ferrocast} + @tab Deprecated + @tab Rust PowerShell rewrite (16-crate workspace) +@item +@code{Craton} + @tab Reserved + @tab Rust universal package manager --- codename registered; no work +started yet. +@item +@code{Ironway} + @tab Active + @tab Rust OpenTTD rewrite +@item +@code{Caliper} + @tab Active + @tab Rust raster-to-vector tracing engine (CLI+TUI) +@item +@code{Mawaqit} + @tab Planning (@strong{Pending rename}) + @tab Islamic prayer times app (Flutter + Rust CLI + libmawaqit). To be +renamed under the v1.2 aerospace/sci-fi/AI convention. +@item +@code{Anvil} + @tab Completed + @tab Rust workspace; benches and CHANGELOG; legacy forging-tool name. +@item +@code{Flux} + @tab Completed + @tab Rust workspace; CHANGELOG and deny.toml; legacy metallurgical-flux +name. +@item +@code{Pearlite} + @tab Active + @tab Rust workspace; audit.toml, clippy.toml, CHANGELOG; steel +microstructure name. +@item +@code{Ferrite_OS} + @tab Active + @tab Custom OS / DOS-emulation experiments; ferrite (iron-based +material) name. +@item +@code{Forge} + @tab Active + @tab Production flavor tooling (forge-cli, forge-build, +forge-activate); forging-tool name. +@end multitable + +Existing legacy-named projects MAY be renamed under the v1.2 convention +at the maintainer's discretion --- renames are optional. When a rename +happens, update this table and §15.1's subdomain table in the same +commit. + +@node Skill IDs +@section §2.2 — Skill IDs are functional, not codenamed +Skill directory names and @code{SKILL.md} @code{name} fields are +@strong{functional identifiers} (e.g., @code{spacecraft-standard}, +@code{spacecraft-document-format}) and are not subject to the §2 +codename convention. §2 reserves codenames for +projects/modules/utilities/releases, not for skill identifiers. + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Priority Hierarchy +@chapter §3 — Priority Hierarchy (Non-Negotiable Order) +A higher-numbered priority @strong{may never compromise} a +lower-numbered one. + +@menu +* Priority 1:: +* Priority 2:: +* Priority 3:: +@end menu + +@node Priority 1 +@section §3.1 — Priority 1: Stability +Software must behave predictably and remain correct under sustained and +adverse conditions. Stability is the foremost priority. @strong{Memory +safety is the single most important contributor to stability and the +primary means of achieving it --- but it is not the whole of Priority +1.} + +@strong{Memory safety (primary lever):} + +@itemize +@item +@strong{Preferred language: Rust} --- governed by the Spacecraft +Software Rust Guidelines. Always load the +@code{microsoft-rust-guidelines} skill before writing any Rust code. +@item +When Rust is not viable (Flutter/Dart, Zig, etc.), @strong{mandatory +mitigations}: +@itemize +@item +@strong{ASLR} (Address Space Layout Randomization) on all compiled +binaries +@item +@strong{CFI} (Control-Flow Integrity) wherever the toolchain supports it +@end itemize + +@item +Memory-Safe Languages (MSLs) are always preferred. If an MSL alternative +exists, it must be chosen unless a documented technical exemption is +filed. +@end itemize + +@strong{Beyond memory safety, stability also requires:} + +@itemize +@item +@strong{Robust error handling} --- failures must be surfaced and +handled, never silently swallowed; no panics / @code{unwrap} / +@code{expect} on untrusted or fallible input in production paths. +@item +@strong{Fault tolerance and graceful degradation} --- components must +survive partial failure, degrade gracefully under load or dependency +loss, and recover rather than crash. +@item +@strong{Verified by testing} --- stability properties must be backed by +tests (unit, integration, and fuzz/property where applicable) gating CI, +not asserted by inspection alone. +@end itemize + +@node Priority 2 +@section §3.2 — Priority 2: Performance +Performance is the foremost priority after stability. The default means +of achieving it is @strong{multi-core, multi-thread concurrency} --- +parallelism is the expected baseline, not an afterthought --- +@emph{unless} concurrency would materially degrade performance +(synchronization overhead, lock contention, or inherently serial / small +workloads outweighing the gains), in which case a simpler or serial +approach must be chosen and the trade-off documented. + +@itemize +@item +Concurrency must be @strong{designed-in from the start}, never bolted on +retroactively. +@item +Release builds should use CPU-optimized flags --- @code{-march=native}, +LTO, PGO --- @strong{where the toolchain and target support them +reliably.} Any such flag known to break or destabilize builds on a given +platform, toolchain, or linker configuration (e.g., LTO under certain +NixOS, cross-compilation, or static-linking setups) MUST be disabled and +the reason documented. Stability (Priority 1) outranks Performance +(Priority 2), so a build-breaking or instability-inducing optimization +always yields --- never ship a broken build for the sake of a flag. +@item +Benchmarking is @strong{mandatory} before and after any optimization +work; regressions must be documented and justified --- and it is the +evidence by which the concurrency-vs-serial trade-off above is decided. +@end itemize + +@node Priority 3 +@section §3.3 — Priority 3: Security by Design +@itemize +@item +Kernel hardening (XanMod, grsecurity profiles) where applicable. +@item +Sandboxing and privilege separation for all network-facing components. +@item +@strong{Post-Quantum Cryptography (PQC) readiness:} all crypto +subsystems must support PQC migration paths. Use hybrid schemes +(classical + PQC candidate) where library support exists. Adopt +NIST-finalized PQC standards within one major release cycle. +@itemize +@item +Current targets: @strong{ML-KEM-768}, @strong{ML-DSA-65} (as used in +Ferrocast) +@end itemize + +@item +Dependency auditing: @code{cargo-audit} or equivalent before any +third-party crate inclusion. +@end itemize + +@strong{Cardinal Rule:} Any optimization that weakens @strong{stability +(including memory safety)} or security hardening @strong{must be +rejected}, no exceptions. + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Licensing +@chapter §4 — Licensing & Compliance + +@menu +* Project License:: +* Upstream License:: +* REUSE Compliance:: +@end menu + +@node Project License +@section §4.1 — Project License (GPL-3.0-or-later or AGPL-3.0-or-later) +@itemize +@item +@strong{License:} strong copyleft --- each project chooses +@strong{@code{GPL-3.0-or-later}} or @strong{@code{AGPL-3.0-or-later}}, +whichever fits the project better: +@itemize +@item +Use @strong{@code{AGPL-3.0-or-later}} when the software is +@strong{network-facing} --- anything users interact with primarily over +a network (servers, web services, SaaS, hosted APIs, multiplayer/network +daemons). AGPL closes the "SaaS loophole" by extending the +source-availability obligation to users served over a network. +@item +Use @strong{@code{GPL-3.0-or-later}} for everything else (local CLIs, +libraries, desktop/TUI apps, OS components, bootloaders). +@item +GPLv3 and AGPLv3 are mutually compatible by design, so an umbrella +mixing both is fine. +@end itemize + +@item +No proprietary, closed-source, or permissive-only license for core +project code. +@item +@strong{Review & migrate (existing projects).} This dual choice is not +merely prospective: existing projects are to be @strong{reviewed and +relicensed} to whichever of @code{GPL-3.0-or-later} / +@code{AGPL-3.0-or-later} best fits them (AGPL for network-facing +software). Migration is the maintainer's per-project decision, landed on +that project's own signed commit; any project that deliberately retains +a non-best-fit license must document why. +@end itemize + +@menu +* Artifact Classes:: +@end menu + +@node Artifact Classes +@subsection §4.1.1 — Artifact license classes +The GPL/AGPL choice above governs @strong{software}. License by artifact +class: + +@multitable {@strong{Documents} --- specifications, prose guides, books, and document deliverables produced per the @code{spacecraft-document-format} skill, including the published Standard} {Preserve the @strong{upstream} license per §4.2 (e.g., @code{MIT}, @code{GFDL-1.3-or-later}) --- never relicensed to the project default} +@headitem +Artifact class + @tab Default license +@item +@strong{Software} --- code, manifests, build tooling, and +@strong{skills} + @tab @code{GPL-3.0-or-later} (or @code{AGPL-3.0-or-later} if +network-facing, §4.1) +@item +@strong{Documents} --- specifications, prose guides, books, and document +deliverables produced per the @code{spacecraft-document-format} skill, +including the published Standard + @tab @code{CC-BY-SA-4.0} by default (@code{CC-BY-4.0} permitted when a +document is intended for maximal reuse) +@item +@strong{Third-party-derived artifacts} + @tab Preserve the @strong{upstream} license per §4.2 (e.g., @code{MIT}, +@code{GFDL-1.3-or-later}) --- never relicensed to the project default +@end multitable + +Skills are @strong{software-class} → @code{GPL-3.0-or-later} (no skill +is network-facing, so AGPL does not apply). Note the deliberate split +for the Standard itself: the @strong{published Standard document} is +@code{CC-BY-SA-4.0} (it is a document), while its +@code{spacecraft-standard} @strong{skill} encoding is +@code{GPL-3.0-or-later} (it is a skill). + +@node Upstream License +@section §4.2 — Upstream License Compliance (preserve what you build on) +When a project incorporates, adapts, or links third-party code, it MUST +satisfy that upstream's license in full --- independent of the project's +own GPL/AGPL choice: + +@itemize +@item +@strong{Preserve verbatim} all upstream copyright notices, license +texts, @code{NOTICE}/@code{AUTHORS} files, and in-file license headers +--- never strip, rewrite, or relicense them. +@item +@strong{Ship} each distinct upstream license text in the project's +@code{LICENSES/} directory (§4.3). +@item +@strong{Verify compatibility} of the upstream license with the project's +GPL/AGPL license before inclusion. +@item +This is the legal/mechanical obligation; §15.3's @code{CREDITS.md} is +the human-readable narrative counterpart. When both are triggered, both +apply. +@end itemize + +@node REUSE Compliance +@section §4.3 — SPDX & REUSE Compliance +Spacecraft Software follows the +@strong{@uref{https://reuse.software,REUSE specification}} for +unambiguous, machine-readable license and copyright metadata. Every +project MUST be @code{reuse lint}-clean. + +@strong{Every file carries two SPDX tags} --- copyright @emph{and} +license: + +@verbatim +// SPDX-FileCopyrightText: 2026 Mohamed Hammad +// SPDX-License-Identifier: GPL-3.0-or-later +@end verbatim + +(Substitute the project's actual license --- @code{GPL-3.0-or-later} or +@code{AGPL-3.0-or-later} --- and the correct comment syntax for the file +type.) + +@itemize +@item +@strong{Software source files} (@code{.rs}, @code{.ts}, @code{.js}, +@code{.py}, @code{.sh}, @code{.ps1}, @code{.go}, etc.) and project +manifests (@code{Cargo.toml}, @code{package.json}, @code{flake.nix}, +etc.) carry both tags as an inline header. +@item +@strong{Files that cannot carry an inline header} --- documents +(@code{.odt}, @code{.ods}, @code{.odp}, @code{.docx}, @code{.xlsx}, +@code{.pptx}, @code{.pdf}, @dots{}), images, binary assets, generated +files --- are covered by a @code{.license} sidecar file @strong{or} an +entry in the repo-root @code{REUSE.toml}. No file is left uncovered +(this replaces the former blanket "documents are exempt" rule). +@item +@strong{@code{LICENSES/} directory:} the verbatim text of every license +used in the repo lives in @code{LICENSES/.txt} (e.g., +@code{LICENSES/GPL-3.0-or-later.txt}, +@code{LICENSES/AGPL-3.0-or-later.txt}, plus any upstream licenses per +§4.2). A root @code{LICENSE} file MAY remain as a pointer for GitHub's +license detection. +@item +@strong{CI gate:} @code{reuse lint} MUST pass before shipping. +@end itemize + +When writing or reviewing any file, confirm REUSE coverage; when +generating a new file, add the two-tag header (or the @code{.license} +sidecar / @code{REUSE.toml} entry for files that can't carry one). + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Project Posture +@chapter §5 — Project Posture +Spacecraft Software is a personal hobby project. This posture is the +@strong{default} for every project under the umbrella and is +non-negotiable. Individual projects may adopt a more open posture (see +§5.3) but never a more closed one. + +§4 defines the formal license; this section defines the @strong{stated +stance} that sits alongside it. License says what the user @emph{may} +do; posture says what they should @emph{expect} from the maintainer. + +@menu +* Default Posture:: +* Required Posture Files:: +* General-Use Carve-Out:: +* Maintainer Discretion:: +* Package Distribution:: +@end menu + +@node Default Posture +@section §5.1 — Default Posture (Personal / Hobby) +@multitable {Contributions} {GPL-3.0-or-later or AGPL-3.0-or-later, per §4.1 (formal terms govern in any conflict)} +@headitem +Aspect + @tab Default +@item +Audience + @tab Maintainer's own use case +@item +Pace + @tab Hobby pace; no service-level commitments +@item +Warranty + @tab None --- provided AS IS +@item +Liability + @tab None --- see project @code{NOTICE.md} +@item +Contributions + @tab Welcome but not guaranteed to be accepted +@item +Forking + @tab Encouraged +@item +License + @tab GPL-3.0-or-later or AGPL-3.0-or-later, per §4.1 (formal terms +govern in any conflict) +@end multitable + +@node Required Posture Files +@section §5.2 — Required Posture Files (per project) +Every Spacecraft Software project repository @strong{must} ship the +following files at its root, derived from the canonical Spacecraft +Software templates: + +@multitable {@code{CONTRIBUTING.md}} {REUSE license directory (§4.3): verbatim text of every license used (@code{GPL-3.0-or-later} or @code{AGPL-3.0-or-later}, plus any upstream licenses per §4.2). A root @code{LICENSE} MAY remain as a GitHub-detection pointer.} +@headitem +File + @tab Purpose +@item +@code{README.md} + @tab Includes a "Project Posture" section linking to the two below +@item +@code{NOTICE.md} + @tab Full no-warranty / no-liability statement; defers to the project's +GPL/AGPL license (§4.1) for binding terms +@item +@code{CONTRIBUTING.md} + @tab Contribution scope, PR-acceptance discretion, sign-off, security +reporting, license-of-contributions +@item +@code{LICENSES/} + @tab REUSE license directory (§4.3): verbatim text of every license +used (@code{GPL-3.0-or-later} or @code{AGPL-3.0-or-later}, plus any +upstream licenses per §4.2). A root @code{LICENSE} MAY remain as a +GitHub-detection pointer. +@end multitable + +Customize only the project name, scope, and any project-specific +carve-outs. + +@node General-Use Carve-Out +@section §5.3 — General-Use Carve-Out +A project may declare itself @strong{intended for general use}. When it +does: + +@itemize +@item +The declaration MUST appear in that project's @code{README.md} posture +section. +@item +The no-warranty / no-liability stance from §5.1 still applies in full +--- general-use status changes audience and intent, @strong{not} legal +terms. +@item +General-use projects must hold a higher release-quality bar: semantic +versioning, maintained @code{CHANGELOG.md}, deprecation policy, and a +documented support window for the current major version. +@end itemize + +@strong{General-use registry} (keep in sync with §15.1 subdomain table): + +@multitable {(all others)} {General-use} +@headitem +Project + @tab Posture +@item +Anvil-SSH + @tab General-use +@item +(all others) + @tab Personal +@end multitable + +@node Maintainer Discretion +@section §5.4 — Maintainer Discretion +PR acceptance, feature scope, naming, architecture, and roadmap are at +the maintainer's sole discretion. This is stated openly so contributors +can calibrate effort accordingly. Rejection reflects fit, not quality. + +@node Package Distribution +@section §5.5 — Package Distribution Requirements +Every released package @strong{must} ship first-party package +definitions for the following package managers, committed alongside the +release: + +@multitable {@code{packaging/default.nix}} {Arch Linux --- @code{makepkg}-compatible} +@headitem +File + @tab Package manager / format +@item +@code{packaging/guix.scm} + @tab GNU Guix --- Scheme package definition +@item +@code{packaging/default.nix} + @tab Nix --- Nix flake / derivation +@item +@code{packaging/PKGBUILD} + @tab Arch Linux --- @code{makepkg}-compatible +@end multitable + +@strong{Rules:} + +@itemize +@item +All three files MUST be present and buildable before a release tag is +pushed. +@item +Each file must reference the exact release version and source archive +SHA-256 checksum so that the package can be built reproducibly from the +tagged release. Use the format native to each package manager: +@itemize +@item +@strong{Guix (@code{guix.scm}):} +@code{(sha256 (base32 ""))} inside the @code{origin} +stanza. +@item +@strong{Nix (@code{default.nix}):} @code{sha256 = "";} +inside the @code{fetchurl} or @code{fetchFromGitHub} call. +@item +@strong{Arch (@code{PKGBUILD}):} @code{sha256sums=('')} array +variable alongside @code{source=()}. +@end itemize + +@item +The @code{packaging/} directory is tracked in the project's +version-control repository alongside the source code. +@item +These files are software-class artifacts and inherit the project's +GPL/AGPL license (§4.1); each file must carry the standard SPDX two-tag +header (§4.3). +@item +If a package manager's ecosystem imposes a stricter naming scheme or +directory layout, comply with that scheme while still meeting the above +requirements. +@end itemize + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Platform Requirements +@chapter §6 — Platform & Systems Requirements + +@menu +* POSIX Compliance:: +* Post-Quantum Cryptography:: +* Signed Commits:: +@end menu + +@node POSIX Compliance +@section §6.1 — POSIX Compliance +All CLI tools, daemons, and system utilities must be +@strong{POSIX-compliant}. Platform-specific extensions go behind feature +flags and must not be required for core functionality. + +@node Post-Quantum Cryptography +@section §6.2 — Post-Quantum Cryptography +Crypto subsystems must have migration paths to post-quantum algorithms. +Current implementations should use hybrid schemes where library support +exists. + +@node Signed Commits +@section §6.3 — Signed & Verified Commits (Non-Negotiable) +Every commit pushed to a Spacecraft Software-controlled Git remote +@strong{must} be cryptographically signed and show "Verified" on the +hosting platform's commit/PR view (GitHub today; Gitway or any future +Spacecraft Software host inherits the same rule). + +@strong{Mandatory rules --- violation blocks shipping:} + +@multitable {Hosting-platform "Verified" required} {All commits from v1.12 onwards must be signed with the @code{Mohamed.Hammad@@SpacecraftSoftware.org} key. The committer email and the signing key identity must both resolve to @code{Mohamed.Hammad@@SpacecraftSoftware.org}. Commits predating v1.12 are exempt from this requirement.} +@headitem +Rule + @tab Detail +@item +All commits signed + @tab @code{commit.gpgsign=true} configured globally. SSH signing +(@code{gpg.format=ssh}) is the current default; GPG is acceptable. The +signing key MUST be registered as a @strong{Signing} key on the hosting +platform --- Authentication-only keys do not validate signatures. +@item +Authorized signing identity + @tab All commits from v1.12 onwards must be signed with the +@code{Mohamed.Hammad@@SpacecraftSoftware.org} key. The committer email +and the signing key identity must both resolve to +@code{Mohamed.Hammad@@SpacecraftSoftware.org}. Commits predating v1.12 +are exempt from this requirement. +@item +Hosting-platform "Verified" required + @tab Every commit on a Spacecraft Software remote must show "Verified" +on the platform's commit/PR view. Unsigned or "Unverified" commits MUST +be remediated (re-signed via rebase or amend by the original author) +before merge to a default branch. +@item +Programmatic commits signed too + @tab Bots, CI pipelines, scripted commits, and assistant-driven commits +inherit the same rule --- no @code{--no-gpg-sign}, no signing-disabled +subshells. The signing pipeline runs unattended. +@item +Rewrites preserve signatures + @tab Rebase, amend, cherry-pick, and squash MUST re-sign each resulting +commit. Don't push history that lost signatures through rewriting. +@item +Local verification is best-effort + @tab @code{git log --show-signature} may report "No signature" on a +given host when @code{~/.ssh/allowed_signers} is not populated --- this +is a local-verifier gap, not a signing failure. The hosting platform's +"Verified" badge is authoritative. +@end multitable + +@strong{Algorithm note:} Ed25519 SSH signing is the current default. +§6.2 calls for PQC readiness across the cryptographic surface; +commit-signing algorithm migration is gated on hosting-platform support +for post-quantum key formats. When GitHub (or Spacecraft Software's own +Gitway) accepts PQC signing keys, Spacecraft Software commits migrate +accordingly. + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Shell Environment +@chapter §7 — Shell Environment +Spacecraft Software tooling, documentation, and CI pipelines target +@strong{four first-class shell environments}: @strong{Nushell}, +@strong{Ion}, @strong{Brush}, and @strong{Bash}. All four are equally +supported; none is deprecated or downgraded. + +@menu +* Script Portability:: +@end menu + +@node Script Portability +@section §7.1 — Script Portability Policy +@multitable {Nushell / Ion native variants when needed} {Bash-only extensions (@code{[[ ]]}, @code{(( ))}, process substitution @code{<(...)}, @code{$@{var^^@}}, indexed arrays) are prohibited in files intended for all four shells. Bash-specific scripts are permitted only when explicitly scoped (e.g., @code{#!/usr/bin/env bash} shebang, clearly labeled).} +@headitem +Rule + @tab Detail +@item +Default: POSIX-compatible + @tab Shell scripts in source trees, CI pipelines, @code{Makefile} +targets, and documentation examples @strong{must} be written to the +POSIX sh subset unless a shell-native feature is required. POSIX scripts +run correctly in Bash and Brush without modification. +@item +Nushell / Ion native variants when needed + @tab When a task cannot be expressed cleanly in POSIX sh (structured +data pipelines, typed parameters, Nushell modules), provide a Nushell +(@code{.nu}) and/or Ion-native variant alongside the POSIX version. Do +not force POSIX-only idioms that degrade the Nushell or Ion experience. +@item +No Bashisms in shared scripts + @tab Bash-only extensions (@code{[[ ]]}, @code{(( ))}, process +substitution @code{<(...)}, @code{$@{var^^@}}, indexed arrays) are +prohibited in files intended for all four shells. Bash-specific scripts +are permitted only when explicitly scoped (e.g., +@code{#!/usr/bin/env bash} shebang, clearly labeled). +@item +Graceful shell detection + @tab Tools that need runtime shell detection must inform the user or +degrade gracefully rather than silently failing in non-Bash +environments. +@end multitable + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Documentation +@chapter §8 — Documentation (Texinfo) +Spacecraft Software user-facing projects should ship a @strong{Texinfo +manual} as the canonical technical reference. Texinfo is the preferred +format for reference documentation that accompanies distributed +software, following GNU project conventions. + +@menu +* When Manual Required:: +* Source Format:: +* Required Elements:: +* Output Formats:: +* Manual Licensing:: +* Packaging Integration:: +@end menu + +@node When Manual Required +@section §8.1 — When a Texinfo Manual Is Required +@multitable {CLI / TUI / GUI application with substantive user-facing functionality} {@strong{MUST} ship a Texinfo manual covering invocation, options, concepts, and examples} +@headitem +Project type + @tab Requirement +@item +CLI / TUI / GUI application with substantive user-facing functionality + @tab @strong{MUST} ship a Texinfo manual covering invocation, options, +concepts, and examples +@item +Library with a public API + @tab @strong{SHOULD} ship a Texinfo reference manual covering all +public interfaces +@item +Simple script / internal tooling + @tab @strong{MAY} skip; a well-structured @code{README.md} suffices +@end multitable + +@node Source Format +@section §8.2 — Source Format and File Layout +@itemize +@item +Source files use the @code{.texi} extension (Texinfo 7.x+). +@item +Manuals live at @code{doc/.texi} in the project root. +@item +The project's top-level @code{Makefile} must expose three targets: +@code{make info}, @code{make html}, @code{make pdf}. +@end itemize + +@node Required Elements +@section §8.3 — Required Structural Elements +Every Texinfo manual must include the following elements: + +@multitable {@code{@@dircategory} / @code{@@direntry}} {Registers the manual in the Info directory} +@headitem +Element + @tab Purpose +@item +@code{@@dircategory} / @code{@@direntry} + @tab Registers the manual in the Info directory +@item +@code{@@copying} block + @tab License statement and copyright notice +@item +@code{@@titlepage} + @tab Title, version, author, and copyright +@item +@code{@@node Top} + @code{@@top} + @tab Required top-level node for Info readers +@item +@code{@@menu} per chapter + @tab Navigation structure +@end multitable + +@node Output Formats +@section §8.4 — Output Formats +Build and ship all three output formats: + +@multitable {@code{.html}} {@code{makeinfo} / @code{texi2any}} {Info readers (Emacs, standalone @code{info})} +@headitem +Format + @tab Tool + @tab Purpose +@item +@code{.info} + @tab @code{makeinfo} / @code{texi2any} + @tab Info readers (Emacs, standalone @code{info}) +@item +@code{.html} + @tab @code{makeinfo --html} + @tab Project documentation website +@item +@code{.pdf} + @tab @code{texi2pdf} + @tab Printable reference +@end multitable + +Install @code{.info} files using @code{install-info} at package install +time so they appear in the system Info directory. + +@node Manual Licensing +@section §8.5 — Licensing +Texinfo manuals are @strong{document-class} artifacts (§4.1.1) and +default to @strong{CC-BY-SA-4.0}. @strong{GFDL-1.3-or-later} is a +permitted alternative when the manual is distributed alongside +GPL-licensed software and compatibility with GNU documentation +collections is desired. Include the chosen license in @code{LICENSES/} +per §4.3. + +@node Packaging Integration +@section §8.6 — Packaging Integration +Package manifests must install the @code{.info} file and register it +with @code{install-info}: + +@multitable {@strong{PKGBUILD} (@code{packaging/PKGBUILD})} {Add @code{texinfo} to @code{makedepends}; @code{install -Dm644} for @code{.info} files; call @code{install-info} in @code{post_install}} +@headitem +Package manager + @tab Requirements +@item +@strong{Guix} (@code{packaging/guix.scm}) + @tab Add @code{texinfo} as a native input; run @code{install-info} in +the install phase +@item +@strong{Nix} (@code{packaging/default.nix}) + @tab Add @code{texinfo} to @code{nativeBuildInputs}; standard +Autoconf/Make @code{installPhase} handles @code{install-info} +automatically +@item +@strong{PKGBUILD} (@code{packaging/PKGBUILD}) + @tab Add @code{texinfo} to @code{makedepends}; @code{install -Dm644} +for @code{.info} files; call @code{install-info} in @code{post_install} +@end multitable + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node PFA Policy +@chapter §9 — Privacy-Friendly Application (PFA) Policy +Every Spacecraft Software application must satisfy @strong{all three} +PFA requirements: + +@multitable {Minimal Permissions} {User data stored locally by default; sync is strictly opt-in, E2E encrypted} +@headitem +Requirement + @tab Rule +@item +No Tracking/No Ads + @tab Zero advertising, tracking, analytics SDKs, or telemetry beacons +@item +Minimal Permissions + @tab Only essential permissions; requested lazily at point of use, +never eagerly +@item +Local Storage + @tab User data stored locally by default; sync is strictly opt-in, E2E +encrypted +@end multitable + +When reviewing or designing any feature that touches data handling, +permissions, or networking, verify all three PFA requirements are met. + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Key Bindings +@chapter §10 — Key Bindings +All interactive applications must support @strong{both}: + +@multitable {@strong{Vim}} {Modal editing layer (Normal / Insert / Visual mode) as opt-in feature. Minimum: hjkl navigation where full Vim layer is impractical} +@headitem +Scheme + @tab Requirement +@item +@strong{CUA} + @tab Standard bindings (Ctrl+C/X/V/Z/S) must work in all text input +contexts +@item +@strong{Vim} + @tab Modal editing layer (Normal / Insert / Visual mode) as opt-in +feature. Minimum: hjkl navigation where full Vim layer is impractical +@end multitable + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Color Palette +@chapter §11 — Spacecraft Software Color Palette (WCAG-Compliant) +The @strong{only} permitted colors for Spacecraft Software interfaces +and documents: + +@multitable {Liquid Coolant} {@code{#8BE9FD}} {RGB(139, 233, 253)} {Primary Text / Active Readout} +@headitem +Token + @tab Hex + @tab RGB + @tab Role +@item +Void Navy + @tab @code{#000027} + @tab RGB(0, 0, 39) + @tab @strong{Background / Canvas} +@item +Molten Amber + @tab @code{#D98E32} + @tab RGB(217, 142, 50) + @tab Primary Text / Active Readout +@item +Steel Blue + @tab @code{#4B7EB0} + @tab RGB(75, 126, 176) + @tab Primary Accent / Structural +@item +Radium Green + @tab @code{#50FA7B} + @tab RGB(80, 250, 123) + @tab Success / Safe Status +@item +Red Oxide + @tab @code{#FF5C5C} + @tab RGB(255, 92, 92) + @tab Warning / Error Status +@item +Liquid Coolant + @tab @code{#8BE9FD} + @tab RGB(139, 233, 253) + @tab Info / Links +@end multitable + +@strong{@code{#000027} (Void Navy) is the mandatory background for ALL +Spacecraft Software surfaces.} No alternative background is permitted. +This is non-negotiable. + +For document/file generation → load the +@code{spacecraft-document-format} skill. For IDE/terminal themes → load +the @code{spacecraft-theme-factory} skill. + +@menu +* Steelbore Theme:: +@end menu + +@node Steelbore Theme +@section §11.1 — Steelbore Theme (Application Theming Standard) +When building a new Spacecraft Software application (GUI, TUI, or web), +all palette references @strong{must} be accessed through a named theme +called @strong{@code{Steelbore}} rather than referenced as bare hex +literals. The @code{Steelbore} theme is the canonical color contract: + +@multitable {@code{foreground}} {Maps to palette token} {@code{#8BE9FD}} +@headitem +Theme token + @tab Maps to palette token + @tab Hex +@item +@code{background} + @tab Void Navy + @tab @code{#000027} +@item +@code{foreground} + @tab Molten Amber + @tab @code{#D98E32} +@item +@code{accent} + @tab Steel Blue + @tab @code{#4B7EB0} +@item +@code{success} + @tab Radium Green + @tab @code{#50FA7B} +@item +@code{error} + @tab Red Oxide + @tab @code{#FF5C5C} +@item +@code{info} + @tab Liquid Coolant + @tab @code{#8BE9FD} +@end multitable + +@strong{Rationale:} isolating palette references behind the +@code{Steelbore} theme name makes it trivial for end users to substitute +a custom theme without touching application logic --- swap the theme, +not every hex literal. + +@itemize +@item +The theme file/module @strong{must} be named @code{steelbore} +(snake_case) in the project's theme registry, configuration layer, or +equivalent (e.g., @code{themes/steelbore.json}, @code{steelbore.toml}, a +Rust @code{Theme::Steelbore} variant). +@item +Hard-coding palette hex values directly in UI logic is +@strong{forbidden} for new apps. Use theme tokens exclusively. +@item +Existing apps are encouraged but not required to migrate; new apps are +required. +@end itemize + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Typography +@chapter §12 — Typography (FOSS-Licensed Fonts Only) +Acceptable font licenses: @strong{OFL, Apache 2.0, Ubuntu Font License, +CC0-1.0} + +@multitable {Body / Code} {monospace (system)} {License} +@headitem +Context + @tab Font + @tab License +@item +Headings + @tab Share Tech Mono + @tab OFL +@item +Body / Code + @tab Inconsolata + @tab OFL +@item +Fallback + @tab monospace (system) + @tab N/A +@end multitable + +Never use proprietary fonts. When suggesting or using fonts in any +Spacecraft Software artifact, verify they are available on Google Fonts +or another FOSS-licensed repository. + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node UI/UX Design System +@chapter §13 — UI/UX Design System +@itemize +@item +@strong{Material Design} is the required component system for all +graphical applications. Theme Material components with the §11 color +palette. +@item +@strong{WCAG 2.1 Level AA} contrast is the minimum for all color +pairings. Any new color additions must be WCAG-verified before adoption. +@item +@strong{Accessibility:} screen readers, keyboard-only navigation, and +system accessibility preferences (reduced motion, high contrast) must +all be respected. +@end itemize + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Date Time Units +@chapter §14 — Date, Time & Units + +@menu +* Date Format Rules:: +* UTC Z Policy:: +* Local Time Companion:: +* Duration Format:: +* Rust Time Guidance:: +@end menu + +@node Date Format Rules +@section §14.1 — Date & Time Format Rules +@multitable {Time format} {@strong{UTC Z is the default and preferred primary} for general-purpose, cross-system, and machine-readable timestamps. A project whose core domain is inherently local-time-bound (e.g., solar/prayer-time calculations) may declare local time as its primary record instead --- a documented exception, not a free choice. See §14.2 and §14.2.1} {@code{PT1H30M} not "1h 30m"} +@headitem +Concern + @tab Rule + @tab Example +@item +Date format + @tab ISO 8601 only: @code{YYYY-MM-DD} + @tab @code{2026-03-08} +@item +Time format + @tab 24-hour only: @code{HH:MM:SS} --- AM/PM is @strong{never} +permitted + @tab @code{14:30:00} +@item +Timestamp + @tab Combined ISO 8601 UTC: @code{YYYY-MM-DDTHH:MM:SSZ} + @tab @code{2026-03-08T14:30:00Z} +@item +Timezone + @tab @strong{UTC Z is the default and preferred primary} for +general-purpose, cross-system, and machine-readable timestamps. A +project whose core domain is inherently local-time-bound (e.g., +solar/prayer-time calculations) may declare local time as its primary +record instead --- a documented exception, not a free choice. See §14.2 +and §14.2.1 + @tab @code{Z} not @code{+00:00} +@item +Duration + @tab ISO 8601 duration format only + @tab @code{PT1H30M} not "1h 30m" +@item +Units + @tab Metric (SI) primary; imperial in parentheses only if locale +requires + @tab @code{100 km (62 mi)} +@end multitable + +Apply these conventions to all generated code, documentation, comments, +and any user-facing strings. Never output AM/PM time, non-ISO dates, or +imperial-primary units. + +@node UTC Z Policy +@section §14.2 — UTC Z Timezone Policy +@strong{UTC Z is the default and preferred timezone for stored, +transmitted, logged, and committed timestamps across Spacecraft Software +projects.} It is the convention every project should reach for first --- +it keeps cross-project tooling, sorting, and interchange simple and +unambiguous. Under this default, the @code{Z} suffix is required on +primary timestamps, and local time expressed as a UTC offset (e.g., +@code{2026-05-24T13:34:55+03:00}) may optionally accompany a UTC Z value +as a secondary, human-convenience field --- but UTC Z remains the +authoritative record. + +This is a strong default, not a universal mandate forced onto every +domain regardless of fit --- §14.2.1 documents the exception that lets a +project whose domain is genuinely local-time-bound use local time as its +primary record instead. + +@strong{Rules for projects under the UTC Z default --- apply unless a +project has filed the §14.2.1 exception:} + +@multitable {File metadata written by Spacecraft Software tools} {Offset notation (@code{+03:00}, @code{-05:00}, etc.) is @strong{forbidden as a replacement} for UTC Z. It is permitted only as an optional companion field alongside a @code{Z}-suffixed primary.} +@headitem +Rule + @tab Detail +@item +@code{Z} suffix required + @tab Every @strong{primary} stored/transmitted timestamp MUST end with +@code{Z}. @code{2026-03-08T14:30:00Z} ✓. A companion local-time field +with UTC offset is permitted alongside it. +@item +No offset notation as replacement + @tab Offset notation (@code{+03:00}, @code{-05:00}, etc.) is +@strong{forbidden as a replacement} for UTC Z. It is permitted only as +an optional companion field alongside a @code{Z}-suffixed primary. +@item +No bare local time in data + @tab Local-time timestamps @strong{without} timezone info are +@strong{forbidden} in files, databases, logs, API responses, and +commits. +@item +Log entries use UTC + @code{Z} + @tab Every log line timestamp must be @code{YYYY-MM-DDTHH:MM:SS.sssZ} +(millisecond precision encouraged). +@item +Commit timestamps use UTC + @tab @code{GIT_COMMITTER_DATE} and @code{GIT_AUTHOR_DATE} must be UTC +when set programmatically. +@item +File metadata written by Spacecraft Software tools + @tab mtime/ctime written by Spacecraft Software tools must be +UTC-sourced. +@end multitable + +@menu +* Domain Exception:: +@end menu + +@node Domain Exception +@subsection §14.2.1 — Domain Exception: Inherently Local-Time-Bound Projects +A project whose core domain is fundamentally defined by @strong{local +civil or solar time} --- not by a moment in absolute (UTC) time --- may +declare local time as the @strong{primary} representation for that +domain's data. Examples: prayer-time calculations (@code{Mawaqit}), +sunrise/sunset tables, local event or business-hours scheduling. For +data like this, the meaningful value @emph{is} "06:14 local, at this +place" --- collapsing it to a UTC instant first and treating that as +authoritative would misrepresent what the data actually is. + +@strong{Conditions for the exception:} + +@enumerate +@item +@strong{Document it.} The project's README or spec must state explicitly +which data uses local time as primary, and the @emph{domain} reason why +--- not developer or user convenience. +@item +@strong{Keep the default everywhere else.} General-purpose machinery +within the same project --- logs, commit timestamps, internal +cross-system APIs, telemetry --- still follows the §14.2 UTC Z default. +The exception covers the domain data itself, not the whole project. +@item +@strong{Preserve UTC derivability.} Store or compute the IANA timezone +(e.g., @code{Africa/Cairo}) alongside the local value, so a UTC instant +remains derivable for interchange, comparison, and storage portability. +@item +@strong{This is an exception, not an escape hatch.} "Local time is more +convenient" or "our users are mostly in one timezone" do not qualify --- +the domain itself must be inherently local-time-bound. +@end enumerate + +@node Local Time Companion +@section §14.3 — Local Time as Optional Companion +@strong{For projects under the UTC Z default} (§14.2), local time +expressed as a UTC offset is permitted as an @strong{optional companion} +to the UTC Z primary value --- in human-facing display, in API responses +(as an additional field, never replacing the UTC Z field), and in stored +records where timezone context aids human readers. The UTC Z value is +always present and always authoritative; the local-time companion is +supplemental only. (A project operating under the §14.2.1 domain +exception inverts these roles for its domain data --- local time is +primary there, with UTC kept derivable rather than displayed as +authoritative.) + +@itemize +@item +The @code{--absolute-time} flag (defined in +@code{spacecraft-cli-standard} §3) disables relative-time rendering but +always renders as UTC, not local time. +@item +If a future CLI wants to show local time in human mode, it MUST: +@enumerate +@item +Accept a @code{--tz } flag (e.g., @code{--tz Africa/Cairo}). +@item +Render local time only to stdout in human mode --- never in +@code{--json} output. +@item +Always include the UTC value alongside the local rendering. +@item +Never persist or transmit the local-time rendering. +@end enumerate + +@item +JSON/machine output (@code{--format json/jsonl/yaml/csv}) MUST always +use UTC + @code{Z}. +@end itemize + +@node Duration Format +@section §14.4 — Duration Format +Durations follow ISO 8601 duration notation: + +@multitable {@code{PTnHnMnS}} {@code{PT1H30M}} {1 hour 30 minutes} +@headitem +Format + @tab Example + @tab Meaning +@item +@code{PTnHnMnS} + @tab @code{PT1H30M} + @tab 1 hour 30 minutes +@item +@code{PnD} + @tab @code{P7D} + @tab 7 days +@item +@code{PnYnM} + @tab @code{P1Y6M} + @tab 1 year 6 months +@end multitable + +Prose forms like "1h 30m", "90 minutes", "1.5 hours" are +@strong{forbidden} in machine-readable output. They are acceptable in +@code{--help} text only. + +@node Rust Time Guidance +@section §14.5 — Rust Implementation Guidance +When writing Rust code that handles time: + +@multitable {No @code{NaiveDateTime} in output} {@code{chrono::Local} and @code{jiff::Zoned} (with non-UTC zone) are @strong{forbidden} in serialized output} +@headitem +Concern + @tab Rule +@item +Crate choice + @tab Use @code{jiff} (preferred) or @code{chrono} --- never @code{time} +0.1.x +@item +UTC type + @tab @code{jiff::Timestamp} or @code{chrono::DateTime} for +all stored values +@item +Local type + @tab @code{chrono::Local} and @code{jiff::Zoned} (with non-UTC zone) +are @strong{forbidden} in serialized output +@item +Serialization + @tab Always serialize as @code{"2026-03-08T14:30:00Z"} (string, ISO +8601, @code{Z} suffix) +@item +@code{serde} + @tab Use @code{#[serde(with = "...")]} or a newtype that enforces UTC +on deserialization +@item +@code{SystemTime} + @tab Acceptable for internal durations; convert to UTC ISO 8601 string +before any output +@item +No @code{NaiveDateTime} in output + @tab @code{chrono::NaiveDateTime} has no timezone --- forbidden in any +serialized or logged value +@end multitable + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Attribution +@chapter §15 — Attribution, Maintainer & Contact +@strong{Maintainer:} Mohamed Hammad +@strong{Contact:} @email{Mohamed.Hammad@@SpacecraftSoftware.org} +@strong{Copyright:} Copyright (C) 2026 Mohamed Hammad & Spacecraft +Software | @strong{License:} CC-BY-SA-4.0 +@strong{Website:} @url{https://SpacecraftSoftware.org/} + +@menu +* Project Pages:: +* Required Attribution:: +* Third-Party Attribution:: +@end menu + +@node Project Pages +@section §15.1 — Project Pages +Each Spacecraft Software project has a dedicated subdomain following the +pattern @code{https://.SpacecraftSoftware.org/}. Use the +project-specific URL in all project-level outputs; use +@code{https://SpacecraftSoftware.org/} only for umbrella references. + +@multitable {Spacecraft Software (main)} {@url{https://Loran-Pages.SpacecraftSoftware.org/}} +@headitem +Project + @tab URL +@item +Spacecraft Software (main) + @tab @url{https://SpacecraftSoftware.org/} +@item +The Steelbore Standard + @tab @url{https://Standard.SpacecraftSoftware.org/} +@item +Aetheric + @tab @url{https://Aetheric.SpacecraftSoftware.org/} +@item +Gitway + @tab @url{https://Gitway.SpacecraftSoftware.org/} +@item +Ferrocast + @tab @url{https://Ferrocast.SpacecraftSoftware.org/} +@item +Caliper + @tab @url{https://Caliper.SpacecraftSoftware.org/} +@item +Craton + @tab @url{https://Craton.SpacecraftSoftware.org/} +@item +Ironway + @tab @url{https://Ironway.SpacecraftSoftware.org/} +@item +Zamak + @tab @url{https://Zamak.SpacecraftSoftware.org/} +@item +Bravais + @tab @url{https://Bravais.SpacecraftSoftware.org/} +@item +Mawaqit + @tab @url{https://Mawaqit.SpacecraftSoftware.org/} +@item +Flux + @tab @url{https://Flux.SpacecraftSoftware.org/} +@item +Anvil + @tab @url{https://Anvil.SpacecraftSoftware.org/} +@item +Construct + @tab @url{https://Construct.SpacecraftSoftware.org/} +@item +Ferrite_OS + @tab @url{https://Ferrite.SpacecraftSoftware.org/} +@item +Forge + @tab @url{https://Forge.SpacecraftSoftware.org/} +@item +Ginx + @tab @url{https://Ginx.SpacecraftSoftware.org/} +@item +Loran + @tab @url{https://Loran.SpacecraftSoftware.org/} +@item +Pearlite + @tab @url{https://Pearlite.SpacecraftSoftware.org/} +@item +MCP Servers + @tab @url{https://MCP-Servers.SpacecraftSoftware.org/} +@item +Lode + @tab @url{https://Lode.SpacecraftSoftware.org/} +@item +Sonde + @tab @url{https://Sonde.SpacecraftSoftware.org/} +@item +Vacuum + @tab @url{https://Vacuum.SpacecraftSoftware.org/} +@item +Vault + @tab @url{https://Vault.SpacecraftSoftware.org/} +@item +Docs + @tab @url{https://Docs.SpacecraftSoftware.org/} +@item +Loran Pages + @tab @url{https://Loran-Pages.SpacecraftSoftware.org/} +@end multitable + +When a new project is created, add its subdomain to this table +immediately. + +@node Required Attribution +@section §15.2 — Mandatory Attribution in Project Outputs +Every Spacecraft Software product @strong{must} surface the following +attribution in at least one of: @code{--help} output, @code{--version} +output, README, or About/Info screen. + +@strong{Required attribution block:} + +@verbatim +Maintained by Mohamed Hammad +Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | License: GPL-3.0-or-later +https://.SpacecraftSoftware.org/ + +(The License line shows the project's own license — GPL-3.0-or-later or AGPL-3.0-or-later per §4.1.) +@end verbatim + +@strong{Per-surface rules:} + +@multitable {About / Info (GUI/TUI)} {REUSE two-tag header (§4.3): @code{SPDX-FileCopyrightText} + @code{SPDX-License-Identifier} (@code{GPL-3.0-or-later} or @code{AGPL-3.0-or-later})} +@headitem +Surface + @tab Required content +@item +@code{--version} + @tab Maintainer name, project URL, copyright year +@item +@code{--help} + @tab Project URL and maintainer name (at footer) +@item +README + @tab "Maintainer" section: name, +@code{Mohamed.Hammad@@SpacecraftSoftware.org}, project URL +@item +About / Info (GUI/TUI) + @tab Maintainer name, project URL, copyright year +@item +SPDX header + @tab REUSE two-tag header (§4.3): @code{SPDX-FileCopyrightText} + +@code{SPDX-License-Identifier} (@code{GPL-3.0-or-later} or +@code{AGPL-3.0-or-later}) +@end multitable + +@strong{Specific rules:} + +@itemize +@item +The contact email is always +@code{Mohamed.Hammad@@SpacecraftSoftware.org} --- never a personal +domain, GitHub handle, or other address. + +@item +The copyright year reflects the year of first release or current year, +or a range (e.g., @code{2025-2026}) when a project spans multiple years. + +@item +Link text for project pages must use the full URL as the display text or +a clear label (e.g., +@code{[Gitway](https://Gitway.SpacecraftSoftware.org/)}), never an +opaque label. + +@item +For CLI @code{--version} output in human mode, the footer line format +is: + +@verbatim +Maintained by Mohamed Hammad +https://.SpacecraftSoftware.org/ +@end verbatim + +@item +For CLI @code{--version} output in JSON/machine mode, include in +@code{metadata}: + +@verbatim +"maintainer": "Mohamed Hammad ", +"website": "https://.SpacecraftSoftware.org/" +@end verbatim + +@item +@strong{Email obfuscation in plain-text prose.} In plain-text prose +contexts (README body, CONTRIBUTING.md, human-readable documentation) +where the address is not a clickable link, +@code{Mohamed.Hammad [at] SpacecraftSoftware.org} is permitted as a +scraper-resistant form. @code{# Maintainer:} lines in PKGBUILDs and +@code{SPDX-FileCopyrightText} headers @strong{must} always use the full +address --- those formats are parsed by @code{makepkg}/@code{pkgcheck} +and @code{reuse lint} respectively, and obfuscation breaks them. + +@end itemize + +@node Third-Party Attribution +@section §15.3 — Third-Party Attribution +Spacecraft Software artifacts must give credit where credit is due. When +a project or skill @strong{substantially builds on third-party work}, +that credit appears in a @code{CREDITS.md} at the artifact's root --- +@code{/CREDITS.md} for projects, +@code{/CREDITS.md} for skills. + +@code{CREDITS.md} is the inbound counterpart to §15.2's outbound +attribution: §15.2 tells consumers who maintains Spacecraft Software; +§15.3 tells consumers whose work Spacecraft Software stands on. + +@strong{Triggers} (any one obligates a @code{CREDITS.md}): + +@itemize +@item +Content adapted, derived, or copied verbatim from an external source +under any license (permissive or copyleft). +@item +A library, framework, or specification whose ideas or implementation +form a substantial conceptual basis for the artifact, beyond routine +dependency use. +@item +Named prior art, research, or design work whose insights were borrowed. +@end itemize + +@strong{Not triggered by} (license metadata alone suffices): + +@itemize +@item +Routine package-manager dependencies whose @code{LICENSE} files are +surfaced mechanically via Cargo, npm, pip, Nix, etc. +@item +Well-known standards and specifications (POSIX, RFC, ISO, GFM, ODF, +OOXML) that the artifact conforms to but does not redistribute. +@item +Public-domain conventions and common idioms. +@end itemize + +@strong{Required content per credited work:} + +@multitable {Source URL} {Required} {@code{https://github.com/microsoft/rust-guidelines}} +@headitem +Field + @tab Required + @tab Example +@item +Name + @tab Yes + @tab @code{Microsoft Pragmatic Rust Guidelines} +@item +Author(s) + @tab Yes + @tab @code{Microsoft Corporation} +@item +License + @tab Yes + @tab @code{MIT License} +@item +Source URL + @tab Yes + @tab @code{https://github.com/microsoft/rust-guidelines} +@item +Scope + @tab Yes + @tab One-line description of what was adapted/used +@end multitable + +A skill MAY keep a deeper, scope-limited attribution file inside its +@code{references/} directory (typically +@code{references/ATTRIBUTION.md}) when the credit applies specifically +to adapted reference content. The root @code{CREDITS.md} remains +canonical and should link down to any such deeper file. + +SPDX headers (§4) cover license compliance mechanically; +@code{CREDITS.md} is the human-readable narrative --- who, what, and how +the upstream work shaped the Spacecraft Software artifact. + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Compliance Checklist +@chapter §16 — Compliance Checklist (Audit Gate) +Before finalising @strong{any} Spacecraft Software artifact, mentally +verify: + +@itemize +@item +☐ @strong{§2} Aerospace/Sci-Fi/AI naming convention applied to all +@strong{new} identifiers; legacy (pre-v1.2) names preserved unless +explicitly renamed +@item +☐ @strong{§3.1} Stability: memory safety (Rust, or ASLR+CFI documented); +robust error handling, fault tolerance, and test-verified +@item +☐ @strong{§3.2} Performance: multi-core/multi-thread concurrency by +default (or serial trade-off documented); concurrency designed-in; +benchmarking before/after +@item +☐ @strong{§3.3} Hardened security; PQC readiness addressed +@item +☐ @strong{§4.1} License is @code{GPL-3.0-or-later} or +@code{AGPL-3.0-or-later} (AGPL for network-facing; per §4.1) +@item +☐ @strong{§4.2} Upstream copyright notices, license texts, and +@code{NOTICE}/@code{AUTHORS} preserved verbatim; upstream licenses +shipped in @code{LICENSES/} +@item +☐ @strong{§4.3} REUSE-compliant: two-tag SPDX header +(@code{SPDX-FileCopyrightText} + @code{SPDX-License-Identifier}) on +every file (or @code{.license} sidecar / @code{REUSE.toml} entry); +@code{LICENSES/} directory present; @code{reuse lint} passes +@item +☐ @strong{§5} Project Posture: README/NOTICE/CONTRIBUTING present; +default personal-hobby stance applied; general-use carve-outs declared +in project README +@item +☐ @strong{§5.5} Package distribution: @code{packaging/guix.scm}, +@code{packaging/default.nix}, and @code{packaging/PKGBUILD} present, +buildable, and carrying correct version + SHA-256 checksum (in each +package manager's native format) before any release tag is pushed +@item +☐ @strong{§6.1} POSIX-compliant CLI/system tools +@item +☐ @strong{§7} Shell scripts are POSIX-compatible; Nushell/Ion native +variants provided where shell-native idioms are required; no Bashisms in +shared scripts +@item +☐ @strong{§8} Texinfo manual present for user-facing programs +(@code{doc/.texi}); builds to @code{.info}, @code{.html}, and +@code{.pdf}; @code{install-info} hook present in all three package +manifests (§5.5) --- N/A for scripts and internal tooling +@item +☐ @strong{§9} PFA: no tracking, minimal permissions, local storage +default +@item +☐ @strong{§10} CUA + Vim-like key bindings planned/implemented +@item +☐ @strong{§11} Spacecraft Software color palette used; Void Navy +background mandatory; new apps expose colors via a named +@code{Steelbore} theme (§11.1) --- no bare hex literals in UI logic +@item +☐ @strong{§12} FOSS-licensed fonts only (Share Tech Mono / Inconsolata) +@item +☐ @strong{§13} Material Design UI/UX; WCAG 2.1 AA verified +@item +☐ @strong{§14} ISO 8601 dates; 24h time; UTC Z is the default primary +timestamp (companion local time with UTC offset permitted, never a +replacement) --- unless the project filed the §14.2.1 domain exception +for inherently local-time-bound data; ISO 8601 durations; metric units +@item +☐ @strong{§15} Attribution present: maintainer name +(@code{Mohamed Hammad}), contact +(@code{Mohamed.Hammad@@SpacecraftSoftware.org}), and project URL in +@code{--version} / README / About +@item +☐ @strong{§15.3} Third-party work credited in @code{CREDITS.md} at +project/skill root when triggers apply; deeper +@code{references/ATTRIBUTION.md} present where reference content is +adapted from external sources +@item +☐ @strong{§6.3} All commits to Spacecraft Software Git remotes +cryptographically signed with the +@code{Mohamed.Hammad@@SpacecraftSoftware.org} key and showing "Verified" +on the hosting platform; rewrites preserve signatures; programmatic and +assistant-driven commits signed too +@end itemize + +If any item is not applicable to the current artifact type (e.g., color +palette for a pure Rust library), note it as N/A rather than silently +skipping it. + +@iftex +@bigskip@hrule@bigskip +@end iftex +@ifnottex +------------------------------------------------------------------------ +@end ifnottex + +@node Skill Cross-References +@unnumbered Skill Cross-References +@multitable {Authoring or building a Texinfo manual} {@code{spacecraft-cli-shell} + @code{spacecraft-cli-preference}} +@headitem +Task + @tab Load this skill +@item +Writing any Rust code + @tab @code{microsoft-rust-guidelines} +@item +Writing or reviewing shell scripts + @tab @code{spacecraft-cli-shell} + @code{spacecraft-cli-preference} +@item +Generating DOCX / ODT / PDF on demand + @tab @code{spacecraft-document-format} +@item +Authoring or building a Texinfo manual + @tab @code{spacecraft-texinfo} +@item +Creating IDE / terminal themes + @tab @code{spacecraft-theme-factory} +@item +All other Spacecraft Software work + @tab @code{spacecraft-standard} +@end multitable + +@node Concept Index +@unnumbered Concept Index + +@printindex cp + +@bye diff --git a/spacecraft.css b/spacecraft.css new file mode 100644 index 0000000..516653f --- /dev/null +++ b/spacecraft.css @@ -0,0 +1,76 @@ +/* SPDX-FileCopyrightText: 2026 Mohamed Hammad + SPDX-License-Identifier: GPL-3.0-or-later + + Spacecraft Software HTML theme for texi2any output. + Apply with: texi2any --html --no-split --css-include=spacecraft.css FILE.texi + Palette: Steelbore Standard §10. Typography: §11 (Share Tech Mono / Inconsolata, both OFL). + Fonts load from Google Fonts; system monospace is the offline fallback. */ + +@import url('https://fonts.googleapis.com/css2?family=Inconsolata:wght@400;700&family=Share+Tech+Mono&display=swap'); + +:root { + --void-navy: #000027; /* background / canvas */ + --molten-amber: #D98E32; /* body text / active readout */ + --steel-blue: #4B7EB0; /* H1 / accent / visited link */ + --radium-green: #50FA7B; /* H2 / success */ + --liquid-coolant: #8BE9FD; /* H3 / info / link */ + --red-oxide: #FF5C5C; /* warning / error */ +} + +body { + background-color: var(--void-navy); + color: var(--molten-amber); + font-family: 'Inconsolata', monospace; + font-size: 16px; + line-height: 1.6; + margin: 0 auto; + max-width: 50rem; + padding: 2rem 1.5rem; +} + +h1, h2, h3, h4, h5, h6, +.settitle, .shortcontents-heading, .contents-heading { + font-family: 'Share Tech Mono', monospace; + font-weight: normal; + line-height: 1.25; +} + +h1, .titlefont, .settitle { color: var(--steel-blue); } +h2, .chapter, .unnumbered, .appendix { color: var(--steel-blue); } +h3, .section { color: var(--radium-green); } +h4, h5, h6, .subsection, .subsubsection { color: var(--liquid-coolant); } + +a:link { color: var(--liquid-coolant); } +a:visited { color: var(--steel-blue); } +a:hover { color: var(--radium-green); } + +code, samp, kbd, tt, pre, .verbatim, +.example, .smallexample, .lisp { + font-family: 'Inconsolata', monospace; + color: var(--liquid-coolant); +} + +pre.example, pre.verbatim, pre.smallexample, pre.lisp, pre.display { + background-color: rgba(75, 126, 176, 0.12); /* steel-blue wash */ + border-left: 3px solid var(--steel-blue); + border-radius: 4px; + padding: 0.75rem 1rem; + overflow-x: auto; +} + +blockquote, .quotation { + border-left: 3px solid var(--molten-amber); + margin-left: 0; + padding-left: 1rem; + color: var(--molten-amber); +} + +table { border-collapse: collapse; } +th, td { border: 1px solid var(--steel-blue); padding: 0.35rem 0.6rem; } +th { color: var(--radium-green); font-family: 'Share Tech Mono', monospace; } + +/* Definition commands (@deffn etc.) */ +dt { color: var(--radium-green); } +dfn, var { color: var(--molten-amber); font-style: italic; } + +hr { border: none; border-top: 1px solid var(--steel-blue); }