fix(client-runtime): keep a warm thread un-settled despite a merged/closed PR

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9

[t3dotgg]

Problem

Sending a message in a settled thread should un-settle it. Two of the three settle signals already behaved:

• Explicit override — the server decider prepends thread.unsettled when thread.turn.start hits an overridden thread (decider.ts).
• Inactivity auto-settle — the new message refreshes threadLastActivityAt.

But the merged/closed-PR auto-settle signal in effectiveSettled is client-derived and never clears. Send a message in a merged-PR thread and the row un-settles only while the queued-turn grace / live-session blockers hold — the moment the turn completes, changeRequestState === "merged" classifies it right back into the settled tail. This also defeats the server's un-settle on explicitly settled threads whose PR is merged: the override clears on send, then the merge signal re-settles the row anyway.

Fix

Gate the change-request signal on idleness: a merged/closed PR settles a thread only after it has been quiet for CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour). Fresh activity — the sent message, its turn starting and completing — keeps the follow-up conversation in the active list; once the burst goes stale, the merge signal settles it again. This mirrors the decider's own "activity clears overrides so the thread can auto-settle again after this burst of work goes stale" model.

Web (SidebarV2.tsx) and mobile (threadListV2.ts) both partition through the shared effectiveSettled, so one change covers both clients. No contract or server changes: the VCS status contract carries no merge timestamp, so idle-based gating is the clean option.

The explicit Settle action on a warm merged-PR thread still works — a user settle sets settledOverride, which is checked before the merge signal.

Testing

• New test: a warm thread (recent activity) stays active under both merged and closed PR states; an idle one still settles.
• Full client-runtime suite passes (449 tests), mobile threadListV2 tests pass, lint and typecheck clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Client-only list-partitioning logic in shared effectiveSettled; behavior is narrower (fewer surprise re-settles) with targeted tests and no server/contract changes.

Overview
Fixes merged/closed PR threads snapping back to settled right after a follow-up message’s turn finishes. effectiveSettled used to treat merged/closed change requests as an always-on settle signal, so activity blockers only briefly kept the row active.

Merged/closed PRs now auto-settle only when threadLastActivityAt is missing or older than CHANGE_REQUEST_SETTLE_IDLE_MS (1 hour) relative to now. Recent follow-ups stay in the active list; after the burst goes idle, the merge signal settles the thread again. Explicit settled / active overrides and existing activity blockers are unchanged.

Tests cover warm vs idle boundaries for merged and closed, and re-settling once the idle window passes.

^{Reviewed by Cursor Bugbot for commit 3cea3f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep warm threads active despite merged/closed PR until idle for one hour

• Previously, effectiveSettled would auto-settle a thread as soon as its change request reached merged or closed state, even if the thread had recent activity.
• Adds a CHANGE_REQUEST_SETTLE_IDLE_MS constant (1 hour) in threadSettled.ts; a thread now only auto-settles if lastActivityAt is older than now - 1h (or absent).
• Behavioral Change: threads with a merged/closed PR that receive post-merge activity will remain unsettled for up to one hour after the last activity.

^{Macroscope summarized 3cea3f9.}

Summary by CodeRabbit

• Bug Fixes
  • Threads associated with merged or closed change requests now remain active during follow-up activity.
  • Threads automatically settle after at least one hour of inactivity, preventing premature status changes.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: client-runtime settlement now stays active for warm merged/closed PR threads.
Description check	✅ Passed	The description explains what changed, why, and testing, but it does not follow the repo's requested section headings or checklist format.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/unsettle-thread-on-message

---

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

[macroscopeapp]

Approvability

Verdict: Approved

This is a targeted bug fix for thread settling logic on merged/closed PRs. The change adds an idle guard to prevent threads from immediately re-settling after follow-up activity. The author owns this code, the scope is limited, and comprehensive tests are included.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate ca5b817

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/client-runtime/src/state/threadSettled.ts`:
- Around line 107-114: Update the lifecycle documentation comment above the
settled-resolution logic to clarify that pending work and unadjudicated queued
turns are evaluated before explicit settled or unsettled overrides. Replace the
claim that overrides “win in both directions” with wording that accurately
reflects these blockers taking precedence, while preserving the existing
override behavior after blockers clear.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b1ae8f2c-80fb-4fb9-aeec-55962715db89

📥 Commits

Reviewing files that changed from the base of the PR and between 9a0a071 and ca5b817.

📒 Files selected for processing (2)

• packages/client-runtime/src/state/threadSettled.test.ts
• packages/client-runtime/src/state/threadSettled.ts

Dismissing prior approval to re-evaluate 3cea3f9