livepilot 1.26.0 → 1.26.1

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

package/livepilot/rubrics/modulation_presence.md

@@ -0,0 +1,63 @@
+# §4 — Modulation > Static
+
+Mechanical check: every melodic/harmonic layer (bass / pad / lead / vox /
+atmos) should have at least one form of motion — a modulation-matrix entry,
+an LFO routing producing audible change, or a clip-automation envelope.
+
+CLAUDE.md §4: "Static MIDI at default velocity ≈ 'didn't try'. Every
+melodic/harmonic layer should have AT LEAST one parameter moving over time."
+
+## Inputs
+
+The grader requires per-track modulation signals to be populated by the
+caller (the `audit_layer` orchestrator already computes both):
+
+```
+{
+  "tracks": [
+    {
+      "index": int,
+      "name": str,
+      "devices": [...],
+      "modulation_count": int,        # sum of mod-matrix non-zero entries
+      "has_clip_automation": bool,    # any clip on track has automation
+    }, ...
+  ],
+}
+```
+
+Missing fields are degraded gracefully:
+- Track has neither key → reported as `unknown`, doesn't pass or fail
+- All checked tracks unknown → criterion returns `n/a`
+
+## Roles required to have motion
+
+bass · pad · lead · vox · atmos
+
+Drum-role tracks (kick / snare / hat / perc) are excluded — sequencer
+humanization is critiqued by the §5 layer-precision rubric, not this one.
+FX tracks are also excluded.
+
+## Criterion
+
+### `melodic_layers_have_motion`
+
+- All checked melodic-role tracks have `modulation_count > 0` OR
+  `has_clip_automation == True` → **pass**
+- One or more static melodic-role tracks → **warn** (advisory; not blocking)
+- No melodic-role tracks present, or all unknown → **n/a**
+
+## Why advisory, not blocking
+
+A stab patch with deliberate static behavior (one-shot pluck, plocked
+bass) is musically valid. The grader can't distinguish "static by intent"
+from "static by neglect" — so it surfaces the layer for review rather than
+auto-undoing. Promote to blocking in a future phase if false-positive
+rate stays low.
+
+## What this rubric does NOT check
+
+- Whether the modulation is **musical** — quality of motion is taste
+- Internal LFOs of opaque curated presets (Vector / Wavetable .adg) —
+  per the standing-rule memory, those are off-limits to modulate
+- Pitch-bend / portamento — handled by the §5 sequence check

package/livepilot/rubrics/sound_design_depth.md

@@ -0,0 +1,40 @@
+# §2 — Sound Design = Instrument Programming
+
+Single-criterion rubric isolating the §5.6 instrument-parameter check from
+the full layer-precision rubric. Runnable on its own when the agent claims
+"I added sound design" but actually only added effects.
+
+CLAUDE.md §2: "Sound design = instrument parameter programming, NOT effects
+chains. Adding Saturator/Redux/Shifter is EFFECT DESIGN, not sound design.
+Real sound design sculpts the source at the instrument/sampler level
+(envelopes, LFO routing, filter envelope, pitch modulation, sample start
+mod, spread, detune)."
+
+## Criterion
+
+### `params_per_track`
+Calls `audit_checks.check_params(role, devices)`. Detection:
+- Inspects the first native-instrument device on each track
+- Looks at parameter values for `Fe < Env`, `Pe < Env`, `Spread`, `Detune`,
+  `Unison`, etc. (the `_SUSPICIOUS_AT_ZERO` set)
+- A param at exactly 0 / factory default is "untouched"
+- For pad / lead / bass roles: ≥3 untouched key params → **fail** with
+  `unprogrammed_instrument` issue
+- For other roles: ≥4 untouched → **warn** with `many_default_params`
+- Drum roles auto-pass — minimal shaping is correct by design
+
+The check has built-in escape hatches: an `Fe < Env` of 0 is fine when
+`Fe On` is also 0 (filter envelope deliberately disabled). Same for pitch.
+
+## What this rubric does NOT check
+
+- Effects chain depth — §5 `effects_per_track` covers that
+- Whether the programmed values are musically right — taste
+- 3rd-party VST/AU instruments — `check_params` returns n/a (no native
+  parameter readouts available)
+
+## Why this exists alongside §5
+
+The full §5 rubric is heavyweight (7 criteria, 6+ data sources). When the
+user is iterating fast on sound design specifically, running just this
+rubric is faster and the brief is sharper.