Align release docs: add validate:schemas, clarify checksum boundary, and document manual publication steps

ONBOARDING.md

@@ -16,6 +16,7 @@ This document is the maintainer workflow for the current release line.
 3. Run validation.
    ```bash
    npm run validate
+   npm run validate:schemas
    npm run validate:examples
    npm run validate:integrity
    ```
@@ -26,6 +27,7 @@ This document is the maintainer workflow for the current release line.
 5. Re-run validation and checksum verification.
    ```bash
    npm run validate
+   npm run validate:schemas
    npm run validate:examples
    npm run validate:integrity
    sha256sum -c checksums.txt
@@ -41,8 +43,8 @@ When editing only prose docs outside the checksum surface, do not regenerate `ch
 4. Add at least one valid request, one valid receipt, one invalid request, and one invalid receipt.
 5. Make every invalid example isolate a single intended failure when practical.
 6. Update `manifest.json`, `schemas/<version>/index.json`, validation expectations, and checksums.
-7. Update README and SPEC if the normative surface changed.
-8. Confirm public docs controlled by this repo still teach the exact current path model.
+7. Update README, SPEC, and any release-process docs if the normative surface changed.
+8. Confirm public docs controlled by this repo still teach the exact current path model and current script names.
 
 ## Version bumps
 
@@ -56,8 +58,12 @@ For the current line, the canonical path model is flat:
 - `https://commandlayer.org/schemas/vX.Y.Z/commercial/<verb>/<verb>.request.schema.json`
 - `https://commandlayer.org/schemas/vX.Y.Z/commercial/<verb>/<verb>.receipt.schema.json`
 
-1. Pin the checksum-covered release artifact set to IPFS.
-2. Capture resulting CIDs.
+## Manual publication follow-up
+
+The repository does not automate publication, IPFS pinning, CID capture, or mirror updates. If your release process uses those steps, perform them manually after the new version line has passed validation:
+
+1. Pin the checksum-covered release artifact set to IPFS, if that distribution channel is being used for the release.
+2. Capture resulting CIDs in the external release record if your publication process requires them.
 3. Update commandlayer.org mirrors to match the release paths exactly.
 4. Update any Agent Card schema bindings that reference the superseded version.
 

README.md

@@ -2,7 +2,7 @@
 
 Protocol-Commercial v1.1.0 is the current CommandLayer commercial schema line.
 
-This README describes the current v1.1.0 release line and its release packaging surface. Repo-wide governance and security policy live in the dedicated meta docs.
+This README describes the current v1.1.0 release line and its release packaging surface. Repo-wide governance, security posture, and checksum-boundary provenance live in the dedicated meta docs.
 
 It defines the canonical commercial overlays that sit on top of Protocol-Commons v1.1.0. Commons defines base semantic actions. Commercial defines the monetized, settlement-aware request and receipt contracts that agents and runtimes use when value moves.
 
@@ -191,13 +191,15 @@ This repository does not define:
 ```bash
 npm install
 npm run validate
+npm run validate:schemas
 npm run validate:examples
 npm run validate:integrity
 npm run generate:checksums
 sha256sum -c checksums.txt
 ```
 
-- `npm run validate` checks current-line metadata, schema identity, layout, and release integrity expectations.
+- `npm run validate` runs the full validation suite for the current release line.
+- `npm run validate:schemas` checks current-line metadata, schema identity, layout, and manifest/index alignment expectations.
 - `npm run validate:examples` validates every current-line valid and invalid example against the canonical schemas.
 - `npm run validate:integrity` verifies the checksum file scope and hash coverage for the current release artifact set.
 - `checksums.txt` intentionally covers machine-validated release payloads only: `manifest.json`, `schemas/v1.1.0/index.json`, `schemas/v1.1.0/`, and `examples/v1.1.0/`.
@@ -208,12 +210,12 @@ Agent Cards v1.1.0 should bind directly to the current flat commercial schema UR
 
 Protocol-Commons and Protocol-Commercial therefore tell one coherent story:
 
