Do not attach a guessed plan or spec as review context (#65)

[pseudoseed]

Reopens and finishes #65, which was closed against the wrong half.

The original report blamed afx spawn. The uiv2 architect corrected it by observation: afx spawn 83 resolved codev/specs/83-v2-client-shell.md correctly with 0083-protocol-agnostic-spawn.md sitting right beside it. The spawn-side lookup has been exact-match only since #69 and is fine.

The consult lane is not. codev/plans/ held 0083-protocol-agnostic-spawn.md and no 83-*, so eleven consecutive consult --type spec --issue 83 rounds each attached a stale January draft about a different subject as "the plan", and every reviewer spent part of its answer saying the plan looked unrelated.

artifactHeading already warns on an inexact match, and that warning worked — the reviewers all flagged it. It just does not help. The round is spent either way.

The rule turns on who asked for the document

artifact	rule
primary (named by --type)	keep the lenient zero-stripped fallback + its warning
secondary (plan on a spec review, spec on a plan review, both on impl)	drop a guess

You asked for the primary by id: refusing would block the review outright, and genuinely zero-padded legacy projects must still resolve. The secondary is offered because it usually helps, and a guess usually does not. Omitting it costs nothing; attaching one costs a review.

Dropping says so on stderr:

Not attaching a plan for context: '0006-tutorial-mode' matched 6 only by zero-stripping,
so it is probably a different project's plan that collides on the number (#65).
Pass --plan-file to attach one explicitly.

A plan that is silently absent is the same defect facing the other way — the operator cannot tell "no plan exists" from "we declined one".

Not a one-file collision

82 project ids in this repo have only a zero-padded plan. Renumbering 0083-protocol-agnostic-spawn.md (uiv2 notes it is a stale 2026-01-27 draft, still Status: Draft, no review) would fix project 83 and leave 81 others. Worth doing on its own merits, but it is not this fix.

Concretely: issue #6 in this fork — an open, unrelated CI bug I am about to work on — currently resolves to 0006-tutorial-mode. Verified against the built module, it now drops.

The reported id no longer reproduces

The project-83 run created codev/plans/83-v2-client-shell.md, so 83 resolves exactly today. The tests are written against the rule rather than against that id, and one of them asserts both spellings still sit side by side so a future renumbering does not silently make them vacuous.

Verification

• 5974 passed, 0 failed (full suite, local)
• tsc --noEmit clean
• 14 new tests, 7 of them driving dropIfGuessed directly
• Live check from the built module: id 6 drops 0006-tutorial-mode, id 83 attaches 83-v2-client-shell

🤖 Generated with Claude Code