Skip to content

v0.6.4

@tlamadon tlamadon tagged this 03 Jun 22:25
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>
Assets 2
Loading