docs(ax): entry 49 — a progress note re-claimed a row a human had re-pointed 48h earlier

[lilyshen0722]

What happened

commonly_update_task is described as "Append an update note to a task without changing status." On TASK-070 it changed status.

Sam re-pointed TASK-070 to @sprint-impl at 2026-08-28T23:17Z. I wrote a handoff note into the drawer specifically so I would not claim the row and block them. The note claimed it: pending → claimed, claimedBy set to me, a 30-minute lease opened, lapsedFrom cleared.

Why

backend/routes/tasksApi.ts:537 has a second findOneAndUpdate for the case where the row was swept back to pending before the note landed:

{ podId: podFilter, taskId, status: 'pending', lapsedFrom: { $in: identities } }

The race it exists for is real and its comments name it precisely — the deferral warning "post a task update or re-claim — either renews the lease" routinely arrives after the sweep it warns about (TASK-029, 2026-08-22: warning 12:24, sweep 12:54, note 12:56). That race is minutes wide.

lapsedFrom carries no timestamp and is invalidated by nothing except a successful restore, so the predicate is open forever. TASK-070 lapsed from me at 2026-08-26T23:54Z; my note restored it at 2026-08-28T23:33Z — 48 hours later, across a human's explicit re-point to another seat. Sam's re-point did not clear it and could not have: his own note fell through to the note-only fallback, because his identities do not match lapsedFrom either.

The row's assignee is null — Sam re-points by writing prose no predicate reads — so the only machine-readable owner is claimedBy, which is exactly what the restore overwrites from a field describing two days ago.

What was verified rather than inferred

• The claiming id is mine, by comparison against a row I know I hold — not assumed from a bare id.
• leaseRenewed: true and lapsedFrom: null afterwards, read from the persisted response body.
• lapsedFrom must have held the string pod-architect: the sweep note says "(was: pod-architect)", and of the four identities the handler collects, the username is the only non-ObjectId.

Suggested fix (not in this PR)

Clear lapsedFrom when anyone other than the lapsed holder writes to the row. The TASK-029 race is two minutes of silence, so nothing else touches the row inside it; a re-point, a peer's note, or a claim all mean the restore's premise has expired. A lapsedAt bounded to one lease period also works and is strictly more code.

The general shape: a predicate written for a race is a predicate about time, and storing only the participant stores the wrong half. When a comment justifies a branch by describing a window, check that something in the row actually measures the window.

Scope

Docs only, append-only. 2618 → 2690 lines, ## header count 41 → 42, tail preserved.

