perf(server): reduce streaming projection overhead

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.

[t3-code]

What Changed

• append streaming deltas atomically in SQLite instead of reading and rewriting the full accumulated message
• skip unchanged thread shell and turn/session projection work for later chunks while still advancing thread activity and projector checkpoints
• process an event's projections in one nested transaction instead of opening one per projector
• let unparked reactors establish hot-stream subscriptions before startup continues
• add focused coverage for streaming append and replay/resume behavior

version	3-run median	ms/chunk	chunks/sec
baseline	188.0 ms	1.88	~532
this PR	127.0 ms	1.27	~787
change	32.4% less time	32.4% less	+48%

The local benchmark used 100 streamed "token " chunks plus completion with the same harness before and after the change.

Why

Each streamed delta was paying for a full-message read and full-text rewrite, thread shell summary queries, repeated turn/session writes, and a nested transaction for every projector. That work grows unnecessarily along the token-by-token hot path.

Verification

• 5 focused test files, 117 tests
• formatting checks on all changed files
• git diff --check
• independent correctness, data integrity, and performance reviews

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there are no UI changes
• Video is not applicable because there are no interaction changes

Built with OpenAI via T3bot in T3 Code.

---

Note

Medium Risk
Changes orchestration projection semantics and transaction boundaries on the streaming hot path; incorrect append or checkpoint logic could corrupt read models, though behavior is covered by focused tests.

Overview
Streaming assistant tokens no longer read the full message and rewrite thread shell summaries on every chunk. Message deltas use SQLite appendStreaming (text || excluded.text) while preserving created_at; streaming assistant events only touchUpdatedAt on the thread row. Later chunks skip turn projection rewrites once the assistant message is already linked.

Live projection runs all projectors for one event inside a single nested transaction (with per-projector projection_state updates), then applies attachment side-effects after commit (failures log as warnings). forkParked yields once when activation is unset so hot-stream children can subscribe before startup continues.

Tests cover atomic streaming append, resume/replay with streaming timestamps, and unparked fork behavior.

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

Note

Reduce streaming projection overhead by skipping redundant writes on streaming message chunks

• Streaming assistant messages now call touchUpdatedAt on ProjectionThreadRepository instead of rewriting the full thread shell, and appendStreaming on ProjectionThreadMessageRepository atomically appends text chunks server-side while preserving created_at.
• Subsequent streaming chunks for the same assistant message no longer rewrite the turn row once the association is established.
• All projectors for a single event now run inside a database transaction; attachment side-effects run post-commit with failures logged as warnings rather than thrown.
• forkParked in serverActivation.ts now yields once after forking when no activation is present, letting the child reach its first suspension point before startup continues.
• Behavioral Change: projection_state is now updated per-projector after each apply, and SqlError is mapped via catchTags instead of the previous error handling path.

^{Macroscope summarized 83b003f.}

[macroscopeapp]

Effect service conventions review: two issues in apps/server/src/orchestration/Layers/ProjectionPipeline.ts. The new repository operations (appendStreaming, touchUpdatedAt) follow the existing persistence layer conventions and are covered by focused tests.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new code paths for streaming message projection, including atomic SQL concatenation, transaction wrapping for projectors, early-returns that skip shell summary refresh, and startup timing changes. These are significant structural changes to streaming pipeline infrastructure that warrant human review.

No code changes detected at 83b003f. Prior analysis still applies.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−46 B (−0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	−2 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.8 KiB	−44 B (−0.7%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.6 KiB	−88 B (−0.2%)	66.4 KiB	✅
Codex	Live turn messages	16	14	−2 (−12.5%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	−38 B (−0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.8 KiB	5.8 KiB	−43 B (−0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.5 KiB	−88 B (−0.2%)	66.4 KiB	✅
Claude	Live turn messages	16	14	−2 (−12.5%)	21	✅

Baseline: a20923c · PR result: 83b003f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this because #9032 merged the narrow part we wanted. Streaming deltas now append text in SQLite without reading and rebuilding the full message. The replacement PR credits this PR as the source of that approach.

We intentionally left the broader transaction, startup scheduling, thread-row, and turn-row changes out to keep the final change small. Those parts did not merge through #9032.