[MotherSphere]

What was wrong

templates/release.yml signed inside the build legs. The job that ran cargo build, and with it the build.rs and procedural macros of every dependency, later received COLONY_SIGNING_KEY_PEM. A process started during the build can keep running until the job ends and read the key file a later step writes. That key is also the one Colony trusts for its own self-updates, so one compromised crate in any program copying the template could forge launcher updates. design/releases.md sections 7 and 8 still sent new and existing programs to that template and to templates/sign-release.sh.

The caller template, the safe path, lacked the colony.json validation and the Intel macOS architecture check the in-build template had, told authors to pin the shared workflow at main's current commit rather than the organisation pin, and the program README skeleton had no ## Code signing policy section although the shared workflow links every release's notes to that anchor.

What changed

• One release template. templates/release.yml and templates/sign-release.sh are removed. templates/sign-and-publish-caller.yml is the only release workflow template; its build legs never receive a key. .github/workflows/sign-and-publish.yml is untouched (callers pin it at 619460ff4dc0049f129955f0988d368427b9eedb).
• Caller template. Adds the verified Validate colony.json step to the Linux leg (embedded Colony release public key, colony-linux + .sig + .meta + .meta.sig from Project-Colony/Colony, two openssl pkeyutl -verify, the asset= and sha256= check, then validate-manifest with the four asset names). It keeps the --version smoke test on every executable leg and adds the file check for the Intel macOS cross-build. It names the organisation pin of the shared workflow, documents the release-please and recovery parts that used to live in the retired template, and notes when code-signing-policy must be turned off. The tag checkout keeps persist-credentials: false (the only checkout left in templates/).
• Pins. actions/upload-artifact v7.0.2 (cf430e0). dtolnay/rust-toolchain is pinned on master (e2a55d2, 2026-10-09) with toolchain: stable, because the stable branch is rebased onto every master commit and its SHAs stop being reachable (the old pin 4cda84d already is). Checked with gh api: checkout v7.0.1 and release-please-action v5.0.0 are already current. rust-cache, action-gh-release and download-artifact were used only by the removed template.
• templates/program/README.md. New ## Code signing policy section (what is signed, with which key, openssl verification commands with the public key, a link to design/releases.md#5-signing, and the SignPath wording and team roles in a comment to add only once SignPath signs). New ## Privacy skeleton per ORG-9, with SignPath Foundation's accepted sentence for programs that contact nothing. design/documentation.md lists both sections and what they must say.
• design/releases.md.
  • Conventional commits and squash-only merges apply from adoption: with the first commit for new repositories, from 2026-10-09 for existing ones. History before adoption is never rewritten.
  • The squash-title paragraph now states the org setting (PR_TITLE / COMMIT_MESSAGES, squash only, delete branch on merge). Every public org repository except the archives already uses PR_TITLE.
  • Section 5 explains who signs and why the key never reaches a compiling job, with manual verification commands. It also replaces the "patch the old job" trap with "replace, do not patch", documents the organisation pin and when it moves, and adds a "Distribution artefacts" clause for Arch Colony: OpenPGP-signed packages and databases with SigLevel = Required DatabaseRequired, and ISO images with their sources or a written offer.
  • Sections 7 and 8 point at the caller template. Section numbers and checklist item positions are unchanged.
• Other pages made wrong by the change: templates/README.md, README.md (templates row), design/repository-layout.md (scripts/), design/dependencies.md (one template, pins bumped by hand since Dependabot does not read templates/).
• Dependabot and the pin. templates/dependabot.yml ignores Project-Colony/Project-Colony-Resources in its github-actions entry, and "The pin" in design/releases.md says why: Dependabot would otherwise propose the newest commit of main to each caller on its own, which contradicts the rule that the pin moves for every program at once.
• No agent artefacts: .claude/skills/colony-theme-set/SKILL.md and the .gitignore lines for agent folders are removed.
• No em or en dashes are left anywhere under templates/ or in design/releases.md.

How it was verified

• Extracted the Validate colony.json step from the template with a YAML parser and ran it locally against Colony v0.10.4. A valid manifest passes (both signatures verify, colony.json: OK). A manifest naming an unknown platform exits 1. A modified public key fails at the first openssl verify before anything runs.
• Ran the README ## Code signing policy commands against Colony v0.10.4's colony-linux: both signatures verify, and the .meta sha256 equals sha256sum.
• The caller template parses as YAML. Checked the job and step order and the pinned SHAs against the tags with gh api.
• cargo run -p colony-tokens -- check: generated/ is up to date. No Rust code reads the changed files.

Links from other repositories

Only Colony linked templates/release.yml and templates/sign-release.sh (gh search code). Project-Colony/Colony#89 points those links at templates/sign-and-publish-caller.yml; its links work on main today, so the order of the two merges does not matter.

Left out on purpose

.github/workflows/sign-and-publish.yml still mentions templates/release.yml and templates/sign-release.sh in three comments. Editing it would move the file away from the organisation pin, so those comments should change the next time the workflow itself changes.