feat(usage): include Grok Build in the usage view - #6051

💭 I'm checking the UsageService file to see how it follows Effect service conventions. Looking at the UsageService.ts change, I'm noticing it accesses process.env["GROK_HOME"] directly inside Effect.gen, which feels like it might violate the convention about not hiding dependencies in module globals. I should check how other providers in the same file handle home path resolution—like resolveClaudeHomePath and resolveCodexHomeLayout—and whether process.env is already being used elsewhere to understand if this is an established pattern or a deviation. I'm noticing a discrepancy between what git grep is showing at the current head commit versus what the diff displayed—the grep found the code at line 210 with a slightly different syntax than the line 223 version I saw in the view, which makes me wonder if there's a revision mismatch or if the grep is pulling from a different commit state than expected. Now I'm checking the conventions around Effect service definitions to see what's actually relevant to this PR—looking at imports, dependencies, and error handling patterns in UsageService.ts. The new import for the path expansion helper is a straightforward named import, which is fine. But I'm noticing that process.env["GROK_HOME"] is being accessed directly inside the service constructor, which is a hidden dependency on the module global rather than going through Effect's environment. The conventions warn against hiding dependencies in module globals or imperative APIs, though this is more of a service-level concern. The existing code already uses NodeOS.homedir() and hostname() directly in this same service, so process.env access is consistent with what's already there. It's borderline—could flag as an optional style preference. The repo does have ServerConfig available, and I should check whether there's an established convention for reading environment variables through Effect Config versus direct access. The real testability issue here is that process.env is hardcoded inline rather than injected as a parameter with a default, which makes the code harder to test. That's more of a practical concern than an Effect service convention violation. The parser itself has tests for the new parseGrokLine behavior, which is good since it's pure logic. But the file-name filter in listTranscriptFiles and the directory resolution in UsageService don't have focused tests, even though backend behavior is changing. The convention expects focused tests when backend behavior changes. That's a marginal gap. I also noticed the main branch already has a similar process.env.GROK_HOME access at line 210, which suggests maintainers have already moved toward this pattern, though they may have refactored it differently. The git grep output was actually from the PR head, not main like I initially thought—the earlier results must have been from a different revision. Now I'm looking at how other providers handle home directory resolution, specifically checking if resolveCodexHomeLayout uses Effect for environment variable access. I'm checking whether the PR's approach of reading process.env directly inside the UsageService constructor violates the Effect service conventions. The existing pattern has home resolution helpers in provider/Drivers modules that take config and use Path.Path from the environment, so I need to understand if ServerConfig is the standard way to access environment configuration in this codebase, or if direct process.env access is acceptable here. The service definition follows established conventions, and while reading process.env directly is a slight deviation, there's precedent for it in the codebase. This doesn't clearly violate the dependency-hiding rule since process.env isn't an Effect service dependency—it's borderline at worst. Given the guidance to report only concrete violations and not flag optional style preferences, I'd consider this acceptable. Now I'm scanning the rest of the diff for other Effect-related issues, starting with usageTranscripts.ts. The rest of the codebase uses pure functions without Effect service violations, and while process.env is accessed directly in the service constructor, that's not flagged by the linting rules since they focus on Effect-specific patterns. I'm also wondering about the Grok home resolution duplication—the existing pattern has provider home resolvers in the provider/Drivers directory, like ClaudeHome. ts and CodexHomeLayout.ts, which are Effect functions taking settings. GrokProvider.ts has an environment parameter, so I should check if there's already a Grok home resolver in the provider directory that this might be duplicating, though that would likely fall outside the scope of this check anyway. There's no existing Grok home resolver, and while the PR's inline environment variable access deviates slightly from the typical pattern of passing env as a parameter for testability, it doesn't violate any of the listed Effect service conventions. I'm facing a conflict though—the instructions say to respond with exactly "All clear" on one line, but the schema requires JSON output, so I need to structure the response as JSON with success state and "All clear" as the title and summary.