commandlayer · GsCommand · Mar 21, 2026 · Mar 21, 2026
diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml
@@ -21,4 +21,4 @@ jobs:
       - run: npm run validate
       - run: npm run generate:checksums
       - run: git diff --exit-code -- checksums.txt
-      - run: npm pack --dry-run
+      - run: npm run validate:pack
diff --git a/ONBOARDING.md b/ONBOARDING.md
@@ -4,17 +4,17 @@ This document is an orientation guide for the active v1.1.0 release line. Contri
 
 ## Document scope
 
-Use this document to understand the repository shape, release line, and published package boundary before editing.
+Use this document to understand the repository shape, release line, and shipped package boundary before editing.
 
 For the authoritative version policy, checksum boundary, and validation requirements, see `POLICY.md` and `SPEC.md`.
 
 ## External consumer workflow
 
-1. Use `manifest.json` to confirm that `v1.1.0` is the current line.
+1. Use `manifest.json` to confirm that `v1.1.0` is the current line in repository-validated, pre-publication state.
 2. Treat the shipped package surface as limited to `schemas/v1.1.0/`, `examples/v1.1.0/`, `manifest.json`, `checksums.txt`, `LICENSE`, `README.md`, and `index.js`.
 3. Use `index.js` or `schemas/v1.1.0/index.json` as the package entrypoint to the current schema map.
 4. Choose flat schemas under `schemas/v1.1.0/commercial/<verb>/` for validator configuration.
-5. Run the maintained verification commands listed in `README.md#validation-commands` before mirroring or vendoring.
+5. Run the maintained verification commands listed in `README.md#validation-commands` before mirroring, vendoring, or performing a release step.
 6. Treat `examples/v1.1.0/commercial/<verb>/valid/` and `invalid/` as conformance fixtures.
 7. Treat `v1.0.0` as repository-only historical material unless a separate compatibility workflow explicitly vendors it from source.
 
@@ -27,7 +27,7 @@ High-level maintainer sequence:
 1. Install dependencies with `npm install`.
 2. Edit schemas, examples, metadata, scripts, and docs coherently.
 3. Run the canonical validation commands referenced from `README.md#validation-commands`.
-4. Regenerate `checksums.txt` when any checksum-covered published payload file changes.
+4. Regenerate `checksums.txt` when any checksum-covered shipped-boundary file changes.
 5. Keep current-line teaching focused on `v1.1.0` and keep `v1.0.0` out of the shipped package boundary.
 
 ## Adding a new commercial verb
@@ -48,17 +48,17 @@ High-level maintainer sequence:
 2. Create a new `schemas/vX.Y.Z/` and `examples/vX.Y.Z/` tree.
 3. Update `package.json`, `manifest.json`, README, SPEC, policy docs, and workflow assumptions.
 4. Draft release notes and changelog updates for the new line before publication.
-5. Regenerate checksums for the new line's checksum-covered published payload.
+5. Regenerate checksums for the new line's checksum-covered shipped payload.
 6. Move superseded lines out of the shipped package boundary unless they are explicitly revalidated and intentionally kept.
 
 For the canonical path model and namespace rules, see `SPEC.md`.
 
 ## Manual publication follow-up
 
-The repository does not automate publication, GitHub Release 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:
+The repository does not automate publication, GitHub Release publication, signed provenance 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. Publish the GitHub Release using `releases/v1.1.0.md` or the corresponding new-version draft.
-2. Pin the checksum-covered published payload to IPFS, if that distribution channel is being used for the release.
+2. Pin the checksum-covered shipped payload to IPFS, if that distribution channel is being used for the release.
 3. Capture resulting CIDs in the external release record if your publication process requires them.
 4. Update commandlayer.org mirrors to match the release paths exactly.
 5. Update any Agent Card schema bindings that reference the superseded version.

diff --git a/POLICY.md b/POLICY.md
@@ -1,10 +1,10 @@
 # POLICY — Protocol-Commercial
 
-This policy governs the active release line and the canonical published package boundary. Repo-wide governance and security reporting are defined separately.
+This policy governs the active release line and the canonical shipped package boundary. Repo-wide governance and security reporting are defined separately.
 
 ## Current line
 
-`v1.1.0` is the current Protocol-Commercial line and the only canonical published package line.
+`v1.1.0` is the current Protocol-Commercial line and the only canonical shipped line.
 
 `v1.0.0` may remain in the repository as historical source material for audit or migration reference, but it is outside the shipped npm package surface and outside the active canonical release boundary.
 
