Revert "feat(providers): add context compaction across harnesses" - #9284

💭 This looks like a revert PR undoing "add compact command," so I'm checking whether the revert introduces any Effect service convention violations. The ProviderAdapterShape/ProviderServiceShape naming predates this change, so that's not something introduced here—now I'm scanning for other suspicious spots like ProviderCommandRe. I'm looking through actor.ts, ProviderService.ts, and ClaudeAdapter.ts, and the reverted code there just restores prior logic (error handling, removing Deferred usage, spreading pendingUserInputs into an array), none of which touches Effect service conventions. The ProjectionPipeline and ProviderCommandReactor changes look like unrelated regressions from the revert rather than convention issues, so I'm weighing whether to flag anything at all given the instructions to only report concrete violations in changed scope. I checked imports and error handling more carefully—nothing new violates the private schema predicate or catchTags conventions, and the Effect.asVoid removal is behavioral, not a convention problem. Now I want to verify the compactThread field removal didn't leave dangling references at head, since that would break the build if consumers weren't updated. Let me grep for compactThread usages.

1. git_tools — compactThread|COMPACT_SLASH_COMMAND|hasAvailableCompactionProvider|providerSupportsManualCompaction|compactThreadUnavailable

2. git_tools — beforeTokens|afterTokens

💭 The empty grep result seems off since compactThreadContext should still match the pattern compactThread as a substring, so maybe the grep call itself failed rather than there being truly zero matches. I should retry with a simpler search pattern.

3. git_tools — compactThreadContext

4. git_tools — compactThread

💭 The default branch state looks older and isn't directly relevant. At the PR head, compactThread is fully removed except for compactThreadContext in ChatComposer.tsx, so I'm checking whether the web still references anything that no longer exists, like a compactThreadUnavailable prop being passed from elsewhere. That prop grep comes back empty, which is good. Now I want to confirm nothing still relies on the removed beforeTokens/afterTokens fields under the "compacted" state, verify ProviderRuntimeIngestion still compiles without formatTokens if it's unused elsewhere, and double check the ChatComposer condition change involving hasSendableContent is intentional behavior. I also need to sweep for other dangling imports across the codebase—things like Cause in ProviderCommandReactor, EventId in CodexAdapter/ProviderService, unused Fiber/Option in CodexAdapter.test, and ProviderAdapterValidationError/Stream in OpenCodeAdapter—to make sure nothing was left orphaned by the revert.

5. git_tools — Cause.|formatFailureDetail|recoverTurnStartFailure

6. git_tools — formatTokens|ProviderAdapterValidationError

💭 Good, no dangling formatTokens references remain in the server. I'm checking the ProviderCommandReactor hunk to see if the error handling there violates any conventions, but it looks fine as a reverted state. Now I'm considering whether the code improperly uses catchTag/catchIf with schema predicates just to recover known errors. Checking ProviderService.ts, the standalone shape interfaces, and providerSnapshot.ts removal — none of these seem like new violations since they follow existing repo patterns. I'm also flagging that removing tests in CodexAdapter.test.ts and ProviderService.test.ts may leave some imports like Fiber, Option, Stream, or asEventId unused, which lint/CI would need to catch, though that's separate from Effect service conventions. Now I'm checking whether the ClaudeAdapter.test.ts revert introduces similar unused-import issues, but since this falls outside the listed conventions, I'll skip flagging it. I'm also verifying that the ProviderCommandReactor and appendProviderFailureActivity reverts stay consistent with their paired changes, and I want to confirm the ProjectionPipeline removal doesn't leave functions like extractActivityRequestId or deletePendingTurnStartByThreadId as unused dead code.

7. git_tools — extractActivityRequestId|getPendingTurnStartByThreadId|deletePendingTurnStartByThreadId

💭 Everything checks out clean with nothing dangling, so there are no convention violations found. Since there's tension between the instruction to output exactly "All clear" and the requirement for valid JSON, I'll follow the schema and encode "All clear" as the success state within it.