[maxigimenez]

Follow-up to #52, which was necessary but not sufficient. A pr_review_requested route matching reviewersAdded still could not fire for the case that actually occurs in practice.

The evidence

PR #408 created   13:19:18   by JamesAIBot
review requested  13:19:21   EomiAIBot

Three seconds apart. The runner's first ever sighting of that pull request already had the reviewer attached, so first sight suppressed the transition, seeded the baseline, and the route went quiet forever. Confirmed against the live runner:

gs-racing-tech/tracksidecc#408 | ["EomiAIBot"] | 2026-09-07 16:29:23

Every transition empty, and no way back.

This is the dominant shape in a bot-to-bot workflow, and it isn't exotic otherwise — filling in the reviewer field on the Create pull request form does the same, as does filing a ticket with its label already on.

The fix

"I have never seen this" and "this did not exist" are different facts, and conflating them is what made the whole class of route impossible. Staying quiet is right for backlog — otherwise creating a route fires it across everything currently open — and wrong for an item created since the last poll, where everything on it really was just added.

• project_watch holds a per-project watermark: the newest item-creation timestamp seen. Anything newer came into existence while we were watching.
• Both sides of that comparison are the provider's clock, deliberately. Comparing GitHub's timestamps against this machine's would make a runner with a slow clock replay its backlog.
• Read once per cycle and advanced after it, so two items opened between the same pair of polls cannot silence each other by ordering. Monotonic, because a reopened item can arrive older than one already seen.
• Set on a project's first cycle, so everything open at that moment is backlog and stays quiet. That is the guard working, not a gap.
• TriggerEvent.createdAt carries the fact — created_at on GitHub issues and pulls, createdAt on Linear issues. It is never matched on.

One implementation

observeCycle now owns the per-cycle observation step, called by the poll loop and driven directly by the tests. Both bugs on this branch shipped past a green suite whose helpers re-implemented that loop, and the unit tests handed changes to the rule engine directly — so neither could see that the real pipeline never produced it.

Covered

Fires for a PR born since the last poll · stays quiet for one that predates the first look · does not re-fire on later cycles · lets two PRs opened between the same polls both fire · does not replay a twenty-PR backlog on a project's first cycle · does not treat an older PR as new once the watermark has moved. Plus the watermark's own monotonicity and per-project isolation, and that sentinel0 explain reports the new-item verdict without moving the watermark.

572 tests pass across all five packages; lint and build clean.

Deploying

The watermark is empty on first boot, so the current backlog stays quiet — including PR #408, which is waiting on a review right now. Re-request the review on it to arm it. PRs opened after that first cycle fire on their own.

Releases 0.0.6.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QNEqbFkMFoPiiVnJGxpjj2