zhila/docs/P2.md

P2 · arrangement, render, agent

P2 turns the loop into a thing that can be played, rendered and performed with an agent. It is delivered in three slices.

P2a · the arrangement

Four 2-bar sections (A–D) form an 8-bar loop. Each section is a full Pattern (5 rows × 16 steps, with per-row faces). The engine walks 64 steps, picks the section and the pattern step, and triggers the section's rows; the bar clock runs 1–8. The state carries arrangement: [Pattern; 4], active_section, and pattern = the active section for the editors.

Commands: select_section { index }, clear_section { index }, copy_section { from, to }, event arrangement { sections, active }. Pattern edits apply to the active section. Select is persisted but not undoable; clear/copy push history. Sections, the active index and their history are stored in SQLite (arrangement, active_section columns, migrated with ensure_column) and restored on load.

Surface: the quarry gets a section strip (A–D with note counts, copy →, clear); the pattern grid edits the active section. The descent draws the 64-step road, bar labels 01–08, section seams and letters A–D, with the active section emphasized; the playhead follows the 8-bar clock.

Verification:

• cargo test -p zhila-core arrangement: sections independent, select/copy/clear, undo, material carries four sections, loop_bars = 8.
• node scripts/persistence-smoke.mjs: imports, edits section B, copies A→C, cuts, restarts, verifies the arrangement, active B, B's step 0 = 0, C = A, and undo/redo.
• npm --prefix ui run arrangement-smoke: four sections, select B, edit a step, switch to the nave, play, screenshot preview-p2-arrangement.png.

Limits: exactly four sections of two bars; no insert/reorder/length; select is not undoable; no per-section mute.

P2b · render

zhila_engine::render_arrangement(RenderRequest) drives the same AudioState offline: no cpal device, the same voices, sample faces, gains, master and the 8-bar sections, plus a 1.5 s tail. Command::render is intercepted by the host, rendered in spawn_blocking, written with hound as 48 kHz stereo 32-bit float to <project>/renders/<project>-<ms>.wav, and announced with Event::rendered { path, duration_sec }; the command result is the unchanged state. Render is not a project edit and does not push history.

Surface: render in the top rail; the wire logs the send and the rendered path; the button's title keeps the last path.

Verification: cargo test -p zhila-engine (non-silent 16.5 s buffer, correct frame count); node scripts/render-smoke.mjs (status 16.5 s, peak 0.442, 6.3 MB, float 48 kHz stereo, event duration matches); npm --prefix ui run render-ui-smoke (button → wire path, screenshot preview-p2-render.png).

Limits: WAV only, stereo float, fixed 48 kHz and 1.5 s tail; no stems, normalisation or section ranges.

P2c · the choir

crates/zhila-daemon/src/agent.rs is the performer. It receives the project state and live meter as text, a system prompt with the ZHILA rules, and an OpenAI-compatible tool list. Safe verbs (play, stop, strike, strike_face, render) execute immediately; project verbs (tempo, gains, pattern, faces, sections, cuts, undo/redo) are collected into one proposal stored with an id. The hand approves or rejects; approval applies every command with Actor::Agent, saves the project, and emits the normal events plus an agent confirmation.

Wire: agent_ask { text }, agent_approve { id }, agent_reject { id }, agent_reset; events agent_message { role, text }, agent_proposal { id, description, commands }, agent_resolved { id, applied }; agent_history { messages } on hello. The host keeps the conversation and pending proposals in memory.

Config: ZHILA_AGENT_KEY or DEEPSEEK_API_KEY enables the live provider (ZHILA_AGENT_URL, default https://api.deepseek.com; ZHILA_AGENT_MODEL, default deepseek-chat). No key, or ZHILA_AGENT_MOCK=1, uses the deterministic mock: "tempo" proposes 132 bpm, "listen" strikes the bass, "play"/"stop"/"render" perform, "bass" proposes a gain.

Surface: the choir room (top rail) with the conversation, proposals (commands labelled, approve/reject), a listen button, an input, and a readout of sections, levels, bpm and cores. The agent's voice is Cormorant; the commands are mono.

Verification: node scripts/agent-smoke.mjs (mock: ask → proposal → approve → tempo 132, resolved, history); npm --prefix ui run agent-ui-smoke (choir ask/approve, readout 132, screenshot preview-p2-agent.png); cargo test -p zhila-daemon (mock turn, tool mapping).

Limits: in-app only, no MCP; one tool round per ask; the conversation is daemon memory; the mock is the default without a key; the host restart clears the chat (the project keeps the approved edits).

P2 acceptance

• Arrangement: four 2-bar sections, 8-bar playback, per-section editing, persisted and undoable.
• Render: a valid 48 kHz stereo float WAV of the arrangement (16.5 s, non-silent, peak 0.442).
• Agent: ask → proposal → approve → a project edit applied with Actor::Agent, on the same wire.
• The native Tauri app hosts all of it in-process; the browser path uses the standalone daemon.
• ./scripts/check.sh, the persistence smoke and the three P2 smokes pass.