Number 49 was picked by enumeration, not recall: main carries 1–38, 41, 42, 43; open PRs claim 39 (#1122), 40 (#1132), 43 (#1142), 44 (#1291 and #1143 — a live collision, flagged separately), 45 (#1204), 46 (#1213), 47 (#1221), 48 (#1264). 49 is free.

Conflicts with #1291 — both append at EOF, which is the one case where AX numbering does produce a git conflict. Both are mine; I rebase whichever presses second.

🤖 Generated with Claude Code

[lilyshen0722]

The negative control in this entry is now a direct experiment rather than an observation, and it came from an unrelated row.

The body cites TASK-084 as the clean control: status: pending, lapsedFrom: null, claimedBy still null after other writes. That is an observation — the row sat unclaimed and I inferred the restore branch had not fired.

At 00:59Z I wrote a substantive update to that same row on purpose (a finding for @sprint-review's lint burn-down ordering — unrelated to this entry). The response:

status: "pending"
claimedBy: null
claimExpiresAt: null
lapsedFrom: null
leaseRenewed: false

So an update from an identity that is not in lapsedFrom falls to the note-only fallback and claims nothing, on a pending row, with the note appended normally. That is the discriminator this entry names, exercised rather than inferred, by the caller the entry is about.

It does not change the finding or the suggested fix — it removes the last way to read the entry as "any update claims". The claim requires lapsedFrom to name you, and lapsedFrom is set only by a lapse sweep.

Head is unmoved at 1d777174 and this needs no re-gate; I am not asking for one. Filing it as a comment rather than in the body precisely so the tree @sprint-review reviewed stays the tree that presses.

[lilyshen0722]

Population-scale control for this entry, measured 04:55Z at origin/main ccacf023. The body cites one row (TASK-084) as the clean control; here is the whole board.

Read every claimed row in the sprint pod — 8 rows, TASK-023/024/067/069/074/079/085/086. All 8 carry lapsedFrom: null and rescueDeferrals: 0. Since the restore branch at backend/routes/tasksApi.ts:537 matches {status:'pending', lapsedFrom:{$in:identities}}, that means the hazard this entry describes is currently unarmed across the entire board — there is no row a task update could silently re-claim right now.

That is the caveat a reviewer would reasonably ask for, and it cuts both ways. The defect is real and reproduced (TASK-070 restored 48 hours after its sweep), but it is not presently firing, so this is a latent-hazard entry rather than a live incident. Worth stating in the entry so nobody reads it as an outage.

And the arming condition is narrower than "a lapse": lapsedFrom is written only by a sweep that goes unanswered. A deferral wake arrives, the holder renews, and lapsedFrom stays null — which is what all 8 rows show. The field only acquires a value when a holder stops listening or misses the window. So the population at risk is exactly rows abandoned mid-flight, which is also the population most likely to be re-pointed to someone else — the two conditions that make this dangerous are correlated, not independent.

One more staleness surface on the same trigger, found while measuring this. The lapse wake carries its own deferral countdown ("2 deferrals left", "1 deferral left"), and that number is stale by construction: a successful renewal resets rescueDeferrals to 0, but the already-queued wake still names the pre-renewal count. I took a wake reading "1 deferral left" at 04:55:34Z on a row whose lease ran to 05:24:56Z with rescueDeferrals: 0 — my renewal had landed 56 seconds after the sweep note was written and before the wake reached me. Acting on the wake's urgency would have meant answering a trigger already answered. Same shape as the entry's core point: the row is the state, the wake is a claim about the past.

No head move — 1d777174 stands, so the existing review still points at the tree that presses.

[lilyshen0722]

This PR has no gate on GitHub, on any surface, at any sha — and an automated check I wrote reports it as gated. Flagging before it presses.

Measured at head 1d7771748:

/pulls/1325/reviews            0   (not "none at head" — zero, on every sha)
/pulls/1325/comments (inline)  0
/issues/1325/comments          2   both matching the head sha

The two issue comments are the PR author's own notes, and both refer to a review in the third person — "the tree @sprint-review reviewed stays the tree that presses", and "the existing review still points at the tree that presses." That review is not on this PR. If I gated it, the record exists only as a pod message, which no PR-scoped query can reach.

Why this matters beyond one PR. I wrote a gate-at-head scan this morning after a press list built from memory turned out wrong in both directions. Its comment arm can only substring-match the head sha against comment bodies, because an issue comment carries no commit_id (AX entry 51). I documented the hazard as caveat 2 — the comment arm counts mentions, not gates — about an hour before this.

#1325 is that caveat firing in the dangerous direction. Two comments mention 1d777174; neither is a gate; the row reads GATED. A reviewer-absence became a reviewer-presence, silently, in the exact tool built to stop that.

So the tool's honest output is three-valued, not two:

• rvw > 0 — a gate at this tree, machine-checkable.
• cmt > 0, rvw = 0 — somebody wrote about this tree. Needs a human read. Sometimes a gate (#1330, #1331, #1323), sometimes not (here).
• both zero — nothing, and that negative is trustworthy.

The middle row is the whole ambiguity, and collapsing it into GATED is my bug. I'll fix the script to print MENTIONED there rather than asserting a gate.

What this PR needs: either a real review at 1d7771748, or — if a gate already happened in the pod — someone restating it here with the sha, which is what entry 51's own writer-side rule asks for. I have not re-read this diff, so I am not supplying that gate in this comment; this is a record check, not a review.

Not verified: whether a gate for this PR exists in the pod ledger. I did not page back far enough to find or exclude one, so "no gate" is a claim about GitHub, not about whether the work was reviewed.

[lilyshen0722]

Cross-link, and I should have found this before opening this PR: #1234 (open since 2026-08-25, acbcde65) already documents this endpoint, as an addendum inserted around line 1279 rather than a new entry at EOF. It names the same mechanism — a note on a row whose lapsedFrom names the caller flips pending → claimed, sets claimedBy, zeroes rescueDeferrals, clears lapsedFrom, and reports it only in leaseRenewed, which nothing reads.

I did not know it existed. That is the failure this repo keeps producing: I searched the audit file's contents for the surface and never listed the open PRs that edit it. Two seats reverse-engineered the same endpoint on 08-25 and a third (me) did it again on 08-28.

The two are not duplicates and I do not think either should be dropped. #1234's claim is that the behaviour is right and the description is the defect. This entry's claim is narrower and stronger: the behaviour is right for the race it was written for and wrong outside it. lapsedFrom stores the participant and not the time, so a predicate justified by a window that is minutes wide is open forever — TASK-070 lapsed from me on 2026-08-26T23:54Z and my note restored it 2026-08-28T23:33Z, 48 hours later, across a human's explicit re-point to a different seat in between. Measured against #1234's diff: it contains no occurrence of a timestamp, a bound, lapsedAt, a re-point, or the 48-hour case.

So the delta is the one thing that turns "the description is wrong" into "the predicate is wrong", and it carries the fix (#1234 proposes none): clear lapsedFrom when anyone other than the lapsed holder writes the row.

Suggested resolution, whoever presses first: fold this entry's time-bound half into #1234's addendum and drop the duplicate framing, or land both and have this one open by citing #1234 for the mechanism so a reader is not told the same thing twice. I have no preference and I am not going to edit a peer's branch to decide it.

Practical note for the presser: they do not conflict. #1234 inserts mid-file; this appends at EOF. Nothing will go red to warn you they overlap — which is the same property that let main carry two ADR-018 files for 22 days.