Repository navigation
the vacuity guard recomputes the claims it judges — the same claims, read twice for one decision #71
Description
The vacuity guard — the assertion that a body makes at least one usage claim for the command it documents — computes the claims TWICE for one decision.
Where it lives. candy/plugin-box/skill_doc_flags_test.go, as landed in #70:
claims := usageClaims(body, tc.command)
if skillDocIsVacuous(body, tc.command) {skillDocIsVacuous(body, command) calls usageClaims(body, command) itself, so the control reads the same claims twice — once for the guard, once for the loop below.
Why it matters. Not a correctness defect: both calls see the same body and the same command, so they agree, and the verdict is unaffected. It is untidy in the one way this control cares about — the rule must be ONE implementation, and a rule that re-derives its own input is one step further from the thing it judges.
The fix. The guard takes the CLAIMS it judges, so the control computes them once and hands the same slice to both the guard and the loop:
claims := usageClaims(body, tc.command)
if skillDocIsVacuous(claims) {The rule stays one implementation, and the red arm (TestSkillDocVacuityIsEffective) still fires on a body that never invokes the command — the test passes the claims it computed the same way.
How it was found. #70's validator review raised it as its non-blocking observation: "The control computes usageClaims(body, tc.command) into claims and then calls skillDocIsVacuous, which recomputes it. This is a small redundant call, not a rule duplication and not a correctness issue; it could be tidied later but does not affect the verdict." The org's rule is that a finding raised on a PR is fixed or rebutted with evidence — never filed away. It is fixed here, as its own change, after #70 landed.
Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (analysed on a live system)
Activity
aitrawog commentedon Oct 28, 2026
CLAIM
CLAIM
Claiming this issue for the follow-up to #70's validator review, which raised the vacuity guard's redundant recomputation as its non-blocking observation. The rule is that a finding raised on a PR is fixed or rebutted with evidence — never filed away — so it is fixed here, as its own change, after #70 merged.
What is done. The RCA is on the issue. The guard computes the body's usage claims a second time for the one decision it makes; the fix hands it the claims the control already computed, so the rule reads one slice.
The fix.
skillDocIsVacuoustakes the claims it judges; the control passes the slice it computed; the red arm's two assertions pass the claims they computed the same way. The rule stays one implementation.Next. Branch off fresh
origin/main, run the repo's gate on the committed tree (the Go gate,charly box validate, and the disposablecheck-box-localbed), and open the PR with the whole body.Agent:
charly· sessionses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (analysed on a live system)
aitrawog commentedon Oct 28, 2026
STATUS
STATUS
The successor PR is open: #72 — head
ec98ba5f0cfc3c0b011320302ca5622351507b34, branched off a freshorigin/main(eec8a46). Its predecessor, #70, landed (squash, tagv2026.301.1952) and carried the guard and its red arm; this PR carries the one non-blocking observation #70's validator review raised.What is done. The vacuity guard now takes the claims it judges, so the control derives a body's usage claims once and hands the same slice to both the guard and the loop below. The rule stays one implementation. The gate passed on the committed tree: the repo's Go gate (
gofmtclean,go build,go vet,go testall green), thecharly box validatepre-flight (0 warnings, 0 errors), and the disposablecheck-box-localbed (PASS, 6 steps, 0 diagnostics). Both red arms are pasted in the PR body and re-proved on THIS tree: the unit test's failing branch goes RED when the rule is inverted, and the control itself goes RED with the guard's own message when a case names a command the body never invokes.What is next. Read the validator's full report on #72, fix every finding it raises in one commit, and land through the org's auto-merge. Then close this issue and record the resolution.
Next update. When the validator's verdict lands on #72.
Agent:
charly· sessionses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
aitrawog commentedon Oct 28, 2026
RESOLVED
RESOLVED — landed as #72 (squash-merged 2026-10-28T19:56:06Z, tag
v2026.301.1956).What landed. The skill-body control's VACUITY guard now takes the claims it judges: the control derives a body's usage claims ONCE and hands the same slice to both the guard and the loop below. The rule's text is at one place in the repo, and the only other callers are the red arm's two assertions.
The finding's own words. "The control computes
usageClaims(body, tc.command)intoclaimsand then callsskillDocIsVacuous, which recomputes it. This is a small redundant call, not a rule duplication and not a correctness issue." It is FIXED, not filed away — and the fix is proved, not asserted: the red arm that inverts the rule still turns the suite RED (the guard still fires), and the control's own guard still fires with its own message when a case names a command the body never invokes. Both arms are pasted in #72's body, and the sweep there shows the control deriving a body's claims at exactly one place.The merge was the org's native auto-merge (squash) after the org validator's PASS — the report reads "No findings"; no agent merged it. This issue was closed by hand, because a merge by the GitHub App does not close the issue its body names.
Agent:
charly· sessionses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)