Tighten the v1.1.0 release package boundary

.github/workflows/validate.yml

@@ -18,8 +18,7 @@ jobs:
           node-version: 20
           cache: npm
       - run: npm ci
-      - run: npm run validate:schemas
-      - run: npm run validate:examples
-      - run: npm run validate:integrity
+      - run: npm run validate
       - run: npm run generate:checksums
       - run: git diff --exit-code -- checksums.txt
+      - run: npm pack --dry-run

ONBOARDING.md

@@ -4,18 +4,19 @@ 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 maintainer intent before editing.
+Use this document to understand the repository shape, release line, and published 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 the repository contents directly, or a published distribution only after release metadata confirms it.
-2. Confirm the current line in `manifest.json` and use `schemas/v1.1.0/index.json` as the authoritative schema map.
-3. Choose flat schemas under `schemas/v1.1.0/commercial/<verb>/` for validator configuration.
-4. Run the maintained verification commands listed in `SPEC.md` before mirroring or vendoring.
-5. Treat `examples/v1.1.0/commercial/<verb>/valid/` and `invalid/` as conformance fixtures.
-6. Use `v1.0.0` only when compatibility with the historical nested path model is required.
+1. Use `manifest.json` to confirm that `v1.1.0` is the current line.
+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.
+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.
 
 ## Maintainer workflow
 
@@ -26,8 +27,8 @@ 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` only when checksum-covered machine artifacts change.
-5. Keep current-line teaching focused on `v1.1.0` and mark `v1.0.0` as retained legacy.
+4. Regenerate `checksums.txt` when any checksum-covered published payload 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
 
@@ -36,18 +37,19 @@ High-level maintainer sequence:
 3. Create matching example folders under `examples/<new-version>/commercial/<verb>/valid` and `invalid`.
 4. Add at least one valid request, one alternate valid request or receipt, one invalid request, and one invalid receipt.
 5. Make every invalid example isolate a single intended failure when practical.
-6. Do not add an ungoverned `examples/v1.1.0/**/ts/` surface to the current line.
-7. Update `manifest.json`, `schemas/<version>/index.json`, validation expectations, and checksums.
-8. Update README, INTEGRATOR, SPEC, and release-process docs if the public teaching surface changed.
-9. Confirm public docs controlled by this repo still teach the exact current path model and current script names.
+6. Do not add an ungoverned `examples/v1.1.0/**/ts/` surface to the active line.
+7. Update `manifest.json`, `schemas/<version>/index.json`, package exports, validation expectations, and checksums.
+8. Update README, SPEC, and release-process docs if the public teaching surface changed.
+9. Confirm public docs controlled by this repo still teach the exact current path model and shipped package boundary.
 
 ## Version bumps
 
 1. Never mutate a published version directory in place after release.
 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 current line's machine-artifact set.
+5. Regenerate checksums for the new line's checksum-covered published 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`.
 
@@ -56,16 +58,16 @@ For the canonical path model and namespace rules, see `SPEC.md`.
 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:
 
 1. Publish the GitHub Release using `releases/v1.1.0.md` or the corresponding new-version draft.
-2. Pin the checksum-covered release artifact set to IPFS, if that distribution channel is being used for the release.
+2. Pin the checksum-covered published 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.
 
 ## Release hygiene
 
 - Keep the current line obvious.
-- Keep legacy lines explicitly marked as legacy.
+- Keep legacy lines explicitly marked as repository-only historical material.
 - Keep schema paths flat and mirror-safe.
-- Keep checksum scope explicit.
+- Keep package surface and checksum scope explicit.
 - Keep GitHub Releases and repository docs in sync.
 - Prefer linking over duplication.

POLICY.md

@@ -1,25 +1,48 @@
 # POLICY — Protocol-Commercial
 
-This policy governs the current release line and its release-management rules. Repo-wide governance and security reporting are defined separately.
+This policy governs the active release line and the canonical published package boundary. Repo-wide governance and security reporting are defined separately.
 
 ## Current line
 
-`v1.1.0` is the current Protocol-Commercial line.
+`v1.1.0` is the current Protocol-Commercial line and the only canonical published package line.
 
