What happened
2026-09-09 ~06:00–06:20 UTC, on the maintainer's machine. Two find / processes were pegging CPU (one at 70%), each walking the entire filesystem:
find / -type d -name codev -path "*@cluesmith*"
find / -path "*codev/protocols/spir/templates/spec.md" -not -path "*/.builders/*"
Both were children of consult -m claude --protocol spir --type spec --project-id <id> lanes running for a SPIR builder in an adopter workspace on codev 3.3.3 (workspace name withheld). Killing a find did not help: the reviewer relaunched the hunt within a minute (three finds killed over ~10 minutes, from two consult attempts).
Root cause
protocols/spir/consult-types/spec-review.md (shipped skeleton) tells the reviewer:
Structure — the spec follows the delivered template (protocols/spir/templates/spec.md), which the specify prompt inlines.
The reviewer is told the template exists, given a path, and told it was "inlined" — but it was inlined into the builder's specify prompt, not into the reviewer's query. The adopter workspace has no local codev/protocols/spir/ (normal: the protocol resolves from the installed package), so the path does not exist anywhere under the workspace, and the reviewer goes looking for it across /. This is the exact anti-pattern CLAUDE.md names: "Deliver framework content; don't instruct an agent to fetch it by path — that bypasses the resolver and fails in fresh installs."
The same shape likely exists in the plan-review prompt (templates/plan.md) and in other protocols' consult-types; audit all of them.
Fix (BUGFIX, prescribed)
- In
buildSpecQuery / buildPlanQuery (packages/codev/src/commands/consult/index.ts), resolve the protocol's template through the normal four-tier resolver (readCodevFile) and inline it into the reviewer query under a "Template this artifact must follow" heading, the same way spec/plan text is already inlined.
- Reword the consult-type prompts (both trees) so they refer to "the template inlined below" and never name a
protocols/... path. Grep every consult-types/*.md in codev/ and codev-skeleton/ for protocols/ and templates/ paths.
- Add a test that the composed spec-review query contains the template's headings and contains no
protocols/<name>/templates/ path string.
Independent of #1659 (the tripwire catches writes, not read-only roaming) and of #1641 (context exhaustion from whole-file reads); this one is about the reviewer being pointed at a file it cannot have.
What happened
2026-09-09 ~06:00–06:20 UTC, on the maintainer's machine. Two
find /processes were pegging CPU (one at 70%), each walking the entire filesystem:Both were children of
consult -m claude --protocol spir --type spec --project-id <id>lanes running for a SPIR builder in an adopter workspace on codev 3.3.3 (workspace name withheld). Killing afinddid not help: the reviewer relaunched the hunt within a minute (three finds killed over ~10 minutes, from two consult attempts).Root cause
protocols/spir/consult-types/spec-review.md(shipped skeleton) tells the reviewer:The reviewer is told the template exists, given a path, and told it was "inlined" — but it was inlined into the builder's specify prompt, not into the reviewer's query. The adopter workspace has no local
codev/protocols/spir/(normal: the protocol resolves from the installed package), so the path does not exist anywhere under the workspace, and the reviewer goes looking for it across/. This is the exact anti-pattern CLAUDE.md names: "Deliver framework content; don't instruct an agent to fetch it by path — that bypasses the resolver and fails in fresh installs."The same shape likely exists in the plan-review prompt (
templates/plan.md) and in other protocols' consult-types; audit all of them.Fix (BUGFIX, prescribed)
buildSpecQuery/buildPlanQuery(packages/codev/src/commands/consult/index.ts), resolve the protocol's template through the normal four-tier resolver (readCodevFile) and inline it into the reviewer query under a "Template this artifact must follow" heading, the same way spec/plan text is already inlined.protocols/...path. Grep everyconsult-types/*.mdincodev/andcodev-skeleton/forprotocols/andtemplates/paths.protocols/<name>/templates/path string.Independent of #1659 (the tripwire catches writes, not read-only roaming) and of #1641 (context exhaustion from whole-file reads); this one is about the reviewer being pointed at a file it cannot have.