@@ -17,7 +17,7 @@ This policy governs the active release line and the canonical published package
 
 ## Canonical published boundary
 
-The canonical published package surface for `v1.1.0` is limited to:
+The canonical shipped boundary for `v1.1.0` is limited to:
 
 - `schemas/v1.1.0/`
 - `examples/v1.1.0/`
@@ -31,7 +31,7 @@ Legacy `v1.0.0` schemas, examples, and any historical TypeScript fixtures are re
 
 ## Integrity boundary
 
-`checksums.txt` is the generated ledger for the canonical published package payload, excluding `checksums.txt` itself.
+`checksums.txt` is the generated ledger for the canonical shipped boundary, excluding `checksums.txt` itself.
 
 The checksum-covered payload consists of:
 
@@ -56,3 +56,5 @@ Release-defining prose docs outside that list are repository guidance only and m
 - `fulfillment_ref` denotes the merchant or provider controlled fulfillment artifact, not a generic external pointer.
 - Shipment receipts must remain commercially scoped and tied to an upstream checkout or purchase.
 - `requester` is the governed field for the initiator of a `verify.request`; `verifier` is reserved for the authority that issues or attests the verification receipt.
+
+Tarball validation may additionally allow npm-emitted `package.json` metadata, but that packaging artifact does not expand the canonical shipped boundary.
diff --git a/README.md b/README.md
@@ -27,14 +27,14 @@ Protocol-Commercial is intentionally limited to protocol truth:
 
 ## Document scope
 
-This README is a repo-wide orientation document for the active release line and its canonical published package boundary.
+This README is a repo-wide orientation document for the active release line and its canonical shipped boundary.
 
 ## Release truth
 
 - **Current canonical line:** `v1.1.0`
 - **Current canonical schema root:** `https://commandlayer.org/schemas/v1.1.0/`
 - **Current package entrypoint:** `index.js` → `schemas/v1.1.0/index.json`
-- **Canonical published package surface:** `schemas/v1.1.0/`, `examples/v1.1.0/`, `manifest.json`, `checksums.txt`, `LICENSE`, `README.md`, `index.js`
+- **Canonical shipped boundary:** `schemas/v1.1.0/`, `examples/v1.1.0/`, `manifest.json`, `checksums.txt`, `LICENSE`, `README.md`, `index.js`
 - **Historical repository-only line:** `v1.0.0`, retained under `schemas/v1.0.0/` and `examples/v1.0.0/`
 - **Changelog:** `CHANGELOG.md`
 - **Release note draft for a future GitHub Release publication:** `releases/v1.1.0.md`
@@ -50,7 +50,7 @@ This repository is the source of truth for those schema files and release metada
 ## Schema identity and trust
 
 - `https://commandlayer.org/...` is the canonical schema namespace and the normative `$id` base for this release line.
-- This Git repository and its canonical published package contents are the source of truth for those artifacts.
+- This Git repository and its canonical shipped package contents are the source of truth for those artifacts.
 - External resolution of `$id` URLs is a convenience, not a trust requirement; consumers should vendor, mirror, or package-pin the repository artifacts they validate against.
 
 ## Relationship to the stack
@@ -73,7 +73,7 @@ The stack story is singular:
 
 For consumers who need the shortest safe path:
 
-1. Install the package and use the package-root export or explicit current-line schema export.
+1. If and when `@commandlayer/commercial` is published, install that package and use the package-root export or explicit current-line schema export. Until then, treat the repository checkout as the authoritative source of the current line.
    ```bash
    npm install @commandlayer/commercial
    ```
