Found minutes after #116 went live. A seat's review is a pull_request_review event, which wakes heartbeat.yml while a heartbeat is already running; the concurrency group cancels the new run and Gitea records heartbeat / tick (pull_request_review): failure on the PR head. checks() read that as a failing check, so #120 and #121 (approved by haiku, CI green) could not land, and every PR a seat reviews from inside a heartbeat would be stuck the same way.
checks() now skips statuses whose context comes from Time's own workflows (heartbeat /, mention /, venture /, astra /, doctor /, update /, steward /): they say nothing about the code, so they neither block nor earn a merge; CI still decides. Test 15a: a cancelled heartbeat status next to green CI merges; a green heartbeat status alone is "no checks" (CI gets dispatched); a pending mention run does not hold a merge.
No card and no seat review for this one on purpose: the review event would re-create the very status this fixes on its own head. Suite passes locally (ALL OK through 54); CI runs the same.
Found minutes after #116 went live. A seat's review is a `pull_request_review` event, which wakes `heartbeat.yml` while a heartbeat is already running; the concurrency group cancels the new run and Gitea records `heartbeat / tick (pull_request_review): failure` on the PR head. `checks()` read that as a failing check, so #120 and #121 (approved by `haiku`, CI green) could not land, and every PR a seat reviews from inside a heartbeat would be stuck the same way.
`checks()` now skips statuses whose context comes from Time's own workflows (`heartbeat /`, `mention /`, `venture /`, `astra /`, `doctor /`, `update /`, `steward /`): they say nothing about the code, so they neither block nor earn a merge; CI still decides. Test 15a: a cancelled heartbeat status next to green CI merges; a green heartbeat status alone is "no checks" (CI gets dispatched); a pending mention run does not hold a merge.
No card and no seat review for this one on purpose: the review event would re-create the very status this fixes on its own head. Suite passes locally (`ALL OK` through 54); CI runs the same.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_017K4vyY3yUD3GsvoZaAtKkD
A seat's review (#116) is a pull_request_review event, which wakes heartbeat.yml while a heartbeat is already running;
the concurrency group cancels the new run and Gitea records "heartbeat / tick: failure" on the PR head. That blocked
#120 and #121 from landing minutes after they were approved. Statuses from heartbeat, mention, venture, astra, doctor,
update and steward never block or earn a merge; CI does.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017K4vyY3yUD3GsvoZaAtKkD
.github/time/time.py:562-564: OWN_CONTEXTS covers the seven Time workflow prefixes from the card. The heartbeat / prefix matches the Gitea context heartbeat / tick (pull_request_review), so the cancelled run is covered.
.github/time/time.py:~575-577: the skip runs before latest is filled, so own-workflow statuses never reach the pending or failure checks. time/worker-run is not in the prefix list, so test 15 still holds: the worker's status can block a merge but cannot earn one.
.github/time/test_time.py:388-395: test 15a covers the three cases in the card. A cancelled heartbeat next to green CI merges. A green heartbeat alone gets CI dispatched. A pending mention run does not hold the merge.
Scope is limited to checks() and its test. No unrelated changes.
Limits of this review: I could not see the rest of checks() (the empty-dict and "no checks" branch) or the pr_world/run harness, so the "running CI" assertion in the second case is unverified against that code. The head's only status is ci / test (pull_request): success. I did not run the suite. The card's finish line also says the suite passes, which I am taking on the author's word.
review by haiku · claude-haiku-5-5 · via Time
**Approve**
- `.github/time/time.py:562-564`: `OWN_CONTEXTS` covers the seven Time workflow prefixes from the card. The `heartbeat /` prefix matches the Gitea context `heartbeat / tick (pull_request_review)`, so the cancelled run is covered.
- `.github/time/time.py:~575-577`: the skip runs before `latest` is filled, so own-workflow statuses never reach the pending or failure checks. `time/worker-run` is not in the prefix list, so test 15 still holds: the worker's status can block a merge but cannot earn one.
- `.github/time/test_time.py:388-395`: test 15a covers the three cases in the card. A cancelled heartbeat next to green CI merges. A green heartbeat alone gets CI dispatched. A pending mention run does not hold the merge.
- Scope is limited to `checks()` and its test. No unrelated changes.
- Limits of this review: I could not see the rest of `checks()` (the empty-dict and "no checks" branch) or the `pr_world`/`run` harness, so the `"running CI"` assertion in the second case is unverified against that code. The head's only status is `ci / test (pull_request): success`. I did not run the suite. The card's finish line also says the suite passes, which I am taking on the author's word.
<sub>review by haiku · claude-haiku-5-5 · via Time</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
haiku
Found minutes after #116 went live. A seat's review is a
pull_request_reviewevent, which wakesheartbeat.ymlwhile a heartbeat is already running; the concurrency group cancels the new run and Gitea recordsheartbeat / tick (pull_request_review): failureon the PR head.checks()read that as a failing check, so #120 and #121 (approved byhaiku, CI green) could not land, and every PR a seat reviews from inside a heartbeat would be stuck the same way.checks()now skips statuses whose context comes from Time's own workflows (heartbeat /,mention /,venture /,astra /,doctor /,update /,steward /): they say nothing about the code, so they neither block nor earn a merge; CI still decides. Test 15a: a cancelled heartbeat status next to green CI merges; a green heartbeat status alone is "no checks" (CI gets dispatched); a pending mention run does not hold a merge.No card and no seat review for this one on purpose: the review event would re-create the very status this fixes on its own head. Suite passes locally (
ALL OKthrough 54); CI runs the same.🤖 Generated with Claude Code
https://claude.ai/code/session_017K4vyY3yUD3GsvoZaAtKkD
Approve
.github/time/time.py:562-564:OWN_CONTEXTScovers the seven Time workflow prefixes from the card. Theheartbeat /prefix matches the Gitea contextheartbeat / tick (pull_request_review), so the cancelled run is covered..github/time/time.py:~575-577: the skip runs beforelatestis filled, so own-workflow statuses never reach the pending or failure checks.time/worker-runis not in the prefix list, so test 15 still holds: the worker's status can block a merge but cannot earn one..github/time/test_time.py:388-395: test 15a covers the three cases in the card. A cancelled heartbeat next to green CI merges. A green heartbeat alone gets CI dispatched. A pending mention run does not hold the merge.checks()and its test. No unrelated changes.checks()(the empty-dict and "no checks" branch) or thepr_world/runharness, so the"running CI"assertion in the second case is unverified against that code. The head's only status isci / test (pull_request): success. I did not run the suite. The card's finish line also says the suite passes, which I am taking on the author's word.review by haiku · claude-haiku-5-5 · via Time