-`v1.0.0` remains published for backward compatibility and audit, but it is superseded and non-canonical for new integrations.
+`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.
 
 ## Change control
 
 - No published version directory may be silently mutated after release.
 - Breaking or semantic changes require a new version directory.
-- Release metadata, examples, schema paths, and checksums must remain internally consistent.
-- Public documentation controlled by this repo must teach the same path model the repo actually ships.
+- Release metadata, package contents, schema paths, examples, and checksums must remain internally consistent.
+- Public documentation controlled by this repo must teach the same current-line package boundary the repo actually ships.
 
-## Normative artifact state
+## Canonical published boundary
 
-The checksum-covered release state consists of the current schema tree, current examples tree, and `manifest.json`. `checksums.txt` is the generated ledger for that machine-artifact set.
+The canonical published package surface for `v1.1.0` is limited to:
 
-Release-defining prose docs may govern interpretation and process, but they are outside checksum coverage unless the checksum tooling is changed deliberately.
+- `schemas/v1.1.0/`
+- `examples/v1.1.0/`
+- `manifest.json`
+- `checksums.txt`
+- `LICENSE`
+- `README.md`
+- `index.js`
+
+Legacy `v1.0.0` schemas, examples, and any historical TypeScript fixtures are repository-retained material only unless a future release explicitly restores them to a validated package boundary.
+
+## Integrity boundary
+
+`checksums.txt` is the generated ledger for the canonical published package payload, excluding `checksums.txt` itself.
+
+The checksum-covered payload consists of:
+
+- `schemas/v1.1.0/`
+- `examples/v1.1.0/`
+- `manifest.json`
+- `LICENSE`
+- `README.md`
+- `index.js`
+
+Release-defining prose docs outside that list are repository guidance only and must not be described as part of the shipped or checksum-covered release payload.
 
 ## Governance threshold
 

README.md

@@ -27,14 +27,15 @@ Protocol-Commercial is intentionally limited to protocol truth:
 
 ## Document scope
 
-This README is a repo-wide orientation document for the current release line and its retained legacy line.
+This README is a repo-wide orientation document for the active release line and its canonical published package boundary.
 
 ## Release truth
 
 - **Current canonical line:** `v1.1.0`
 - **Current canonical schema root:** `https://commandlayer.org/schemas/v1.1.0/`
-- **Current package entrypoint:** `schemas/v1.1.0/index.json`
-- **Historical legacy line:** `v1.0.0`, retained under `schemas/v1.0.0/` and `examples/v1.0.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`
+- **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`
 
@@ -49,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 published package contents are the source of truth for those artifacts.
+- This Git repository and its canonical published 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
@@ -72,23 +73,23 @@ The stack story is singular:
 
 For consumers who need the shortest safe path:
 
-1. Install the package and import the current index entrypoint using the explicit JSON path export.
+1. Install the package and use the package-root export or explicit current-line schema export.
    ```bash
    npm install @commandlayer/commercial
    ```
    ```js
-   import commercialIndex from '@commandlayer/commercial/schemas/v1.1.0/index.json';
+   import commercialIndex from "@commandlayer/commercial";
    ```
-   The bare package import `@commandlayer/commercial` resolves to the same file today, but treat that shortcut as environment-dependent rather than the default documentation path.
-2. Treat `schemas/v1.1.0/index.json` as the authoritative map of current schemas and verb inventory.
+   ```js
+   import commercialSchemaIndex from "@commandlayer/commercial/schemas/v1.1.0/index.json";
+   ```
+2. Treat `schemas/v1.1.0/index.json` as the authoritative map of current schemas and verb inventory. The package-root `index.js` export resolves to that same file.
 3. Prefer `schemas/v1.1.0/commercial/<verb>/<verb>.request.schema.json` and `...receipt.schema.json` directly for validator configuration.
-4. Verify the machine-artifact set before mirroring or vendoring using the canonical command surface in [Validation commands](#validation-commands).
-5. Ignore `v1.0.0` unless you are maintaining compatibility with historical nested paths. Current automated validation targets `v1.1.0`; retained `v1.0.0` artifacts remain published for compatibility and audit without equal current-line guarantees.
-6. Treat schemas and `manifest.json` as normative machine artifacts. Treat examples as illustrative conformance fixtures. Treat prose docs as normative interpretation and release-process guidance.
-
-Package-install instructions are intentionally omitted here because npm publication for `@commandlayer/commercial` could not be verified from this repository alone.
+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.
 
-A longer external-consumer workflow lives in `INTEGRATOR.md`.
+Package-install instructions are intentionally minimal here because npm publication state for `@commandlayer/commercial` could not be verified from this repository alone.
 
 ## Commercial execution model
 
@@ -144,7 +145,7 @@ The verbs use those layers intentionally:
 ```text
 protocol-commercial/
 ├── schemas/
