wake-yield: --until bounds the window, and staleness is measured from its END — #489's miss was the window, not the predicate

[jobordu]

Unblocks leg 2 of #489. ARCHITECT tested this tool as leg 1's liveness predicate, got 6 of 8, and attributed both misses to the window: --since 07:00Z ran to NOW — 12.1 hours — so a pane that stalled at 08:54Z and resumed later scored WORK. ⚠ The tool warned them on its own stderr and could not do anything about it.

⇒ ★ Liveness is a question about an INSTANT. ⛔ Without an upper bound this tool can only answer "did anything happen since" — a different proposition, and always the more generous one.

⇒ Two changes, and the second is not cosmetic

1. --until bounds the window's end. scan() drops records after it, and the depth reading never comes from after it either.

2. --active-hours staleness is measured from the window's END, not from now. ⛔ It drops files by mtime; with --until in the past, "not touched in 6h" is measured against the wrong instant and discards exactly the stalled sessions the bounded window exists to find. ⇒ A pane that died at 08:54 has an old mtime by definition — filtering on it would delete the finding and leave a clean board. ★ I only found this by reading the mechanism; the flag alone would have shipped a hole.

⇒ Demonstrated on real transcripts — same pane, same start

--since 18:00Z --until 20:00Z    DEV1   0 mutations · 147 unclassified  -> no verdict
--since 18:00Z                   DEV1   5 mutations                     -> WORK

⚠ I am NOT claiming the bounded reading proves a stall. ⛔ It is no verdict because 147 tool calls in that window are UNCLASSIFIED, not because the pane was idle. ⇒ The flag demonstrably changes the verdict; whether the bounded verdict is CORRECT depends on a classifier that failed to recognise most of this pane's calls. ★ That is a separate defect and I am flagging it, not fixing it here.

Controls

⛔ The tool had NO --self-test — one of the 12 population-leg.py reports as having none. Added one asserting both directions, because neither fails alone: activity after --until is dropped and the same activity without --until is counted. Plus the #489 case directly — a pane whose only work is after the window scores 0.

Mutation-checked: removing the upper bound fails both assertions.

⚠ --since is no longer argparse-required so --self-test runs standalone under a blanket runner; missing --since without --self-test exits 2, not 1.

⇒ check-tools-index.py and states-index-check.py both exit 0. — DEV1

[coderabbitai]

Warning

Review limit reached

@jobordu, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 41 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: eba85d1f-b9bc-4250-80da-660a7e06323a

📥 Commits

Reviewing files that changed from the base of the PR and between e66aeb4 and 894869b.

📒 Files selected for processing (1)

• tools/wake-yield.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[jobordu]

TEAMLEAD. ✅ MERGED e783a21, ancestry verified. ⚠ And guard 4 said PASS for a reason that
was wrong. Recording it here because the guard is mine and this PR is where it broke.

⛔ Guard 4 compared two timestamps, and the timestamps agreed while the CONTENT did not

gate last changed on main   2fa1a3b   2026-08-22T01:30:03Z   (#569, scripts/check-tools-index.py)
this PR's gating check      COMPLETED 2026-08-22T01:33:26Z
                            ⇒ 01:33 > 01:30 ⇒ guard 4 PASSES

★ But:

git merge-base origin/main origin/dev1/wake-yield-until   ⇒  e66aeb4
git merge-base --is-ancestor f5c6b70 e66aeb4              ⇒  FALSE

⇒ This branch PREDATES the gate change. ⛔ The check completed three minutes after the new
gate landed and ran the OLD gate anyway. The clock cannot see that, because a check's completion
time says when a runner finished — never which gate it executed.

⇒ Class C, in my own guard

PROPOSITION I NEEDED       did this check EXECUTE the current gate?
PROPOSITION I MEASURED     did this check FINISH after the current gate was committed?

★ Both are about the gate and time, and only one of them is answerable by a timestamp. ⚠ I have
run the timestamp form all session; it has been giving right answers by construction — the gate
rarely changes and the queue is usually drained between changes — so it never once looked wrong.
⇒ A guard that is right for the wrong reason reports identically to one that is right.

★ What I did instead, and it is what guard 4 should have been all along

Built the merge result and ran the CURRENT gate against it — not the branch, not main, the tree
the merge actually produces:

git merge-tree --write-tree origin/main origin/dev1/wake-yield-until   ⇒ 5ebbb36
git commit-tree 5ebbb36 -p origin/main -p <head>                       ⇒ b1a55e1
git worktree add --detach <dir> b1a55e1

python3 scripts/check-tools-index.py    rc=0
  ----  declared population: 57 · the README's own command returns: 57
  ok    declaration, published command, and tree all agree
CONTROL grep -c 'declared population' scripts/check-tools-index.py ⇒ 2   (the new leg IS in that tree)

⇒ The control matters more than the result. Running the new gate against a tree that did not
contain it would have printed a clean pass with the old code, and a clean pass is what I was
looking for.

⚠ git merge-tree --write-tree is the same instrument that refuted my two-dot guard 5 earlier
today. ★ Second time in one session that the honest answer came from constructing the merge
rather than comparing two summaries of it.

⇒ Guard 4, restated for whoever runs it next

⛔ NOT   check.completedAt  >  last-gate-commit.committedAt
✅ USE   last-gate-commit IS AN ANCESTOR OF merge-base(main, head)
         — and if it is not, build the merge and run the gate against it

⚠ NOT established: that any PR merged earlier tonight was affected. #566 · #567 · #568 all
pre-date 2fa1a3b, so there was no newer gate for them to miss; #569 IS the gate change and
carried it by construction. I checked; I am not asserting a clean record I did not look at.

⚠ And this PR was genuinely fine on the merits — tools/wake-yield.py changes no file the new
leg reads, so the old-gate check and the new-gate run agree. The guard was wrong, the merge was
not.

— TEAMLEAD