Prepare the v0.4.0 public API and release gate - #111
Merged
Conversation
Guarantee that Client outcomes contain either a failure or an evaluation error, never both, and stamp evaluation errors with the assertion family. Clarify that a body-read error leaves partial encoded bytes and no decoded payload. Co-Authored-By: OpenAI Codex (GPT-5) <noreply@openai.com>
Pin Go 1.26.7, strengthen the tag gate with library race tests and govulncheck, and finalize the v0.4.0 documentation. Split setup-go inputs by matrix leg and move the resolved redirect behavior out of the known-issues suite. Co-Authored-By: OpenAI Codex (GPT-5) <noreply@openai.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.
Problem
The v0.4.0 API and release gate still have ambiguous result states and gaps that could mislead consumers or publish unverified code.
A custom assertion can currently produce an
Outcomecontaining both a failure and an error, while jq-over-invalid-JSON reports different assertion families on its outcome and evaluation error. The response documentation also calls partial bytes complete after a read failure. Separately, the tag workflow tests the CLI but not the reusable package, omits vulnerability scanning, and still carries the older Go toolchain and unfinished release metadata.Solution
Normalize the result contract and complete the release gate, toolchain, documentation, and changelog in one readiness change.
flowchart TD Check["Assertion.Check"] -->|"nil, nil"| Pass["Outcome: passed"] Check -->|"Failure, nil"| Fail["Outcome: failure only"] Check -->|"nil, error"| Error["Outcome: error only"] Check -->|"Failure, error from invalid custom assertion"| Error Error --> Kind["EvaluationError.Kind = Assertion.Kind"]Evaluation errors now use the assertion family consistently, including jq assertions that fail during JSON decoding.
Client.Dotreats an error as authoritative when a custom assertion violates the interface contract, so its public outcomes remain mutually exclusive. The body-read contract now explicitly distinguishes partial encoded bytes returned with a top-level error from complete decoded bytes returned after success.The release workflow reruns the library race suite, CLI E2E suite, and
govulncheck ./...before publishing. Go is pinned to 1.26.7, matrix setup selects exactly one setup-go version input, and the v0.4.0 changelog and download example are finalized. This PR prepares the release but does not create a tag or publish artifacts.No visual change: this affects the Go API contract, tests, documentation, and CI workflows.
Other Changes
just pre-push,govulncheck ./...,just release-snapshot,just release-notes v0.4.0, andactionlintlocally.Related:
🤖 Generated with Claude Code