Planning bug: MOTIR-3735 deliverable 2 asserted `schema.prisma`'s `sessionBranch` "carries no comment" — it carries a 12-line one at the cited ref

Planning telemetry. The correction is already applied — the card was run, not re-planned. Nothing is blocked and no sprint is joined.

The false claim

MOTIR-3735's What actually remains item 2, and the same sentence in docs/decisions/session-branch-lineage.md §4 and in the card's 2026-08-28 re-scope comment, all say:

prisma/schema.prisma — sessionBranch String? (:1991) carries no comment saying what it is. Add a short one … This is the line a future retirement card meets first.

It carries a twelve-line comment, at the very ref the card cites. Measured on origin/main 17a3aba23 — the commit session-branch-lineage.md §0 pins every one of its own numbers to:

$ git show 17a3aba23:prisma/schema.prisma | sed -n '1979,1991p'
  // Integration branch (Story 7.8 · Subtask 7.8.11) — the session branch this
  // item's work currently sits on after a run integrated it (status moved to
  // `in_review` via `mark_integrated`). NON-NULL ⇔ the item is integrated-
  // awaiting-review: its work is mergeable so it UNBLOCKS dependents (the
  // integrated-dep readiness rule, keyed on THIS field, not the status key —
  // custom workflows can name review states anything, but the recorded branch
  // is the ground truth a dependent can build on). CLEARED back to NULL the
  // moment the item reaches a `done`-category status (the chokepoint is
  // `applyStatusTransition`; `complete_session` is the bulk close-out after the
  // human merges the session PR). Indexed for the `complete_session` lookup
  // (every item recorded on a branch) — a plain `String?` matching this table's
  // camelCase, no-`@map` columns.
  sessionBranch         String?

That comment already states the field's meaning, the readiness rule keyed on it, the done-clears invariant and the reason for the index — i.e. three of the four things the card asked to be written from scratch.

Why it happened, and what it cost

The ref was verified; the PREDICATE was not. :1991 is the line the declaration sits on, and a Prisma field's documentation sits on the lines ABOVE it. A reader who opens the file AT :1991 sees sessionBranch String? and nothing else. The claim was checked against a coordinate rather than against the thing the sentence is about.

Cost was small — the deliverable shrank from author a comment to extend the comment that is there — but the shape is the one this story keeps paying for: session-branch-lineage.md §0 names MOTIR-3733 and MOTIR-3753 as the first two occurrences and itself as the third. This is the fourth, and it is inside the ADR that documents the class.

What was done instead

The run shipped the corrected version: the existing comment was EXTENDED with the retirement answer and the ADR pointer, which is what deliverable 2 was reaching for. AC 2 (git diff shows no model, index, attribute or migration change) is unaffected. The falsification and this command are in the pull request body, and the card body is amended on the record.

Acceptance criteria

1. session-branch-lineage.md §4's What MOTIR-3735 becomes no longer says the field is uncommented — it says the comment exists and names what it was missing (the retirement answer + the ADR slug). Amended in the file's amendment idiom; original text preserved.
2. The amendment cites this bug and git show 17a3aba23:prisma/schema.prisma.
3. No other change — this is a prose correction to a merged ADR.