-│   ├── v1.0.0/                     # published legacy line; historical nested layout
+│   ├── v1.0.0/                     # repository-only historical nested layout
 │   └── v1.1.0/
 │       ├── index.json
 │       └── commercial/
@@ -164,12 +165,13 @@ protocol-commercial/
 │               ├── verify.request.schema.json
 │               └── verify.receipt.schema.json
 ├── examples/
-│   ├── v1.0.0/                     # published legacy line
+│   ├── v1.0.0/                     # repository-only historical examples
 │   └── v1.1.0/commercial/<verb>/{valid,invalid}/
 ├── manifest.json
 ├── checksums.txt
-├── CHANGELOG.md
-├── INTEGRATOR.md
+├── index.js
+├── LICENSE
+├── README.md
 └── scripts/
 ```
 
@@ -263,10 +265,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, schema identity, layout, and manifest/index alignment expectations.
+- `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: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/`, and `examples/v1.1.0/`.
+- `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`.
 
 ## Agent Cards and Commons alignment
 
@@ -279,18 +281,18 @@ Protocol-Commons and Protocol-Commercial therefore tell one coherent story:
 - Commons defines base actions.
 - Commercial defines monetized overlays.
 - Agent Cards point at the current flat commercial schema paths.
-- Legacy nested v1.0.0 paths remain published only for compatibility.
+- Legacy nested v1.0.0 paths remain in the repository only as historical source material.
 
 ## Checksum boundary and provenance summary
 
 The checksum boundary is defined normatively in `SPEC.md` and governed by `POLICY.md`.
 
-`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, so checksum verification confirms covered files only relative to the checked-in `checksums.txt` ledger and does not independently authenticate that ledger. Release-defining prose docs such as `README.md`, `SPEC.md`, `POLICY.md`, `SECURITY_PROVENANCE.md`, `INTEGRATOR.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 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.
 
 For external verification, the minimal path is:
 
 1. Inspect `manifest.json` to confirm the current line is `v1.1.0`.
 2. Run `npm run validate:integrity`.
 3. Run `sha256sum -c checksums.txt`.
 4. Load `schemas/v1.1.0/index.json` and bind validators from the listed request and receipt schema paths.
-5. Ignore `v1.0.0` unless compatibility requires the historical line.
+5. Ignore `v1.0.0` unless you are consulting repository-only historical material during migration work.

SECURITY_PROVENANCE.md

@@ -4,18 +4,33 @@
 
 Current release line: `v1.1.0`
 
-Checksum-covered machine-artifact roots:
+Canonical shipped npm package surface:
 
 - `schemas/v1.1.0/`
 - `examples/v1.1.0/`
 - `manifest.json`
+- `checksums.txt`
+- `LICENSE`
+- `README.md`
+- `index.js`
 
-`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, so checksum verification confirms covered files only relative to the checked-in `checksums.txt` ledger and does not independently authenticate that ledger. Release-defining prose docs in the repository are intentionally outside this checksum boundary and must not be described as checksum-protected.
+Checksum-covered published payload:
+
+- `schemas/v1.1.0/`
+- `examples/v1.1.0/`
+- `manifest.json`
+- `LICENSE`
+- `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.
 
 Release integrity state for this repository:
 
 - `manifest.json` marks `v1.1.0` as the current release line.
-- `checksums.txt` records repository-local SHA-256 digests for the normative schema and example artifacts published from this tree.
+- `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.