docs: enforce release validation in CI; update README, CHANGELOG, SECURITY, ONBOARDING

.github/workflows/validate.yml

@@ -28,7 +28,7 @@ jobs:
       - name: Verify release checksums
         run: npm run validate:checksums
 
-      - name: Release validation
+      - name: Validate release reproducibility and external bindings
         run: npm run validate:release
 
       # Mirror enforcement stays explicit because publish-time mirror availability can lag normal CI.

CHANGELOG.md

@@ -1,59 +1,38 @@
 # Changelog
 
-This changelog records release-line differences that are visible in the checked-in schemas, cards, discovery artifacts, and release validation flow.
+This changelog records release-line differences that are visible in the checked-in schemas, cards, discovery artifacts, and validation flow.
 
 ## [1.1.0]
 
-### Why 1.1.0 happened
+### Summary
 
-`v1.1.0` establishes the current canonical Agent Cards line around flat, directly inspectable bindings and reproducible release artifacts. The goal is to remove migration-era ambiguity from cards, discovery descriptors, and publication surfaces so reviewers can validate the current release line without inferring hidden inheritance or historical packaging assumptions.
+`v1.1.0` is the current canonical Agent Cards line. It replaces the older `v1.0.0` working shape with a flatter current-line structure, direct schema bindings, and release validation centered on canonical root artifacts plus a reproducible derivative publish bundle.
 
-### Added
+### Removed from the current line
 
-- Flat `v1.1.0` agent card structure aligned directly to the current protocol schema surfaces.
-- Required `schemas_mirror` bindings alongside authoritative upstream schema URLs for each current-line card.
-- Release validation and checksum-oriented artifact discipline for canonical root artifacts plus the derivative `dist-pin/` publish bundle.
-- Clearer metadata around current published artifacts, including manifest and discovery authority boundaries.
+- Current-line reliance on `_shared` composition or inherited card structure.
+- Deprecated descriptive fields from the current `v1.1.0` card surface, including `slug`, `display_name`, `description`, `capabilities`, and `meta`.
+- Migration-era assumptions that treated older descriptor-led or packaging patterns as part of the active release path.
 
-### Changed
+### Structural changes
 
-- `v1.1.0` cards now bind directly to current Commons and Commercial protocol surfaces rather than older shared or inherited descriptor patterns.
-- Descriptor and publication surfaces were simplified so root repository artifacts are authoritative, `.well-known/` stays discovery-only, and `dist-pin/agent-cards/v1.1.0/` is explicitly derivative.
-- Current-line schema references moved to tagged HTTPS source URLs and `commandlayer.org` mirror URLs.
-- Validation for the current line is centered on canonical cards, manifest alignment, checksums, and reproducible release artifacts.
-
-### Removed
-
-- Legacy or shared structural patterns carried forward from `v1.0.0` where they were no longer needed for the current line.
-- Deprecated descriptive card fields from the current-line schema surface, including `slug`, `display_name`, `description`, `capabilities`, and `meta`.
-- Deprecated internal migration-era packaging assumptions that made the publication path harder to inspect.
-
-### Flattened
-
-- Current-line cards are intentionally flat and minimal, publishing binding facts directly instead of relying on `_shared` composition for `v1.1.0`.
-- Current release validation treats the repository root as the authority surface and the publish bundle as a reproducible copy, not a second source of truth.
-
-### Moved
-
-- Current schema bindings moved from legacy IPFS-era and descriptor-led references to direct tagged HTTPS schema URLs plus explicit public mirror URLs.
-- Current publication expectations moved toward manifest-checked, checksum-covered, release-validated root artifacts.
+- `v1.1.0` cards are flat and live directly under `agents/v1.1.0/`.
+- Current cards bind directly to tagged Commons and Commercial schema URLs plus explicit `commandlayer.org` mirror URLs.
+- Root repository artifacts are the authority surface for the current line, while `dist-pin/agent-cards/v1.1.0/` is a committed derivative bundle that must remain reproducible from the root.
+- Validation for the current line includes schema/card integrity, manifest alignment, checksums, and release reproducibility.
 
 ### Legacy status
 
-- `v1.0.0` remains legacy-compatible where documented, but it is no longer the current canonical working line.
-- `v1.0.0` artifacts are retained for archival compatibility and migration review, not as the preferred source for new integrations.
-
-### Breaking or non-breaking?
-
-- For consumers already treating `v1.1.0` as a distinct release line, this is the authoritative current line and not a surprise patch over `v1.0.0`.
-- For tooling that depended on `v1.0.0` shared schema paths, broader descriptor assumptions, descriptive card fields, or older publication layouts, migrating to `v1.1.0` is a breaking change and requires updates.
+- `v1.0.0` remains in-tree only as an archival compatibility line.
+- Legacy `v1.0.0` materials may still include broader card fields, `_shared` schema structure, and older descriptor or publication assumptions that do not apply to the `v1.1.0` authority path.
+- Legacy artifacts are retained for migration review and compatibility, not as the preferred source for new integrations.
 
-### Migration notes
+### Migration implications
 
-- Treat `v1.1.0` as the authoritative current line.
-- Update tooling that expects `v1.0.0` shared schema paths, descriptor-led inheritance, or IPFS-era schema bindings.
+- Treat `v1.1.0` as the authoritative release line for current integrations and validation.
+- Update tooling that expected `v1.0.0` shared schema paths, broader descriptive card fields, or older descriptor-led publication layout.
 - Expect current cards to expose only the minimal binding fields required by the `v1.1.0` schema.
