v2.0.0

GuideCheck 2.0.0 release notes

Release version: 2.0.0

GuideCheck 2.0.0 adds the opt-in corrected-content-1 policy for guides that
explicitly declare profile 2.0.0. It retains the 1.0.0-strict anchor policy:
repository-file evidence remains corroborating and cannot qualify a guide for
Level 4. An unresolved execution target blocks Level 3 under this policy.

The release preserves the isolated 0.7.1 legacy engine, the prior 1.0.0
profile, the 0.7.1 self-guide, and all frozen reports. Existing guides are not
migrated or reinterpreted automatically.

The experimental POSIX JSON CLI contract, selected with
--contract posix-json-v1, is independent of the guide-declared profile
selector. See the CLI contract.

The normative requirements are in the
2.0.0 specification and
verifier conformance profile.

Verified delivery

Released commit: 0991c18ec6dd8b966d67bab9802f6559e7e74b91, identified by the signed v2.0.0 tag and production deployment manifest.

• Release metadata PR #4 merged after Python 3.10/3.12 CI; main CI and the release workflow passed on the released commit.
• All 24 published contract files matched exact source hashes. Live legacy/strict/corrected dispatch, unresolved-execution blocking, required-profile rejection, and the 404 route passed. Existing GuideCheck and A11y legacy consumer results were preserved.
• All 12 downloaded asset digests and SHA256SUMS matched. Source tar/ZIP contents matched all 395 tagged source files; the conformance kit matched 279 tagged files.
• All four Cosign signatures verified the release-workflow identity, exact source SHA, and transparency-log inclusion. Installation from the downloaded source passed legacy, strict, corrected, experimental-contract, and scanner consumer checks.

Successful hosted Level 4 fixture behavior remains covered by controlled tests. The live fixture checks exercised declared profile selection and unavailable-manifest handling. No adopter guide or anchor was migrated.

v1.0.0

GuideCheck 1.0.0

GuideCheck now selects verification policy from the guide's declared profile
version. Existing supported legacy guides keep their previous anchor eligibility,
report format, and conformance results. A guide that deliberately declares
1.0.0 uses the stricter repository-anchor policy.

Changes

• Under profile 1.0.0, a matching repository-file hash remains visible evidence
  but cannot qualify toward Level 4. Another qualifying anchor is required.
  A conflicting repository hash still blocks Level 4 even when DNS matches.
• Exact-profile assertions are available through --require-profile-version
  and the hosted API's required_profile_version. Incompatible declarations
  are rejected rather than reinterpreted.
• Strict reports identify the selected policy and qualifying evidence. New
  schemas and normative documents live under schemas/1.0.0/ and profiles/1.0.0/.
• Package, engine, profile, and self-guide versions are independent. The
  published self-guide and manifest remain byte-for-byte unchanged at 0.7.1.
• This release also includes the bounded-execution enforcement already present
  in baseline commit 3ceb30a: named script classification, execution-pin checks,
  and opacity rationale. Valid execution pins remain declared but unverified.

Compatibility and adoption

Legacy declarations 0.1.0, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 0.5.0, 0.6.0, 0.7.0,
and 0.7.1 select the preserved pre-dispatch evaluator. Build metadata is accepted;
prereleases, version ranges, ambiguous declarations, and unsupported versions
are rejected. Legacy support has no automatic sunset. Existing adopters need
no guide, manifest, repository, or DNS changes to retain that behavior.

Consumers requiring 1.0.0 should assert it and validate the strict response
schema and profile_selection.evaluated_policy. An old server may ignore an
unknown request field; HTTP 200 or a legacy Level 4 report is insufficient.

The compatibility baseline is the verifier at 3ceb30a, not every historical
verifier release. The included bounded-execution enforcement predates dispatch.

Validation

• Full Python and UI contract suites pass, including 138 evals, 74 reference
  fixtures, 84 contract fixtures, six strict cases, and mixed-request isolation.
• All 74 captured local reports and 25 captured hosted responses match the
  pre-dispatch baseline exactly. Nine legacy versions have 54 anchor scenarios.
• All 25 discovered local guide paths and 16 public fetch/replay comparisons
  matched. Separate production observations confirmed matching level and guide
  hash for nine manifest-declaring adopters; all four observed Level 4 adopters
  remained Level 4 in the candidate.
• An isolated wheel installation exercised the actual console entry point.

