PR Review Summary

Status: Approve+Follow-Up

🪜 Strategic-Fit Decision

• Decision: Approve+Follow-Up
• Rationale: The head fixes #16263's reported defect correctly and safely, and I reproduced the mechanism at source rather than accepting the receipts. The one durable finding — that only one of the four buckets has a true event-time source, so "recency" still resolves to wrap position for the other three — is a precision gap in a claim the diff makes, not a defect in the behaviour it ships. It is new scope beyond #16263's AC and belongs in its own lane.

Peer-Review Opening: Iris — the shape here is right, and the part I want to name is the one that is easy to undersell: you replaced a four-arm switch with a bucketOf map, so the count/latest rule is now written once. That is what stops this class recurring, and it is worth more than the recency fix itself. The resolveEventTimestamp fallback chain is also correctly ordered — payload.sentAt before emittedAt — which matters because those two mean different things, and picking the wrong one first would have looked identical in every test you wrote.

🧭 Patch-Blind Premise Snapshot

• Inputs Read Before Patch: #16263 in full (Context, The Problem, The Architectural Reality — including its own scoping of the count: 18 half to #15825); Ada's live receipt as quoted in the ticket; current dev source of CoalescingEngineService._buildDigestEnvelope and WAKE_PRIORITY_RANKS; WakeSubscriptionService enqueue sites (:250-265), _wrapEvent (:1527-1539), and the permission_granted delivery path (:1425-1435).
• Expected Solution Shape: latest selected by maximum timestamp rather than final iteration position; a timestamp resolver preferring true event time over envelope emission time; the per-bucket duplication collapsed so the rule cannot drift between buckets; a spec that fails on the pre-fix tree with an out-of-order queue. Must not: reorder the queue itself, change count, alter priority ranking, or silently drop events whose timestamp is unresolvable.
• Patch Verdict: Matches, and improves on the expected shape in one place — collapsing the four-arm switch into bucketOf was not required by the AC and is the change that prevents recurrence.
• Premise Coherence: Coheres. #16263 correctly scopes the count: 18 anomaly out to #15825's broadcast read-state persistence rather than conflating two defects behind one receipt, and this diff respects that boundary — count behaviour is untouched.

🕸️ Context & Graph Linking

• Target Issue: Resolves #16263
• Related Graph Nodes: #16233 (working delivery, which surfaced this), #16258 (restart-cold routes — the sibling silent-wake mode), #15825 (the count half, explicitly not this PR), #16246 (degrade path on the same delivery lane)
• Origin Session ID: 713db0da-2239-44ea-ba5b-931be90d34fc

🔬 Depth Floor

Finding 1 (non-blocking, durable): "recency" has a true source in only ONE of the four buckets, and one bucket has a timestamp field the resolver ignores.

resolveEventTimestamp reads payload.sentAt, then event.emittedAt. Verified at source:

• sentAt is never set by WakeSubscriptionService — grep -c sentAt returns 0 for that file. It arrives from the mailbox message record, which is why Ada's sent_to_me receipt carried it. So sent_to_me is the only bucket with a genuine event time.
• emittedAt is wrap time, not event time — _wrapEvent sets new Date().toISOString() unconditionally at :1539. For a replay batch or restart re-walk, every event is wrapped during the walk, so their emittedAt values are near-identical and ordered by walk position. For the three non-mailbox buckets, latest therefore still resolves by position — just a different position than before.
• permission_granted has a true event-time field that the resolver does not read. :1431-1433 sets result.payload.grantedAt, with a comment stating it is "a delivery-time stamp, distinct from the envelope's emittedAt" and a documented wire-contract field. resolveEventTimestamp never consults it.

None of this makes the shipped behaviour worse than dev — for the three buckets the outcome is equivalent to the previous last-write-wins, and for sent_to_me (the reported defect) it is strictly correct. So this is not a blocker.

What I would not leave as-is is the claim. The new JSDoc says "Each bucket's latest is chosen by RECENCY (max timestamp), never by iteration position", stated unconditionally for all four. A future reader debugging a stale permission_granted pointer will trust that sentence and look everywhere except the resolver. Either narrow the sentence to name which buckets have a real event time, or add grantedAt to the chain for the bucket that has one. My preference is the second for permission_granted and the first for the remaining two, but it is your call and it is follow-up scope, not this PR's.

Nit (inline, not blocking): the guard reads

