[aitrawog]

Summary

Head 5e0c084647e428be9d500ce460c79ca2908d47c2 — 2 files changed, 3 insertions(+), 3 deletions(-).

The data channel has two halves, in two repos, and this binary carried only
one of them. The SDK's seam — kit.RunnerConfig.StepEnv — came with sdk
v0.2026297.1851 (#1062). The PLUGIN's side, which is the half
that actually opens the channel — a task's RESOLVED values reach a step's
process environment, with the map CLONED before captureStdin mutates it — is
opencharly/plugin-task#47, which is after the pinned version.
opencharly/plugin-task#34 was closed against that fix, so the org closed the
data-channel issue against a fix the shipped binary did not carry.

charly/go.mod:141 moves github.com/opencharly/plugin-task/candy/plugin-task
from v0.2026297.1542 to v0.2026297.2108, and charly/go.sum moves with it,
derived by go mod tidy: the superseded v0.2026297.1542 pair goes and the live
v0.2026297.2108 pair arrives.

The version also carries opencharly/plugin-task#49 — the runner's test pipes
close their read ends, and the stdin-exclusion test asserts its precondition —
and opencharly/plugin-task#52, the correction of that release's own landed
record.

The split is measured, not asserted, and the measurement is in the gate
below. The old pin's source carries no StepEnv anywhere; the new pin's
carries it in the runner and in its test; the SDK carries the seam. The gate
asserts all three, and it FAILS if the old pin turns out to carry the channel
too — in which case this diff buys nothing and the premise is false.

Nothing else in the diff moves, and the reason is visible in the two module
versions' own manifests. The new version's candy/plugin-task/go.mod asks
for a newer go (1.26.8), a newer sdk (v0.2026297.1851) and a newer spec
(v0.2026296.1036) — all three the versions this repo already carries — and it
adds and moves INDIRECT requirements as well (containerd, logrus, go-toml,
golang.org/x/net, grpc, protobuf). This repo's lock already pins the newer of
each pair, so go mod tidy re-derives the same indirect set and the ONLY pair
that moves is plugin-task's own. The COMPLETE diff of the two manifests is
pasted below — no hunk is elided.

The generated word→provider index is a PROJECTION of the corpus, and the
re-projection with the build's own pluginsgen invocation produced no diff to
it: the committed index already names the providers the corpus serves today.

The branch carries main. The head is a merge of this repo's main
(ad7e4e67) into feat/pt-2108, so the evidence below was produced on the
tree the PR's own checks will run, and the diff against main is exactly the
two files named below.

file	what it carries
charly/go.mod	the plugin-task pin — v0.2026297.1542 → v0.2026297.2108
charly/go.sum	the hash-pair swap, derived by go mod tidy: the superseded v0.2026297.1542 pair goes, the live v0.2026297.2108 pair arrives

How tested

The head this body describes

$ git rev-parse HEAD
5e0c084647e428be9d500ce460c79ca2908d47c2
$ git status --short --untracked-files=no; echo "exit=$?"
exit=0
$ git diff --shortstat origin/main HEAD
 2 files changed, 3 insertions(+), 3 deletions(-)
$ git diff --name-only origin/main HEAD
charly/go.mod
charly/go.sum

The branch update, and what it brought in. The org ruleset judges the
branch against a strict up-to-date policy, so the branch was brought up to
main with a merge — never a rebase, never a reset, never a history rewrite.
The merge brought in exactly two commits, and neither touches a Go file, a
module pin or a schema: #1067's release-binary toolchain fix
and the changelog that records it. The diff this PR carries against its base is
therefore the same as it was — still charly/go.mod and charly/go.sum, still
the same +3/-3 — and the gate below ran on the MERGE COMMIT itself, not on the
pre-merge head.

$ git log -1 --format='%H %P'
5e0c084647e428be9d500ce460c79ca2908d47c2 01d4d89e6399ed9a7ac2685b65295880027d5d11 ad7e4e675c5c0f19cf649430eb0c95c88010165e
$ git log --oneline 01d4d89e..origin/main
ad7e4e67 docs: add CHANGELOG 2026.297.2223 for PR #1067
4a19da38 ci(release-binary): declare the Go toolchain the workflow builds with (#1067)
$ git rev-list --left-right --count origin/main...HEAD
0	3
$ git show --stat --oneline HEAD | tail -6
5e0c0846 Merge remote-tracking branch 'origin/main' into feat/pt-2108

 .github/workflows/release-binary.yml |  22 ++++-
 CHANGELOG/2026.297.2223.md           | 158 +++++++++++++++++++++++++++++++++++
 2 files changed, 177 insertions(+), 3 deletions(-)

The change-class gate, on the committed tree this body describes. A compiled-in
plugin's module version IS the behaviour of charly task, so the gate that owns
this diff is this repo's own core Go gate — go test ./... and go vet ./...
from charly/, as this repo's AGENTS.md states ("The core gate is go test ./... and go vet ./... from charly/, then the R9 build above") — and then
the R9 build, the worktree-local CalVer-stamped binary. The build also runs the
repo's own generated-file guard, and the gate asserts the tree is clean after
it. The gate then checks the DATA CHANNEL in the two module versions, and
finally the head it ran on. The whole gate log is pasted below.

=== 0. the head, and the merge that produced it ===
5e0c0846 Merge remote-tracking branch 'origin/main' into feat/pt-2108
--- what the merge brought in ---
5e0c0846 Merge remote-tracking branch 'origin/main' into feat/pt-2108

 .github/workflows/release-binary.yml |  22 ++++-
 CHANGELOG/2026.297.2223.md           | 158 +++++++++++++++++++++++++++++++++++
 2 files changed, 177 insertions(+), 3 deletions(-)
--- the diff this PR carries, against the base it will merge into ---
0	3
 2 files changed, 3 insertions(+), 3 deletions(-)
charly/go.mod
charly/go.sum

=== 1. the core Go gate, on the committed tree ===
ok  	github.com/opencharly/charly/charly	222.374s
ok  	github.com/opencharly/charly/charly/internal/pluginsgen	129.100s
rc=0 (want 0)

=== 2. go vet ===
rc=0 (want 0)

=== 3. the R9 build, and the generated-file guard it runs ===
bootstrap-charly: regenerating compiled-in plugin wiring
bootstrap-charly: building bin/charly
bootstrap-charly: built ./bin/charly (2026.297.2234)
rc=0 (want 0)
2026.297.2234
rc=0

=== 4. the tree after the build ===
rc=0

=== 5. the data channel: both halves, in the two module versions ===
module cache: /home/atrawog/go/pkg/mod
download rc=0
--- the old pin's own sources ---
0
--- the new pin's own sources ---
2
--- the SDK seam ---
7

=== 6. the head this gate ran on ===
5e0c084647e428be9d500ce460c79ca2908d47c2
rc=0
 2 files changed, 3 insertions(+), 3 deletions(-)
charly/go.mod
charly/go.sum

GATE_RC=0

The pin, and what the two module versions' own manifests carry. The
complete diff — every hunk, nothing elided:

$ cd charly && GOWORK=off go list -m github.com/opencharly/plugin-task/candy/plugin-task
github.com/opencharly/plugin-task/candy/plugin-task v0.2026297.2108
rc=0
$ diff <(curl -s https://proxy.golang.org/github.com/opencharly/plugin-task/candy/plugin-task/@v/v0.2026297.1542.mod) \
       <(curl -s https://proxy.golang.org/github.com/opencharly/plugin-task/candy/plugin-task/@v/v0.2026297.2108.mod)
3c3
< go 1.26.4
---
> go 1.26.8
6,7c6,7
< 	github.com/opencharly/sdk v0.2026276.1822
< 	github.com/opencharly/spec v0.2026276.1636
---
> 	github.com/opencharly/sdk v0.2026297.1851
> 	github.com/opencharly/spec v0.2026296.1036
14a15,17
> 	github.com/containerd/containerd/v2 v2.4.1 // indirect
> 	github.com/containerd/errdefs v1.0.0 // indirect
> 	github.com/containerd/log v0.2.0 // indirect
30c33
< 	github.com/pelletier/go-toml/v2 v2.2.4 // indirect
---
> 	github.com/pelletier/go-toml/v2 v2.4.3 // indirect
32a36
> 	github.com/sirupsen/logrus v1.10.2 // indirect
36,42c40,46
< 	go.yaml.in/yaml/v3 v3.0.4 // indirect
< 	golang.org/x/net v0.57.0 // indirect
< 	golang.org/x/sys v0.47.0 // indirect
< 	golang.org/x/text v0.40.0 // indirect
< 	google.golang.org/genproto/googleapis/rpc v0.0.0-20231106174013-bbf56f31fb17 // indirect
< 	google.golang.org/grpc v1.61.0 // indirect
< 	google.golang.org/protobuf v1.36.12-0.20260120151049-f2248ac996af // indirect
---
> 	go.yaml.in/yaml/v3 v3.0.5 // indirect
> 	golang.org/x/net v0.58.0 // indirect
> 	golang.org/x/sys v0.48.0 // indirect
> 	golang.org/x/text v0.42.0 // indirect
> 	google.golang.org/genproto/googleapis/rpc v0.0.0-20260825221802-da73d73af1c5 // indirect
> 	google.golang.org/grpc v1.83.2 // indirect
> 	google.golang.org/protobuf v1.36.12 // indirect

The go/sdk/spec lines are the DIRECT pair, and this repo already carries
exactly those three versions (charly/go.mod declares go 1.26.8, sdk
v0.2026297.1851, spec v0.2026296.1036). The indirect lines move too, and they
cost this repo nothing: its own lock already pins the newer of each pair, so
the re-derived charly/go.sum differs from the old one by exactly plugin-task's
own hash pair.

$ git diff origin/main HEAD -- charly/go.mod
diff --git a/charly/go.mod b/charly/go.mod
index 9c755d0e..637aa5d4 100644
--- a/charly/go.mod
+++ b/charly/go.mod
@@ -138,7 +138,7 @@ require (
 	github.com/mattn/go-isatty v0.0.20 // indirect
 	github.com/mitchellh/go-wordwrap v1.0.1 // indirect
 	github.com/oklog/run v1.1.0 // indirect
-	github.com/opencharly/plugin-task/candy/plugin-task v0.2026297.1542
+	github.com/opencharly/plugin-task/candy/plugin-task v0.2026297.2108
 	github.com/opencharly/spec v0.2026296.1036
 	github.com/pelletier/go-toml/v2 v2.4.3 // indirect
 	github.com/protocolbuffers/txtpbfmt v0.0.0-20260217160748-a481f6a22f94 // indirect

Rulebook compliance

• R0 — skills first. /charly-internals:git-workflow, /charly-internals:go, /charly-internals:strict-policy and /charly-internals:root-cause-analyzer were loaded before the first action, and this repo's own AGENTS.md ("R9 and the core Go gate", "The pin-currency control") was read for the class this change falls in.
• R1 — every finding is fixed or filed. The finding this change exists for is the split data channel, and it is FIXED here; the gate now machine-checks its premise instead of the body asserting it. One finding this change RAISES is not fixed here, because it is genuinely separable from a two-file module bump, and it is FILED. The repo's mods-tidy task tidies the tools/* modules and does not cover the core module's lock, so a core-module bump has no canonical tidy path: a go get bump that is not followed by a go mod tidy leaves the superseded hash pair behind, and nothing in the repo detects that. FILED as charly/go.sum can carry a superseded module version's hash pair: nothing checks that the core module's lock is the tidy artifact of its go.mod #1058; this diff is one instance of its remedy, not its closure. A second finding — the tracked go.work.sum holds 180 module@version lines (167 distinct pairs), and 134 of them name a version no lock in this repo carries, a fossil of the pre-cutover workspace, owned by no generator and read by no check — is FILED as go.work.sum is a fossil lock: 174 of its 180 entries name versions no lock carries, and nothing prunes it #1065, and the same issue's own cutover now deletes that fossil. Neither is introduced by this change, and neither is a reason to carry a hand-edited lock file in this diff. A third finding was raised on this PR's own body while it was being re-measured — the first version of this body pasted a TRUNCATED diff of the two module manifests and claimed they "differ in exactly the sdk/spec/go pair", which the complete diff above contradicts (the indirect requirements move too). It is FIXED here: the diff is pasted in full, and the prose now says what the measurement says.
• R2 — no duplication. The pin is stated once, in charly/go.mod; charly/go.sum is derived from it by go mod tidy and carries no hand-written version of the same fact. The compiled-in plugin WORD (plugin-task) is named in charly/charly.yml, and a version never belongs in that file — the version lives in the module lock, and the module lock is charly/go.mod.
• R3 — no workaround. The version was resolved by the module proxy through go get, and the lock was re-derived by go mod tidy — the same GOWORK=off form the repo's own mods-tidy task uses. No hand-edited go.sum, no --replace (there is no replace directive in the file), no vendored copy.
• R4 — no documented command changed. This diff moves one module pin and its derived hashes; no command, prose surface or documented behaviour in this repo changes.
• R5 — legacy deleted. The superseded v0.2026297.1542 hash pair is gone from charly/go.sum, proven by the diff above; the live v0.2026297.2108 pair is the only plugin-task pair the file carries.
• R6 — user work preserved. git status was read first, the tree carried only this change's two files, the change lives in the session worktree on feat/pt-2108, main was merged in (never a rebase, never a reset), no submodule was edited, no published history was rewritten, and nothing was pushed to main.
• R7 — behaviour proven. The behaviour of the pinned module is charly task's behaviour, and the core Go gate ran it live on the committed tree: the whole charly module's suite and the pluginsgen package, plus go vet over the same module — the elapsed times are in the pasted log. TestPluginsRefsIndexSound is inside that package: it compares the committed word→provider index against what the corpus serves RIGHT NOW — a live fetch of the corpus repos, not a fixture — and the build's own re-projection of that index produced no diff. The data channel itself is checked against the two module versions' real sources, and the check is discriminating: it fails if the old pin already carries the channel.
• R8 — live or skip, never a mock. The module was resolved from the live module proxy, the corpus index was compared against the live plugin repos, and the suite ran against those. Nothing here is mocked.
• R9 — the binary equals source. The binary is this worktree's own, built by scripts/bootstrap-charly.sh from the head's source, and bin/charly version reports its stamp. A shared install is never used, and the build's own guard confirms the source and the generated files agree.
• R10 — fresh disposable proof. The change-class gate ran on the committed tree this PR pushes — the core Go gate with the test cache defeated (-count=1), the R9 build, and the data-channel check — with the whole log pasted below and zero warnings.

Change classification

• Change class: a compiled-in plugin's module version — charly/go.mod + the derived charly/go.sum. No Go source, no schema, no gitlink, no box pin, no behavioural configuration.
• Verification gate: this repo's core Go gate (go test -count=1 ./... and go vet ./... from charly/) plus the R9 build, run on the committed tree — all pasted above. No bed run and no image build: a module pin is not a runtime target, and the suite that covers the changed behaviour is the core one.
• Attribution tier: fully tested and validated — the change-class gate passed on the final tree, and the changed path (the pinned module, compiled into the binary this build produced) was executed live.

Filed issues

• charly/go.sum can carry a superseded module version's hash pair: nothing checks that the core module's lock is the tidy artifact of its go.mod #1058 — the core module's lock can carry a superseded module version's hash pair, and nothing in this repo detects it. This diff is one instance of the remedy: the bump re-derives charly/go.sum, so the superseded v0.2026297.1542 pair goes and only the live v0.2026297.2108 pair remains in that file. The CONTROL that would make that true of every future bump is what the issue carries, and it is not closed by this change — a go get bump still leaves the superseded pair unless a tidy follows it. It is separable from this bump and is filed rather than fixed here.
• go.work.sum is a fossil lock: 174 of its 180 entries name versions no lock carries, and nothing prunes it #1065 — the tracked go.work.sum is a fossil lock: 134 of its 180 lines name a version no lock in this repo carries (123 of its 167 distinct module@version pairs), and nothing prunes it. The same class of defect as charly/go.sum can carry a superseded module version's hash pair: nothing checks that the core module's lock is the tidy artifact of its go.mod #1058, in the workspace's lock rather than the module's: a different file, a different owner (the generator that already writes go.work, not the module's own tidy) and a different blast radius (a checksum conflict rather than a stale hash pair). This diff leaves that file alone, and one is not a fix for the other. It is separable from this bump and is filed rather than fixed here.

Agent: charly

Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

[aitrawog]

STATUS — the plugin half of the data channel is open as a PR, with its premise machine-checked.

• PR: chore(deps): adopt plugin-task v0.2026297.2108 — the plugin half of the data channel #1068, head 01d4d89e6399ed9a7ac2685b65295880027d5d11, branch feat/pt-2108, base main. The diff is charly/go.mod + charly/go.sum: the plugin-task module pin moves from v0.2026297.1542 to v0.2026297.2108, and the lock is re-derived by go mod tidy.
• Why: the data channel has two halves, in two repos. The SDK's seam — kit.RunnerConfig.StepEnv — came with sdk v0.2026297.1851 (chore(deps): adopt sdk v0.2026297.1851 (the data channel + the never-hang verdict) #1062). The PLUGIN's side — a task's RESOLVED values reach a step's process environment, with the map cloned before captureStdin mutates it — is feat(task): a task's resolved values reach a step's process environment as DATA plugin-task#47, which is after the pinned version. a task param reaches its command only as shell SOURCE: there is no data channel into a command step process environment plugin-task#34 was closed against that fix, so the org closed the data-channel issue against a fix the shipped binary did not carry. This PR closes that gap.
• Proof, and the premise is checked, not asserted: the gate measures the split — the old pin's source carries 0 StepEnv occurrences, the new pin's carries 2, the SDK's kit/runner.go carries 7 — and it FAILS if the old pin turns out to carry the channel too, in which case the diff buys nothing. The gate is the repo's own core gate (go test -count=1 ./..., go vet ./...) plus the R9 build (the worktree-local CalVer-stamped binary, 2026.297.2204) plus the body-vs-diff checks. The negative control — a body naming a stale head — is rejected by the body check, and the spliced log is a FIXED POINT of the gate's own output (modulo the go test durations): the gate run on the spliced body reproduces the pasted log and returns the same verdict.
• Filed, not fixed here: charly/go.sum can carry a superseded module version's hash pair: nothing checks that the core module's lock is the tidy artifact of its go.mod #1058 (the core module's lock has no canonical tidy path, so a go get bump without a tidy leaves the superseded hash pair behind) and go.work.sum is a fossil lock: 174 of its 180 entries name versions no lock carries, and nothing prunes it #1065 (the tracked go.work.sum is a fossil lock — 134 of its 180 lines name a version no lock in this repo carries).
• Next: read the validator's verdict in full, fix or rebut every finding on the thread, then land and close this issue with its RESOLVED record. Next update at the validator verdict, or within 30 minutes — whichever comes first.

Agent: charly

Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

[github-actions]

Review — PASS

What the diff does

Two files, both mechanical:

• charly/go.mod — one line: plugin-task pin v0.2026297.1542 → v0.2026297.2108, in the direct-require block, alphabetically in place, no // indirect, no replace added.
• charly/go.sum — the superseded v0.2026297.1542 h1: + /go.mod h1: pair removed, the v0.2026297.2108 pair added, sorted position preserved, both lines present for the new version (a lone /go.mod line would be a red flag; it isn't).

That is +3/−3, exactly the shortstat the body claims, and exactly the two files the body's table lists. No source, no schema, no generated file, no unrelated churn.

Correctness and internal consistency

• The stated head 01d4d89e6399ed9a7ac2685b65295880027d5d11 matches the PR's head; the commit list shows the bump commit plus the origin/main merge the body describes, and rev-list --left-right --count origin/main...HEAD = 0 2 is consistent with a merged-forward branch (2 commits ahead: bump + merge; 0 behind).
• The body's premise — the new pin's own go.mod requires sdk v0.2026297.1851 / spec v0.2026296.1036, both already carried by this repo — is the reason a bump of this size is sufficient. The pasted .mod diff shows the only inter-version differences are the go directive and those two module lines, so no new transitive module and therefore no additional go.sum entries are owed. The diff agrees: only the plugin-task pair moves.
• The go.work.sum question is anticipated and explicitly scoped out (filed as go.work.sum is a fossil lock: 174 of its 180 entries name versions no lock carries, and nothing prunes it #1065), which is the right call: a tracked workspace lock is not owed an entry for a module version no workspace module newly requires, and hand-editing it would be the workaround R3 forbids.

Tests

No test files change, which is correct for a module-pin bump — the changed behaviour is the pinned module's behaviour, exercised through the compiled-in plugin path. The body routes the verification to the repo's core gate (go test -count=1 ./..., go vet ./...) plus the R9 build and its generated-file guard, and states the tree is clean afterwards. That is the appropriate gate for this change class; asking for a new unit test here would be asking for a test of another repo's code.

Honesty of the body

Every checkable number reproduces against the diff: 2 files, +3/−3, the two named files, the single pin move, the old pair gone. The negative-control claim (gate fails if the old pin already carried StepEnv) is a genuinely discriminating check rather than a restatement, and the body openly records the two findings it does not fix (#1058, #1065) instead of overclaiming closure. The evidence is pasted console output, i.e. self-attested rather than independently re-runnable by me from this message — that is a limitation of the review channel, not a contradiction in the body, and nothing in the diff conflicts with the log.

Comments

One comment, by @aitrawog (the PR author), timestamped after the push. It is a status update, not an approval, and no designated maintainers are configured for this run, so it is not a sign-off and I do not treat it as one. Its claims re-derive cleanly against current state: head SHA matches, branch/base match, the file set and pin move match, and the filed issues are stated as filed rather than as fixed. Nothing stale, nothing contradicted. The phrase "spliced log" is the author describing how the body was assembled from the gate's own output; it is an odd word choice but the substance — the gate ran on this head and returned GATE_RC=0 — is the same claim the pasted log makes, and it is not contradicted by the diff.

Non-blocking notes (no action required for merge)

1. go.sum hashes cannot be verified from the PR message; a mismatch would fail the first go build/go mod verify, so CI on this head is the real confirmation.
2. charly/go.sum can carry a superseded module version's hash pair: nothing checks that the core module's lock is the tidy artifact of its go.mod #1058 and go.work.sum is a fossil lock: 174 of its 180 entries name versions no lock carries, and nothing prunes it #1065 are correctly filed rather than fixed here — keep them open so the "no canonical tidy path for the core lock" control is not lost when this lands.

The change is coherent, minimal, complete for its stated class, and honest about what it does and does not prove.

Verdict: PASS

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

[aitrawog]

STATUS — the branch now carries main, and the body pastes the complete manifest diff.

• Head: 5e0c084647e428be9d500ce460c79ca2908d47c2 (was 01d4d89e6399ed9a7ac2685b65295880027d5d11). The branch was brought up to main with a MERGE — never a rebase, never a reset — because the org ruleset judges the branch against a strict up-to-date policy, and a BEHIND branch cannot merge. The merge brought in exactly two commits, neither of which touches a Go file, a module pin or a schema: ci(release-binary): declare the Go toolchain the release build already assumes #1067's release-binary toolchain fix and its changelog. The diff against the base is the same two files and the same +3/-3 as before.
• Proof: the change-class gate ran on the MERGE COMMIT itself, not on the pre-merge head — the whole log is pasted in the body: the core Go gate (go test -count=1 ./... from charly/, rc=0), go vet (rc=0), the R9 build (scripts/bootstrap-charly.sh → the worktree-local binary 2026.297.2234) and a clean tree after it, and the data-channel measurement that discriminates the premise — the old pin's source carries 0 StepEnv occurrences, the new pin's carries 2, the SDK's kit/runner.go carries 7.
• A finding on this PR, found and FIXED. Re-measuring the two module versions' manifests for the new body showed that the diff the first body pasted was TRUNCATED: it showed only the go/sdk/spec lines, and the prose then claimed the two manifests "differ in exactly the sdk/spec/go pair this repo already carries". The complete diff also moves INDIRECT requirements (containerd, errdefs, log, logrus, go-toml, golang.org/x/net, x/sys, x/text, grpc, protobuf, genproto). The claim was false as written, and the truncated paste is what let it stand. The body now pastes every hunk and says what the measurement says: the DIRECT pair is the one this repo already carries, the indirect requirements move too, and they cost this repo nothing because its own lock already pins the newer of each pair — which is exactly what the diff shows, only plugin-task's own hash pair moving. The diff itself is unchanged: two files, +3/-3.
• Next: read the validator's verdict on this head in full, fix or rebut every finding on the thread, then land and close charly is compiled against plugin-task v0.2026297.1542, so the plugin half of the data channel (opencharly/plugin-task#34) is not in the shipped binary #1064 with its RESOLVED record. Next update at the validator verdict, or within 30 minutes — whichever comes first.

Agent: charly

Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

[github-actions]

Review — PASS

What the diff is

Two files, both mechanical and internally consistent:

• charly/go.mod — a single line inside the direct-require block: github.com/opencharly/plugin-task/candy/plugin-task moves v0.2026297.1542 → v0.2026297.2108. No // indirect marker added, no replace directive, alphabetical position preserved, no other line touched.
• charly/go.sum — exactly one hash pair swapped: the v0.2026297.1542 h1: + /go.mod h1: lines are removed and the v0.2026297.2108 pair arrives, both lines present, sort order preserved. A lone /go.mod line (the classic hand-edit failure) is absent.

That is +3/−3 across 2 files, exactly the shortstat and the file set the body claims, and exactly the "only plugin-task's own pair moves" outcome the body's manifest analysis predicts.

Correctness and internal consistency

• Stated head 5e0c084647e428be9d500ce460c79ca2908d47c2 matches the PR head; branch feat/pt-2108, base main, 2 changed files all match. The commit list (7549706c bump, 01d4d89e merge, 5e0c0846 merge) is consistent with the body's account of bringing the branch up to main by merge rather than rebase.
• The body's argument for why no other lock line moves is checkable against the diff: the new pin's manifest raises only go/sdk/spec to versions the repo already carries, and moves indirect requirements to versions the repo already pins. If that were wrong, go.sum would have to gain entries; it gains none beyond plugin-task's pair. The diff corroborates the claim rather than contradicting it.
• The body openly records that the first version of it pasted a truncated manifest diff and claimed the two manifests "differ in exactly the sdk/spec/go pair", and that the complete diff also moves indirect requirements. The current body pastes the full diff and states the indirect movement plainly. The earlier false claim is disclosed, not laundered — that is the correct disposition of a self-found finding.

Tests

No test files change. For a compiled-in plugin's module pin this is right: the changed behaviour is the pinned module's behaviour, exercised through the core gate and the R9 build the body routes verification to. Asking for a new unit test here would be asking this repo to test another repo's code.

Security / scope

No secrets, no new dependency introduced by this diff (the indirect set is unchanged in the lock), no source, schema, generated file or unrelated churn. The superseded hash pair is removed — no dead legacy pin left behind.

Comments, re-derived against current state

• Comment 6390259260 (@aitrawog): names head 01d4d89e…, which is now stale — the head is 5e0c0846…. Per the rulebook I dismiss that SHA as stale rather than import it. Its substantive claims (file set, pin move, filed issues) still hold, and the staleness is explicitly superseded by the author's later status comment.
• Comment 6390263882 (@github-actions[bot]): a bot review of the pre-merge head; its rev-list --left-right --count … = 0 2 reflects that pre-merge tree (now 0 3). Its diff analysis is unaffected — the diff is unchanged — and its conclusions re-derive cleanly against the current files. It is not a maintainer sign-off and I do not treat it as one.
• Comment 6390460421 (@aitrawog): self-consistent with current state — head 5e0c0846… matches, 2 files +3/-3 matches, the gate-on-merge-commit claim is consistent with the pasted log, and it honestly discloses the truncated-diff finding as fixed.

No designated maintainers are configured for this run, so no comment counts as a sign-off; the change must stand on its own evidence, and it does.

Non-blocking notes (no action required to merge)

1. The pasted gate log (GATE_RC=0, test durations, StepEnv counts 0/2/7, binary stamp 2026.297.2234) is self-attested and cannot be independently re-run from this review channel. Nothing in the diff contradicts it; CI on this head is the real confirmation.
2. go.sum hashes cannot be verified from the PR message; a mismatch would fail go mod verify / the first build, which the gate covers.
3. charly/go.sum can carry a superseded module version's hash pair: nothing checks that the core module's lock is the tidy artifact of its go.mod #1058 and go.work.sum is a fossil lock: 174 of its 180 entries name versions no lock carries, and nothing prunes it #1065 are correctly filed rather than fixed here — keep them open so the "no canonical tidy path for the core lock" control is not lost when this lands.

The change is minimal, coherent for its stated class, honest about what it does and does not prove, and its only checkable numbers reproduce exactly against the diff.

Verdict: PASS

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run