See validation evidence
for methods and limitations. Finite adopter checks do not establish compatibility
with every unknown external integration.

Artifacts and limits

The source tarball, source ZIP, conformance kit, and SHA256SUMS are signed with
Sigstore keyless in the tag-triggered release workflow. No package registry
publication is part of this release; install the packaged source from this tag.

The hosted verifier remains a preview. Local verification caps at Level 3;
signed security.txt anchors are not fetched; runtime Level 5 conformance,
execution-artifact fetching, and transitive scanning remain out of scope.
Repository exclusion does not establish new administrative-independence proof
for the other retained anchor channels.

v0.7.1

GuideCheck 0.7.1

GuideCheck 0.7.1 is a backward-compatible verifier hardening and documentation
release. It resolves two false blockers found during the Harnessie adoption
without changing the normative profile requirements or finding-id contract.

Fixed

• compact verification instructions may wrap concept pairs across lines
  without producing a false verification-instruction.missing blocker
• CLI result prose such as tool eval (expect ...) no longer triggers the
  JavaScript detector; JavaScript eval call syntax remains blocking across
  spaces, newlines, and case variants
• repeated per-action command classification is cached, and the Level 5
  readiness scan is simpler without changing its output contract

Documentation

• added GitHub Pages .nojekyll, response-header, Level 4 rotation, and
  volatile-fact maintenance guidance
• clarified that an immutable release URL may identify the release being
  authored but must resolve when the guide is published
• refreshed hosted-verifier copy to describe the current seven-fetch budget
  and supported Level 4 anchors
• corrected project context to reflect Sigstore signing shipped in 0.6.0

Verification

• full make test suite passes, including 134 eval cases, 70 verifier fixtures,
  80 contract validations, parser regressions, hosted API and anchor tests,
  fetch replay, CLI checks, and 58 scanner tests
• GuideCheck's own guide and the Harnessie adopter guide pass the local
  reference verifier
• adversarial parser coverage confirms that actual JavaScript eval calls are
  still blocked and maximum-size inputs do not cause pathological regex runtime

Residual risks and follow-up

• repository-file anchors served from the same control plane as a Pages
  deployment are not yet distinguished from independent anchors; adopters
  should retain a genuinely independent channel such as DNS TXT
• bounded-execution requirements defined in 0.7.0 are not yet emitted as local
  verifier findings; enforcement remains planned for a subsequent 0.7.x release
• signed security.txt is not fetched by the hosted verifier
• GuideCheck's independent DNS TXT anchor must be rotated after publishing so
  it carries the 0.7.1 guide digest

v0.7.0

Full Changelog: v0.6.0...v0.7.0

v0.6.0

Full Changelog: v0.5.0...v0.6.0

GuideCheck 0.5.0

Audit-driven release. Highlights:

Security

• package-registry JSON anchors bind the hash to assistant-guide-specific metadata instead of accepting the first sha256 field anywhere in the registry record
• hosted verification enforces a five-fetch per-request budget with exact fetch deduplication, uses one deterministically selected unbranded content-variation probe, warns on off-domain recommended verifiers, and warns when package-registry assistant-guide URLs disagree with canonical-url

Added

• version-sync check in make test across every version-bearing surface, including byte-identity of the published .well-known guide copy
• exact warning pinning on all 68 local-file fixtures (warnings_exact / forbidden_warning_ids), so false-positive warnings fail tests
• deterministic anchor-channel tests for dns-txt, repository-file, signed-security-txt, and transparency-log
• first standalone conformance-kit artifact (fixtures, schemas, finding-ids, verifier-conformance) for independent verifier implementations

Changed

• finding-ids.md is normative for the finding-id registry
• ADOPTION reframes MCP/A2A as ecosystem integrations of the core profile
• INTENT records the Level 5 ownership decision (GuideCheck owns the runtime fixture suite and evaluator, gated by pre-level-5 readiness)

Fixed

• published docs/.well-known/assistant-guide.txt resynced with the repository guide; the new version-sync check makes this drift a test failure

Full changelog: https://github.com/snapsynapse/guidecheck/blob/main/CHANGELOG.md

SHA-256 of the artifacts is in the attached SHA256SUMS files.

GuideCheck 0.4.0

GuideCheck 0.4.0

A security hardening release. It supersedes 0.3.2 (which was version-bumped but
never tagged or published) and covers everything since 0.3.1.

