Skip to content

v3.14.0

Choose a tag to compare

@mrbro-bot mrbro-bot released this 23 Aug 23:44
· 265 commits to main since this release
1e3d512

What's new

Small, focused release: the review artifact contract can now say exactly why a validation didn't run, and a solutions doc that quoted the old, unconditional version of that instruction has been corrected.

Features

ce-review: Unrun validations in the review artifact now record exactly where and why. Previously the contract told the parent to note that a validation didn't run, without saying where that note should live — neighboring rules in the same file name their fields, so this one read as an instruction with nowhere to land (#853).

The run artifact now carries a validation object with an explicit status: passed, failed, unavailable, or not_attempted. A reason is required for the three non-passing states and rejected for passed, since a check that succeeded has nothing to explain and the field shouldn't invite narration. The object deliberately does not reuse the existing coverage object — a validator_failures list already lives there and refers to the per-finding validation pass, a different mechanism that happens to share the word "validation." Keeping them apart is the point of the change.

The status is self-reported: an agent can claim passed without having run anything, so this is not evidence that validation happened. What it buys is that four outcomes which previously produced one identical silence can now be told apart.

A follow-up commit tightened the documentation itself: the paragraph wiring the unavailable status to its trigger left the not_attempted case to inference, using the word "skipped" twice without ever pairing it with the status name. Both trigger conditions now name their status explicitly where the distinction is drawn.

Documentation

A learning captured in docs/solutions/ describing the review artifact contract had gone stale the day after it was written. The note quoted the unconditional form of the validator instruction as the shipped design — but that instruction was corrected a day later, after it reached a harness with no executable to run (#852).

Two passages were wrong. The worked example told a reader to run the validator command outright, and the honest-limitation passage repeated the claim that an agent producing no evidence is an acceptable outcome, without the distinction the contract now draws between an agent choosing not to run a check and being unable to. The packaging section also gains the half the incident exposed: getting the validator into a reachable location is not the same as every reader of the contract being able to invoke it — bundled prose is copied into all three harness packages, while the bin entry only reaches installs of the npm package. An instruction naming a command has a wider reach than the command itself.

Compare

v3.13.7...v3.14.0