livepilot 1.25.0 → 1.26.1

package/livepilot/commands/arrange.md

@@ -0,0 +1,47 @@
+---
+name: arrange
+description: Guided arrangement — build song structure with sections, transitions, and energy flow
+---
+
+Guide the user through arranging their session using the V2 orchestration pipeline.
+
+## Orchestration Flow
+
+1. **Session kernel** — `get_session_kernel(request_text=<user's request>, mode="improve")`
+2. **Route** — `route_request(<user's request>)` for engine routes + semantic moves
+
+## Analysis Phase
+
+3. **Scene matrix** — `get_scene_matrix` for the full clip grid
+4. **Section purposes** — `infer_section_purposes` to understand what each scene is doing
+5. **Emotional arc** — `score_emotional_arc` — does the song have build → climax → resolve?
+6. **Repetition check** — `detect_repetition_fatigue` — are patterns overused?
+7. **Motif analysis** — `get_motif_graph` for recurring patterns and fatigue risk
+8. **Role conflicts** — `detect_role_conflicts` to find competing tracks
+
+## Planning Phase
+
+9. **Ask about target** — what form? (verse-chorus, build-drop, through-composed). What energy arc?
+10. **Plan arrangement** — `plan_arrangement(target_bars, style)` for section blueprint
+11. **Propose moves** — `propose_next_best_move(request_text)` for arrangement semantic moves (e.g., `create_buildup_tension`, `smooth_scene_handoff`)
+12. **Preview** — `preview_semantic_move(move_id)` to see the gesture plan
+
+## Execution Phase
+
+13. **Build sections** — duplicate scenes, set names/colors, use `transform_motif` for melodic development
+14. **Apply gestures** — `apply_gesture_template` for transitions:
+    - `pre_arrival_vacuum` — energy suck before drops
+    - `harmonic_tint_rise` — filter opening for intros
+    - `re_entry_spotlight` — highlight returning elements
+    - `tension_ratchet` — stepped energy build
+    - `outro_decay_dissolve` — gradual dissolution
+15. **Add organic movement** — `apply_automation_shape(curve_type="perlin")` on filters/sends
+16. **Verify arc** — `score_emotional_arc` again to confirm improvement
+17. **Perception check** — `capture_audio` + `analyze_loudness` to verify LRA > 2 LU
+
+## Summary
+
+18. **Report** — "What I did / what improved / what I protected / what remains"
+19. **Session memory** — `add_session_memory` for arrangement decisions
+
+For exploratory arrangement, use the branch-native experiment path (see livepilot-core SKILL.md, Flow B). Each section-ordering variant becomes one `composer`-source seed; attach pre-compiled plans via `compiled_plans`. When the user's request is vague or exploratory ("what would you do?", "surprise me with a structure"), bias `get_session_kernel(freshness=0.7-0.9)` to surface less-conservative branches.

package/livepilot/commands/beat.md