Security

• detector negation handling rewritten: a negation now suppresses a prohibited
  or encoded-execution pattern only when it directly governs that pattern, so
  inserting do not elsewhere on the line no longer disables the detector
• marker discipline: action and metadata fences that differ only by surrounding
  whitespace or letter case (for example [ACTION]) are no longer silently
  dropped; they raise a blocking malformed finding so a verifier and a lenient
  agent parser cannot diverge on which actions exist
• command and class consistency: a command is cross-checked against its declared
  class by command-head analysis; a network fetch piped into an interpreter
  blocks as command.fetch-execute, and under-declared network or code-executing
  commands raise warnings
• registry anchors: a registry-url is counted toward Level 4 only when its host
  is a recognized independent registry, closing a self-hosted-anchor path

Added

• finding ids command.fetch-execute, network.command-implies-networked,
  approval.command-implies-required, anchor.registry.unrecognized-host, and
  level4.requires-fetch
• verifier-conformance.md sections for marker discipline and command/class
  consistency
• a recorded adversarial review in threat-register.md

Changed

• the local-file reference verifier now caps the achieved level at Level 3. It
  still checks supplied manifest and anchor evidence for consistency and reports
  level4.requires-fetch, but Level 4 (independent provenance) is assertable
  only by the fetching hosted verifier, matching verifier-conformance.md
  section 6
• the eval runner imports the primary engine instead of carrying a second copy
  of the checks, so there is one source of truth
• profile, verifier, hosted verifier, spec, verifier-conformance, examples, and
  public pages now report 0.4.0; guide verifier-conformance ranges move to
  >=0.4.0, <0.5.0 and applies-to to guidecheck 0.4.x
• the published docs/.well-known/assistant-guide.txt is resynced byte-for-byte
  with the repository assistant-guide.txt (it had drifted at 0.3.1)

Verification

• make test: 130 eval cases, 66 reference fixtures, 76 contract fixtures,
  6 guide-artifact byte profiles, and the parser-edge, hosted-API, fetch-replay,
  fetch-safety, and CLI-contract suites all pass.
• Detector changes were re-attacked by an independent adversarial pass before
  release; verified bypasses and false positives were fixed and regression-tested.
• docs/.well-known/assistant-guide.txt confirmed byte-identical to the
  repository assistant-guide.txt at 0.4.0.

Residual risks

Recorded in threat-register.md (Adversarial review 2026-05-29): heuristic
command analysis is best-effort, verifier fingerprinting is not fully defeated,
the hosted checker is a modest request-proxy amplifier, anchor extraction can
pick a decoy hash, and the version string is still duplicated across files.

GuideCheck 0.3.1

Patch release for GuideCheck positioning and ecosystem integration documentation. Adds MCP/A2A integration notes, a database MCP server Level 3 example guide, homepage trust-boundary positioning, and updates first-party profile/verifier version strings to 0.3.1. Conformance semantics remain unchanged.

GuideCheck 0.3.0

GuideCheck 0.3.0 adds Level 4 verifier coverage, Level 5 readiness reporting, hosted public-web hardening warnings, clearer guide-score messaging, and Level 4 package-registry adoption examples. See CHANGELOG.md for details.

GuideCheck v0.2.0

Human-Verifiable Assistant Guide profile 0.2.0 and verifier-conformance profile 0.2.0.

This release resolves all open questions from the spec, the verifier-conformance profile, and the roadmap, restructures the spec into an adoption-first document set, and bumps the version to reflect constraint tightenings.

Added

• ADOPTION.md — practical on-ramp: conformance ladder, level-by-level path, guide-author checklist.
• operator-guide.md — non-normative defense-in-depth practices.
• Public append-only transparency log as an independent cross-channel provenance anchor.
• Reading guide and linked contents at the top of spec.md.

Changed

• code-executing actions now require explicit approval at Level 3.
• Guide copies served at both the well-known path and the repository root must be byte-identical.
• repository-url is defined as the source repository root.
• Staleness keys off the publisher's valid-until; no arbitrary last-reviewed threshold.
• Reference verifier and eval harness updated to match.

Removed

• The Open Questions sections from spec.md and verifier-conformance.md; resolved and future items now live in roadmap.md.

Full detail in CHANGELOG.md. Conformance is not safety: a verifier confirms form, the human confirms meaning.