diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index 9b10be4..3b0b86d 100644 --- a/.github/workflows/validate.yml +++ b/.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. diff --git a/CHANGELOG.md b/CHANGELOG.md index 4e7a172..7da4ba4 100644 --- a/CHANGELOG.md +++ b/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] diff --git a/ONBOARDING.md b/ONBOARDING.md index afbfe37..9d0733d 100644 --- a/ONBOARDING.md +++ b/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 diff --git a/README.md b/README.md index 64016be..8314ea3 100644 --- a/README.md +++ b/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. diff --git a/SECURITY.md b/SECURITY.md index 11e32ae..e1e6c26 100644 --- a/SECURITY.md +++ b/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