Skip to content

Split operator_env.rs

Status: Open — Phase 2, confirmation needed

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.

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
  • 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
  • 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.

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.

  • 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