Repository navigation
chore(deps): adopt spec v0.2026302.327 (a step renders on ONE line, so a reader can pair its status with its id) - #1086
Merged
Conversation
…o a reader can pair its status with its id) `github.com/opencharly/spec` is compiled into the charly binary, so the pinned module version IS the behaviour of `charly check run` — of the bed record every R10 proof rests on. At the pinned version (v0.2026296.1036) a step whose text carries a newline spanned SEVERAL lines of the child's report: `spec/report`'s `renderStep` wrote `step.Text` verbatim, so the step's `[id]` bracket landed on a line of its own and no line carried both the status and the id. `plugin-check`'s reader matches ONE line per step, so it credited nothing for that step, the child's report carried 21 step lines against the 22 its own rollup counted, and — since plugin-check#134 — a report that disagrees with itself is refused WHOLE. Every check phase of the bed then SKIPs and the run exits 3. That is exactly what opencharly/layer-docs-site#13's `check-docs` bed hit: all five of its check phases SKIP with "the child's report could not be read: 21 step line(s) against the 22 step(s) its own rollup counted". The base tree of that repo, WITHOUT that repo's own change, produces the identical skip with the identical numbers and the identical exit code 3 — so the defect is pre-existing and lives in the PRODUCER of the report format. The producer is fixed, producer-first, in opencharly/spec#283 (squash 4266c8b, module tag v0.2026302.327): `spec/report` now renders every step on EXACTLY one line — the text and the message flattened through one rule — so the status and the id are on the SAME line, and `truncate` cuts on a character boundary so a report line is always decodable. The producer's own tests assert the invariant and FAIL against the old renderer. `charly/go.mod:142` moves `github.com/opencharly/spec` from v0.2026296.1036 to v0.2026302.327. The three lockstep modules move with it — tools/generate-packages, tools/golden-cloudinit and tools/golden-compile — by `charly task mods-tidy`, because tools/gomod-canonical's TestContractPinsMatchShared requires every in-repo module that requires a contract module to list the SAME shared sdk and spec pins. The sdk pin is unchanged (v0.2026297.1851, which requires spec v0.2026280.2244): v0.2026302.327 is the maximum the module graph selects, so no sdk move is behind it and no cascade follows. Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
Contributor
Review — PASSI re-derived every claim against the current state. Scope & correctness
Honesty of the body
Tests
Security
Cleanliness
Comments
No blocking findings. The diff does exactly what the body claims, with consistent and complete evidence. Verdict: PASS ollama-cloud/deepseek-v4.1-flash — action-review. |
This was referenced Oct 29, 2026
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
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
github.com/opencharly/specis compiled into the charly binary, so the pinned module version ISthe behaviour of
charly check run— of the bed record every R10 proof rests on.At the pinned version (
v0.2026296.1036) a step whose text carries a newline spanned SEVERALlines of the child's report:
spec/report'srenderStepwrotestep.Textverbatim, so thestep's
[id]bracket landed on a line of its own and no line carried both the status and theid.
plugin-check's reader matches ONE line per step, so it credited nothing for that step, thechild's report carried 21 step lines against the 22 its own rollup counted, and — since
plugin-check#134 — a report that disagrees with itself is refused WHOLE. Every check phase of
the bed then SKIPs and the run exits 3.
That is exactly what opencharly/layer-docs-site#13's
check-docsbed hit: all five of its checkphases SKIP with "the child's report could not be read: 21 step line(s) against the 22 step(s)
its own rollup counted". The base tree of that repo, WITHOUT that repo's own change, produces
the identical skip with the identical numbers and the identical exit code 3 — so the defect is
pre-existing and lives in the PRODUCER of the report format, not in the change that found it.
The producer is fixed, producer-first, in opencharly/spec#283 (squash
4266c8b, module tagv0.2026302.327):spec/reportnow renders every step on EXACTLY one line — the text and themessage flattened through one rule — so the status and the id are on the SAME line, and
truncatecuts on a character boundary so a report line is always decodable. The producer's owntests assert that invariant and FAIL against the old renderer.
This change carries that version into the binary. Head
cfcbfe7a461bd89c6d714e8ff3bb50394d78ee42— 8 files changed, 12 insertions(+), 12 deletions(-) — moves
github.com/opencharly/specincharly/go.mod:142fromv0.2026296.1036tov0.2026302.327, and moves the three lockstepmodules with it (
tools/generate-packages,tools/golden-cloudinit,tools/golden-compile),because
tools/gomod-canonical'sTestContractPinsMatchSharedrequires every in-repo modulethat requires a contract module to list the SAME shared sdk and spec pins.
The
sdkpin is unchanged atv0.2026297.1851. That module requires specv0.2026296.1036itself, but Go's minimal version selection takes the MAXIMUM of the requirements in the graph,
so
v0.2026302.327is the version the graph selects — the sdk does not have to move for thischange, and no sdk release is required by it.
How tested
The work happened on
feat/spec-pin-report-one-linein this repository's own session worktree,off fresh
origin/main(be7a505f). Every gate below ran on the committed tree this PRcarries — the same tree the head sha names.
The affected target, re-proved live. The change is a behaviour change in the binary, so the
proof that it works is a REAL bed on a REAL disposable target — not a unit test. The
check-docsbed of opencharly/layer-docs-site (
disposable: true,charly.yml:275) ran against thatrepo's committed tree
fa50b946f868a442d3c3868c0a2c5b539e6c9e8fwith the binary this changebuilds. Before this pin, every check phase SKIPped with the reason above and the run exited 3;
after it, the bed is green:
The same bed, on the same committed tree of that repo, with the binary built from the PREVIOUS
spec pin, SKIPped every check phase and exited 3 — the evidence that the pin bump is what
turned it green:
$ git grep -n "v0.2026296.1036" -- . ':(exclude)CHANGELOG'
exit=1