[aitrawog]

Summary

The compiled-in plugin-task pin is behind the served release, and what the release carries is a refusal that protects an operator's commit.

charly/go.mod requires github.com/opencharly/plugin-task/candy/plugin-task v0.2026297.2108; plugin-task's served main is v0.2026299.2314 (b523e8780bd2943a40fdc8c81b4470673c867d93), and the delta between the two is two code fixes plus their changelogs:

upstream commit	what it carries
7d3b373af3	fix(git-submodules): a bump that would drop a nested checkout's work refuses (plugin-task#55)
1c451fc7a4	fix(git-submodules): the nested-work refusal's scope is the REFUSED SUBMODULE (plugin-task#57)

Why this repo, and not only plugin-task. charly IS the binary that runs the org's pin waves. The umbrella's charly task sync (its pins task, MODE=bump) is a git-submodules verb, and that verb lives in the compiled-in plugin-task — the one charly/go.mod pins. The umbrella's tree carries 411 submodules, and the verb rolls each one and then reconciles that path's OWN nested checkouts.

Before the fix, that reconcile was (plugin-task v0.2026297.2108, candy/plugin-task/verbs.go:1488-1489, in reconcileNestedCheckouts):

if _, stderr, exit := hostCapture(context.Background(), projDir,
	fmt.Sprintf("git -C %s submodule update --recursive", shellQuote(abs))); exit != 0 {

git submodule update --recursive moves an already-initialized nested checkout onto the gitlink the parent records for it, unconditionally. It never asks whether that nested checkout carries work. So a nested checkout sitting on a LOCAL COMMIT was moved off it, with exit 0 and nothing reported — the operator's commit was no longer at HEAD, was reachable by no branch, and survived only in the reflog.

In v0.2026299.2314 that statement is unchanged (candy/plugin-task/verbs.go:1690-1691, reconcileNestedCheckouts at :1681) — but it is now reached only after judgeNestedLevel (:1550, called at :1442) has judged every nested checkout the move would touch, and a refusal stops that submodule before its checkout is switched and before its pin is staged.

The fixed behaviour is the one thing that loses nothing: the bump refuses, it names the nested checkout, and it leaves the refused submodule exactly as it was — the operator's commit still at HEAD, the superproject's pin NOT staged, the submodule's own checkout not switched. The refusal's scope is per-submodule (plugin-task#57): a sibling that sorts after the refused one still rolls, because the bump collects per-path failures and continues.

file	what the diff does to it
charly/go.mod	requires plugin-task/candy/plugin-task v0.2026299.2314 (was v0.2026297.2108)
charly/go.sum	carries the new version's hash pair; go mod tidy drops the superseded pair

Nothing else changes: the delta between the two versions is the refusal and its scope.

Producer-first. plugin-task's producer work is MERGED and TAGGED (v0.2026299.2314); this repo's compiled-in pin is the consumer that had not moved, so the refusal never reached the binary. The umbrella's own plugin-task gitlink is the NEXT consumer leg, after this one lands and this repo's merge is tagged — and the umbrella's prose citations of a plugin-task version are re-derived from this repo's pin by scripts/check-cited-plugin-task-version.mjs, so that re-key belongs to the umbrella's leg, not to this one.

Closes #1073

How tested

The change-class gate ran on the committed tree this PR pushes (21307612f344bf1fed01a9c322a9144b76ba9083), with zero warnings, and the live differential ran the SAME fixture through the binary built from this tree and through the binary built from origin/main (f1f85d19).

The gate — this repo's own CI shape (go test ./charly/..., the tools/* sweep, gofmt, golangci-lint v2.13.2 over charly/ and over every tools/* module), plus this repo's core gate (go vet ./... from charly/) and the R9 worktree-local build:

=== go version ===
go version go1.26.8 linux/amd64

=== 0. the tree is the committed one (R7/R10: the gate runs on what is pushed) ===
f41fa0269d0913f2e76befdeccca648e03242536
HEAD_RC=0

=== 1. build (R9): scripts/bootstrap-charly.sh ===
bootstrap-charly: regenerating compiled-in plugin wiring
Downloading github.com/opencharly/plugin-task:candy/plugin-task/v0.2026299.2314...
bootstrap-charly: building bin/charly
bootstrap-charly: built ./bin/charly (2026.300.0215)
BUILD_RC=0

=== 2. the generated wiring is clean (scripts/check-generated-clean.sh) ===
GENERATED_RC=0

=== 3. the binary is the worktree-local build ===
2026.300.0215
VERSION_RC=0

=== 4. go vet ./... (from charly/) ===
VET_RC=0

=== 5. go test ./charly/... (from the repo root, CI shape) ===
ok  	github.com/opencharly/charly/charly	180.418s
ok  	github.com/opencharly/charly/charly/internal/pluginsgen	129.830s
TEST_RC=0

=== 6. the tools/* sweep (GOWORK=off, -count=1) ===
== tools/generate-packages/ ==
?   	github.com/opencharly/charly/candy/generate-packages/cmd/serve	[no test files]
== tools/golden-cloudinit/ ==
?   	github.com/opencharly/charly/tools/golden-cloudinit	[no test files]
== tools/golden-compile/ ==
?   	github.com/opencharly/charly/tools/golden-compile	[no test files]
== tools/gomod-canonical/ ==
ok  	github.com/opencharly/charly/tools/gomod-canonical	0.001s
== tools/ledger-validate/ ==
ok  	github.com/opencharly/charly/tools/ledger-validate	0.002s
TOOLS_RC=0

=== 7. gofmt (gofmt -l charly tools) ===
gofmt: no files to rewrite
GOFMT_RC=0

=== 8. golangci-lint fmt --diff (charly/) — must print nothing ===
FMT_RC=0

=== 9. golangci-lint v2.13.2 (charly/) ===
LINT_RC=0

=== 10. golangci-lint v2.13.2 (each tools module) ===
TOOLSLINT_RC=0

=== 11. the binary's module set carries the NEW plugin-task (and not the old one) ===
	dep	github.com/opencharly/plugin-task/candy/plugin-task	v0.2026299.2314	h1:PelS5kDgk8zq4DAwF3c+/Giljs/PBqNcQrKGqfa3ECw=
MODS_RC=0
MODS_NEW: the binary compiles plugin-task v0.2026299.2314
MODS_OLD: the old pin is gone from the binary's module set

=== 12. the tree is still clean (the generated files are committed state) ===
STATUS_RC=0

GATE_DONE: all steps passed
GATE_EXIT=0

Why the gate's step 0 shows the pre-amend SHA. The gate ran on commit f41fa0269, whose tree is 056f8f4d14c3bdba089daa89becb9eb15e427514; the commit was then amended ONCE — before the first push, which the lifecycle allows — to re-tier its own attribution from syntax check only to the tier it had earned. The amend touched the MESSAGE only, so the tree is byte-identical and the gate's result is the gate's result for this head:

gated tree : 056f8f4d14c3bdba089daa89becb9eb15e427514
head  tree : 056f8f4d14c3bdba089daa89becb9eb15e427514

The live differential — the producer's own fixture shape (candy/plugin-task/nested_work_test.go's nestedWorkFixture), rebuilt in shell so it can be driven by the binary rather than by the plugin's in-process test seam: a three-level file:// tree (umb → outer → inner) plus a sibling zebra, where the nested checkout carries a commit no ref references — the exact shape git submodule update --recursive drops. outer sorts before zebra, so the refused path is visited first and the sibling's roll is the evidence that the walk CONTINUED past the refusal.

The check states the product's promise and must fail against the old binary (R7: a check that cannot fail proves nothing):

• the bump refuses and names outer/inner;
• the operator's commit is still at HEAD in the nested checkout;
• the superproject's pin for outer is not staged and outer's own checkout is not switched;
• the sibling zebra still rolled (the walk did not abort).

=== the binaries under test ===
  NEW    : 2026.300.0215
  BEFORE : 2026.298.0310
  NEW    compiles: 	dep	github.com/opencharly/plugin-task/candy/plugin-task	v0.2026299.2314	h1:PelS5kDgk8zq4DAwF3c+/Giljs/PBqNcQrKGqfa3ECw=
  BEFORE compiles: 	dep	github.com/opencharly/plugin-task/candy/plugin-task	v0.2026297.2108	h1:lUSaJqErWnWHPLj3bMZdpzEsM+CNaGcgjgbMb7c8KC8=

=== [NEW] the fixture ===
  [NEW] L1=7dfdebe2178329fccaff236a3effb57d01d6db25 L2=f5d10fa733f749906183aa413d224319a46924f0 O1=d2c9850088f383ac5e9b91731ea04bbe39cacf93 O2=9aaa8113b1257fbd6f85f2ba880cbddc675c7bc3 WORK=54a94dca8eb402820ad8d7f5e2cf6551179436a3
=== [NEW] the bump, through the binary ===
task bump: 1 step(s), 1 failed, 0 skipped
  [fail] run — run git-submodules in the selected mode
      1 pin(s) FAILED: the nested checkout outer/inner carries a commit the update would drop — its HEAD 54a94dca8eb402820ad8d7f5e2cf6551179436a3 is in no branch, tag or remote-tracking ref of that checkout (the recorded pin is f5d10fa733f749906183aa413d224319a46924f0), so the update would move it off that commit and leave it in the reflog alone; push it, branch it, or stash it, then re-run; rolled 1 submodule(s) to their default-branch HEAD; advanced 0 pin(s) in the index; pinned 0 pin_map entr(y|ies):
charly: error: command "task": task "bump" failed (1 step(s) failed)
  [NEW] task rc=1
  [NEW] nested HEAD=54a94dca8eb402820ad8d7f5e2cf6551179436a3  outer pin=d2c9850088f383ac5e9b91731ea04bbe39cacf93  outer checkout=d2c9850088f383ac5e9b91731ea04bbe39cacf93  zebra pin=f5d10fa733f749906183aa413d224319a46924f0
  [NEW] PASS: the bump refused the move, named outer/inner, left the refused submodule untouched, and the sibling still rolled

=== [BEFORE] the fixture ===
  [BEFORE] L1=7dfdebe2178329fccaff236a3effb57d01d6db25 L2=f5d10fa733f749906183aa413d224319a46924f0 O1=e9f23fe72ca321a18bc173e96a9d2916e324b74a O2=9db4f44695c8c66d6515dba08b4a6e5d82a78ed8 WORK=54a94dca8eb402820ad8d7f5e2cf6551179436a3
=== [BEFORE] the bump, through the binary ===
task bump: 1 step(s), 0 failed, 0 skipped
  [pass] run — run git-submodules in the selected mode
      pinned 0 pin_map entr(y|ies) () after rolling 2 submodule(s) to their default-branch HEAD and advancing 0 pin(s) in the index
  [BEFORE] task rc=0
  [BEFORE] nested HEAD=f5d10fa733f749906183aa413d224319a46924f0  outer pin=9db4f44695c8c66d6515dba08b4a6e5d82a78ed8  outer checkout=9db4f44695c8c66d6515dba08b4a6e5d82a78ed8  zebra pin=f5d10fa733f749906183aa413d224319a46924f0
  [BEFORE] FAIL: the bump reported SUCCESS
  [BEFORE] FAIL: the refusal does not NAME the nested checkout (outer/inner)
  [BEFORE] FAIL: the operator's commit is NOT at HEAD (the update dropped it: f5d10fa733f749906183aa413d224319a46924f0 != 54a94dca8eb402820ad8d7f5e2cf6551179436a3)
  [BEFORE] FAIL: the superproject's pin was staged (9db4f44695c8c66d6515dba08b4a6e5d82a78ed8 != e9f23fe72ca321a18bc173e96a9d2916e324b74a)
  [BEFORE] FAIL: the refused submodule's checkout was switched (9db4f44695c8c66d6515dba08b4a6e5d82a78ed8 != e9f23fe72ca321a18bc173e96a9d2916e324b74a)
  [BEFORE] FAIL: 1 assertion(s) failed

NEW_RC=0 BEFORE_RC=1
LIVE_PROOF_OK: the check passes against the new binary and FAILS against the before binary
LIVE_RC=0

Reading the two runs. The BEFORE run is the defect, live: the bump reported success (task rc=0) while the nested checkout was moved off the operator's commit onto the recorded pin f5d10fa7 — the commit survives only in the reflog, and nothing in the output says so. The NEW run refuses, names the path, leaves the refused submodule exactly as it was, and still rolls the sibling (zebra pin = f5d10fa7), so the refusal is scoped to the refused submodule and not the tree.

One note on the two fixtures' SHAs. L1, L2 and WORK are identical across the runs; O1/O2 are not, because outer's .gitmodules records the absolute path of the leaf bare repo, and the two fixtures live in different directories. Every assertion is a comparison WITHIN one fixture, so the difference does not affect the result.

Rulebook compliance

• R0 — skills first. /charly-internals:git-workflow (the branch/commit/push/PR lifecycle) and /charly-internals:strict-policy (engineering discipline) were loaded before the first tool action; this repo's own AGENTS.md was read before acting here.
• R1 — every anomaly got an RCA. The finding this change raised — the compiled-in pin was behind the served release — is blocking for this change and is fixed by it: filed as the compiled-in plugin-task pin is behind the served release: the nested-work refusal never reaches the binary #1073, claimed, and closed by this PR rather than filed away. The validator's round-1 finding — that the body claimed go mod tidy also dropped the stale v0.2026296.1911 pair, which this diff does not show — is fixed in this round; both mentions are corrected below, and the commit message never carried the claim. The missed control is named in the round's comment on this PR. No finding was filed away.
• R2 — no duplication. Nothing is implemented here: the refusal is the producer's, and this repo's diff is the pin that carries it.
• R3 — no workaround. No sleep, retry, suppression or fallback. The refusal is the product's own behaviour, reached through the sanctioned verb.
• R4 — product before prose. The product side is the producer's, already merged and tagged; this change moves the consumer so the behaviour actually reaches the binary. No prose changes here.
• R5 — legacy deleted. The superseded v0.2026297.2108 pair is gone from charly/go.mod and charly/go.sum. The go.sum hunk removes exactly the two v0.2026297.2108 lines and adds exactly the two v0.2026299.2314 lines — and nothing else; the stale v0.2026296.1911 pair that feat(pins): install the pin-currency control and advance box/ubuntu to the served ref #1050 left behind went with the previous leg's go mod tidy, not with this one. The claim-keyed proof is the gate's step 11 — the binary's module set carries v0.2026299.2314 and no longer carries v0.2026297.2108 — plus the diff above.
• R6 — git safety. git status was run first in every step; the branch is feat/plugin-task-nested-refusal off fresh origin/main; the commit was amended ONCE, before the first push, to re-tier its own attribution; no force-push, no history rewrite, no hook bypass, no direct push to main.
• R7 — behavior proven, not compilation. The differential is DISCRIMINATING: it passes against the new binary and fails against the binary built from origin/main. The changed path executed live, with commands, outputs and exit codes retained above.
• R8 — live or skip. The bump ran against real local git remotes (file://); nothing was mocked.
• R9 — binary equals source. The binary under test is this worktree's scripts/bootstrap-charly.sh build (2026.300.0215); the gate asserts bin/charly version and the binary's module set. No shared install was used. No new runtime OS dependency was introduced, so packaging: is unchanged.
• R10 — fresh disposable proof. The change-class gate ran on the committed tree this PR pushes, with zero warnings, and the live differential ran on that same build.

Change classification

• Change class: runtime — a compiled-in dependency's version. The binary's behaviour changes (the pin wave's nested-work refusal reaches the product), so the live differential is part of the gate, not an extra.
• Consumer leg of a producer-first chain: plugin-task v0.2026299.2314 (merged, tagged) → this repo's compiled-in pin (this PR) → the umbrella's plugin-task gitlink and its prose re-key (the next PR, one PR, gated with charly task verify on the committed tree).
• Tier: fully tested and validated — the change-class gate passed on the final tree and the changed path executed live.
• Diffstat:

 charly/go.mod | 2 +-
 charly/go.sum | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

Filed issues

None. The one finding this change raised — the compiled-in pin being behind the served release — is blocking for this change and is fixed by it (#1073); it is closed by this PR, not filed away.

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

[aitrawog]

STATUS

Leg A — the charly consumer of plugin-task v0.2026299.2314. The PR is open: #1074, head 21307612f344bf1fed01a9c322a9144b76ba9083, branch feat/plugin-task-nested-refusal off fresh origin/main.

Done. The compiled-in pin moved v0.2026297.2108 → v0.2026299.2314 (charly/go.mod + charly/go.sum; 2 files, +3/−3). The change-class gate passed on the committed tree with zero warnings — 12 steps: the R9 worktree-local build (2026.300.0215), the generated-wiring check, charly version, go vet ./... from charly/, go test ./charly/..., the tools/* sweep, gofmt, golangci-lint v2.13.2 over charly/ and over every tools/* module, the binary's module set (it carries v0.2026299.2314 and no longer v0.2026297.2108), and the tree's cleanliness. The live differential is green and discriminating: the producer's nested-work fixture (umb → outer → inner, plus the sibling zebra, over file:// remotes, with the nested checkout on a commit no ref references) through the NEW binary refuses, names outer/inner, leaves the refused submodule exactly as it was and still rolls the sibling; the binary built from origin/main reported success while moving the nested checkout off the operator's commit onto the recorded pin, with nothing in its output saying so.

Next. The validator's verdict on #1074; every finding it raises is fixed in ONE commit per round, and nothing is pushed before every comment and the full report have been read. On landing, #1073 is closed by hand with a RESOLVED record naming the merged PR, its squash SHA and its merge tag, and the umbrella's next leg — advance the plugin-task gitlink and re-key the plugin-task prose citations that scripts/check-cited-plugin-task-version.mjs derives from this repo's pin — is taken in ONE PR, gated with charly task verify on the committed tree.

Next update: on the validator's verdict, or within 2 h — whichever comes first.

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

[github-actions]

Review — PASS

I re-derived every claim in the body and the one comment against the current diff.

What the diff actually does

• charly/go.mod: plugin-task v0.2026297.2108 → v0.2026299.2314 (1 line, +1/−1).
• charly/go.sum: removes the v0.2026297.2108 h1 + /go.mod pair, adds the v0.2026299.2314 h1 + /go.mod pair (+2/−2).
• Diffstat is exactly 2 files, +3/−3, matching the body's stated diffstat.
• The new h1:PelS5kDgk8zq4DAwF3c+/Giljs/PBqNcQrKGqfa3ECw= matches the hash shown in the body's gate step 11 (MODS), so the go.sum is internally consistent with the claimed binary module set.
• The /go.mod hash is unchanged between the two versions (h1:a8WkZ...), which is plausible for a version bump whose dependency's own go.mod did not change; not a contradiction.

Correctness / scope / cleanliness

The change is a pure compiled-in pin bump; it is coherent, complete, and has no leftover legacy path. The producer work (plugin-task v0.2026299.2314) is claimed merged/tagged upstream, and this repo is the consumer leg — consistent with the "producer-first" narrative. No secrets, no injection surface, no privilege change; the only new code is an external dependency from the same org.

Tests

No test files are in this PR, which is appropriate for a version bump: the behavior under change lives in the producer (nested_work_test.go) and is demonstrated via the live differential in the body. The pin adoption itself needs no new test in this repo.

The one comment (@aitrawog, the PR author)

It is a self-authored STATUS update restating the body's claims (open PR, head SHA, gate green, live differential discriminating). It is not a maintainer/operator sign-off (it is the opener's own status comment, and no designated maintainer wrote it), so it carries no approval weight; I re-derived its factual content against the diff and it matches the head SHA and the 2-file bump.

Findings (non-blocking)

• Body inaccuracy (go.sum narrative). R5 and the body claim go mod tidy dropped a "stale v0.2026296.1911 pair." The full go.sum diff removes only the v0.2026297.2108 pair; no v0.2026296.1911 lines appear in the hunk. That claim is not reproduced by the diff. It is a narrative embellishment about the tidy mechanism and does not affect the functional change (the pin bump and its hash pair are correct and complete), so it does not block — but the body should not assert a removal the diff does not show.

The functional change stands on its own evidence: the pin moves, the go.sum hash matches the new module, and the diff is exactly what the stated purpose requires.

Verdict: PASS

---

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

View action run

[aitrawog]

STATUS — round 1: the validator's verdict, and the disposition of its one finding.

The verdict. ## Review — PASS — the validator re-derived every claim in the body and the comment against the diff, confirmed the diffstat (2 files, +3/−3), confirmed the go.sum h1:PelS5kDg… matches the module the binary compiles, and raised one non-blocking finding.

The finding — FIXED, not filed away and not rebutted. The body claimed that go mod tidy also dropped the stale v0.2026296.1911 pair. The go.sum hunk removes only the v0.2026297.2108 pair; no v0.2026296.1911 line appears in it. The claim is true of the PREVIOUS leg (charly#1057's tidy dropped that pair) and false of this diff, and it had been carried over from there into this body.

The RCA.

• Mechanism. The claim was written from the previous leg's tidy output and reused here without re-deriving it against this diff. This leg's tidy said exactly one thing — go: upgraded github.com/opencharly/plugin-task/candy/plugin-task v0.2026297.2108 => v0.2026299.2314 — and the hunk shows exactly that.
• Missed control. The change-class gate proves what the code does — the binary's module set (step 11) and the diff's shape — but nothing in it re-derives a prose claim about the diff against the diff. The claim had no gate behind it; the control that caught it was the validator's review, which re-derived the body against the hunk and found the claim unreproduced. That is the control working, not a hole in the tree.
• Blast radius. The claim lived in two PROSE bullets (R1 and R5) and described a REMOVAL. The change itself is unaffected: the pin moves, the new hash pair matches the module the binary compiles, and the diff is exactly what the stated purpose requires. The commit message never carried the claim — which the commit gate does read — so the tree was never in question.
• Root fix, in the control as well as in the body. Both bullets are corrected on this PR: R1 now names the two findings that actually exist (the pin being behind, fixed by this change; the validator's finding, fixed in this round), and R5 now states the hunk's own content — the two v0.2026297.2108 lines out, the two v0.2026299.2314 lines in, and the v0.2026296.1911 pair attributed to the previous leg's tidy. The general fix, applied from here on: every diff-derived claim in a body is re-derived from git show HEAD -- <path> before it is published, never carried over from a sibling leg.

Also corrected in the body, before the validator's report landed. The body's citation of the old reconcile was candy/plugin-task/verbs.go:1479; the statement is at verbs.go:1488-1489 in v0.2026297.2108. The body now quotes the source's own three lines verbatim and adds the pointer the earlier text lacked — the same statement sits at verbs.go:1690-1691 in v0.2026299.2314 and is now reached only after judgeNestedLevel (:1550, called at :1442). The correction is recorded on #1073, whose body carried the same wrong number.

What changed in this round: the BODY only. The two bullets above — R1 and R5. The tree is unchanged: head 21307612f344bf1fed01a9c322a9144b76ba9083, the same tree the gate ran on (056f8f4d14c3bdba089daa89becb9eb15e427514). A body-only correction carries no new code to gate, so no commit and no gate re-run — and no amend, because the commit was already pushed.

Next. The remaining checks (go, pin-currency, validate / arm) settle. On landing, #1073 is closed by hand with a RESOLVED record naming the merged PR, its squash SHA and its merge tag, and the umbrella's next leg — advance the plugin-task gitlink and re-key the plugin-task prose citations that scripts/check-cited-plugin-task-version.mjs derives from this repo's pin — is taken in ONE PR, gated with charly task verify on the committed tree.

Next update: on the checks settling, or within 2 h — whichever comes first.

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

[aitrawog]

RESOLVED — merged.

squash SHA	d7e04e9b116116fc1886f17a409006bec76b4176
merge tag	v2026.300.0235
merged at	2026-10-27T02:35:55Z
changelog	CHANGELOG/2026.300.0235.md

All five checks passed on the merged head (go 9m24s, pin-currency 6m37s, validate / arm 7m52s, validate / lint 45s, validate / validate 1m47s), and the validator's verdict was PASS. Its one non-blocking finding — the body's claim that this diff's go mod tidy also dropped the stale v0.2026296.1911 pair, which the diff does not show — was fixed in the body in round 1, with the RCA in the round-1 comment above; the tree never carried the claim.

The issue this PR closed, #1073, is closed by hand with a RESOLVED record, because the org's auto-merge is a GitHub App and GitHub's close-on-merge fires only for User-type accounts.

Next, in one PR in opencharly/opencharly: the umbrella's plugin-task gitlink and the umbrella's plugin-task version citations, gated with charly task verify on the committed tree.

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