@@ -87,9 +87,9 @@ For consumers who need the shortest safe path:
 3. Prefer `schemas/v1.1.0/commercial/<verb>/<verb>.request.schema.json` and `...receipt.schema.json` directly for validator configuration.
 4. Verify the shipped current-line payload before mirroring or vendoring using the canonical command surface in [Validation commands](#validation-commands).
 5. Ignore `v1.0.0` unless you are consulting repository-local historical material for migration work. It is not part of the canonical shipped package surface.
-6. Treat schemas, examples, `manifest.json`, `README.md`, `LICENSE`, and `index.js` as the shipped release payload. Treat `checksums.txt` as the ledger for that payload.
+6. Treat `schemas/v1.1.0/`, `examples/v1.1.0/`, `manifest.json`, `checksums.txt`, `README.md`, `LICENSE`, and `index.js` as the canonical shipped boundary for the current line. Treat the checksum-covered subset as that same boundary minus `checksums.txt` itself.
 
-Package-install instructions are intentionally minimal here because npm publication state for `@commandlayer/commercial` could not be verified from this repository alone.
+The install command above is a future-publication consumer path, not a claim that npm publication has already happened. In the current repository state, the checked-in artifacts are the authoritative release candidate surface.
 
 ## Commercial execution model
 
@@ -175,6 +175,8 @@ protocol-commercial/
 └── scripts/
 ```
 
+When npm produces a tarball, it also emits `package.json` as required package metadata. That generated tarball addition does not widen the canonical shipped boundary described above.
+
 Protocol-Commercial v1.1.0 does **not** use a current-line `_shared/` tree. Every v1.1.0 request and receipt schema is self-contained, flat, and mirror-safe.
 
 ### Browsing large self-contained schemas
@@ -266,9 +268,10 @@ sha256sum -c checksums.txt
 
 - `npm test` runs the full current-line validation aggregate (`npm run validate`).
 - `npm run validate:schemas` checks current-line metadata, package boundary, schema identity, layout, and manifest/index alignment expectations.
-- `npm run validate:examples` validates every current-line JSON valid and invalid example against the canonical schemas.
+- `npm run validate:examples` validates every shipped v1.1.0 JSON valid and invalid example fixture against the canonical schemas.
 - `npm run validate:integrity` verifies the canonical shipped payload scope and hash coverage for the current release line.
-- `checksums.txt` intentionally covers the shipped payload excluding the ledger itself: `manifest.json`, `schemas/v1.1.0/`, `examples/v1.1.0/`, `LICENSE`, `README.md`, and `index.js`.
+- `checksums.txt` intentionally covers the shipped boundary excluding the ledger itself: `manifest.json`, `schemas/v1.1.0/`, `examples/v1.1.0/`, `LICENSE`, `README.md`, and `index.js`.
+- `npm run validate:pack` checks that `npm pack --dry-run` contains only the canonical shipped boundary plus npm-emitted `package.json`.
 
 ## Agent Cards and Commons alignment
 
@@ -287,7 +290,7 @@ Protocol-Commons and Protocol-Commercial therefore tell one coherent story:
 
 The checksum boundary is defined normatively in `SPEC.md` and governed by `POLICY.md`.
 
-`checksums.txt` is the generated hash ledger for the shipped payload; it describes that surface but is not itself part of the hashed payload, so checksum verification confirms covered files only relative to the checked-in `checksums.txt` ledger and does not independently authenticate that ledger. Repository docs outside the published package surface remain authoritative guidance inside the repo, but they are not shipped or checksum-covered unless package metadata is expanded deliberately in a later release.
+`checksums.txt` is the generated hash ledger for the shipped payload; it describes that surface but is not itself part of the hashed payload, so checksum verification confirms covered files only relative to the checked-in `checksums.txt` ledger and does not independently authenticate that ledger. Repository docs outside the shipped package surface remain authoritative guidance inside the repo, but they are not shipped or checksum-covered unless package metadata is expanded deliberately in a later release.
 
 For external verification, the minimal path is:
 

diff --git a/SECURITY_PROVENANCE.md b/SECURITY_PROVENANCE.md
@@ -2,7 +2,7 @@
 
 ## Release posture
 
-Current release line: `v1.1.0`
+Current release line: `v1.1.0` (repository-validated, not yet asserted as publicly published)
 
 Canonical shipped npm package surface:
 
@@ -14,7 +14,7 @@ Canonical shipped npm package surface:
 - `README.md`
 - `index.js`
 
-Checksum-covered published payload:
+Checksum-covered shipped payload:
 
 - `schemas/v1.1.0/`
 - `examples/v1.1.0/`
@@ -23,14 +23,16 @@ Checksum-covered published payload:
 - `README.md`
 - `index.js`
 
-`checksums.txt` is the generated SHA-256 ledger for that checksum-covered payload. Because the ledger describes the payload, it is not itself part of the hashed payload. Checksum verification therefore confirms the published payload relative to the checked-in `checksums.txt` ledger and does not independently authenticate that ledger.
+`checksums.txt` is the generated SHA-256 ledger for that checksum-covered payload. Because the ledger describes the payload, it is not itself part of the hashed payload. Checksum verification therefore confirms the shipped payload relative to the checked-in `checksums.txt` ledger and does not independently authenticate that ledger.
 
 Release integrity state for this repository:
 
-- `manifest.json` marks `v1.1.0` as the current release line.
+- `manifest.json` marks `v1.1.0` as the current draft line and avoids asserting a completed external publication date.
 - `checksums.txt` records repository-local SHA-256 digests for the canonical shipped payload excluding the ledger file itself.
 - `index.js` resolves the package root export to `schemas/v1.1.0/index.json`.
 - Canonical schema `$id` values resolve to the commandlayer.org release paths for `v1.1.0`.
 - Retained `v1.0.0` material is repository-only historical source and is not part of the shipped package boundary.
 
 This file makes only repository-backed claims. It does not assert external pin, CID, or public mirror state unless those values are recorded in this repository.
+
+The repository does not currently claim signed provenance attestations, external transparency-log inclusion, or registry publication beyond what can be verified from checked-in files.
diff --git a/SPEC.md b/SPEC.md
@@ -1,6 +1,6 @@
 # SPEC — Protocol-Commercial v1.1.0
 
-This document is normative for the active v1.1.0 commercial release line.
+This document is normative for the active v1.1.0 commercial release line in its repository-validated, pre-publication state.
 
 ## 1. Scope
 
@@ -14,15 +14,15 @@ This specification governs:
 - deterministic versioning rules
 - x402-first commercial binding expectations
 - validation and integrity requirements
-- canonical published package boundary requirements
+- canonical shipped package boundary requirements
 
 This specification does not govern runtime transport implementation, provider policy, or legal adjudication.
 
 ## 2. Canonical release boundary
 
-The canonical published package line is `v1.1.0` only.
+The canonical shipped line is `v1.1.0` only.
 
-Canonical published package contents:
+Canonical shipped package contents:
 
 - `schemas/v1.1.0/`
 - `examples/v1.1.0/`
@@ -32,7 +32,7 @@ Canonical published package contents:
 - `README.md`
 - `index.js`
 
-Checksum-covered published payload:
+Checksum-covered shipped payload:
 
 - `schemas/v1.1.0/`
 - `examples/v1.1.0/`
@@ -48,7 +48,7 @@ Historical repository-only material that is outside the canonical shipped packag
 - `schemas/v1.0.0/`
 - `examples/v1.0.0/`
 
-Additional prose docs may remain authoritative for interpretation or process inside the repository, but they are outside the published package surface unless package metadata is changed deliberately in a later release.
+Additional prose docs may remain authoritative for interpretation or process inside the repository, but they are outside the shipped package surface unless package metadata is changed deliberately in a later release.
 
 ## 3. Version and identity rules
 
@@ -58,8 +58,8 @@ Additional prose docs may remain authoritative for interpretation or process ins
 4. A schema file path and its `$id` MUST agree exactly.
 5. A v1.1.0 schema MUST NOT be mutated in place after release publication.
 6. Breaking or meaning-changing edits require a new version directory.
-7. `manifest.json` MUST identify the current release line and any retained repository-only legacy lines.
-8. `checksums.txt` MUST enumerate the checksum-covered published payload exactly and MUST NOT be described as protecting files it does not hash.
+7. `manifest.json` MUST identify the current release line, publication posture, and any retained repository-only legacy lines.
+8. `checksums.txt` MUST enumerate the checksum-covered shipped payload exactly and MUST NOT be described as protecting files it does not hash.
 9. The npm `files` surface and package exports MUST exclude non-canonical legacy lines unless those lines are revalidated and intentionally reintroduced.
 
 ## 4. Current path model
@@ -167,12 +167,17 @@ A conformant release MUST satisfy all of the following:
 - every declared verb has valid and invalid examples for both request and receipt artifacts
 - 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
-- the package `files` field matches the canonical published package boundary exactly
+- the package `files` field matches the canonical shipped package boundary exactly
 - `npm test` passes as the current-line validation aggregate
 - `npm run validate:schemas` passes
 - `npm run validate:examples` passes
 - `npm run validate:integrity` passes
-- `sha256sum -c checksums.txt` passes for the checksum-covered published payload
-- repository metadata does not drift from the active current line
+- `sha256sum -c checksums.txt` passes for the checksum-covered shipped boundary
+- repository metadata does not drift from the active current line or overclaim publication state
 
 The canonical command list lives in `README.md#validation-commands`.
+
+
+## 10. Publication posture
+
+Until a public release is actually performed, repository metadata MUST describe `v1.1.0` as the current line without claiming that npm publication, GitHub Release publication, or signed provenance publication has already happened. `release_date` MAY remain null before publication, and any publication-state field MUST describe repository-local readiness only.