@@ -0,0 +1,81 @@
+---
+name: beat
+description: Guided beat creation — create a beat from scratch with genre, tempo, and instrumentation choices
+---
+
+Guide the user through creating a beat from scratch. Follow these steps:
+
+## Step 0: Session Prep (fresh projects only)
+
+If the user asks for a **fresh start** (new track, clean slate, start from scratch):
+
+1. **Read the session** — `get_session_info` to see what exists
+2. **Delete all existing tracks** — loop through all tracks with `delete_track`, starting from the highest index down to 0 (deleting from the top prevents index shifts)
+3. **Load the M4L Analyzer on master** — `find_and_load_device(track_index=-1000, device_name="LivePilot_Analyzer")`. This enables real-time spectral analysis, RMS metering, and key detection for the entire session. If it fails, try `search_browser(path="max_for_live", name_filter="LivePilot")` to find the URI and load manually.
+4. **Set up master chain** — load Glue Compressor + EQ Eight + Utility on master for bus processing
+5. **Verify analyzer** — wait 2 seconds, then call `get_master_spectrum`. If it returns data, the bridge is connected. If it errors with "UDP bridge not connected", call `reconnect_bridge` to rebind.
+
+If the user is adding to an **existing project**, skip step 0 — just call `get_session_info` and work with what's there.
+
+## Step 1: Ask about the vibe
+Genre, tempo range, mood, reference tracks.
+
+## Step 2: Set up the session
+`set_tempo`, create tracks for drums/bass/harmony/melody with `create_midi_track`, name and color them.
+
+## Step 3: Load instruments
+Use `search_browser` to find devices by name, `load_browser_item` or `find_and_load_device` to load them.
+
+## Step 4: Verify device health
+After loading, run `get_device_info` on each loaded device. A `parameter_count` of 0 or 1 on AU/VST plugins means the plugin failed to initialize (dead plugin). If detected:
+- Delete the dead plugin with `delete_device`
+- Replace with a native Ableton alternative (e.g., Saturator instead of tape plugins, Operator instead of failed FM synths)
+- Run `get_session_diagnostics` for any other issues (armed tracks, missing instruments)
+- Inform the user which plugin failed and what replacement was used
+
+## Step 5: Program drums first
+Create a clip, add kick/snare/hat patterns with `add_notes`.
+
+## Step 6: Add bass
+Create clip, program a bassline that locks with the kick.
+
+## Step 7: Add harmony
+Chords or pads that set the mood.
+
+## Step 8: Add melody
+Top-line or lead element.
+
+## Step 9: Mix + VERIFY
+Balance levels with `set_track_volume` and `set_track_pan`.
+
+**MANDATORY after every parameter change:**
+- Read `value_string` in the response to confirm the actual Hz/dB/% value makes sense
+- Call `get_track_meters(include_stereo=true)` and verify each track has non-zero output
+- If a track's stereo output drops to 0, the effect is killing the signal — check `get_device_parameters` for `value_string`, fix, re-verify
+- Parameter ranges are NOT always 0-1. Always read `value_string`.
+
+## Step 10: Pitch & tuning audit
+MANDATORY before firing. Run on every melodic track (skip drums):
+- `identify_scale` on each track — verify all tracks agree on the same tonal center
+- `analyze_harmony` on chordal tracks — verify chord quality
+- `detect_theory_issues` with `strict=true` on each track — check for out-of-key notes, parallel fifths, voice crossing
+- **Interpret results against the intended scale**, not just C major
+- Report a clear tuning table to the user: which tracks are clean, which have issues
+- Fix wrong notes with `modify_notes` before proceeding
+
+## Step 11: Perception check
+If the M4L Analyzer is connected:
+- `get_master_spectrum` — check spectral balance (sub should be present but not >60% for most genres)
+- `get_master_rms` — check levels aren't clipping
+- `get_detected_key` — verify the analyzer agrees with the intended key
+
+If not connected, use `capture_audio` + `analyze_loudness` + `analyze_spectrum_offline` for offline analysis.
+
+## Step 12: Fire the scene
+Fire to listen, iterate based on feedback.
+
+Use the livepilot-core skill for all tool calls. Verify after each step. Keep the user informed of what you're doing and why.
+
+## Branch-Native Variations
+
+When the user wants options instead of a single committed beat ("try a few variants", "surprise me with the drum feel", "what else could this be?"), use the exploratory flow from livepilot-core SKILL.md (Flow B). Emit 2-3 seeds that differ in *how* they interpret the vibe — for example one `semantic_move` seed with `make_punchier`, one `freeform` seed describing a swung / pushed-beat variation with a pre-compiled plan, one `synthesis` seed that changes the kick's synthesis rather than its pattern. Set `get_session_kernel(freshness=0.6-0.8)` and `creativity_profile="alchemist"` when the user hasn't given concrete parameters.

package/livepilot/commands/evaluate.md

