writing-plans: expected values in verification steps are asserted, not produced — and can be contradicted by the plan's own text

The problem

writing-plans requires every step to carry the actual content an engineer needs, and forbids placeholders like "TBD" or "add appropriate error handling" on the grounds that a step describing what without showing how is not a plan.

That rule does not currently extend to the outputs those steps assert. A verification step of the form:

grep -c "some-pattern" path/to/file

Expected: 4

is a placeholder wearing a number. The 4 is a claim about a command the plan author never ran.

The failure direction is the damaging one. A wrong expectation reports a correct implementation as broken, and pressures whoever executes the plan to bend working code until it matches the author's guess.

Evidence from real use

Across three plans written in one session, four stated expectations were wrong. Three were caught only because the implementers stopped and reported a mismatch rather than adjusting the work to fit; one was caught in self-review, after the same class of error had already surfaced twice.

Two were wrong for a reason worth calling out separately: the plan's own added text changed what the command would match. A step instructed the implementer to insert a paragraph containing a word, and a later verification step grepped for that word with a count derived from the file before the insertion.

A sharper variant appeared in the same set: a verification grep whose pattern matched a phrase the plan's own inserted text used, so the check could never pass regardless of how correct the implementation was. The implementer correctly reported it as unsatisfiable rather than as a failure.

Proposed change

Two small additions, both in existing sections.

1. Add to the No Placeholders list:

• An expected count, output, or match you did not produce by running the command against the real tree. A stated expected value is an untested assertion, and it fails toward reporting correct work as broken. Either run the command while writing the plan and paste the real value, or describe what the reader should observe ("every reference rewritten, none left bare") and have the step compare two independently derived counts rather than one count against a literal.

2. Add to Self-Review:

4. Self-contradiction check: for every verification command, ask whether text this plan introduces elsewhere would match it. A step that greps for a word the plan itself adds will return a count the author did not anticipate, or can become unsatisfiable outright.

Notes

• Agent-agnostic. Both are prose rules about what a plan may assert; nothing depends on a particular harness, tool name, or shell.
• Scoped to writing-plans. executing-plans and subagent-driven-development consume these plans but do not author the expectations, so the rule belongs upstream of both.
• If useful, I can open this as a PR against dev instead.