From 0081ced223cc81a4dd80a3caaa381c3c137ebd46 Mon Sep 17 00:00:00 2001 From: UnbreakableMJ Date: Mon, 27 Jul 2026 14:54:22 +0300 Subject: [PATCH] =?UTF-8?q?feat(standard):=20=C2=A76.4=20authorized=20cont?= =?UTF-8?q?ribution=20targets,=20=C2=A75.6=20skill=20packaging=20=E2=80=94?= =?UTF-8?q?=20v1.40?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit §6.3 says how a commit must be signed on "a Spacecraft Software-controlled Git remote" but never defines that set, so nothing stopped a script, a CI job, or an assistant-driven session from pushing a branch or opening a PR against a third-party repository. §6.4 names the authorized namespaces (Spacecraft-Software, UnbreakableMJ, plus any future Spacecraft Software-controlled host) and makes every other destination outbound and default-deny. Automation never initiates; only the maintainer, explicitly and per contribution, may authorize one. Package registries and external issue trackers are covered too. Forks under our namespaces stay free — turning a fork branch into an upstream PR is the gated act. §4.2's carry-the-patch route is preferred to upstreaming, and the GNU posture yields the identity clauses but not this one. §5.6 caps a SKILL.md frontmatter description at 1000 rendered characters against the loader's hard 1024 limit, pins down what "rendered" means for YAML folded scalars, and requires the cap to be machine-enforced in CI and in the command that produces the bundle — a local git hook is opt-in per clone and is not the gate. §16 gains a checklist bullet for each section. Co-Authored-By: Claude Opus 5 (1M context) --- CHANGELOG.md | 1 + The_Steelbore_Standard.md | 59 ++++++++++++++++- The_Steelbore_Standard.texi | 126 +++++++++++++++++++++++++++++++++++- 3 files changed, 182 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 51c7c47..3b405bf 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,7 @@ Entries are newest-first. Dates are UTC, ISO 8601 (§14). Versioning policy: bum for upstream skill changes, registry updates (§2.1, §15.1), factual corrections to normative content, and brand/identity changes. +- **v1.40 (2026-07-27):** **Two gaps closed: where work may be sent, and what must be measured before a skill is packed.** **§6.4 added — Authorized Contribution Targets (Non-Negotiable).** §6.3 has always said how a commit must be signed on "a Spacecraft Software-controlled Git remote" without ever defining that set, so nothing in the standard stopped a script, a CI job, or an assistant-driven session from pushing a branch or opening a pull request against a third-party repository. §6.4 names the authorized namespaces — `github.com/Spacecraft-Software` and `github.com/UnbreakableMJ`, with a future Spacecraft Software-controlled host (Gitway) inheriting the same standing — and makes every other destination **outbound** and **default-deny**: silence is a denial, not permission. **Automation never initiates** an outbound contribution, and authorization for one does not carry to the next task, session, or repository; only Mohamed Hammad, acting explicitly and per contribution, may authorize one (§5.4). The rule is not git-only — publishing to a package registry under a namespace Spacecraft Software does not control (`crates.io`, npm, PyPI, AUR, Nixpkgs, Guix, Flathub) and filing issues or patches on an external tracker or mailing list are outbound under the same rule. **Forks stay free**: a fork under an authorized namespace may be created and pushed to at will, because that is our namespace — turning a fork branch into an upstream PR is the gated act. Where an upstream change is needed, §4.2's carry-the-patch-in-tree route is preferred to upstreaming. The free-software/GNU posture (§1) yields the identity clauses (§2, §11–§12, §15) but **not** this one: sending anything to GNU, the FSF, or Savannah still needs explicit authorization. An unauthorized submission MUST be withdrawn as soon as it is discovered, and recorded. **§5.6 added — Skill Packaging Requirements.** Skills are software-class artifacts (§4.1.1) whose loader limits are only discovered at install time, after the packing work is done: a `SKILL.md` frontmatter `description` over **1024** characters is rejected on load. §5.6 caps it at **1000 rendered characters** — a deliberate 24-character margin — and pins down *rendered*: a YAML folded scalar (`description: >`) joins its wrapped lines with single spaces and keeps a trailing newline, so raw line lengths are not the measurement, and block (`>`/`|`) and single-line plain or quoted forms alike are counted after folding. The cap MUST be **machine-enforced** in two places — the skill repository's CI on every pull request and push to the default branch, *and* the command that produces the distributable bundle. A developer-installed git hook is a convenience, never the gate: hooks are opt-in per clone. An over-limit skill MUST NOT be packed, committed, or published; trim the description rather than raise the cap. §16 gains a checklist bullet for each section. - **v1.39 (2026-07-26):** **Three external palettes registered, and a new class for the two that cannot conform.** **§11.3.5 added — Tokyo Night**, taken verbatim from the upstream editor theme (canvas Night `#1A1B26`, `surface` the documented Storm background `#24283B`, `surface-alt` the Night `bg_dark` `#16161E`, which sits darker than the canvas as §11.0.1 permits). It needed no Spacecraft-derived substitutes: every role token clears 4.5:1 on all three backgrounds — accent `#7AA2F7` 6.79:1, structure `#BB9AF7` 7.39:1, success `#9ECE6A` 9.35:1, error `#F7768E` 6.46:1, warning `#E0AF68` 8.55:1, focus `#7DCFFF` 9.96:1 — so it is registered as a conforming alternate, with `tokyonight-high-contrast` lifting the two tokens below 7:1 on the canvas (`accent` → `#97B6F9` 8.44:1, `error` → `#F998AA` 8.22:1). The upstream comment tone `#565F89` (2.76:1) is recorded as not bindable to any role token. **§11.5 added — Fidelity Palettes (registered, non-conforming):** a new class for palettes reproduced exactly from a widely used external theme so tooling can meet a user already working in it. **Solarized Dark (§11.5.1) and Solarized Light (§11.5.2)** are registered verbatim from Ethan Schoonover's Solarized — no token substituted, deepened, or lifted to make a number pass — and they **do not** satisfy §11's contrast guarantee. Solarized Dark: body text `base0` 4.75:1 on the canvas, twelve pairings below 4.5:1, and `structure`/`border` (2.97:1) and `error` (2.81:1) below 3:1 on `base02`. Solarized Light is worse: body text `base00` measures **4.13:1, under the AA floor**, and `success` (2.97:1), `warning` (2.98:1), and `focus` (2.93:1) fall below 3:1, so an interface built on it cannot signal status by color at all. §11.5 therefore bars adopting a fidelity palette as a project's §11.4 palette, keeps `steelbore-mono` as the accessible-mode path, and ships no `-high-contrast` sibling for them (lifting would change the values they exist to reproduce); † and ‡ mark the two failure bands throughout. Solarized defines one elevated tone per mode, so `surface-alt` shares `surface`. **§11.4.1 added — Reference Names:** every palette gains an additive reference name for prose (`steelbore-color-palette`, `steelboreclassic-color-palette`, `blue-color-palette`, `blackpinkpanther-color-palette`, `matrixgreen-color-palette`, `navywhite-color-palette`, `tokyonight-color-palette`, `solarizeddark-color-palette`, `solarizedlight-color-palette`). Slugs are unchanged and remain the machine identifier, so no consumer breaks. **§11.4** gains bullets for both additions. - **v1.38 (2026-07-26):** **§4.3 corrected — the symlink runs the other way.** v1.36 required the root `LICENSE` to be a symlink into `LICENSES/`, on the premise that GitHub follows symlinks for license detection. It does not: GitHub's detector reads **git blobs**, and a symlink's blob is the target *path*, not the license text. Measured after v1.36 landed, both `Standard` and `Construct` reported `NOASSERTION` — no identified license — where sibling repos with a regular `LICENSE` file report `GPL-3.0`. The rule is inverted: the root `LICENSE` is now a **regular file** holding the verbatim primary license text, and `LICENSES/.txt` for that license is a **symlink back to it** (`ln -s ../LICENSE LICENSES/GPL-3.0-or-later.txt`). `reuse` reads the working tree through the filesystem, so it follows the link and lints clean; GitHub gets a real blob. The single-source-of-truth goal of v1.36 is preserved — the text still exists exactly once — and two independently maintained copies remain non-compliant. Added: the root text MUST be a **canonical, unmodified** copy as published (FSF text for the GPL family, Creative Commons text for CC-BY-SA-4.0, or the choosealicense.com copy) — reflowed or Markdown-formatted texts defeat detection even when the wording is intact. Secondary licenses in `LICENSES/` (§4.2 upstream texts, a differently-licensed tooling class per §4.1.1) stay regular files; only the primary license is linked. §5.2 `LICENSE` row and the §16 checklist bullet updated to match. - **v1.37 (2026-07-26):** **Changelog extracted from the document.** The full diff --git a/The_Steelbore_Standard.md b/The_Steelbore_Standard.md index 8e6592b..4ebb10d 100644 --- a/The_Steelbore_Standard.md +++ b/The_Steelbore_Standard.md @@ -29,7 +29,7 @@ repository](https://github.com/Spacecraft-Software/Standard), newest entry first. It is kept out of this document so the standard reads as the rules *in force* rather than the record of how they got there. -This document is **version 1.39**, updated 2026-07-26 (§14: UTC, ISO +This document is **version 1.40**, updated 2026-07-27 (§14: UTC, ISO 8601). The skill encoding of the standard keeps a parallel history in `spacecraft-standard-constitution/references/CHANGELOG.md` in the [Construct @@ -485,6 +485,23 @@ the following package managers, committed alongside the release: directory layout, comply with that scheme while still meeting the above requirements. +## §5.6 — Skill Packaging Requirements + +Skills are software-class artifacts (§4.1.1) distributed as `SKILL.md` +bundles. The loading agent imposes hard limits that a bundle only +discovers at install time, when the upload is rejected and the packing +work is already done. Those limits are therefore enforced **before +packing**, not after a failure. + +**Mandatory rules — violation blocks shipping:** + +| Rule | Detail | +|----|----| +| Description cap | A skill’s frontmatter `description` MUST NOT exceed **1000 rendered characters**. The consuming loader’s absolute limit is **1024**; 1000 is the deliberate 24-character margin for encoding and trailing-newline edge cases. | +| Rendered, not raw | "Rendered" means the string the loader sees. A YAML folded scalar (`description: >`) joins its wrapped lines with single spaces and retains a trailing newline, so the raw line lengths are not the measurement. Block (`>` / `|`) and single-line plain or quoted forms alike are measured after folding. | +| Machine-enforced | The cap MUST be checked by an automated gate that runs both in the skill repository’s CI on every pull request and push to the default branch, and in whatever command produces the distributable bundle. A developer-installed git hook is a convenience, never the gate — hooks are opt-in per clone and cannot be relied on. | +| Over-limit skills do not ship | A skill whose description exceeds the cap MUST NOT be packed, committed, or published. Trim the description; do not raise the cap. | + ———————————————————————— # §6 — Platform & Systems Requirements @@ -526,6 +543,34 @@ post-quantum key formats. When GitHub (or Spacecraft Software’s own Gitway) accepts PQC signing keys, Spacecraft Software commits migrate accordingly. +## §6.4 — Authorized Contribution Targets (Non-Negotiable) + +Spacecraft Software work is published only to namespaces Spacecraft +Software controls. Two are authorized today: +[github.com/Spacecraft-Software](https://github.com/Spacecraft-Software) +(the umbrella organization) and +[github.com/UnbreakableMJ](https://github.com/UnbreakableMJ) (the +maintainer’s personal namespace). A future Spacecraft +Software-controlled host — Gitway, or any successor — inherits the same +standing. Every other destination is **outbound** and gated. + +§6.3 says how a commit must be signed on a Spacecraft Software remote; +this section says which remotes those are, and what it takes to send +anything anywhere else. + +**Mandatory rules — violation blocks shipping:** + +| Rule | Detail | +|----|----| +| Default-deny outbound | No `git push`, pull or merge request, patch series, or mailing-list submission to any Git remote outside the authorized namespaces. Silence is a denial, not permission. | +| Automation never initiates | Bots, CI pipelines, scripted workflows, and assistant-driven sessions MUST NEVER open an outbound contribution. Authorization for one contribution does not carry to the next task, session, or repository. | +| Maintainer-only exception | Only Mohamed Hammad, acting explicitly and per contribution, may authorize an outbound submission (§5.4 maintainer discretion). The authorization names the destination and the change; it does not generalize. | +| Registries and trackers included | Publishing to a package registry under a namespace Spacecraft Software does not control (`crates.io`, npm, PyPI, AUR, Nixpkgs, Guix, Flathub, and the like), and filing issues, bug reports, or patches on an external tracker or mailing list, are outbound contributions under this same rule. | +| Forks are inbound-only | A fork under an authorized namespace may be created and pushed to freely — that is our namespace. Turning a fork branch into an upstream pull request is the gated act, not the fork itself. | +| Prefer carrying the patch | When an upstream change is needed, carry the patch in-tree (§4.2 preserves upstream copyright, license texts, and notices) rather than upstreaming it, unless the maintainer authorizes upstreaming. | +| GNU posture does not exempt | An artifact under the free-software/GNU posture (§1) still requires explicit maintainer authorization before anything is sent to GNU, the FSF, or Savannah. That posture yields this standard’s identity clauses (§2, §11–§12, §15); it does not yield this one. | +| Withdraw mistakes promptly | An outbound submission made without authorization MUST be closed or withdrawn as soon as it is discovered, and the incident recorded. | + ———————————————————————— # §7 — Shell Environment @@ -1885,6 +1930,12 @@ Before finalising **any** Spacecraft Software artifact, mentally verify: and carrying correct version + SHA-256 checksum (in each package manager’s native format) before any release tag is pushed +- [ ] **§5.6** Skill packaging: every `SKILL.md` `description` measures + ≤ 1000 rendered characters (folded scalars counted as the loader sees + them, not as raw lines); the cap is enforced by CI *and* by the + command that produces the bundle, not only by a local git hook — N/A + for projects that ship no skills + - [ ] **§6.1** POSIX-compliant CLI/system tools - [ ] **§7** Shell scripts are POSIX-compatible; Nushell/Ion native @@ -1950,6 +2001,12 @@ Before finalising **any** Spacecraft Software artifact, mentally verify: the hosting platform; rewrites preserve signatures; programmatic and assistant-driven commits signed too +- [ ] **§6.4** No commit, pull request, patch, issue, or package + publication sent to a namespace outside `Spacecraft-Software` / + `UnbreakableMJ` without explicit per-contribution maintainer + authorization; automation, CI, and assistant-driven work never + initiate an outbound contribution + 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. diff --git a/The_Steelbore_Standard.texi b/The_Steelbore_Standard.texi index 23b4096..a284ace 100644 --- a/The_Steelbore_Standard.texi +++ b/The_Steelbore_Standard.texi @@ -5,11 +5,11 @@ @setfilename The_Steelbore_Standard.info @documentencoding UTF-8 @documentlanguage en -@settitle The Steelbore Standard 1.39 +@settitle The Steelbore Standard 1.40 @c %**end of header -@set VERSION 1.39 -@set UPDATED 2026-07-26 +@set VERSION 1.40 +@set UPDATED 2026-07-27 @set SUBDOMAIN https://Standard.SpacecraftSoftware.org/ @copying @@ -659,6 +659,7 @@ do; posture says what they should @emph{expect} from the maintainer. * General-Use Carve-Out:: * Maintainer Discretion:: * Package Distribution:: +* Skill Packaging:: @end menu @node Default Posture @@ -824,6 +825,46 @@ directory layout, comply with that scheme while still meeting the above requirements. @end itemize +@node Skill Packaging +@section §5.6 — Skill Packaging Requirements +Skills are software-class artifacts (§4.1.1) distributed as @code{SKILL.md} +bundles. The loading agent imposes hard limits that a bundle only discovers +at install time, when the upload is rejected and the packing work is already +done. Those limits are therefore enforced @strong{before packing}, not after +a failure. + +@strong{Mandatory rules --- violation blocks shipping:} + +@multitable {Over-limit skills do not ship} {The cap MUST be checked by an automated gate that runs both in the skill repository's CI on every pull request and push to the default branch, and in whatever command produces the distributable bundle.} +@headitem +Rule + @tab Detail +@item +Description cap + @tab A skill's frontmatter @code{description} MUST NOT exceed +@strong{1000 rendered characters}. The consuming loader's absolute limit +is @strong{1024}; 1000 is the deliberate 24-character margin for +encoding and trailing-newline edge cases. +@item +Rendered, not raw + @tab "Rendered" means the string the loader sees. A YAML folded scalar +(@code{description: >}) joins its wrapped lines with single spaces and +retains a trailing newline, so the raw line lengths are not the +measurement. Block (@code{>} / @code{|}) and single-line plain or quoted +forms alike are measured after folding. +@item +Machine-enforced + @tab The cap MUST be checked by an automated gate that runs both in the +skill repository's CI on every pull request and push to the default +branch, and in whatever command produces the distributable bundle. A +developer-installed git hook is a convenience, never the gate --- hooks +are opt-in per clone and cannot be relied on. +@item +Over-limit skills do not ship + @tab A skill whose description exceeds the cap MUST NOT be packed, +committed, or published. Trim the description; do not raise the cap. +@end multitable + @iftex @bigskip@hrule@bigskip @end iftex @@ -838,6 +879,7 @@ requirements. * POSIX Compliance:: * Post-Quantum Cryptography:: * Signed Commits:: +* Contribution Targets:: @end menu @node POSIX Compliance @@ -908,6 +950,72 @@ for post-quantum key formats. When GitHub (or Spacecraft Software's own Gitway) accepts PQC signing keys, Spacecraft Software commits migrate accordingly. +@node Contribution Targets +@section §6.4 — Authorized Contribution Targets (Non-Negotiable) +Spacecraft Software work is published only to namespaces Spacecraft +Software controls. Two are authorized today: +@uref{https://github.com/Spacecraft-Software,github.com/Spacecraft-Software} +(the umbrella organization) and +@uref{https://github.com/UnbreakableMJ,github.com/UnbreakableMJ} (the +maintainer's personal namespace). A future Spacecraft Software-controlled +host --- Gitway, or any successor --- inherits the same standing. Every +other destination is @strong{outbound} and gated. + +§6.3 says how a commit must be signed on a Spacecraft Software remote; +this section says which remotes those are, and what it takes to send +anything anywhere else. + +@strong{Mandatory rules --- violation blocks shipping:} + +@multitable {Registries and trackers included} {Publishing to a package registry under a namespace Spacecraft Software does not control (@code{crates.io}, npm, PyPI, AUR, Nixpkgs, Guix, Flathub, and the like), and filing issues, bug reports, or patches on an external tracker or mailing list, are outbound contributions under this same rule.} +@headitem +Rule + @tab Detail +@item +Default-deny outbound + @tab No @code{git push}, pull or merge request, patch series, or +mailing-list submission to any Git remote outside the authorized +namespaces. Silence is a denial, not permission. +@item +Automation never initiates + @tab Bots, CI pipelines, scripted workflows, and assistant-driven +sessions MUST NEVER open an outbound contribution. Authorization for one +contribution does not carry to the next task, session, or repository. +@item +Maintainer-only exception + @tab Only Mohamed Hammad, acting explicitly and per contribution, may +authorize an outbound submission (§5.4 maintainer discretion). The +authorization names the destination and the change; it does not +generalize. +@item +Registries and trackers included + @tab Publishing to a package registry under a namespace Spacecraft +Software does not control (@code{crates.io}, npm, PyPI, AUR, Nixpkgs, +Guix, Flathub, and the like), and filing issues, bug reports, or patches +on an external tracker or mailing list, are outbound contributions under +this same rule. +@item +Forks are inbound-only + @tab A fork under an authorized namespace may be created and pushed to +freely --- that is our namespace. Turning a fork branch into an upstream +pull request is the gated act, not the fork itself. +@item +Prefer carrying the patch + @tab When an upstream change is needed, carry the patch in-tree (§4.2 +preserves upstream copyright, license texts, and notices) rather than +upstreaming it, unless the maintainer authorizes upstreaming. +@item +GNU posture does not exempt + @tab An artifact under the free-software/GNU posture (§1) still +requires explicit maintainer authorization before anything is sent to +GNU, the FSF, or Savannah. That posture yields this standard's identity +clauses (§2, §11--§12, §15); it does not yield this one. +@item +Withdraw mistakes promptly + @tab An outbound submission made without authorization MUST be closed +or withdrawn as soon as it is discovered, and the incident recorded. +@end multitable + @iftex @bigskip@hrule@bigskip @end iftex @@ -3408,6 +3516,12 @@ in project README buildable, and carrying correct version + SHA-256 checksum (in each package manager's native format) before any release tag is pushed @item +☐ @strong{§5.6} Skill packaging: every @code{SKILL.md} @code{description} +measures ≤ 1000 rendered characters (folded scalars counted as the loader +sees them, not as raw lines); the cap is enforced by CI @emph{and} by the +command that produces the bundle, not only by a local git hook --- N/A for +projects that ship no skills +@item ☐ @strong{§6.1} POSIX-compliant CLI/system tools @item ☐ @strong{§7} Shell scripts are POSIX-compatible; Nushell/Ion native @@ -3472,6 +3586,12 @@ 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 +@item +☐ @strong{§6.4} No commit, pull request, patch, issue, or package +publication sent to a namespace outside @code{Spacecraft-Software} / +@code{UnbreakableMJ} without explicit per-contribution maintainer +authorization; automation, CI, and assistant-driven work never initiate an +outbound contribution @end itemize If any item is not applicable to the current artifact type (e.g., color