fix(t3x): auto-resume never fired — 'thread-advanced' false cancellation on settled turns by radroid · Pull Request #9 · radroid/t3code

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid · 2026-07-25T12:29:36Z

Fixes#6.

What was broken

Every real-world auto-resume was cancelled at wake time with "Auto-resume cancelled: thread-advanced." — observed 3/3 on 2026-07-25 (threads 33c06a5a, 8f31df69, bb66acc2, all cancelled within 2s of their shared window reset), and the durable state showed firedAtMs: [] everywhere: the feature had never successfully fired.

Root cause

ProjectionSnapshotQuery.getSnapshot() reads threads from the SQLite projection, where latestTurn is joined on projection_threads.latest_turn_id — a column populated only while a turn is active. A usage limit normally lands mid-turn, so the guard baseline captures the running turn's id; by wake time the turn has settled and the snapshot reports latestTurn: null. The guard

if((thread.latestTurn?.turnId??null)!==baseline.latestTurnId)return"thread-advanced";

read null !== "<turnId>" as advancement and cancelled — then nothing ever re-armed, because an idle thread emits no further rejection events.

The fix

thread-advanced now requires positive evidence — a different, non-null turn id:

constcurrentTurnId=thread.latestTurn?.turnId??null;if(currentTurnId!==null&&currentTurnId!==baseline.latestTurnId)return"thread-advanced";

null at fire time means "no active turn", the expected state after a settled limit. Genuine user takeovers remain covered by user-took-over (checked first, keyed on the newest user message); active work remains covered by progressing. Known residual: an auto-started turn that both runs and settles during the wait with no user message is no longer detected via turn id — acceptable against a guard that previously cancelled 100% of legitimate resumes.

Testing

New unit case (guards.test.ts): fire-time latestTurn: null vs non-null baseline → no cancellation; plus the converse (baseline null, turn present → still cancels).
New integration case (Reactor.test.ts): replays the production incident — rejection arrives mid-running-turn, thread settles to latestTurn: null + session stopped during the wait, wake must dispatch exactly one resume turn and post no thread-advanced note.
Both verified to fail against the unfixed guard (stash-run-restore), then pass with the fix.
Full src/t3x/autoResume suite: 69/69 across 4 consecutive runs. pnpm typecheck output identical to main (two pre-existing non-error diagnostics in untouched files).
Diagnosis evidence (timeline, event-store replay, live DB columns) recorded in Auto-resume never fires in practice: 'thread-advanced' false cancellation when the limited turn settles during the wait #6.

🤖 Generated with Claude Code

…d turn settles The projection populates projection_threads.latest_turn_id only while a turn is active, so a usage limit that lands mid-turn captures the running turn's id in the guard baseline — and by wake time (turn settled, session idle) the snapshot reports latestTurn: null. cancelReason treated that null as evidence the thread had advanced and cancelled the pending resume, which killed every real-world resume (observed 3/3 on 2026-07-25; firedAtMs was empty across all threads — the feature had never fired). Advancement now requires positive evidence: a different, NON-NULL turn id. Null means "no active turn" — the expected state after a settled limit. User takeovers stay covered by the user-took-over guard (checked first) and active work by the progressing guard. Regression coverage: a guards.test.ts unit case (null-at-fire vs non-null baseline must not cancel) plus a Reactor.test.ts integration case replaying the production shape (schedule mid-running-turn, settle to latestTurn: null, assert the resume fires with no thread-advanced note). Both verified to fail against the previous guard. Fixes#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-07-25T12:29:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9a36a907-aa9f-4ca4-bf0e-1e8885209e18

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3x/fix-thread-advanced-false-cancel

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

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

Closes#39. Two defects compounded into a permanently stranded thread: a usage limit armed a resume, the user typed "keep going" at the banner, that message was itself rejected so it started nothing, and the wake tick then threw the arm away as `user-took-over`. Net pending afterwards: zero. Measured on the reporting install at 4 of 17 armed resumes (~24%) since #6. 1. `guards.ts` — drop the `user-took-over` branch. It is the same negative-evidence mistake #6 fixed on the line below it: "a message exists that wasn't there when we armed" is not evidence the human took the wheel, and in practice it is the opposite signal. Everything the branch reached for is still covered — `progressing` (actively driving), `awaiting-input` (blocked on a prompt), `thread-advanced` (a different live turn), and the per-thread switch for "stop entirely". `baseline.newestUserMessageId` stays: it is part of the persisted record, it is re-captured on every (re)schedule, and it is what makes a stranded arm diagnosable from the state file. 2. `decide.ts` — narrow `already-pending`. A rejection naming a CONCRETE reset time later than the pending one now supersedes it instead of being dropped, so a `seven_day` limit landing on an armed `five_hour` no longer leaves the arm firing into a window that is still shut. Restricted to `windowOpensInFuture` on purpose: a ladder-derived time is `nowMs + delay`, so it is later on every telemetry re-emit, and letting those supersede would push the arm out forever and flood the timeline. An earlier reset never supersedes either — the existing arm is already the conservative choice. A supersede re-writes the record with a fresh `captureBaseline`, so it is also the re-arm path, and posts a distinct `t3x.auto-resume.rescheduled` note rather than a second "scheduled". The issue's third item — detecting the org monthly spend limit — is a genuinely separate feature (no `account.rate-limits.updated` path reaches it at all) and is deliberately not in scope here, per the triage. Tests: 4 new behavioural cases, each verified to fail against the old code — guards (a newer user message does not cancel; it still cancels when that message is actually being worked on), decide (supersede, earlier-window no-op, ladder-churn guard), and two reactor integration tests covering the reported shape end to end. Reactor suite run 12x for flake. `docs/t3x/loop/DESIGN.md` §6 gets a dated note: guard #9 still stands, but the hazard it was defending against is gone.

radroid merged commit 237ca66 into mainJul 25, 2026
1 check passed

radroid deleted the t3x/fix-thread-advanced-false-cancel branch July 25, 2026 12:56

radroid mentioned this pull request Aug 2, 2026
[Feature]: Self-paced loops — the Claude binary can already wake a T3 thread; surface it, bound it, and give models a durable T3-native wake_me instead #42
Open
3 tasks

radroid mentioned this pull request Aug 11, 2026
fix(t3x): stop a user message destroying a pending auto-resume #80
Merged