@@ -0,0 +1,49 @@
+---
+name: evaluate
+description: Evaluate recent changes — run the full before/after evaluation loop and recommend keep or undo
+---
+
+Run the universal evaluation loop on recent production changes.
+
+1. **Check capability state** — `get_capability_state` to see what evaluation modes are available:
+   - `normal` — full measured evaluation with analyzer data
+   - `measured_degraded` — analyzer online but stale data
+   - `judgment_only` — no analyzer, parameter-level heuristics only
+   - `read_only` — session disconnected
+
+2. **Ensure analyzer** — if mode is `judgment_only`, try to get full perception:
+   - `find_and_load_device(track_index=-1000, device_name="LivePilot_Analyzer")`
+   - Wait 2s, then `get_master_spectrum` to test the bridge
+   - If bridge disconnected: `reconnect_bridge`
+   - If still unavailable: proceed with `judgment_only` but tell the user
+
+3. **Get the last move** — `get_last_move` to understand what was changed. If no recent move, `get_recent_actions` for history.
+
+4. **Ask what the goal was** — what were they trying to achieve? More clarity? Wider stereo? Punchier drums?
+
+5. **Compile the goal** — `compile_goal_vector(goal_description, mode="improve")`
+
+6. **Capture current state** — full perception snapshot:
+   - `get_master_spectrum` + `get_master_rms` (if analyzer available)
+   - `get_track_meters(include_stereo=true)` — verify all tracks producing audio
+   - `get_mix_snapshot` — full volume/pan/send state
+   - Optionally: `capture_audio` + `analyze_loudness` + `analyze_spectrum_offline` for ground truth
+
+7. **Undo the change** — `undo()` to restore the before state
+
+8. **Capture before state** — same reads as step 6
+
+9. **Redo the change** — `redo()` to restore the after state
+
+10. **Evaluate** — `evaluate_move(before_snapshot, after_snapshot, goal)` or use engine-specific:
+    - Mix changes: `evaluate_mix_move`
+    - Composition changes: `evaluate_composition_move`
+    - Multi-dimensional: `evaluate_with_fabric`
+
+11. **Report results** — show: score (0-1), keep_change recommendation, goal_progress, collateral_damage, dimension changes
+
+12. **Act on recommendation:**
+    - If `keep_change=true` — keep, suggest `memory_learn` if score > 0.7
+    - If `keep_change=false` — `undo()`, explain why (collateral damage, goal regression)
+
+Use the livepilot-evaluation skill for the full evaluation loop details.

package/livepilot/commands/memory.md

@@ -0,0 +1,22 @@
+---
+name: memory
+description: Browse, search, and manage your saved technique library
+---
+
+Show the user's technique memory library. Follow these steps:
+
+1. Call `memory_list(limit=20)` to get an overview of saved techniques
+2. Format as an organized list grouped by type:
+   - **Beats** — beat_pattern techniques
+   - **Device Chains** — device_chain techniques
+   - **Mix Templates** — mix_template techniques
+   - **Browser Pins** — browser_pin techniques
+   - **Preferences** — preference techniques
+3. For each technique show: name, summary, rating (stars), favorite marker, tags
+4. Show total count and breakdown by type
+
+After presenting, ask if the user wants to:
+- **Search** — "search for [query]" → use memory_recall
+- **View details** — "show me [name]" → use memory_get
+- **Delete** — "delete [name]" → use memory_delete (confirm first)
+- **Rate** — "rate [name] 5 stars" → use memory_favorite

package/livepilot/commands/mix.md

@@ -0,0 +1,47 @@
+---
+name: mix
+description: Mixing assistant — analyze and balance track levels, panning, and sends
+---
+
+Help the user mix their session using the V2 orchestration pipeline.
+
+## Orchestration Flow
+
+1. **Session kernel** — `get_session_kernel(request_text=<user's request>, mode="improve")` for the full turn snapshot
+2. **Route** — `route_request(<user's request>)` to get engine routes + semantic move recommendations
+3. **Ensure analyzer** — if `get_master_spectrum` errors, load it: `find_and_load_device(track_index=-1000, device_name="LivePilot_Analyzer")`. If bridge disconnected, try `reconnect_bridge`.
+
+## Analysis Phase
+
+4. **Quick status** — `get_mix_summary` for track count, dynamics, stereo, issues
+5. **Run critics** — `get_mix_issues` for problems. `get_masking_report` for frequency collisions.
+6. **Spectral check** — `get_master_spectrum` for 9-band balance (sub_low → air). Genre targets:
+   - Hip-hop: sub/sub_low dominant, centroid 400-800 Hz
+   - Electronic / microhouse: sub_low carries the kick (Villalobos), centroid 800-1500 Hz
+   - Ambient: mid-focused, low sub_low + sub, centroid 500-1000 Hz
+7. **Musical intelligence** — `detect_role_conflicts` to find tracks competing for the same space. `detect_repetition_fatigue` if arrangement feels stale.
+
+## Decision Phase
+
+8. **Propose semantic moves** — `propose_next_best_move(request_text=<user's request>)` for ranked suggestions (e.g., `make_punchier`, `widen_stereo`, `tighten_low_end`)
+9. **Preview chosen move** — `preview_semantic_move(move_id)` to see the full compile plan before executing
+10. **Rank by taste** — if user has history, `rank_moves_by_taste(move_specs)` to personalize ordering
+
+## Execution Phase
+
+11. **Apply with approval** — `apply_semantic_move(move_id, mode="improve")` returns the compiled plan. Present it to the user: "I'd suggest: push Drums to 0.75, pull Pad to 0.25. Shall I do it?"
+12. **Verify after EVERY change** — read `value_string` in response, call `get_track_meters(include_stereo=true)`, check no track went silent
+13. **Capture + analyze** — `capture_audio` then `analyze_loudness` for LUFS/LRA, `analyze_spectrum_offline` for centroid/balance
+14. **Evaluate** — `evaluate_mix_move` with before/after snapshots. If `keep_change` is false, `undo` immediately.
+
+## Summary
+
+15. **Report** — "What I did / what improved / what I protected / what remains"
+16. **Session memory** — `add_session_memory` for notable decisions
+17. **Taste update** — successful moves update the TasteGraph automatically
+
+For deeper critic-driven iterative improvement, use the livepilot-mix-engine skill.
+
+## Branch-Native Exploratory Mode
+
+When the user asks for multiple options or is vague about direction ("try a few things", "I don't know what's wrong — just make it better", "what would you do?"), use Flow B from livepilot-core SKILL.md. Build 2-3 `create_experiment` seeds with different angles — for example one `semantic_move` seed for a conventional fix, one `freeform` seed for an unconventional approach (sidechain from an unexpected source, mid/side EQ instead of stereo EQ, etc.), one `synthesis` seed if the root cause is instrument-level (PR9+). Set `get_session_kernel(freshness=0.7)` to nudge branches away from the safest option.

