The briefing covered the CLI surface end-to-end but treated the YAML
as read-only. So when the user asked an agent to "add a CUDA env
group" or "set a per-project WANDB_PROJECT", the agent had to guess
which file to edit, what the env-rule shape looks like, and whether
to overwrite or patch. Often it'd dump the change in the wrong layer
(rejected at load) or rewrite the whole file (losing comments).
New `## Editing scripthut.yaml` section covers:
- The two-layer model — what `~/.config/scripthut/scripthut.yaml`
carries (backends/sources/settings/pricing) vs. what
`./scripthut.yaml` carries (stacks/workflows/env/env_groups), with
the explicit note that mis-placement raises ConfigError rather
than silently doing nothing.
- Merge semantics — env CONCATS, env_groups MERGE, stacks/workflows
OVERRIDE-BY-NAME. These differ from each other and from common
sense, so they're spelled out.
- The env-rule schema with a 6-line example covering all five fields
(set / if / include / append / init), the AND-across-keys guard
semantic, the ${name} expansion, and the resolver order
(server → backend → workflow → task).
- An edit-discipline checklist: read first, minimal diff, one concept
per edit, hot-reload vs restart, show the user the diff before
saving.
Tests:
- `TestYamlEditingGuidance` pins all of the above (section header,
both file paths, the 4+4 section-allowance lists, the five env-rule
keys, the AND semantic, the resolver order, the three distinct
merge verbs, and the read-first / minimal-diff / hot-reload
discipline).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>