Planning bug: the CORRECTION to MOTIR-3721's inventory was itself scoped by a one-file grep, so nine is short by seven in the same shape as five was short by four

This is the THIRD pass over one question, each narrower than its own claim. MOTIR-3733 records passes one and two; this records pass three, and its point is that the pass which FIXED the inherited inventory reproduced the inherited inventory's shape.

The sequence

The command, and why it was not the claim's

Pass 2 corrected the inherited table by re-deriving it. Its command:

git grep -n "workItemId" lib/repositories/githubPullRequestRepository.ts

That command is correct and its answer is correct. The sentence it was used to support — "the real set is nine reader sites plus one service-level cardinality cap" — quantifies over the CODEBASE. A Prisma row is a plain object, so pr.workItemId in a service is a read of github_pull_request.work_item_id that no grep of the repository FILE can see. The claim quantifies over X, the command enumerated Y, X ⊋ Y.

run.md's RE-MEASURE THE PREDICATE, NOT ONLY THE REF names this exactly, and names the tell: "the command is scoped by how the defect was NOTICED, not by what the sentence is about." Pass 2 noticed the problem in the repository file (findWorkspaceIdByWorkItem's header is what gave it away), so it measured the repository file.

The seven, all predating the card

git grep -nE "(pr|existingPr|existing|candidate|row|target|m)\.workItemId" origin/main -- lib app packages

changeRequestStatusSync.ts:241-242 (the sync's PRIMARY resolve) · changeRequestCiFeedback.ts:384,388 (consumed at eight sites incl. addComment and setCiState) · ciPromotion.ts:147 · githubPullRequestService.ts:74 · historicalPullRequestBackfillService.ts:357 · proseGraphAdvisoryService.ts:522,599 · pullRequestBaseRefBackfillService.ts:221. Plus two WRITERS in the repository file itself (setWorkItemLink, UpsertGithubPullRequestInput.workItemId) that no pass has ever listed.

Every one predates pass 2, so this is an amendment on the record, not drift.

Two findings pass 3 made that are worth more than the count

1. findTouchingPaths's excludeWorkItemId — the predicate MOTIR-3751's Q4 asked about — is DEAD. Its only production call site (proseGraphAdvisoryService.ts:515) passes null; the live exclusion is m.workItemId !== id at :599. Q4 would have been answered in the wrong layer, correctly.
2. listMergedMissingBaseRefByRepo's projection was recorded as "log-only" and is not. It feeds touchedWorkItemIds → repoSetCompletionService.reevaluateItems — i.e. it is the INPUT to the very read Q1 is about.

Both are recorded in docs/decisions/delivery-reader-migration.md §§0, 4, 5.

The takeaway

A card that corrects an inherited number is the highest-risk place to take a new one, because the correction arrives with the authority of having caught an error and the reader's attention has moved to the four decisions it surfaced. The instrument is not measure more carefully; it is print the COMMAND beside the number and read the claim's own quantifier against it — which is what pass 3 did, and it is the only reason the seven were found.

Acceptance criteria

1. MOTIR-3733's body records pass 3 as its third member, with the sequence table above.
2. If plan-rules/phase-deepen.md's ENUMERATION limb does not already say a correction to a count owes the same predicate check as the count, it does after this card — the correction case is where the limb is least likely to be applied, and that is the whole finding.
3. No product code changes.

Context refs

• docs/decisions/delivery-reader-migration.md §0 — the re-measurement, both commands, and the 17.
• MOTIR-3721 — re-scoped to EXPAND-1 on the strength of pass 3.
• MOTIR-3751 — pass 2's card and the ADR that found this.