---
title: "Split operator_env.rs"
---
import RepoFile from '../../../../components/RepoFile.astro'

**Status**: Open — Phase 2, confirmation needed

## Problem

<RepoFile path="src/operator_env.rs" /> is **3573L** total (was 2975L at original analysis — +20% growth). It has grown into a shared cross-cutting module that serves runtime launch, config validation/persistence, console widgets, and the console op-cache layer. The file mixes public traits/parsers, subprocess client logic, metadata parsing for the picker, env-layer composition, launch diagnostics, and tests.

## Proposed split

```
src/operator_env/
  mod.rs         ← re-exports, public traits/shared types, parser helpers
  cli.rs         ← OpCli struct + subprocess / timeout / JSON helpers
  resolve.rs     ← EnvLayer, merge_layers, validate_reserved_names, resolve_operator_env*
  diagnostics.rs ← print_launch_diagnostic + classify_value helpers
  picker.rs      ← OpStructRunner types + metadata parsing for the picker
```

## Dependency graph — verified constraints

- runtime launch needs the env-resolution and diagnostic layers
- config persistence/editor needs reserved-name validation
- console widgets / op-cache need the picker metadata types and `OpStructRunner`
- re-exports from `mod.rs` should preserve current call sites while the internals split

## Duplication found

- `operator_env.rs` does NOT duplicate work done by `instance/auth.rs` or `workspace/token_setup.rs` — these three files handle distinct responsibilities (env resolution vs credential provisioning vs token orchestration). The split is clean.
- The file's own internal structure is well-factored already — the split is about physical file organization, not logical separation.

## Migration note

After split, existing callers such as `use crate::operator_env::resolve_operator_env` and `use crate::operator_env::OpField` should continue to work because `mod.rs` re-exports the public surface. The goal is an internal split, not a crate-wide rename churn.

## What needs confirmation

- Whether `diagnostics.rs` is worth its own file or should stay with `resolve.rs`
- Whether raw picker metadata structs (`RawOpField`, friends) belong beside `OpCli` or in the picker-facing layer

## Related files

- <RepoFile path="src/operator_env.rs" /> — target file (3573L)
- <RepoFile path="src/runtime/launch.rs" /> — resolves operator env and emits launch diagnostics
- <RepoFile path="src/console/widgets/op_picker/mod.rs" /> — uses `OpStructRunner` / picker metadata
