Found by a cross-slice review of PR #381 (orchestrate run prd352-20260803-015333, PRD #352). Not a defect in any single slice — it is the seam between three of them.
The tension
skills/slice-pipeline/SKILL.md:210-215 requires the executor's no-progress guard to use a content-level fingerprint, and explicitly forecloses the cheap alternative: "A filename-set comparison is insufficient… that it is content-level is not [yours to choose]".src/tools/verify-changeset.ts:54,195 returns actualFiles — names only. No hash, no size, no content.agents/slice-executor-{standard,deep}.md:4 grant Read, Write, Agent plus validate_envelope, verify_changeset, run_build, run_tests. No Bash, no hashing tool.
So the procedure mandates a content-level comparison, the tool that inspects the worktree returns no content, and the agent holds nothing that can hash a file.
The concrete cost
An implementer returns incomplete on a slice touching 30 files. The only procedure-compliant route left is to Read all 30 files in full into the executor's context, then read them again after the next continuation to compare.
That is two full reads of the changeset per continuation turn, spent inside the very agent whose purpose is to keep that material out of the orchestrator's window. On a large slice it can exhaust the executor's own budget before the no-progress guard it is feeding ever fires — the guard defeats itself.
Options
- Have
verify_changeset return a per-file content hash alongside actualFiles. Cheapest, keeps the executor's tool surface closed, and makes the fingerprint a single tool call.
- Permit a stated cheaper proxy in the procedure (size + mtime, or a hash of the concatenated
git status porcelain plus file sizes) and say plainly what it can and cannot catch.
- Grant the executor a hashing affordance — worst of the three, since it widens the no-Bash boundary the delegation design rests on.
Option 1 looks right: it turns an unbounded read loop into one call, and it is the only option that does not weaken either the procedure's stated requirement or the sandbox.
Found by a cross-slice review of PR #381 (orchestrate run
prd352-20260803-015333, PRD #352). Not a defect in any single slice — it is the seam between three of them.The tension
skills/slice-pipeline/SKILL.md:210-215requires the executor's no-progress guard to use a content-level fingerprint, and explicitly forecloses the cheap alternative: "A filename-set comparison is insufficient… that it is content-level is not [yours to choose]".src/tools/verify-changeset.ts:54,195returnsactualFiles— names only. No hash, no size, no content.agents/slice-executor-{standard,deep}.md:4grantRead, Write, Agentplusvalidate_envelope,verify_changeset,run_build,run_tests. No Bash, no hashing tool.So the procedure mandates a content-level comparison, the tool that inspects the worktree returns no content, and the agent holds nothing that can hash a file.
The concrete cost
An implementer returns
incompleteon a slice touching 30 files. The only procedure-compliant route left is toReadall 30 files in full into the executor's context, then read them again after the next continuation to compare.That is two full reads of the changeset per continuation turn, spent inside the very agent whose purpose is to keep that material out of the orchestrator's window. On a large slice it can exhaust the executor's own budget before the no-progress guard it is feeding ever fires — the guard defeats itself.
Options
verify_changesetreturn a per-file content hash alongsideactualFiles. Cheapest, keeps the executor's tool surface closed, and makes the fingerprint a single tool call.git statusporcelain plus file sizes) and say plainly what it can and cannot catch.Option 1 looks right: it turns an unbounded read loop into one call, and it is the only option that does not weaken either the procedure's stated requirement or the sandbox.