Re-vendor the specification bundle at neutral identifiers#8
Merged
Conversation
…l identifiers The embedded bundle was pinned to the pre-neutralization upstream tag, whose schema `$id` values point at a temporary repository-hosted URL under the predecessor organization. Two hardcoded constants also named that organization and gated the maintainer tooling: `sync-spec-artifacts` compares the source checkout's `origin` against its own constant, so the documented re-vendor procedure in docs/releasing.md could not run at all against the real specification repository. Re-vendor from Judgment-Pack/judgment-pack-spec. The two schema `$id` members now carry the permanent https://judgmentpack.org/schema/ identifiers. The conformance corpus and manifest are byte-identical to the previous pin, so all 47 cases still pass; only lock.json, schema.json, and manifest.schema.json change. Pin an exact commit rather than a tag. The specification's release tooling binds the tag string to `specVersion` in three assertions, so the permanent identifiers on its `main` branch cannot be republished under a second 0.1.0-draft tag without faking a version bump across the manifest, schema const, 47 conformance cases, and examples. `releasecheck.immutableRef` already accepts a full-length commit digest as immutable, so this is a supported reference, not a relaxation. The pin moves back to a tag once a specification version carrying the permanent identifiers is published. This is machine-visible: `spec schema` now reports a different schemaId, sha256, and bytes (14307 -> 14268), and the bundle digest changes. `outputVersion` stays "1". Also corrects three prose claims. README and CHANGELOG attributed the delay to the specification project not having published a neutral tag; the permanent identifiers were already on its `main` branch, and the real blocker was inside this repository. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Brian Jin <35789537+kikashy@users.noreply.github.com>
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.
The actual blocker
CHANGELOG.mdandREADME.mdboth said re-vendoring was "pending the specification project publishing" a neutral tag. That was wrong. The permanenthttps://judgmentpack.org/schema/identifiers have been onjudgment-pack-spec'smainsince its first neutrality PR. The blocker was inside this repository:tools/sync-spec-artifacts/main.go:225compares the source checkout'sgit remote get-url originagainst its own hardcoded constant. That constant named the predecessor organization, while the real spec repo's origin isJudgment-Pack/judgment-pack-spec— so the documented procedure indocs/releasing.mdexited 1 withsource origin is not the official judgment-pack-spec repository. The re-vendor path was dead.Changes
Atomic — none of these work alone:
tools/sync-spec-artifacts/main.go:23andinternal/releasecheck/check.go:12→ theJudgment-PackURL. The sync tool's constant had to move first, since it gates the tool that regenerates the lock the release gate then validates.lock.json,schema.json,manifest.schema.jsoninternal/artifacts/artifacts_test.go:11-14→ new pinned repository, commit, refWhy a commit pin, not a tag
Attempted first, and it failed.
judgment-pack-spec/tools/build_release.py:52-67binds the tag string tospecVersionin three assertions plus a release-notes check.v0.1.0-draft.1fails all four — the design is one tag per specification version. Republishing under a second tag would require bumpingspecVersionacross the manifest, schema const, schema$id, 47 conformance cases and the examples, announcing a revision when nothing normative changed.releasecheck.immutableRef(check.go:58-66) already accepts a full-length commit digest as immutable. This is a supported reference, not a relaxation of the gate. The pin returns to a tag when a specification version carrying the permanent identifiers is published.Machine-visible change
spec schema 0.1.0-draft --format jsonmoves:schemaIdraw.githubusercontent.com/…https://judgmentpack.org/schema/0.1.0-draft/…bytessha25681f6986e…c65c559d…Bundle digest changes too.
outputVersionstays"1". PerVERSIONING.mdthis warrants a minor bump, not a patch.Verified
gofmt -lempty ·go vet ./...clean ·go test ./...all packages okcheck-release --tag v0.1.0→Release inputs verified for v0.1.0.spec test-conformance→ 47/47, exit 0 — corpus is byte-identical to the previous pin, so this is a genuine no-change-in-behavior resultgoreleaser checkvalidatedgrep -rn protossai .→ no matches (was 9). The one survivingprotossstring is the intentional origin statement atCHANGELOG.md:28.Unblocks
This was the only item blocking the MCP skeleton —
describe_runtimeexposesartifact.provenance, which until now would have surfaced the predecessor URL to every agent that called it.🤖 Generated with Claude Code