Planning bug: MOTIR-3739 called a neighbouring line "protected" without reading its call chain, and named ONE instance of a copy-pasted pattern as the population

Telemetry about the planner, filed by the motir run MOTIR-3739 that hit it. The correction is already applied — moooon-B-V/motir-core#2402 ships the widened fix — so this card holds up nothing.

What the card said, and what was true

MOTIR-3739's opening sentence:

tests/e2e/code-graph-refresh-engine.spec.ts's beforeEach runs three resets in a row. The first two are protected against the job worker; the third is not, and it is the one that fails.

The second of those two is not protected. Read on origin/main:

$ git show origin/main:tests/helpers/db.ts | sed -n '57,67p'
export async function truncateJobRuns(): Promise<void> {
  await db.$executeRawUnsafe(
    'TRUNCATE TABLE "job_run", "job_run_dlq", "job_event", "job_queue", "job_step", "email_delivery" RESTART IDENTITY CASCADE',
  );
}

A bare $executeRawUnsafe with no retry — and it truncates a strict superset of the three tables the "unprotected" line named. Two consequences the card could not see:

1. Its own fix direction would not have worked. Wrapping line 66 alone leaves line 65 truncating the same three tables unprotected on the line above; the deadlock moves up one line.
2. Line 66 was REDUNDANT. Nothing writes between the two but the worker, so it cleared nothing line 65 had not already cleared — and it was the statement that deadlocked. The right disposition was to delete it, not to wrap it.

And the population was ONE where it is EIGHT

The card's third acceptance criterion quantifies over "an unprotected truncate in tests/e2e/**"; its evidence was one stack trace. Measured on origin/main:

$ git grep -n 'TRUNCATE TABLE' origin/main -- 'tests/e2e/**'      # 5 raw statements, byte-identical
$ git grep -n 'await truncateJobRuns()' origin/main -- 'tests/e2e/**'   # 3 more, unprotected the same way

Five specs carry the raw statement; three more call the helper bare. A fix scoped to the named site would have shipped with seven sites still unprotected and a guard that went red on its own merge.

The two takeaways

1. A protection claim about a NEIGHBOURING line is a claim about that line's own call chain, not about how the block looks. Three awaits in a row read as one guarded operation; the guarantee lives one file away, per call. Read each call's own implementation before describing any of them as protected.
2. A card naming ONE instance of a statement that could have been copy-pasted owes the git grep over the ref before it names a population. This is the enumeration limb (plan-rules/phase-deepen.md) firing on a shape it is not usually read against: the card was not counting anything — it wrote a singular sentence about one file — and its criterion then quantified over a directory anyway. A singular subject with a plural criterion is the tell.

Acceptance criteria

• plan-rules/phase-deepen.md's enumeration limb carries the corollary above: a card whose criterion quantifies over a population owes the ref-based measurement even when its description names one instance — and a claim that a neighbouring call is protected is checked at that call's own implementation.
• The rule is stated once, in the pack that owns it, and cited rather than restated anywhere it is referenced (plan-rules/MANIFEST.md routes it).

Evidence

• Filed by the motir run MOTIR-3739 session on 2026-08-28. Every command above was run against origin/main at bed2bbc52, not against a working tree.
• The corrected shape is on subtask/MOTIR-3739-e2e-truncate-retry (PR #2402): eight sites routed through one exported retry wrapper, plus tests/e2e-truncate-retry.test.ts, which is the guard that makes the population visible from now on.