fix(server): settle threads at startup without waiting on GitHub

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}

[StiensWout]

Since #8600 made settlement server-owned, the first snapshot after a restart could show threads as active until the initial settlement sweep landed. The earlier version of this PR fixed that by holding startup until the sweep finished, which put a GitHub round trip per branch on the startup path.

The sweep now persists its last pull request answer per lookup key in settlement-lookups.json and runs in two phases. The local phase decides branchless threads and threads with a persisted answer, then signals readiness so startup can accept commands. The network phase refreshes every lookup in the background and only re-decides groups whose answer is new or changed. A sweep that dies before its local phase still signals readiness, so startup can never hang on it.

Verified with the settlement reactor, orchestration reactor, and startup tests, server typecheck, lint, and formatting.

Changes and PR text by Claude Fable 5.1 in T3 Code with the Claude Code harness.

---

Note

Medium Risk
Changes orchestration startup ordering and introduces on-disk settlement cache that affects auto-settle behavior across restarts; failures degrade to warnings but incorrect cache could delay or skew settlement until network refresh.

Overview
Thread settlement no longer blocks startup on GitHub. The first sweep runs in two phases: a local phase settles branchless threads and any thread whose PR state was cached from a prior run, then signals ready; a network phase refreshes lookups in the background and only re-settles when answers change.

PR lookup results are persisted under settlement-lookups.json (new settlementLookupsPath in server config), loaded at reactor start and written atomically after sweeps with stale keys pruned.

Startup gains a reactors.ready phase that awaits OrchestrationReactor.ready (delegated from ThreadSettlementReactor.ready) before opening the command gate, so the first client snapshot reflects local settlements without waiting on network. Failed sweeps still unblock ready via Effect.ensuring.

Tests and integration mocks were updated for ready; new reactor tests cover early readiness, restart from cache, and readiness when projection read fails.

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

Note

Add local-phase thread settlement to 'ThreadSettlementReactor' at startup

• Splits the ThreadSettlementReactor.ts sweep into a local phase and a network phase. The local phase settles branchless threads and threads with persisted pull request lookups before resolving a new ready effect.
• Persists pull request lookup answers to settlement-lookups.json via the new settlementLookupsPath config field, so settlements survive restarts.
• Server startup in serverRuntimeStartup.ts now awaits orchestrationReactor.ready before accepting commands.
• Behavioral Change: Server startup blocks on the local settlement phase instead of network lookups. ready always resolves via Effect.ensuring, even if the sweep fails before the local phase.

^{Macroscope summarized 395ccff.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production startup ordering and adds a persistent settlement cache, allowing cached decisions to affect the first snapshot while network refreshes continue asynchronously. The cross-component readiness coordination and restart-sensitive state make this broader than a small, isolated bug fix.

^{You can add or adjust custom eligibility rules. Learn more.}