if (bucket.latest === null || ts === null || ts >= bucket.latestTs) {

The ts === null arm makes a timestamp-less event unconditionally displace a known-fresh one — position beating recency, which is the exact shape #16263 exists to remove. I traced whether it is reachable and it is not: _wrapEvent always stamps emittedAt, and Date.parse on that ISO string is always finite, so ts is never null for any envelope this service produces. It is dead-but-correct defensive code. Worth one word in the comment saying so ("unreachable while _wrapEvent always stamps emittedAt; kept as a floor"), because otherwise the next reader has to re-derive the reachability argument I just did to decide whether it is a bug.

Verified correct, for the record — I traced the predicate rather than trusting the specs:

• first event ⇒ latest === null arm, adopts, latestTs = ts;
• strictly newer ⇒ ts >= latestTs true, adopts;
• strictly older ⇒ skipped (the fix);
• equal timestamps ⇒ >= adopts the later-positioned one, a defensible tie-break and spec'd;
• latestTs seeded from null ⇒ ts >= null coerces to ts >= 0, true for any epoch, so the first timestamped event after a timestamp-less one correctly takes over.

Rhetorical-Drift Audit:

• PR/ticket claims spot-verified at source: the :392/:403/:407/:411 unconditional assignment, state.queue.push at :217 as the ordering source, and the four enqueue sites all say what the ticket says they say.
• count and priority ranking are genuinely untouched — verified in the diff, not assumed.
• No [RETROSPECTIVE] tag needed.

Findings: Pass, with the follow-up above.

🧠 Graph Ingestion Notes

• [KB_GAP]: none.
• [TOOLING_GAP]: Memory Core semantic recall remains degraded (mid-restore), so my prior-art sweep for this decision space returned unrelated rows rather than absence. I substituted direct source reads plus git grep and am naming the instrument, per the standing rule this week — an empty sweep is not clearance right now.
• [RETROSPECTIVE]: the durable lesson is which timestamp means what. This lane now has three time fields in play — payload.sentAt (true send time), payload.grantedAt (delivery stamp), emittedAt (wrap time) — and they diverge exactly under replay, which is the condition the defect appears in. A pointer that means "most recent" is only as good as the field it reads.

🎯 Close-Target Audit

• Close-target: Resolves #16263, newline-isolated
• #16263 is not epic-labeled
• Branch commits carry (#16263)

Findings: Pass.

📑 Contract Completeness Audit

• The originating ticket carries the contract in its Problem/Reality sections; the diff matches it row for row (recency selection, fallback ordering, timestamp-less behaviour preserved, count untouched).
• The bucket map is the contract made mechanical — one rule, four buckets, no per-bucket arm to drift.

Findings: Pass. Note (not blocking): the ticket has no formal Contract Ledger matrix; for a change this contained the Problem section carries it adequately.

🪜 Evidence Audit

• 6 new specs covering out-of-order (Ada's shape), arrival-order regression, equal-ts, no-ts fallback, emittedAt fallback, and all four buckets — the last is what pins the bucket-map refactor.
• The out-of-order spec is the one that fails on pre-fix dev; the arrival-order spec is the regression guard that would catch an over-correction.
• 28/28 reported; CI CLEAN at review time.
• No L2→L3 promotion: nothing here claims a live-plane property. Correct, and worth stating explicitly — live readback is impossible today regardless, since the running plane is c2304ea118, 15 merged PRs behind dev, so this fix will not be observable in production until a rebuild. That is not this PR's problem, but do not let a "verify on the live digest" request block merge.

Verified against the PR head with CI CLEAN. Approving; the follow-up is yours to file or fold into the wake-timestamp lane as you see fit.

📋 Required Actions

No required actions — eligible for human merge.

The recency-source finding in Depth Floor is a follow-up, not a gate: the shipped behaviour is strictly better than dev for the reported defect and never worse for the other three buckets. Iris's call whether to narrow the JSDoc or extend resolveEventTimestamp to grantedAt.

📊 Evaluation Metrics

Verdict weights: 30% premise / right thing, 30% architecture + placement, 30% diff correctness, 10% AC/audit sanity.

• [ARCH_ALIGNMENT]: 92 - Correct layer: the pointer is computed where the digest is built, not pushed onto producers, so no enqueue path had to change. Collapsing the four-arm switch into bucketOf removes the drift surface rather than patching four copies. -8 only because the recency source still differs per bucket while the dispatch no longer does.
• [CONTENT_COMPLETENESS]: 95 - JSDoc states the recency rule and the timestamp-less fallback; the resolver documents its precedence order. Gap: the rule is stated unconditionally for all four buckets.
• [EXECUTION_QUALITY]: 95 - Predicate traced by hand across five orderings; fallback precedence (sentAt before emittedAt) is the non-obvious call and it is the right one.
• [PRODUCTIVITY]: 100 - Filed, fixed, spec'd and opened same-day off a live receipt.
• [IMPACT]: 85 - latest is the field an agent reads to decide act-or-ignore; it was misleading on exactly the enablement/restart days when it matters most.
• [COMPLEXITY]: 45 - Contained: one resolver, one loop, no cross-service contract change.
• [EFFORT_PROFILE]: Quick Win - Small diff, high signal-value, no blast radius beyond the digest envelope.

Approving. The bucket map is the part that stops this class recurring.