package/livepilot/commands/perform.md

@@ -0,0 +1,42 @@
+---
+name: perform
+description: Performance mode — enter a safety-constrained live performance context with energy tracking and safe moves
+---
+
+Enter performance mode with safety constraints and energy tracking.
+
+## Orchestration Flow
+
+1. **Session kernel** — `get_session_kernel(request_text="live performance", mode="improve")`
+2. **Route** — `route_request("live performance")` → workflow_mode should be `performance_safe`
+3. **Performance state** — `get_performance_state` for current scene, energy level, and safe moves
+
+## Safety-First Rules
+
+- **NEVER** execute moves rated "high risk" during performance
+- **ALWAYS** use `get_performance_safe_moves` before ANY change
+- Only fire scenes, adjust volumes, and trigger safe effects
+- No device loading, track creation, or destructive operations
+
+## Performance Tools
+
+4. **Safe moves** — `get_performance_safe_moves` for available actions
+5. **Scene handoff** — `plan_scene_handoff` for safe transitions between scenes
+6. **Energy tracking** — monitor energy level across scene transitions
+7. **Semantic moves** — only performance-safe semantic moves:
+   - `smooth_scene_handoff` — safe transition between scenes
+   - Gesture templates: `pre_arrival_vacuum`, `re_entry_spotlight`
+
+## Live Dashboard
+
+8. **Monitor** — `get_track_meters(include_stereo=true)` for real-time levels
+9. **Spectrum** — `get_master_spectrum` for frequency balance during performance
+10. **Playing clips** — `get_playing_clips` to see what's active
+
+## Recovery
+
+11. **If something goes wrong** — `undo` immediately
+12. **Emergency** — `stop_all_clips` if audio goes haywire
+13. **Check safety** — `check_safety` to verify constraints are holding
+
+Keep the user informed of what's happening. Never make surprise changes during a live set.

package/livepilot/commands/session.md

@@ -0,0 +1,13 @@
+---
+name: session
+description: Get a full overview of the current Ableton Live session
+---
+
+Get a comprehensive overview of the current Ableton Live session by calling `get_session_info`. Format the results as an organized report showing:
+
+1. **Transport** — tempo, time signature, playing state, loop settings
+2. **Tracks** — list all tracks with type, name, color, arm/mute/solo state
+3. **Scenes** — scene names and clip occupancy
+4. **Master** — master volume and devices
+
+After presenting the overview, ask if the user wants to dive deeper into any specific track, device, or area.

package/livepilot/commands/sounddesign.md

