feat(standard): §6.4 authorized contribution targets, §5.6 skill packaging — v1.40 - #19
Conversation
…aging — v1.40 §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) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0081ced223
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @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. |
There was a problem hiding this comment.
When the maintainer explicitly asks a bot, script, CI job, or assistant session to make a particular outbound submission, this absolute MUST NEVER open rule forbids the action, while the immediately following maintainer-only exception permits an explicitly authorized submission and the session-scoping sentence implies such authorization can exist. This makes the non-negotiable policy ambiguous at exactly the point automation must enforce it; specify either that automation may execute a per-contribution authorization or that the exception is restricted to submissions performed directly by the maintainer.
Useful? React with 👍 / 👎.
| @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. |
There was a problem hiding this comment.
When an over-limit description is committed locally or pushed only to a feature branch without opening a pull request, neither required gate runs: CI is mandated only for pull requests and default-branch pushes, and the bundle check occurs later. The subsequent MUST NOT be ... committed rule therefore is not machine-enforced as this section claims; either require validation of every pushed/new commit through an enforceable mechanism or narrow the prohibition to merging, packing, and publishing.
Useful? React with 👍 / 👎.
…ll packaging — v1.40 (#21) Mirrors Spacecraft-Software/Standard#19 at the same version and date. §6.4 names the authorized publication 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. Forks under our namespaces stay free — turning a fork branch into an upstream PR is the gated act. 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, defines "rendered" for YAML folded scalars, and requires the cap to be machine-enforced in CI and in the command that produces the bundle rather than by an opt-in git hook. The frontmatter description is re-cut to 973 chars under the new §5.6 cap: §6.4 and §5.6 added to the encoded-sections list, §8 Texinfo and the redundant "§11 palette family" dropped. §16 gains a bullet for each section. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
What
Two normative additions at v1.40 (2026-07-27).
§6.4 — 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-Softwareandgithub.com/UnbreakableMJ, with a future Spacecraft Software-controlled host (Gitway) inheriting the same standing — and makes every other destination outbound and default-deny:crates.io, npm, PyPI, AUR, Nixpkgs, Guix, Flathub) and external issue trackers or mailing lists are covered.The tooling already assumed this rule:
construct-cli's ship command hard-codesEXPECTED_REMOTE = "Spacecraft-Software/Construct". Now the standard says it, so it applies beyond one command.§5.6 — Skill Packaging Requirements
A
SKILL.mdfrontmatterdescriptionover 1024 characters is rejected at install time — after the packing work is done. §5.6 caps it at 1000 rendered characters (a deliberate 24-char margin), pins down what rendered means for YAML folded scalars (description: >joins wrapped lines with single spaces and keeps a trailing newline, so raw line lengths are not the measurement), and requires the cap to be machine-enforced in the skill repo's CI and in the command that produces the bundle. A developer-installed git hook is opt-in per clone and is explicitly not the gate.§16 gains a checklist bullet for each section.
Verification
makeinfo --no-split The_Steelbore_Standard.texi→ zero errors, zero warnings.mdcompanion regenerated via the DocBook route; both multitables render as GFM tablesreuse lint→ compliant.github/validate-configs.py→ 3 config files, 0 failed@set VERSION, and@set UPDATEDall read 1.40 / 2026-07-27Follow-ups (separate PRs)
spacecraft-standard-constitutionSKILL.md +references/CHANGELOG.mdto v1.40SKILL.md, plus a pre-pack check inconstruct ship🤖 Generated with Claude Code