Repository navigation
fix(spec): vendor agentnative-spec v0.6.0 - #136
Merged
Merged
Conversation
The vendored spec read 0.5.0 while the registry already carried `p3-should-unprefixed-command-list`, so every scorecard declared conformance to a published standard that did not define a requirement it graded. Spec v0.6.0 publishes that SHOULD, and `spec_version` now reports 0.6.0. Vendored through `scripts/sync-spec.sh`, which resolved v0.6.0 at 5077a5d. Only `VERSION` and the vendored `CHANGELOG.md` move: the principle text was already current, having been vendored from the spec's `dev` branch while the requirement was in flight, so the generated requirement set, the registry counts, and the coverage matrix are untouched. `src/principles/spec/CHANGELOG.md` joins the markdownlint ignore list alongside the root changelog. The vendored file carries upstream's one-logical-line-per-bullet shape, which trips MD013, and wrapping it would make the vendored copy differ from upstream rather than match it byte for byte.
12 of 14 tasks
brettdavies
added a commit
to brettdavies/agentnative-site
that referenced
this pull request
Oct 5, 2026
## Summary Vendors `agentnative-spec` v0.6.0 into `src/data/spec/`, which publishes `p3-should-unprefixed-command-list`: command-list entries SHOULD name the command directly (`status`, `server stop`) rather than repeat the binary name on every line, with the bare invocation line as the one entry that legitimately carries the binary name alone. `SPEC_VERSION` moves to 0.6.0. Vendored through `scripts/sync-spec.sh`, resolved at 5077a5d. `SITE_SPEC_VERSION` deliberately stays at 0.5.0. Per `src/data/spec/README.md`, the vendored copy is a reference snapshot with no user-visible surface, while the footer renders `SITE_SPEC_VERSION` from `content/principles/VERSION` and moves only once a contributor reconciles the site's own principle prose. The footer therefore keeps making an honest claim about what the rendered pages describe, which is the state that README calls out explicitly. Reconciling `content/principles/p3-progressive-help-discovery.md` and bumping that marker is the editorial follow-up, and it is not in this PR. `tests/build-mcp-catalog.test.ts` asserted the catalog's `spec_version` against a literal `'0.5.0'` while already importing `SPEC_VERSION` and passing it in as the input, so it pinned a value guaranteed to go stale on the next spec sync. It now asserts the pass-through against the constant. ## Changelog ### Changed - Vendor spec v0.6.0, which adds the `p3-should-unprefixed-command-list` SHOULD to the reference snapshot the web audit and discovery documents read. ## Type of Change - [x] `fix`: Bug fix (non-breaking change which fixes an issue) ## Related Issues/Stories - Story: n/a - Issue: n/a - Architecture: `src/data/spec/README.md` (the three version markers and which surface each drives); `scripts/SYNCS.md` (`sync-spec.sh` row) - Related PRs: brettdavies/agentnative#56 (the spec v0.6.0 release), brettdavies/agentnative-cli#136 (the same sync on the CLI side), #426 (the `ANC_VERSION` sync) ## Files Modified **Modified:** - `src/data/spec/VERSION`: 0.5.0 to 0.6.0. - `src/data/spec/CHANGELOG.md`: vendored, gains the upstream 0.6.0 section. - `src/data/spec/principles/p3-progressive-help-discovery.md`: vendored, gains the new SHOULD and its requirement block. - `src/worker/spec-version.gen.ts`: regenerated, `SPEC_VERSION` only. - `tests/build-mcp-catalog.test.ts`: assert `spec_version` against `SPEC_VERSION` instead of a literal. **Created:** - None. **Renamed:** - None. **Deleted:** - None. ## Testing - [ ] Unit tests added/updated - [x] Integration tests added/updated - [x] Manual testing completed - [x] All tests passing **Test Summary:** `bun test` reports 2774 pass / 111 fail, which is identical to the count on a clean `origin/dev` checkout. The 111 are pre-existing and environment-dependent: they are the `(built dist/)` suites that need a prior `bun run build`, plus the R2-backed paths that have no local binding. That baseline was measured rather than assumed. Running the suite before the change gave 111 failures and after gave 112, and diffing the normalized failure names isolated the single regression to `buildMcpCatalog: shape invariants > top-level fields present`, the hardcoded `'0.5.0'` assertion. With that assertion fixed the totals match the baseline exactly, so this change introduces no net regression. ## Breaking Changes - [x] No breaking changes ## Deployment Notes - [ ] No special deployment steps required - [x] Deployment steps documented below: `SPEC_VERSION` is part of the web-audit cache key (`audits/web/<url-hash>/<SPEC_VERSION>.json`) and of the domain-budget hold key, so this bump **rotates every web-audit cache entry**. Expect cached web audits to miss and re-audit after deploy, and the web leaderboard to repopulate as they do. `src/worker/audit-web/leaderboard-render.ts` already carries a comment describing this behaviour from a previous `SPEC_VERSION` bump, so it is expected rather than new. Merge-order note: this PR and #426 both regenerate `src/worker/spec-version.gen.ts` on adjacent lines (`SPEC_VERSION` here, `ANC_VERSION` there). Whichever merges second should regenerate the file with `bun src/build/00-spec-version-gen.mjs` rather than hand-resolving a conflict. ## Checklist - [x] Code follows project conventions and style guidelines - [x] Commit messages follow [Conventional Commits](https://www.conventionalcommits.org/) - [x] Self-review of code completed - [x] Tests added/updated and passing - [x] No new warnings or errors introduced - [x] Changes are backward compatible (or breaking changes documented) ## Additional Context Two things found while doing this that are not fixed here: - The spec's `publish.yml` dispatches a `spec-release` event to this repo and to `agentnative-cli` on every tagged release, with the loop commented "Non-fatal: downstream consumers opt in when they wire handlers." Neither repo has a handler, so the dispatch is a silent no-op and this sync had to be run by hand. `scripts/SYNCS.md` already tracks the auto-PR handler as a follow-up. - `tests/spec-version-hardcoding.test.ts` is a red-team guard against `ANC_VERSION`-shaped literals in tests, but the literal fixed in this PR was a `SPEC_VERSION` one and slipped through. Widening that guard to cover all three markers would have caught it at authoring time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Vendors
agentnative-specv0.6.0, sospec_versionin every scorecard reports 0.6.0 instead of 0.5.0.This closes a coherence gap rather than adopting new requirements. The registry already carried
p3-should-unprefixed-command-listandancalready graded it, because the principle text was vendored from the spec'sdevbranch while the requirement was in flight. The vendoredVERSIONstayed at 0.5.0, so published scorecards declared conformance to a standard that did not define a requirement they carried a row for. Spec v0.6.0 publishes that SHOULD.Only
VERSIONand the vendoredCHANGELOG.mdchange. The principle text is byte-identical to what was already vendored, so the generated requirement set, the registry counts, anddocs/coverage-matrix.mdare all untouched.src/principles/spec/CHANGELOG.mdalso joins the markdownlint ignore list, next to the root changelog that is already there for the same reason. The vendored file carries upstream's one-logical-line-per-bullet shape, which trips MD013 at 189 to 379 characters on the new 0.6.0 bullets. Wrapping it would make the vendored copy differ from upstream, which is the one propertyscripts/sync-spec.shexists to preserve.Changelog
Changed
spec_version: "0.6.0"in scorecards, matching the published spec that now definesp3-should-unprefixed-command-list.Type of Change
fix: Bug fix (non-breaking change which fixes an issue)Related Issues/Stories
scripts/SYNCS.md(sync-spec.shrow)Files Modified
Modified:
src/principles/spec/VERSION: 0.5.0 to 0.6.0.src/principles/spec/CHANGELOG.md: vendored, gains the upstream 0.6.0 section..markdownlint-cli2.yaml: ignore the vendored spec changelog.Created:
Renamed:
Deleted:
Testing
Test Summary:
No new tests: the change is a vendored version string, and nothing in
tests/asserts aspec_versionliteral, which is what lets the bump pass without edits.Verified in emitted output rather than inferred from the file:
anc audit --command jq --audit-profile posix-utility --output jsonreportsspec_version=0.6.0, and thep3-should-unprefixed-command-listrow is still present and resolves ton_aforjq, which is correct for a requirement gated on the CLI having subcommands. Confirmed the new markdownlint ignore takes effect (Linting: 0 filesfor the vendored changelog) while other markdown still lints.Breaking Changes
Consumers that pin on
spec_versionsee it move from0.5.0to0.6.0. The site accepts the scorecard onschema_version, notspec_version, so nothing downstream gates on this.Deployment Notes
Published
ancv0.6.0 keeps reportingspec_version: "0.5.0"; this reaches users with the nextancrelease.Checklist
Additional Context
The spec's
publish.ymldispatches aspec-releaseevent to this repo and toagentnative-siteon every tagged release, with its loop commented "Non-fatal: downstream consumers opt in when they wire handlers." Neither repo has a handler, so no workflow fires and the dispatch is silently a no-op. That is why this sync is a hand-run script and a PR rather than something that happened on its own, and wiring a handler here would be a reasonable follow-up.