@@ -0,0 +1,58 @@
+---
+name: sounddesign
+description: Sound design workflow — load instruments and effects, shape parameters for a target sound
+---
+
+Guide the user through designing a sound using the V2 orchestration pipeline.
+
+## Orchestration Flow
+
+1. **Session kernel** — `get_session_kernel(request_text=<user's request>, mode="improve")`
+2. **Route** — `route_request(<user's request>)` for engine routes + semantic moves
+
+## Design Phase
+
+3. **Ask about target** — what character? (warm pad, aggressive bass, shimmering lead, etc.)
+4. **Choose instrument** — `search_browser` to find devices, `load_browser_item` to load
+5. **Verify health** — `get_device_info` to confirm plugin initialized. Read `value_string` from `get_device_parameters` to understand actual units.
+6. **Shape sound** — `set_device_parameter` or `batch_set_parameters`. **ALWAYS read `value_string` in response** to confirm Hz/dB/% values make sense.
+7. **Verify after every change** — `get_track_meters(include_stereo=true)` — if stereo drops to 0, the effect killed the signal.
+
+## Critic Phase
+
+8. **Run critics** — `analyze_sound_design(track_index)` for static timbre, missing modulation, spectral imbalance
+9. **Plan improvements** — `plan_sound_design_move(track_index)` for suggested changes
+10. **Patch model** — `get_patch_model(track_index)` to see chain structure and controllable blocks
+
+## Effects & Automation
+
+11. **Add effects** — load with `find_and_load_device(track_index, device_name)`. Verify health.
+12. **Organic movement** — `apply_automation_shape(curve_type="perlin")` for filter/send drift
+13. **Automation recipes** — `apply_automation_recipe` for breathing, vinyl_crackle, auto_pan. Verify after applying.
+
+## Evaluation
+
+14. **Perception check** — `get_master_spectrum` or `capture_audio` + `analyze_spectrum_offline`
+15. **Evaluate** — `evaluate_move(goal_vector, before_snapshot, after_snapshot)` to score improvement
+
+## Summary
+
+16. **Report** — "What I changed / what improved / what I protected"
+17. **Memory** — if score > 0.7, suggest `memory_learn` to save the technique
+
+For critic-driven iterative refinement, use the livepilot-sound-design-engine skill.
+
+## Branch-Native Exploratory Mode
+
+For open-ended sound design ("design me something that feels like X", "make this more interesting", "surprise me"), use Flow B from livepilot-core SKILL.md. Prefer `source="synthesis"` seeds for any request that calls for genuinely different timbres — PR9+ introduces native-synth adapters (Wavetable, Operator, Analog, Drift, Meld) that can propose per-device parameter branches. Pass `synth_hints` on `get_session_kernel` when you know which tracks or devices to focus on:
+
+```
+get_session_kernel(
+    request_text="make the pad more alive",
+    freshness=0.75,
+    creativity_profile="sculptor",
+    synth_hints={"track_indices": [pad_track_idx], "preferred_devices": ["Wavetable", "Operator"]},
+)
+```
+
+Seeds with `source="synthesis"` that arrive without a compiled plan will (post-PR9) be compiled by the synthesis_brain; pre-PR9 they must ship with a freeform plan attached via `compiled_plans`.

package/livepilot/rubrics/default_preset_check.md