-The v1.1.0 checksum surface is intentionally limited to canonical machine artifacts:
+The v1.1.0 checksum-covered machine-artifact set is intentionally limited to:
 
 - `schemas/v1.1.0/`
 - `examples/v1.1.0/`
 - `manifest.json`
 
-`checksums.txt` records hashes for that machine-verifiable set only. Release-defining prose docs such as `README.md`, `SPEC.md`, `POLICY.md`, `SECURITY_PROVENANCE.md`, and `ONBOARDING.md` are authoritative guidance, but they are outside the checksum surface unless the tooling is expanded deliberately in a later release.
+`checksums.txt` is the generated hash ledger for that machine-artifact set; it describes that surface but is not itself part of the hashed payload. Release-defining prose docs such as `README.md`, `SPEC.md`, `POLICY.md`, `SECURITY_PROVENANCE.md`, and `ONBOARDING.md` are authoritative guidance, but they are outside the checksum surface unless the tooling is expanded deliberately in a later release.
 
 After any mutation to the checksum-covered set, regenerate `checksums.txt` and repin any release bundle that depends on those artifacts.

SECURITY.md

@@ -33,11 +33,12 @@ Protocol-Commercial provides schema-level security properties, not transaction o
 
 ```bash
 npm run validate
+npm run validate:schemas
 npm run validate:examples
 npm run validate:integrity
 sha256sum -c checksums.txt
 ```
 
-`sha256sum -c checksums.txt` verifies only the checksum-covered machine-artifact surface, not release prose docs.
+`npm run validate:schemas` is the direct schema/metadata drift check. `sha256sum -c checksums.txt` verifies only the checksum-covered machine-artifact surface, not release prose docs.
 
 Security contact: `security@commandlayer.org`

SECURITY_PROVENANCE.md

@@ -10,7 +10,7 @@ Checksum-covered machine-artifact roots:
 - `examples/v1.1.0/`
 - `manifest.json`
 
-`checksums.txt` is the generated SHA-256 ledger for that machine-artifact set. Release-defining prose docs in the repository are intentionally outside this checksum boundary and must not be described as checksum-protected.
+`checksums.txt` is the generated SHA-256 ledger for that machine-artifact set. It describes the checksum-covered payload but is not itself part of the hashed payload. Release-defining prose docs in the repository are intentionally outside this checksum boundary and must not be described as checksum-protected.
 
 Release integrity state for this repository:
 

SPEC.md

@@ -24,7 +24,7 @@ Current normative machine-artifact line:
 - `schemas/v1.1.0/`
 - `examples/v1.1.0/`
 - `manifest.json`
-- `checksums.txt` as the hash ledger for that machine-artifact set
+- `checksums.txt` as the generated hash ledger describing that machine-artifact set
 
 Published legacy line retained but superseded:
 
@@ -40,7 +40,7 @@ Release-defining prose docs remain normative for interpretation, but they are ou
 3. A v1.1.0 schema MUST NOT be mutated in place after release publication.
 4. Breaking or meaning-changing edits require a new version directory.
 5. `manifest.json` MUST identify the current release line and any retained legacy lines.
-6. `checksums.txt` MUST cover the canonical machine-verifiable release artifact set and MUST NOT be described as protecting prose docs it does not hash.
+6. `checksums.txt` MUST enumerate the canonical machine-verifiable release artifact set and MUST NOT be described as protecting prose docs it does not hash.
 
 ## 4. Current path model
 
@@ -148,5 +148,6 @@ A conformant release MUST satisfy all of the following:
 - every current schema path matches its `$id`
 - `manifest.json` and `schemas/v1.1.0/index.json` agree on the current verb set and path inventory
 - `npm run validate` passes
+- `npm run validate:schemas` passes
 - `sha256sum -c checksums.txt` passes for the checksum-covered machine-artifact set
 - repository metadata does not drift from the published current line