livepilot 1.26.0 → 1.26.1

package/livepilot/skills/livepilot-creative-director/references/phase-6-execution.md

@@ -0,0 +1,409 @@
+# Phase 6 — Execution Contracts (v1.20+)
+
+Full contracts for the 10 semantic moves shipped in v1.20.0, plus the
+escape-hatch policy for patterns not yet covered. Read this alongside
+the Phase 6 decision table in `SKILL.md`.
+
+Every NEW move listed here takes its user targets via
+`apply_semantic_move(move_id, mode, args)`, where `args` is threaded
+into the compiler's kernel as `kernel["seed_args"]`. The pre-v1.20 33
+moves (mix / arrangement / transition / sound_design / performance /
+sample families) still read only from `session_info` and ignore args.
+
+---
+
+## Routing family (v1.20 commit 1)
+
+### `build_send_chain`
+
+Load an ordered device chain onto a return track. The Basic Channel /
+dub-techno / ambient send-architecture primitive.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `return_track_index` | int | yes | 0 = Return A, 1 = Return B, ... (0-based) |
+| `device_chain` | list[str] | yes | Device names in load order. Duplicates allowed (e.g., two Echos stacked). |
+
+Compiled steps (per device in order, then a final verify read):
+
+1. `find_and_load_device(track_index=-(return_track_index+1), device_name=<name>, allow_duplicate=True)`
+2. ... (one per device)
+3. `get_track_info(track_index=-(return_track_index+1))` — read-only verify.
+
+Risk: **medium** (return chains affect every track routing sends there).
+Protect: `low_end=0.6` (dub returns can accumulate sub mud).
+Family: `device_creation`.
+
+**Typical caller:** "build me a Basic Channel dub architecture on
+Return A" → build_send_chain({return_track_index: 0, device_chain:
+["Echo", "Auto Filter", "Convolution Reverb"]}).
+
+---
+
+### `configure_send_architecture`
+
+Set send levels across a set of source tracks in a single move.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `source_track_indices` | list[int] | yes | 0-based; negative indices for returns |
+| `send_index` | int | yes | Which send slot (0 = Send A, 1 = Send B, ...) |
+| `levels` | list[float] | yes | 0.0-1.0. Must be same length as source_track_indices. Out-of-range values are clamped with a warning. |
+
+Compiled steps: one `set_track_send` per (track, level) pair.
+
+Risk: **low**. Protect: `clarity=0.5` (overdone sends muddy the mix).
+Family: `mix`.
+
+**Typical caller:** "route all percussion to the dub reverb at -10 dB" →
+configure_send_architecture({source_track_indices: [2, 3, 4], send_index: 0, levels: [0.35, 0.35, 0.35]}).
+
+---
+
+### `set_track_routing`
+
+Rewire a track's output routing. Useful for setting up bus architectures
+("Sends Only") or routing a track to a specific return.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `track_index` | int | yes | 0-based; negative for returns |
+| `output_routing_type` | str | at least one of output_* required | e.g., "Sends Only", "Master" |
+| `output_routing_channel` | str | | Display name from Live (e.g., "Post Mixer") |
+
+Compiled steps: single `set_track_routing` call.
+
+Risk: **medium** (a bad routing silences or feedback-loops audio).
+Protect: `clarity=0.5`. Family: `mix`.
+
+**Typical caller:** "send track 0 to bus-only so it only feeds the return" →
+set_track_routing({track_index: 0, output_routing_type: "Sends Only"}).
+
+---
+
+## Device-mutation family (v1.20 commit 2)
+
+### `configure_device`
+
+Reconfigure an existing device in bulk — set N parameters in one
+undoable move. The ergonomic replacement for a chain of
+`set_device_parameter` raw calls.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `track_index` | int | yes | Negative allowed (returns, master=-1000) |
+| `device_index` | int | yes | Position in the track's chain |
+| `param_overrides` | dict[str, Any] | yes | `{param_name: value}`. At least one entry required. |
+
+Compiled steps: single `batch_set_parameters` call. Each
+`{param_name, value}` pair is normalized into Live's preferred shape
+(`parameter_name` key).
+
+Risk: **low**. Protect: `{}` — caller declares via the specific
+param_overrides. Family: `sound_design`.
+
+**Preset library note (v1.21 scope):** the plan originally called for
+`preset_name` + an affordance-YAML library. v1.20 ships `param_overrides`
+only — once a preset library lands, the preset simply resolves to the
+same dict and the move contract stays identical.
+
+**Typical caller:** apply an affordance preset (affordance YAML →
+resolved param dict) → configure_device({track_index: -1, device_index: 0,
+param_overrides: {"Decay Time": 4000.0, "Dry/Wet": 0.35, "Size": 1.0}}).
+
+---
+
+### `remove_device`
+
+Delete a device with a required audit reason. Destructive but undoable
+via Live's undo stack.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `track_index` | int | yes | |
+| `device_index` | int | yes | |
+| `reason` | str | **yes** | Non-empty, non-whitespace. Destructive ops must be justified. |
+
+Compiled steps:
+
+1. `delete_device(track_index, device_index)`
+2. `add_session_memory(category="device_removal", content="Removed track=<ti> device_index=<di>: <reason>")`
+
+Risk: **medium**. Protect: `signal_integrity=0.9` (live signal-path
+removal can silence audio). Family: `sound_design`.
+
+---
+
+## Content family (v1.20 commit 3)
+
+### `load_chord_source`
+
+Create a named MIDI clip at a specific slot with chord voicing notes.
+Feeds a `build_send_chain` return chain for dub-chord workflows.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `track_index` | int | yes | |
+| `clip_slot` | int | yes | Non-negative |
+| `notes` | list[dict] | yes | `[{pitch, start_time, duration, velocity?, probability?}]`; non-empty |
+| `name` | str | yes | Non-whitespace |
+| `length_beats` | float | no | Default 4.0 (one bar 4/4) |
+
+Compiled steps (ordered, all remote_command):
+
+1. `create_clip(track_index, clip_index=clip_slot, length=length_beats)`
+2. `add_notes(track_index, clip_index=clip_slot, notes=...)`
+3. `set_clip_name(track_index, clip_index=clip_slot, name=...)`
+
+Risk: **low**. Protect: `cohesion=0.6`. Family: `sound_design`.
+
+---
+
+### `create_drum_rack_pad`
+
+Add one pad (chain) to a Drum Rack, loading a sample + setting Snap=0
+post-load. Wraps the Live 12.4 native `replace_sample_native` flow.
+Build kits one pad at a time à la Dilla.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `track_index` | int | yes | Track containing the Drum Rack |
+| `pad_note` | int | yes | MIDI 0-127. Standard drum map: 36=Kick, 38=Snare, 42=CHH, 46=OHH. |
+| `file_path` | str | yes | Absolute path to the audio file |
+| `rack_device_index` | int | no | Auto-detects first Drum Rack if omitted |
+| `chain_name` | str | no | Display name for the new chain |
+
+Compiled steps: single `add_drum_rack_pad` call (backend=`mcp_tool`,
+async — it composes insert_rack_chain + set_drum_chain_note +
+insert_device + replace_sample_native + hygiene internally).
+
+Risk: **low**. Family: `device_creation`.
+
+---
+
+## Metadata family (v1.20 commit 4)
+
+### `configure_groove`
+
+Assign a groove to clips and optionally tune its timing_amount. The
+Dilla-swing primitive; pre-resolve the groove_id via `list_grooves()`
+before calling.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `track_index` | int | yes | |
+| `clip_indices` | list[int] | yes | Non-empty; non-negative entries |
+| `groove_id` | int | yes | From `list_grooves()` |
+| `timing_amount` | float | no | 0.0-1.0; clamped with warning on out-of-range |
+
+Compiled steps:
+
+1. `assign_clip_groove(track_index, clip_index=<each>, groove_id)` — one per clip
+2. `set_groove_params(groove_id, timing_amount=<clamped>)` — only if provided
+
+Risk: **low**. Protect: `clarity=0.5`. Family: `arrangement`.
+
+---
+
+### `set_scene_metadata`
+
+Set scene name / color / tempo in one conditional move. Each field is
+optional; at least one required.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `scene_index` | int | yes | Non-negative |
+| `name` | str | no | |
+| `color_index` | int | no | |
+| `tempo` | float | no | BPM. **set_scene_tempo DOES affect playback timing on scene fire — use cautiously inside a performance context.** |
+
+Compiled steps: one tool call per provided field (`set_scene_name` /
+`set_scene_color` / `set_scene_tempo`). Zero-field calls reject.
+
+Risk: **low**. Family: `arrangement`.
+
+---
+
+### `set_track_metadata` (bundled rename + color)
+
+Set track name and/or color in a single bundled move. Both fields are
+optional; at least one required.
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `track_index` | int | yes | Negative indices for returns allowed |
+| `name` | str | no | |
+| `color_index` | int | no | |
+
+Compiled steps: one call per provided field. Zero-field calls reject.
+
+Risk: **low**. Family: `mix`.
+
+**Why bundled?** Phase 6 usage always pairs rename with color (name is
+what the director types; color carries aesthetic meaning — green for
+analog, orange for harmonic, etc.). The bundled move replaces two
+raw calls with one named intent.
+
+---
+
+## Escape-hatch policy (v1.20, phased cutover)
+
+When no semantic move in Phase 6's decision table covers the pattern,
+the director may fall back to raw tool calls — BUT only with the
+mandatory logging contract below. The hatch is explicitly a phased-
+cutover transitional state; v1.21+ closes patterns as they accumulate
+tech_debt log entries.
+
+### The three mandatory calls (in order)
+
+1. **The raw tool call itself** — e.g., `set_device_parameter(...)`,
+   `load_browser_item(...)`, `create_take_lane(...)`.
+2. **`add_session_memory(category="move_executed", ...)`** — one-line
+   ledger entry summarizing the move's family + target + brief
+   identity. Anti-repetition is blind without this.
+3. **`add_session_memory(category="tech_debt", ...)`** — tracking log
+   that names the uncovered pattern. Use wording specific enough that
+   v1.21 release planning can turn it into a semantic move.
+
+### Example: the director rewires a track group (pattern not yet in decision table)
+
+```python
+# Raw tool call (no semantic move covers "rename track group")
+ableton.send_command("set_group_name", {"group_index": 0, "name": "DRUMS"})
+
+# Mandatory 2/3: ledger marker for anti-repetition
+add_session_memory(
+    category="move_executed",
+    content="mix:group-0 rename to DRUMS — brief: stem organization for export",
+    engine="creative_director",
+)
+
+# Mandatory 3/3: tech_debt log so v1.21 can close the gap
+add_session_memory(
+    category="tech_debt",
+    content="no semantic_move for: rename a track group (set_group_name). "
+            "Suggested move: set_group_metadata, family=mix, "
+            "seed_args={group_index, name?, color_index?}",
+    engine="creative_director",
+)
+```
+
+### What the two entries do differently
+
+| Entry | Consumer | Scrub? |
+|---|---|---|
+| `move_executed` | Anti-repetition Phase 3 recency table | Stable — never scrubbed |
+| `tech_debt` | v1.21 release planning | Scrubbed per release after closure |
+
+### Honesty rules for the hatch
+
+- **Don't treat the hatch as a shortcut.** Default is always
+  `apply_semantic_move`. The hatch is the branch you take once you've
+  checked the decision table AND run
+  `list_semantic_moves(domain="<family>")`.
+- **Don't skip the tech_debt log because "that pattern is weird."**
+  Weird patterns are exactly the ones v1.21 should close. The log is
+  the input.
+- **Don't use `category="tech_debt"` for other purposes.** It's a
+  specific contract with release planning. Use a different category
+  (e.g., `observation`) for general session notes.
+
+---
+
+## Affordance-preset resolution (bridge into configure_device)
+
+**Shipping in v1.21.** The affordance library lives at
+`mcp_server/affordances/devices/<slug>.yaml` and exposes a Python loader
+at `mcp_server.affordances`. When the plan calls for a preset-style
+reconfiguration (e.g., "dub cathedral reverb", "ping-pong dub delay"),
+you have two equivalent dispatch paths:
+
+### Preferred (v1.21+): pass the preset reference to configure_device
+
+The compiler resolves the preset YAML at compile time. This keeps the
+director's turn clean (no filesystem call in Python) and makes the
+dispatch self-describing:
+
+```python
+apply_semantic_move(
+    "configure_device",
+    mode="explore",
+    args={
+        "track_index": -1,
+        "device_index": 0,
+        "device_slug": "reverb",       # required when preset is used
+        "preset": "dub-cathedral",     # v1.21 library name
+    },
+)
+```
+
+`device_slug` is REQUIRED when `preset` is supplied — v1.21 doesn't
+auto-infer from class_name (that's v1.22 scope). The compiler returns
+a clear warning if `device_slug` is missing.
+
+### Preset + explicit override (merge semantics)
+
+The compiler merges preset-resolved params first, then applies any
+explicit `param_overrides` on top (last-write-wins at dict-key
+granularity):
+
+```python
+apply_semantic_move(
+    "configure_device",
+    mode="explore",
+    args={
+        "track_index": -1,
+        "device_index": 0,
+        "device_slug": "reverb",
+        "preset": "dub-cathedral",
+        "param_overrides": {"Decay Time": 0.5},   # overrides preset's 0.85
+    },
+)
+# Result: Decay Time=0.5 (explicit wins), Room Size=0.95 (from preset),
+#         Dry/Wet=0.40 (from preset), etc.
+```
+
+### Fallback: resolve explicitly in Python
+
+When you want to inspect or modify the resolved params before dispatch,
+call the loader directly:
+
+```python
+from mcp_server.affordances import resolve_preset
+
+preset = resolve_preset("reverb", "dub-cathedral")
+# preset = {"Decay Time": 0.85, "Room Size": 0.95, "Dry/Wet": 0.40, ...}
+
+apply_semantic_move(
+    "configure_device",
+    mode="explore",
+    args={
+        "track_index": -1,
+        "device_index": 0,
+        "param_overrides": preset,     # equivalent to path (1) above
+    },
+)
+```
+
+### v1.21 library content
+
+Minimal (3 seed presets, by design — v1.22 expands):
+
+| device_slug    | preset         | description                              |
+|----------------|----------------|------------------------------------------|
+| `reverb`       | `dub-cathedral`| Basic Channel-adjacent huge space        |
+| `delay`        | `ping-pong-dub`| Dotted-8th ping-pong, feedback 0.45      |
+| `auto-filter`  | `slow-sweep`   | Bar-long LFO LP sweep, moderate resonance|
+
+List available presets programmatically via
+`mcp_server.affordances.list_devices()` and
+`mcp_server.affordances.list_presets(device_slug)`.
+
+---
+
+## See also
+
+- `SKILL.md` §Phase 6 — the entry-level decision table
+- `references/anti-repetition-rules.md` §v1.20 update — how ledger
+  entries feed the recency table
+- `docs/plans/v1.20-structural-plan.md` — design rationale + §7 risks

package/livepilot/skills/livepilot-creative-director/references/the-four-move-rule.md

@@ -0,0 +1,192 @@
+# The Four-Move Rule
+
+A creative pass should touch four dimensions: **structural**,
+**rhythmic**, **timbral**, **spatial**. The three plans generated in
+Phase 3 distribute across these dimensions — they do not duplicate one.
+
+This is the complement to the move-family diversity rule. Family
+diversity enforces "different machinery"; four-move coverage enforces
+"different musical consequence."
+
+## The four dimensions
+
+Dimensions are orthogonal to `move.family`. A plan has ONE dominant
+dimension and ONE dominant family. Multiple dimensions can map to the
+same family (e.g. an `arrangement`-family plan can be structural OR
+rhythmic depending on what it does). See
+`move-family-diversity-rule.md` §"Family vs. dimension" for the split.
+
+| Dimension | What it is | Dominant family typically | Tag with | Also uses |
+|---|---|---|---|---|
+| **Structural** | Section-level form — adds, removes, reshapes sections or clip density | `arrangement` or `transition` | `dimension_hint` optional (family implies it) | `livepilot-arrangement`, `livepilot-composition-engine`, scene/arrangement tools |
+| **Rhythmic** | Timing, groove, swing, motif patterns, polyrhythm, per-hit velocity/probability | `arrangement` (clip pattern edits) OR `sound_design` (per-hit feel) | `dimension_hint: "rhythmic"` REQUIRED — there is no rhythmic family in the registry | `livepilot-notes`, `assign_clip_groove`, `modify_notes`, motif tools, Euclidean rhythm |
+| **Timbral** | Source character — instrument choice, patch, saturation, texture | `sound_design` or `device_creation` | `dimension_hint` optional | `livepilot-sound-design-engine`, `livepilot-devices`, atlas lookups |
+| **Spatial** | Space and stereo field — reverb, delay, pan, width, depth | `mix` (space-oriented moves) | `dimension_hint: "spatial"` recommended when family=mix (distinguishes from level/EQ mix plans) | `set_track_send`, `set_track_pan`, return-track routing, `add_space` |
+
+Note that `performance` family is orthogonal — it rarely applies on
+first-pass creative work; it's for live contexts.
+
+**The fudge is not a fudge:** earlier drafts of this rule described
+rhythmic plans as "fudged" because they borrow the `arrangement` or
+`sound_design` family. That framing was wrong. The family axis and the
+dimension axis are orthogonal by design — a rhythmic plan has an
+honest family tag AND an honest dimension tag, via `dimension_hint`.
+State both explicitly in the turn. No apology needed.
+
+## The rule
+
+For a creative pass of 3 plans, coverage should span at least 3 of the
+4 dimensions. Plans may overlap only after all four dimensions have
+been considered.
+
+```
+dimensions_touched = {dominant_dimension(p) for p in plans}
+len(dimensions_touched) >= 3      # default
+len(dimensions_touched) >= 4      # ideal
+```
+
+Falling below 3 distinct dimensions is the same failure mode as
+falling below 3 distinct families — the agent is clustering.
+
+## How to identify a plan's dominant dimension
+
+Use the move-family → dimension map, then confirm against the plan's
+audible consequence:
+
+1. If dominant move's family is `arrangement` or `transition` → **structural**
+2. If dominant move's family is `sound_design` or `device_creation` → **timbral**
+3. If dominant move's family is `mix` AND the move is space-oriented
+   (`add_space`, `widen_stereo`, reverb-related) → **spatial**
+4. If dominant move's family is `mix` AND the move is level / EQ /
+   dynamics → still **spatial** for this taxonomy (mix's audible
+   consequence is positional)
+5. If the plan is primarily MIDI-editing (notes, grooves, motif
+   transforms) → **rhythmic**, regardless of family tagging
+
+Ambiguous? Tag the seed explicitly in `seed.dimension_hint`.
+
+## Interaction with `locked_dimensions`
+
+If the brief's `locked_dimensions` includes a dimension, that dimension
+is off-limits. The remaining three must be covered across the three
+plans.
+
+| Locked | Must cover |
+|---|---|
+| (nothing) | any 3 of 4 (all 4 ideal) |
+| `structural` | rhythmic + timbral + spatial |
+| `timbral` | structural + rhythmic + spatial |
+| `rhythmic` | structural + timbral + spatial |
+| `spatial` | structural + rhythmic + timbral |
+| two locks | the remaining two — ship 2 plans, not 3 |
+
+Two locks on a 4-dimension space means the problem is narrow. Two
+plans is honest; faking a third by sneaking into a locked dimension
+violates both this rule AND the user's explicit constraint.
+
+## Example 1 — "Make it feel like Basic Channel if Dilla touched the swing"
+
+No locked dimensions. Ideal coverage = 4/4 but we only have 3 plans.
+Each plan tagged `family / dimension`:
+
+- Plan A (`arrangement` / **structural**): Add an 8-bar breakdown at bar 48 where kick drops out and only ghost hats + dub-chord tail remain.
+- Plan B (`arrangement` / **rhythmic**, dimension_hint="rhythmic"): Micro-shift hi-hat notes by −8 to +12 ticks, add ghost notes at 62% probability, assign a "Dilla-esque" groove.
+- Plan C (`sound_design` / **timbral**): Load Drift for the chord, route to a send with Ping Pong Delay + Auto Filter on the return, print 25% wet.
+
+Family-diversity note: Plans A and B are BOTH `arrangement` family —
+this is a rule violation unless corrected. Swap Plan B to tag
+`sound_design` family instead (per-hit velocity + micro-timing counts
+as feel-shaping sound_design per the family→dimension map), OR swap
+Plan A to `transition` family (create_breakdown semantic move). Either
+fix keeps all three dimensions covered. The point: rhythmic as a
+dimension does not exempt the plan from the three-distinct-families
+constraint — the director must still land family diversity, just via
+the appropriate tag.
+
+Corrected version:
+- Plan A (`transition` / **structural**): `create_breakdown` semantic move at bar 48.
+- Plan B (`arrangement` / **rhythmic**, dimension_hint="rhythmic"): groove + probability edits to clip.
+- Plan C (`sound_design` / **timbral**): Drift + send chain.
+
+Spatial dimension is not directly touched by a plan — but Plan C's
+send-chain IS spatial in consequence. Coverage is honest: 3 explicit
+dimensions, one implicit.
+
+## Example 2 — "Make the drums more interesting, don't touch the arrangement"
+
+Locked: `structural`. Must cover rhythmic + timbral + spatial.
+
+- Plan A (`arrangement` / **rhythmic**, dimension_hint="rhythmic"): Add probability 70-90% to the hat and clap clip; apply a 58% swing groove from `list_grooves`. Family is `arrangement` because the target is clip content; dimension is rhythmic because the audible consequence is feel. The `structural` lock concerns SECTION-level arrangement, not clip-level edits — locked_dimensions semantics resolve at the dimension level, not the family level.
+- Plan B (`sound_design` / **timbral**): Layer a parallel drum bus with Saturator + Drum Bus; per-hit velocity mod on snare.
+- Plan C (`mix` / **spatial**, dimension_hint="spatial"): Send hats and ghost snares to a short plate reverb at -14 dB; narrow the kick to mono under 80 Hz.
+
+All three dimensions hit. Section arrangement untouched. Three families
+distinct. Honest.
+
+## Example 3 — Narrow request: "the pad is too static"
+
+Ambiguous whether "static" means timbre or space. The agent should
+compile a brief that acknowledges this and generate plans across both:
+
+- Plan A (`sound_design` / **timbral**): Enable wavetable position LFO + macro
+  modulation on Drift.
+- Plan B (`mix` / **spatial**, dimension_hint="spatial"): Send the pad to a long convolution reverb on a
+  return with Auto Filter LFO.
+- Plan C (`arrangement` / **rhythmic**, dimension_hint="rhythmic"): Automate a slow 8-bar amplitude envelope so
+  the pad breathes with the section.
+
+This is an explicit case where the structural dimension is not
+relevant (it's one sound, not an arrangement decision). Three of four
+is the natural coverage. Shipping a structural plan would be
+fabricated.
+
+## When to drop below three dimensions
+
+Drop to 2 of 4 (or 1 of 4) ONLY in these situations. In all cases:
+ship fewer plans honestly. Do not fake coverage.
+
+1. **Two or more dimensions locked.** User explicitly locked two
+   dimensions → at most 2 dimensions remain → at most 2 honest plans.
+
+2. **Genuinely narrow task AND concept packet confirms no other
+   dimension is in scope.** Example: "make this one reverb return
+   less muddy" is spatial-only.
+
+3. **Low novelty_budget + narrow-idiom concept packet.** When the
+   user's request is reference-adjacent (`novelty_budget` ≤ 0.50) AND
+   the concept packet explicitly de-prioritizes certain dimensions,
+   dropping those dimensions is idiomatic, not fabricated. Examples:
+
+   - **Dub-techno packets** (Basic Channel / Rhythm & Sound) explicitly
+     de-emphasize the rhythmic dimension ("percussion implied not
+     stated"). Three plans may legitimately cluster in
+     timbral + spatial + (optional) structural. Rhythmic absent is
+     idiomatic honesty.
+   - **Ambient packets** (Gas / Basinski / Stars of the Lid) explicitly
+     de-emphasize rhythmic AND structural (static with very slow
+     evolution). Three plans clustering in timbral + spatial is
+     idiomatic.
+   - **Beat-focused packets** (Dilla / Premier) explicitly
+     de-emphasize the spatial dimension (dry intimacy is the aesthetic).
+     Three plans clustering in rhythmic + timbral + structural is
+     idiomatic.
+
+   When this rule fires, document the decision in the turn: *"The
+   packet's aesthetic de-prioritizes <dimension>; dropping it here is
+   idiomatic rather than coverage failure."* This prevents future
+   agents from mistaking the under-coverage for a skill bug.
+
+**Never-drop rule:** even when dropping dimensions, the family
+diversity rule still applies to whatever plans you DO ship. Two plans
+must have different families; three plans must have three different
+families. Narrow doesn't excuse fabricated distinctness.
+
+## Why this rule works
+
+"Layered and complex output" — what the user asks for when they say
+"more interesting" — is almost always a DISTRIBUTION problem, not a
+depth problem. A pass that touches rhythm + timbre + space feels
+three-dimensional even if each individual change is small. A pass that
+stacks three `mix` moves feels thin even when the changes are large.
+
+Force distribution. Depth emerges.