@@ -0,0 +1,82 @@
+# §1 — Default Preset Energy is Forbidden
+
+Mechanical check: when a melodic-role track (bass / pad / lead) is loaded
+with a banned default synth and no preset has been applied, flag it.
+
+CLAUDE.md §1: "Never reach for Analog / Poli / Drift / Meld as a default for
+bass / pad / lead. They read as 'generic AI synth' and have been rejected
+multiple times."
+
+This rubric does NOT ban these synths outright — it bans them in their
+**factory-default state** for melodic roles. A programmed Drift bass with a
+preset name and modulated parameters is fine. A naked `Drift` device with
+display name `"Drift"` is the chronic anti-pattern.
+
+## Inputs
+
+```
+{
+  "tracks": [
+    {
+      "index": int,
+      "name": str,
+      "devices": [
+        {"class_name": str, "name": str, ...},
+        ...
+      ],
+    }, ...
+  ],
+}
+```
+
+The first instrument-class device on each track is the candidate. `name` is
+Ableton's display name for the device — for a freshly-loaded Drift it
+equals `"Drift"`; for a preset-loaded Drift it equals the preset stem.
+
+## Banned default class names
+
+| Class name | Reason |
+|------------|--------|
+| Drift  | Generic subtractive — reach for Granulator III / Wavetable / sample-based instead |
+| Analog | Same reason |
+| Poli   | M4L opaque — sound-design critic can't analyze |
+| Meld   | M4L opaque — sound-design critic can't analyze |
+
+## Trigger conditions for banned roles
+
+| Role | Triggers |
+|------|----------|
+| bass | banned class + default name |
+| pad  | banned class + default name |
+| lead | banned class + default name |
+
+Other roles (kick, snare, hat, perc, vox, atmos, fx, unknown) are
+**not flagged** by this rubric.
+
+## Default-name detection
+
+A device is considered "default-loaded" when its display `name` matches its
+`class_name` exactly (case-insensitive). For example:
+- `class_name="Drift", name="Drift"` → default
+- `class_name="Drift", name="BoC Wash"` → preset applied → not default
+
+## Criteria
+
+### `no_banned_default_instruments`
+
+- All tracks pass → **pass**
+- One or more banned-default + banned-role tracks → **fail**
+
+### `prefer_curated_or_under_used`
+
+Advisory: when the first instrument is on the user's under-used list
+(Operator, Wavetable, Sampler, Simpler, Granulator III, Tension, Collision,
+Electric, Drum Synths, Inspired-by-Nature variants), praise it. This is a
+**signal-only** check, never blocks — it surfaces in evidence.
+
+## What this rubric does NOT check
+
+- Sound-design depth — see §2 rubric (Phase 2b)
+- Whether the preset is musically right for the genre — that's taste
+- Whether the player has been told to use a banned class explicitly
+  ("subtractive" / "analog texture") — context lives outside the snapshot

package/livepilot/rubrics/layer_accumulation.md

