feat: native subagent & workflow observability - #5219

💭 I'm checking the current state of the codebase for the previously flagged issues. The key files in the orchestration layer appear to be properly structured now—ThreadBackgroundLiveness is consolidated into a single module and correctly uses the service type and layer composition pattern with provideMerge in the runtime setup. Looking at workflowScriptQuery, the error handling has been refactored to return failure objects with specific reason literals and scriptPath information, which is cleaner than the previous approach. Now I'm examining whether the current error handling strategy aligns with the conventions—specifically, whether using a lookup table to map eight distinct error reasons to user-facing messages violates the principle of splitting semantically distinct failures into separate error classes. The instruction suggests that when a reason discriminator drives both the user message and caller control flow, those failures should be modeled as separate error classes rather than consolidated into one with a lookup table. However, this design was explicitly requested in the prior review at commit 3585e63, which asked for exactly this structure: multi-value reason literals plus derived messages. The tests also use the reason field for control flow assertions, but only in test code, not in production logic. Since the RPC error is caller-visible with the reason on the wire for client-side distinction, and this matches the requested design, I'm not flagging it as a violation. Now I'm moving through the other Effect service definitions in the diff to check for consistency with the established patterns. The mutable Map is scoped to each instance created by make, so there's no module-level state issue. Both ProviderRuntimeIngestion.ts and ProjectionSnapshotQuery.ts properly acquire the service from the environment, and the composition layer correctly merges in the dependency without self-providing concerns. On imports, there's a question about whether the named import of just the service tag in ProjectionSnapshotQuery.ts aligns with the guidance to use namespace imports at service boundaries, though the rule isn't an absolute blanket requirement. Looking at how other services are imported in the same file—like ProjectionCheckpoint—they also use named imports of the tag, so this is consistent with the repo's convention and doesn't need flagging. The import placement in ws.ts is fine too. Now checking how workflowScriptQuery.ts handles error cases with Effect.tryPromise. In ClaudeAdapter, there's a tryPromise call that catches errors and returns undefined, then ignores the result — it's intentionally discarding the error rather than modeling it as a domain failure, which is acceptable here. Let me check if there are any new Effect service definitions elsewhere in the diff. Looking at ThreadBackgroundLiveness and workflowScriptQuery to confirm they match the current state. The pure helper functions like classifyTaskAgentKind are fine, but I'm noticing that OrchestrationGetWorkflowScriptError in the contracts uses a tagged error class with a lookup table for eight different reasons, each with distinct user-facing messages — the convention suggests these should probably be split into separate error classes instead. However, the guidance does allow multi-value reasons when failures share the same semantics, and explicitly warns against large switch statements in message getters. Since all eight reasons are variations of "cannot serve this script" around path validation and containment, and I previously recommended this exact approach, re-flagging it now would be contradictory and create unnecessary churn. The instruction also says not to fail on optional style preferences. I need to reconsider the check's default-failure clause though — it says to respond with exactly "All clear" when there are no findings, but my response needs to be JSON per the schema, so there's a conflict there. Actually, the system-level format takes precedence, so I'll produce JSON with a success state and the title/summary reflecting "All clear". The check defaults to failure when findings exist, so no findings means success. Let me verify a few files at the head of the repository to catch anything not visible in the diff — specifically whether ProjectionSnapshotQuery's layer type now exposes the requirement, and whether there are any leftover old files like the ThreadBackgroundLiveness implementations. Verifying the cleaned-up files and checking that ThreadBackgroundLiveness.ts is properly structured. The layer composition for ProjectionSnapshotQuery looks correct with the runtime layer using provideMerge at the infrastructure level. I should confirm the naming convention for service interfaces follows the Foo["Service"] pattern. Checking imports across the touched files — ThreadBackgroundLiveness pulls Context, Effect, and Layer from subpaths, while CodexSessionRuntime and ClaudeAdapter keep their existing imports unchanged. Everything checks out. The schema requires JSON output with a success state and title "Effect Service Conventions: Complete", with "All clear" as the summary.