sync(upstream): merge upstream/main 6b73b3def into fork/dev

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

[omegent-app]

Adopts upstream through 6b73b3def, headlined by pingdotgg#5493 "paginate thread loading with
user-anchored turn windows" — 2,093 insertions plus a keyset-index migration.

Important

Merge with a merge commit, not squash. Squashing collapses the second parent and discards
upstream's commits as ancestors — the thing that keeps "commits behind upstream" honest.

The candidate question, settled with evidence

pingdotgg#4018 (getThreadActivities) is superseded — upstream never merged it and ships
loadOlderTurns instead. And the check you suggested surfaced more: pingdotgg#3510 (mobile paging) is
partially superseded too — its mobile scroll-up half is exactly the scaffolding this merge
removes, while its server bounded-replay half in OrchestrationEngine stays active.

Both are recorded in .github/upstream-candidates.json (superseded / partially-superseded,
with what replaced them and what remains).

The server RPC stays. Deployed mobile builds still call orchestration.getThreadActivities;
the RPC, schemas and window constant are kept as a marked compatibility surface. Remove once no
fleet mobile build predates this merge.

On "undo the candidate first": it would have shrunk the 24 textual conflicts, but not the real
blockers — those were upstream's new code meeting fork-added fields/services, which exist regardless.

What the resolutions actually involved

All 24 textual conflicts went to upstream. The expensive part was what git auto-merged wrong or
left dangling — found by typecheck and tests, never by conflict markers:

Where	Defect	Resolution
threads.ts	upstream's applyItemLocked header welded onto the fork's batch-reducer body, referencing an out-of-scope variable and silently dropping upstream's synchronized branch	fork batching layer removed (+2 tests); upstream body restored
threads.ts	fork's load-once HTTP fallback guard lost	reimplemented on upstream's model; its regression test passes
ws.ts	fork reuseBaseBranch flow vs upstream pingdotgg#5556 no-origin fallback — neither alone compiled	combined; upstream's new fallback test given the projection stub the fork's bootstrap wait requires
ProjectionSnapshotQuery	upstream's windowed message SQL missing fork source_json → every windowed read failed decode; bounded query destructured 9 results from 7 queries	column added; fork's queued-messages + pending-turn-start members restored
web/mobile UI	prop/rename skews (selectedThreads, WorkspaceTarget, routeServerThreadShell, queue props)	reconciled per owning side
migrations	ledger fixtures drifted by upstream's 037	extended; fork 037 lives in t3_fork_sql_migrations, no collision

fork/tim

fork/tim touches threads.ts, ProjectionSnapshotQuery and contracts/orchestration — the same
surface — but no tim commit is merged upstream, so nothing tim-authored is superseded. Review
those diffs with tim provenance in mind; tim-derived behaviour with tests is green.

Verification

• Full recursive typecheck clean across 17 packages.
• 2,269 tests pass (2,281 collected), including upstream's 11 pagination and 7 windowed-detail
  tests, the fork's five bootstrap replay/reuse tests, and the terminal-failure and load-once
  regression tests. Single failure is the pre-existing CodexTextGeneration launch-args one,
  reproducible on unmerged fork/dev.
• Adversarial reviews by grok-4.5 and gpt-5.6-sol over the git show --cc resolution
  surface: findings below.

Adversarial review findings & dispositions

grok-4.5 — 1 HIGH, 1 MED, all other categories explicitly clear:

Finding	Disposition
HIGH — fork's bootstrap replay/reuse block dropped in ws.ts: worktreeAlreadyPrepared declared and read but never set; a replayed bootstrap would re-run git worktree add -b and fail on the existing branch; the five fork tests locking this in were deleted	Fixed. Full replay/reuse block restored (projected-shell lookup → reuse existing worktree / recreate at the recorded branch), all five fork bootstrap tests re-inserted and passing alongside upstream's no-origin test. Restoring it also exposed that the merged code checked remoteExistsbefore the reuse short-circuit — now evaluated lazily, so the reuse path never touches the remote
MED — MessagesTimeline.test.tsx lost the fork's positive load-control assertions; remaining test would pass with the control deleted	Fixed. Positive assertions added for upstream's "Load earlier turns" / "Loading earlier turns…" header states

gpt-5.6-sol — 4 HIGH, 3 MED, 1 LOW claimed; each verified against the tree:

Finding	Disposition
HIGH — setDeleted() on terminal subscription failure runs outside applyLock, racing older-page merges; every other history rewrite is serialized by that lock	Confirmed weld, fixed. Upstream only calls setDeleted from inside applyItemLocked; the fork's terminal path now takes the lock too
HIGH — fork's 500-activity truncation applied to upstream's turn-windowed snapshot: rows dropped mid-window are unreachable (loading earlier turns fetches earlier windows, never the middle of this one)	Confirmed, fixed. Cap + hasMoreActivities now apply only to the legacy unbounded snapshot, where the compat activities-page RPC can recover them; windowed snapshots return the full window
HIGH — nextLatestTurnId computed but ignored in ProjectionPipeline, expression duplicated in the upsert	Confirmed (severity: cosmetic), fixed. Variable now used
HIGH — older-page cursor read before historyEpoch, neither under applyLock	Out of scope. That region is upstream's own code, byte-identical to 6b73b3def — a candidate for an upstream issue, not a resolution defect
MED — upstream's loadingServerThread/activeServerThread computed but never consumed; hideEmptyPlaceholder lost the threadDetailLoading guard, so a loading thread could flash the genuine-empty placeholder	Confirmed welds, fixed.activeServerThread now drives isServerThread/activeThread/threadError as upstream intended, and the placeholder guard is restored
MED — mobile activeThreadBusy threaded into screens but never read	Confirmed dangling, removed. Upstream's consumers (send-button "Queue" label + queued-count note) are superseded by the fork's sendEntersSteeringQueue (same running/starting predicate) and queue chips; the dead threading is deleted rather than double-wired
MED — fork's live-event batching (groupedWithin) lost	Intentional. The batch reducer was a weld casualty either way (it silently dropped upstream's synchronized branch); upstream's epoch/semaphore apply model plus windowed initial snapshots replaces the render-storm bound it provided. If large-thread churn resurfaces, batching gets rebuilt against the new model, not welded onto it
LOW — timeline tests assert rendered strings, not interaction semantics	Accepted. These are SSR-markup existence tests by design; interaction is covered at the ChatView level

Both reviews independently cleared the SQL/decode surface (source_json, queued messages, pending turn start, keyset ORDER) and found no state-machine races beyond the setDeleted weld above.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3