@@ -0,0 +1,79 @@
+# §7.3 — Layer Accumulation Rubric
+
+Mechanical checks on track count and per-role volume balance, derived from
+CLAUDE.md §7.3 ("no layer accumulation with low volume — 5–6 GREAT layers
+prominent > 12 mediocre layers buried") and the track-meter hierarchy
+feedback memory.
+
+This rubric is graded by `mcp_server.grader.client.evaluate("layer_accumulation", state)`.
+All checks are pure Python — zero LLM calls, zero token cost.
+
+## Inputs
+
+The grader expects a `state` dict shaped like:
+
+```
+{
+  "tracks": [
+    {
+      "index": int,
+      "name": str,
+      "mixer": {"volume": 0.0–1.0, "panning": -1.0–1.0},
+      "devices": [{"class_name": str, ...}, ...],
+      "meter": {"peak": 0.0–1.0} | None,   # optional
+    }, ...
+  ],
+}
+```
+
+In production this comes from `get_session_info` + per-track `get_track_info`
++ optional `get_track_meters`. In tests, synthesize the dict directly.
+
+## Criteria
+
+### `track_count_within_limit`
+
+Total non-master, non-return tracks under the sustainable threshold.
+
+- ≤ 8 tracks → **pass**
+- 9–11 tracks → **warn** (approaching the §7.3 ceiling)
+- ≥ 12 tracks → **fail** (delete buried layers, feature 5–6 great ones)
+
+### `no_extreme_buried_track`
+
+Any track with `mixer.volume < 0.15` is a buried layer that should be
+deleted unless it's explicitly tagged ghost. Track-name keyword match:
+`ghost`, `_g`, `gh `.
+
+- All buried tracks are ghost-tagged → **pass**
+- Any non-ghost track at volume < 0.15 → **fail** with track names
+
+### `role_volume_hierarchy`
+
+Per-track role inferred via `infer_role` from `audit/checks.py`. Volume
+must land within the role's permitted band:
+
+| Role  | Band         | Why |
+|-------|--------------|-----|
+| kick  | [0.60, 0.85] | anchor — must dominate |
+| bass  | [0.60, 0.85] | anchor — must carry |
+| snare | [0.55, 0.80] | groove |
+| hat   | [0.40, 0.70] | groove — often quieter |
+| perc  | [0.40, 0.65] | groove |
+| lead  | [0.50, 0.80] | accent / anchor |
+| vox   | [0.55, 0.85] | anchor |
+| pad   | [0.25, 0.50] | atmosphere — hide, don't dominate |
+| atmos | [0.25, 0.45] | atmosphere |
+| fx    | [0.30, 0.70] | variable |
+| unknown | [0.30, 0.80] | generous default |
+
+- All tracks within role band → **pass**
+- Any track outside band → **warn** (not blocking — could be deliberate;
+  the grader flags it for review, not auto-undo)
+
+## What this rubric does NOT check
+
+§5 layer-by-layer precision (timbre, sequence, stereo, modulation, automation)
+— that's `audit_layer` territory and gets its own rubric in Phase 2. This
+rubric is intentionally narrow: it catches the **layer accumulation**
+anti-pattern only.

package/livepilot/rubrics/layer_precision.md

@@ -0,0 +1,79 @@
+# §5 — Layer-by-Layer Precision
+
+Wraps the seven `audit/checks.py` functions into one rubric. Each criterion
+runs the relevant audit check across every track and aggregates per-track
+results into a single criterion verdict (worst-case severity).
+
+CLAUDE.md §5: "For EVERY layer (drums, bass, lead, pad, vox, perc): solo +
+spectrum check tone, critique sequence (swing/humanization/ghosts/per-bar
+variation/micro-timing), check stereo image, plan automation/pitch-bends/
+filter sweeps. Same depth as the 2026-04-25 hi-hat critique. No layer is
+'done' without this checklist."
+
+This rubric is the most data-hungry of the set. Each criterion degrades to
+n/a gracefully when the corresponding signal is missing on every track.
+
+## Criteria
+
+### `timbre_per_track` (§5.1)
+Calls `audit_checks.check_timbre(role, fingerprint)`. Requires per-track
+`fingerprint` (from `get_master_spectrum` after solo).
+
+- All tracks pass → **pass**
+- Any track has wrong-band dominance → **fail** (sample is wrong for role)
+- Off-band but secondary in expected range → **warn**
+
+### `sequence_per_track` (§5.2)
+Calls `audit_checks.check_sequence(role, notes_per_clip)`. Requires per-track
+`notes_per_clip` (from `get_notes` per clip slot).
+
+- Drum-role tracks need humanization + ghost notes
+- Pad/lead/bass need pitch + duration variation
+- Audio tracks → n/a (no notes)
+
+### `stereo_per_track` (§5.3)
+Calls `audit_checks.check_stereo(role, track)`. Pure pan-position check.
+
+- Bass panned > 0.05 → **warn** (sub should be center for translation)
+- Kick/snare panned > 0.15 → **warn**
+
+### `masking_per_track` (§5.4)
+Calls `audit_checks.check_masking(track_index, masking_report)`. Requires
+session-level `masking_report` from `get_masking_report`.
+
+- Any high-severity collision → **fail**
+- Mid-severity collision → **warn**
+- No `masking_report` provided → criterion **n/a** (whole rubric still runs)
+
+### `modulation_per_track` (§5.5 + §4)
+Calls `audit_checks.check_modulation(role, devices, has_clip_automation,
+wavetable_mod_routings)`. More accurate than the standalone
+`modulation_presence` rubric — analyzes parameter routings (`Fe < Env`,
+`Pe < Env`, etc.) on the actual instrument.
+
+### `params_per_track` (§5.6 + §2)
+Calls `audit_checks.check_params(role, devices)`. Detects "unprogrammed"
+instruments — pad/lead/bass with ≥3 key shaping parameters at default values.
+Drum roles auto-pass (single-sample minimal-shaping is correct by design).
+
+### `effects_per_track` (§5.8)
+Calls `audit_checks.check_effects(role, devices)`. Verifies role-appropriate
+effect chain coverage:
+- kick / snare / bass / vox / lead → EQ required
+- bass / vox / lead → compressor required
+- pad / atmos / vox / lead → reverb or delay required
+
+## Aggregation
+
+Per criterion: worst severity wins. If any track fails → criterion fails.
+Otherwise if any warns → warns. Otherwise pass. Tracks where the audit
+returns n/a (data missing, role doesn't apply) are filtered before
+aggregation — they don't drag the criterion to n/a unless every track is n/a.
+
+Whole-rubric `passed` is False iff any criterion is fail (blocking).
+
+## What this rubric does NOT cover
+
+- Sample audition (§5.7) — slice classification — niche, separate rubric later
+- Aesthetic register (§8) — taste, never rubric-graded
+- Per-track meter levels — that's the §7.3 `layer_accumulation` rubric