Repository navigation
test(skills): the vacuity guard takes the claims it judges - #72
Conversation
The control computed the body's usage claims into `claims` and then called `skillDocIsVacuous(body, command)`, which computed them AGAIN — the same claims, read twice, for one decision. The guard now takes the claims, so the control computes them once and hands the same slice to both the guard and the loop below. The rule stays one implementation and the red arm still fires on a body that never invokes its command. This is the non-blocking observation #70's validator review raised, and it is fixed here rather than filed away. Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
|
STATUS STATUS The successor PR is open: #72 — head 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 ( 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: |
Review — PASSWhat the change doesThe diff is exactly what the body describes: Verification against the body
Disposition of commentsThe Checks
No findings. Verdict: PASS ollama-cloud/deepseek-v4.1-flash — action-review. |
Closes #71
Summary
Head
ec98ba5f0cfc3c0b011320302ca5622351507b34— the commit this PR pushes: 1 file changed, 13 insertions(+), 9 deletions(-).The finding. #70's validator review raised one non-blocking observation: the control computes the body's usage claims into
claimsand then callsskillDocIsVacuous(body, command), which computes them AGAIN — the same claims, read twice, for one decision.The RCA.
This is the successor to #70, which landed the guard and its red arm. #70 merged before this fix could be pushed onto it, so the fix is its own change here, off a fresh
origin/main— the successor's body names its predecessor, and #71 carries the finding.What lands. One file:
candy/plugin-box/skill_doc_flags_test.goNo verb, no flag, no published prose, and no grammar changes: this is a tidy-up of the control that guards the corpus, and the guard's behaviour is unchanged.
How tested
Everything below ran on the committed tree this PR pushes.
1. The repo's own Go gate — the gate this repo's AGENTS.md names.
2. R7 (a) — the guard's RED ARM still fires. The fix moves the guard's argument, so the arm that proves the guard can fire is re-proved on THIS tree: the rule's body is replaced by
return false, so it never fires, and the suite must go RED on the arm that expects it to fire.The file is restored and the tree is clean; the green run of the same test is below, and the whole-suite green is block 1.
3. R7 (b) — the guard is still live INSIDE the control. The unit test proves the function fires; this proves the CONTROL calls it, so the guard still stands where it does its work rather than only in a test of itself. One case's command is mutated to a spelling the body never invokes, so the body makes no usage claim for it:
Both arms fail the suite when the rule is broken and pass when it is intact, and the tree is restored after each.
4. The pre-flight — the project's own manifest validates on the tree that carries the change.
5. R10 — the live bed.
check-box-localis this repo's disposable witness (akind:localdeploy onhost: local), and it ran green on the committed tree:The bed's own summary carries the verdicts, with zero diagnostics:
6. R5 — the sweep. The claim: the control reads a body's claims exactly ONCE, and the rule's text appears once in the repo. The block below is the sweep for both:
The control derives a body's claims at ONE place (line 336) and hands the same slice to the guard (line 337) and to the loop below; the rule's text is at ONE place (line 308), inside the function; and the only other callers of the rule are the test's two arms, each with its own body.
Rulebook compliance
/charly-image:image,/charly-build:build,/charly-build:validate,/charly-internals:pluginand/charly-internals:git-workfloware the skills this repo's AGENTS.md names for this area; they were read before the first edit, and the git-workflow mechanics this PR follows are the ones they state (branch off freshorigin/main, commit, gate the committed tree, write the whole body before the push, PR-only landing).git statuswas run first in this worktree; the branch isfeat/vacuity-guard-once-71, cut off a freshorigin/main(eec8a46); no force-push, no history rewrite, no hook bypass, no push tomain. The two mutations in blocks 2 and 3 were reverted from a backup copy, andgit status --porcelainprinted nothing after each.kind:localdeploy and removed it again (thecleanupandcleanup-memberssteps are in the summary above). Nothing is mocked.2026.301.1632), named by the bed's own summarydriveranddriver_versionlines. The only.gofile in the diff is a TEST file, so no production code changed and the binary is unaffected by this commit; no new runtime OS dependency is introduced, sopackaging/is untouched.charly box validatepre-flight, and the disposable bed that composes the changed entity (check-box-local) — all pasted above, all on the committed tree, all with zero warnings and zero diagnostics.Change classification
go build/go vet/go test) plus this repo's project-configuration pre-flight (charly box validate) and its disposable R10 bed (check-box-local). NOT documentation: what changes is the control's own code, and the two red arms above are what prove the guard still behaves.fully tested and validated— the change-class gate passed on the final tree (the repo's Go gate, the pre-flight, and the disposable R10 bed), the changed path was executed live, and both red arms demonstrate the coverage can fail.Filed issues
Agent: charly · session
ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)