-- Use the root package validation and release commands, and validate against the canonical root artifacts plus `checksums.txt`.
+- Use the root package commands, especially `npm run validate` and `npm run validate:release`, when reviewing or publishing the current line.
 
 ## [1.0.0]
 

ONBOARDING.md

@@ -25,7 +25,7 @@ Do not add descriptive fields to current-line cards; if the detail is not a bind
 
 The `scripts/archive/` directory is retained for historical reference only. It is not part of the current `v1.1.0` workflow and should not be treated as an active or supported execution path.
 
-Use the root package scripts and documented current validation and release commands instead.
+Use the supported root package scripts and current commands instead: `npm run validate`, `npm run validate:release`, `npm run generate:dist-pin`, `node scripts/generate-checksums.mjs`, and the current validators under `scripts/validate-cards.mjs` and `scripts/validate-release.mjs`.
 
 ## Legacy / compatibility
 

README.md

@@ -2,7 +2,7 @@
 
 Agent Cards are CommandLayer's canonical discovery and binding artifacts. They bind ENS names to a single verb, the authoritative request/receipt schemas for that verb, the public schema mirrors, and the semver-pinned x402 entrypoint. They do not act as product pages, feature summaries, or semantic substitutes for the linked protocol schemas.
 
-In these cards, `x402://...` is the protocol-form entry identifier used by CommandLayer agents. It represents a standardized action endpoint (verb + route + version). See the external x402 protocol specification at `https://docs.x402.org/` for the canonical protocol definition.
+In these cards, `x402://...` is the protocol-form entry identifier used by CommandLayer agents. It represents a standardized action endpoint (verb + route + version). This repository may interoperate with x402-related payment context where relevant, but it does not define x402 itself; see the external x402 protocol specification at `https://docs.x402.org/` for the canonical protocol definition.
 
 See `CHANGELOG.md` for version differences.
 

SECURITY.md

@@ -1,53 +1,62 @@
 # Security Policy
 
-This repository publishes discovery metadata, schema bindings, manifests, and checksums for CommandLayer Agent Cards.
+This repository publishes discovery metadata, schema bindings, manifests, release validation logic, and checksums for CommandLayer Agent Cards.
 
 ## Reporting a vulnerability
 
-Please report suspected security issues to: `dev@commandlayer.org`
+Report suspected security issues to: `security@commandlayer.org`
 
 Include:
-- affected repository and version
+- affected repository path, artifact, or command
+- affected release line or version
 - reproduction steps
-- proof of concept, if available
+- proof of concept, logs, or sample output if available
 - impact assessment
-- any suggested mitigations
+- any suggested mitigation or patch
 
 Please do not open public issues for unpatched vulnerabilities.
 
-## Supported reporting path
+## Supported intake and handling
 
-Email is the supported intake path for private vulnerability reports affecting this repository's trust, validation, release, or publication surfaces. If we need follow-up context, we may continue the discussion by email and ask for a minimal private reproduction or patch suggestion.
+Email is the supported intake path for private vulnerability reports affecting this repository's trust, validation, release, or publication surfaces. We may continue follow-up by email to request clarification, a minimal reproduction, or a proposed patch.
 
 ## Disclosure process
 
 After receiving a report, we will:
 1. acknowledge receipt
-2. validate and reproduce the issue
-3. assess severity and affected surfaces
-4. prepare a fix or mitigation
-5. coordinate disclosure as appropriate
+2. review the report for scope and reproducibility
+3. reproduce and assess severity where possible
+4. decide on remediation, mitigation, or documented rejection if the report is out of scope
+5. coordinate a disclosure timeline with the reporter when a valid issue is confirmed
+6. publish a fix, mitigation, or advisory when appropriate
 
-We ask reporters to avoid public disclosure until remediation or coordinated disclosure timing has been agreed.
+We ask reporters not to disclose valid issues publicly until remediation is available or a coordinated disclosure date has been agreed. If a report cannot be reproduced or is out of scope, we will say so directly.
 
 ## Response targets
 
+Target response times for this repository are:
 - Initial acknowledgment: within 3 business days
-- Triage or status update after review: within 7 business days
-- Fix timeline: depends on severity, impact, and release scope
+- Triage outcome or substantive status update: within 7 business days
+- Remediation plan for confirmed in-scope issues: within 14 business days
+- Fix release timing: depends on severity, review scope, and whether the change affects the canonical `v1.1.0` release surfaces or only archival material
 
-## Scope
+These are targets, not guarantees.
 
-This policy covers:
-- schema integrity issues with security implications
-- validation bypasses
-- artifact substitution or release integrity issues
-- signing or verification related issues
-- metadata or publication issues that could mislead integrators about trust surfaces
+## In scope
+
+This policy covers security issues that materially affect the integrity, trust, or validation story of this repository, including:
+- release or artifact substitution risks
+- checksum generation or verification bypasses
+- validation bypasses or false-positive validation paths
+- schema, manifest, or discovery metadata issues that could cause consumers to trust the wrong current-line artifact
+- publication or build issues that break reproducibility of canonical root artifacts or the derivative `dist-pin/` bundle
+- secrets accidentally committed to this repository
 
 ## Out of scope
 
 This policy does not cover:
 - general feature requests
-- stylistic documentation issues
-- unsupported historical artifacts unless they create active security risk
+- stylistic or editorial documentation issues with no security impact
+- requests to broaden protocol support beyond what the repository currently implements
+- vulnerabilities in external dependencies or external protocol specifications unless they create a concrete security issue in this repository's checked-in artifacts or validation flow
+- unsupported historical artifacts unless they create an active security risk for the current release line