---
requires: scratch/garden-assessment.md or scratch/vsm-*-assessment.md
produces: wave/ config, Linear planning state, scratch/wave-mutate.md
---
Compose and play the chord in one pass.
## Orientation
Before starting, orient yourself in this branch:
- Read `scratch/` — design docs and notes for the current work live here
(`scratch/<branch>.md` is this PR's design; `scratch/questions.md` holds open
questions and assumptions).
- Read wave/PM context only when the seed names the exact wave, task, project,
or a concrete coordination question; never infer it or repair access as a
prerequisite.
- Read the repo's agent doc (`CLAUDE.md` / `AGENTS.md`) for conventions.
Write design artifacts, notes, and open questions under `scratch/`. Don't
re-derive what these already record.
## Goal
The assessment already surfaced the pressure. Act on it now.
Compose the smallest coordinated set of mutations that addresses the current
pressure points or proposals, apply them immediately, and leave a clean record
of what changed and why. This step is both composer and performer.
## Workflow
1. **Read the freshest assessment.** Use the assessment produced by the current
flow:
- `scratch/garden-assessment.md`, or
- `scratch/vsm-s5-assessment.md`, `scratch/vsm-s4-assessment.md`,
`scratch/vsm-s3-assessment.md`, or `scratch/vsm-s2-assessment.md`
2. **Extract the actionable pressure.** Pull out only the items that warrant
mutation now:
- garden pressure points
- s5 identity / boundary concerns
- s4 environmental proposals
- s3 mechanical or capacity fixes
- s2 coordination fixes
3. **Compose the chord.** For each change you will make, specify:
- target wave
- lever (`objective`, `flow`, `project`, `task`, `agent`, `triggers`,
`lifecycle`)
- before / after
- rationale
- risk
4. **Play it immediately.** Apply each mutation through its owner:
- edit wave YAML for config changes
- create or update Projects and tasks with `lf pm`; never write a local
planning mirror
- create or remove wave directories only when lifecycle pressure requires it
5. **Sync runtime state.** For changes that affect registered wave config,
update runtime state through the equivalent `lf` API.
6. **Verify.** Read back every changed config and make sure the YAML still
parses. If a mutation cannot be applied cleanly, skip it and record why.
7. **Record the chord.** Write what you played, what changed, and what you left
alone.
## Output
Write `scratch/wave-mutate.md`:
```markdown
# Chord Played — <date>
## Source
<which assessment drove this chord>
## Summary
<what pressure this chord addressed>
## Mutations
### 1. <title>
**Wave**: <name>
**After**: <state after>
**Rationale**: <why this change now>
**Risk**: <what could go wrong>
**Files changed**: <paths>
**Status**: applied | skipped
**Notes**: <verification or skip reason>
## Deferred
<findings that did not warrant mutation now>
```
Commit the applied changes with message: `wave: mutate`.
## What to avoid
**Two-step theater.** Don't draft a proposal and leave execution for later.
Play the chord now.
**Over-mutation.** Change only what the assessment actually justifies.
**Silent skips.** If a mutation was considered but not applied, say why.