Problem
Workspace configuration has accumulated overlapping controls across YAML and CLI, which makes behavior hard to predict.
Current confusion points:
- Multiple ways to express static workspaces (
mode/static_path, CLI path flags, legacy forms).
- Mode and path interactions are implicit in places and strict in others.
- Legacy pooling and retention flags add extra precedence branches.
We want a single, obvious configuration model for workspace behavior.
Proposal: canonical workspace.mode + workspace.path
Adopt one workspace shape in YAML:
workspace:
mode: pooled | temp | static
path: /abs/path # required only when mode=static
template: ./template # for pooled/temp flows
repos: [...] # for pooled/temp flows
hooks: {...}
Semantics
mode=pooled → use pooled workspace lifecycle.
mode=temp → materialize fresh workspace per run (no pooling).
mode=static → use an existing user-managed workspace at workspace.path.
Defaults and implied mode
- If no mode/path is provided, default to
pooled.
- In YAML, non-empty
workspace.path with missing workspace.mode implies static.
- In CLI,
--workspace-path implies --workspace-mode static.
Validation rules
- If
mode=static and path is missing/empty → hard error.
- If
--workspace-path is set and --workspace-mode is provided with non-static value → hard error.
Precedence (highest first)
- CLI
--workspace-path (implies static)
- CLI
--workspace-mode
- YAML
workspace.path / workspace.mode
- Default
mode=pooled
CLI surface simplification
Keep only mode/path workspace controls in CLI:
- Keep
--workspace-mode pooled|temp|static
- Keep
--workspace-path
Remove these flags entirely (hard remove, no warnings/transition period):
--keep-workspaces
--cleanup-workspaces
--retain-on-success
--retain-on-failure
--pool-workspaces
--no-pool
Cleanup/retention behavior remains hook/config-driven (before_each / after_each / after_all), not CLI-driven.
Schema cleanup (hard remove)
Remove legacy/duplicate workspace fields and aliases:
- Remove
workspace.static (if introduced in prior drafts)
- Remove
workspace.static_path
- Remove
workspace.pool boolean
- Remove target-level
workspace_template
Use only eval-level workspace.template / workspace.mode / workspace.path.
Acceptance signals
Non-goals
- No backward-compat aliases for removed fields/flags
- No warning-based transition period
- No changes to core hook execution semantics
Related
Problem
Workspace configuration has accumulated overlapping controls across YAML and CLI, which makes behavior hard to predict.
Current confusion points:
mode/static_path, CLI path flags, legacy forms).We want a single, obvious configuration model for workspace behavior.
Proposal: canonical
workspace.mode+workspace.pathAdopt one workspace shape in YAML:
Semantics
mode=pooled→ use pooled workspace lifecycle.mode=temp→ materialize fresh workspace per run (no pooling).mode=static→ use an existing user-managed workspace atworkspace.path.Defaults and implied mode
pooled.workspace.pathwith missingworkspace.modeimpliesstatic.--workspace-pathimplies--workspace-mode static.Validation rules
mode=staticandpathis missing/empty → hard error.--workspace-pathis set and--workspace-modeis provided with non-staticvalue → hard error.Precedence (highest first)
--workspace-path(implies static)--workspace-modeworkspace.path/workspace.modemode=pooledCLI surface simplification
Keep only mode/path workspace controls in CLI:
--workspace-mode pooled|temp|static--workspace-pathRemove these flags entirely (hard remove, no warnings/transition period):
--keep-workspaces--cleanup-workspaces--retain-on-success--retain-on-failure--pool-workspaces--no-poolCleanup/retention behavior remains hook/config-driven (
before_each/after_each/after_all), not CLI-driven.Schema cleanup (hard remove)
Remove legacy/duplicate workspace fields and aliases:
workspace.static(if introduced in prior drafts)workspace.static_pathworkspace.poolbooleanworkspace_templateUse only eval-level
workspace.template/workspace.mode/workspace.path.Acceptance signals
workspace.mode+workspace.pathmode=pooledwhen neither mode nor path is setworkspace.pathwithout mode impliesstatic--workspace-pathimpliesstaticwithout requiring--workspace-mode--workspace-pathwith non-static--workspace-modemode=staticwithoutpathis rejectedstatic_path,pool, targetworkspace_template)Non-goals
Related