cad-executor: the terminal success-criteria check has no report field and no consumer #65

New issue

Closed

opened 2026-07-28 17:41:22 +00:00 by crenshawdev · 0 comments

crenshawdev commented

2026-07-28 17:41:22 +00:00

(Migrated from github.com)

What happened

agents/cad-executor.md ends its <process> block with an instruction whose output has nowhere to go:

# agents/cad-executor.md:35-36
After the last task: check the plan's success criteria against what you
built, then return the report.

The <report> block that follows defines the return contract, and it has no field for that check. The executor is told to do the work and given no slot to put the answer in, so the result is either dropped or smuggled into a field meant for something else.

Nothing downstream asks for it either:

grep -c -i 'success criteria' cadence-core/workflows/execute.md
0

The next orchestrator step, goal_check, redoes the same assessment inline, and it does so with an articulated purpose the executor's version lacks: producing evidenced claims for cad-verifier to falsify.

What you expected

An agent contract that does not require work it cannot report. Either the <report> block gains a field for the check and execute.md consumes it, or the instruction goes.

Reproduction

Read agents/cad-executor.md: the <process> block's final line asks for the check, the <report> block immediately below defines every field the executor may return, and none of them holds it.

Then grep -c -i 'success criteria' cadence-core/workflows/execute.md returns 0, confirming no consumer exists.

Environment

Claude Code version: 2.1.220
node --version: v26.4.0
OS: Linux (CachyOS, 7.1.5-1-cachyos)
Cadence: v1.4.0 at fba5879

Notes

The fix is a deletion: drop the terminal success-criteria line from <process>. goal_check already owns this assessment, owns it later (with the full phase diff in view rather than one executor's slice), and owns it for a stated reason.

Do not touch the per-task predict-then-verify at process step 2. That one has a consumer (the deviation record), a contract, and it is what makes a SUMMARY's claims trustworthy in the first place.

Verification after the fix: grep -i 'success criteria' agents/cad-executor.md returns nothing, and the executor's report contract is unchanged.

## What happened `agents/cad-executor.md` ends its `<process>` block with an instruction whose output has nowhere to go: ``` # agents/cad-executor.md:35-36 After the last task: check the plan's success criteria against what you built, then return the report. ``` The `<report>` block that follows defines the return contract, and it has no field for that check. The executor is told to do the work and given no slot to put the answer in, so the result is either dropped or smuggled into a field meant for something else. Nothing downstream asks for it either: ``` grep -c -i 'success criteria' cadence-core/workflows/execute.md 0 ``` The next orchestrator step, `goal_check`, redoes the same assessment inline, and it does so with an articulated purpose the executor's version lacks: producing evidenced claims for `cad-verifier` to falsify. ## What you expected An agent contract that does not require work it cannot report. Either the `<report>` block gains a field for the check and `execute.md` consumes it, or the instruction goes. ## Reproduction Read `agents/cad-executor.md`: the `<process>` block's final line asks for the check, the `<report>` block immediately below defines every field the executor may return, and none of them holds it. Then `grep -c -i 'success criteria' cadence-core/workflows/execute.md` returns `0`, confirming no consumer exists. ## Environment - Claude Code version: 2.1.220 - `node --version`: v26.4.0 - OS: Linux (CachyOS, 7.1.5-1-cachyos) - Cadence: v1.4.0 at `fba5879` ## Notes The fix is a deletion: drop the terminal success-criteria line from `<process>`. `goal_check` already owns this assessment, owns it later (with the full phase diff in view rather than one executor's slice), and owns it for a stated reason. Do not touch the per-task predict-then-verify at process step 2. That one has a consumer (the deviation record), a contract, and it is what makes a SUMMARY's claims trustworthy in the first place. Verification after the fix: `grep -i 'success criteria' agents/cad-executor.md` returns nothing, and the executor's report contract is unchanged.