perf(server): finish runtime messages without full thread reads - #10120

💭 I'm identifying which in-scope files in the diff touch Effect service/layer code, focusing on the orchestration and persistence layers to check for convention violations. Looking at the Shape interface pattern, I decide this is pre-existing repo structure, so adding methods to existing Shape interfaces isn't something to flag—it would be demanding unrelated repo-wide cleanup. I'm checking that files properly use named imports from specific effect submodules rather than the bare "effect" package, confirming ProjectionThreadActivities.ts and the Services files follow this correctly, then moving to verify the same for ProviderRuntimeIngestion.ts's imports. That file's import of the repository and its live layer separately reflects an existing Services/Layers split in the repo, so I want to confirm this matches the file's other imports before treating it as consistent. I'm noting a few candidate issues to verify against actual code: a SQL trim-character detail, a magic limit value, possible ordering logic in the activities query, and whether hasAssistantMessageForTurn handles decode errors from SqlSchema.findOne given its result schema. I need to actually open the files to check these concerns concretely.

1. browse_code — apps/server/src/persistence/Layers/ProjectionThreadMessages.ts

2. browse_code — apps/server/src/persistence/Layers/ProjectionThreadActivities.ts

💭 These follow existing repo conventions like the Shape interface and Live layer naming, so no repo-wide cleanup is needed here. Checking the Services files for error handling patterns, I notice hasAssistantMessageForTurn uses SqlSchema.findOne but only maps errors to toPersistenceSqlError, meaning decode errors would end up mislabeled as SQL errors. There's a toPersistenceSqlOrDecodeError helper elsewhere in the repo for this exact case, so this is a mild mislabel worth checking against Errors.ts, since SqlSchema.findOne technically fails with NoSuchElementError if no row is returned but EXISTS always returns one so that's fine. I should also check ProviderRuntimeIngestion.ts's import style against existing conventions in the file — it already uses named imports for repository services, so this matches rather than introducing a new pattern.

3. browse_code — apps/server/src/persistence/Errors.ts

4. browse_code — apps/server/src/persistence/Services/ProjectionThreadActivities.ts

💭 These are pre-existing patterns, so that's fine. I'm checking that hasAssistantMessageForTurn correctly maps decode errors through toPersistenceSqlError, since its describeSqlCause handles SchemaError and produces a proper detail summary typed as PersistenceSqlError — the same logic applies to getByMessageId. Now I'm shifting to ProviderRuntimeIngestion.ts, looking at how it uses Layer/Effect, error handling, and dependency acquisition via yield*. The changed lines pull ProjectionThreadMessageRepository from the environment and provide it through Layer at the bottom, which looks consistent, but I want to check how the file imports its local service modules to see if the named-import pattern matches convention elsewhere in the file.

5. browse_code — apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

6. browse_code — apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

💭 Everything checks out against the file's existing patterns—no stray imports, no ManagedRuntime additions, no new errors or lint suppressions. The one slightly awkward bit is how getLatestTaskActivity wraps findTaskTitleInActivities with Option.match, but it's not a convention violation, and the required tests for the backend behavior change are already present. Given there are no findings, I need my final response to just be "All clear" per the instructions, while still satisfying the structured fields minimally with that same phrase.