feat: griff split in the browser — paginated per-phrase chunks (auto-split #2b: web)

docs/decisions.log.md

@@ -1229,3 +1229,25 @@ Architectural decisions go to [`adr/`](adr/) instead.
   determinism is unaffected (zip never consumes randomness on the read
   path), the lean MIDI-only wasm path still exists behind
   `default-features = false`, and ADR-0024's egui M2 plan is untouched.
+
+- 2026-06-18 — In the context of auto-split **#2b** (the web half of
+  feature #2, after the core+CLI #2a landed in PR #70), facing that the
+  browser capture tool only emitted **one chunk per whole track** while
+  `griff split` already produces **one corpus chunk per phrase**, we decided
+  to **add a single `#[wasm_bindgen] split_chunks_json` that mirrors the CLI
+  split in the browser**: it reuses core's now-public `slice::extract_bars`
+  + `split::bar_segments` and the existing web `build_chunk_meta_record`,
+  cutting the selected track at its detected phrase boundaries into one
+  `chunk.json` per sounding phrase — single-track contract, so phrases
+  silent on the detected track are dropped, never re-measured on another
+  track (the Codex P2 fix from PR #70) — with inclusive `bar_range` and
+  ids/titles suffixed `_p<N>`. The capture panel gains a phrase **pager**
+  (review), per-phrase **playback** (reusing the transport synth on each
+  phrase's rebased notes), and per-phrase / all-phrase download. Against
+  hoisting a shared `phrase_chunks` helper into core: the assembly reads
+  curate inputs that differ per front (CLI prompts vs JS string args), so
+  web mirrors the CLI exactly as `build_chunk_meta_record` already mirrors
+  `build_chunk_meta` — the *primitives* are shared via core, the *assembly*
+  is duplicated and kept in step (both fronts now test the track-consistency
+  rule). Accepted: `arrange` generation is untouched, and `web/dist` stays
+  gitignored (CI rebuilds it on deploy).

web/README.md

@@ -19,6 +19,11 @@ with live controls for **mode**, **seed**, **register offset**, and **pitch
 spread** (the ADR-0023 `VariationControl`, audible on the grid-locked modes).
 Deterministic: the same controls always produce the same result.
 
+It also **captures corpus chunks** from a loaded tab (ADR-0026): annotate a track
+with rights + metadata and download a `chunk.json`, or **auto-split** the track
+into one `chunk.json` per detected phrase — the browser twin of `griff split`
+(#2b) — and page through the phrases to review, play, and download each.
+
 ## Build & run locally
 
 ```sh
@@ -45,12 +50,18 @@ Two `#[wasm_bindgen]` functions, called from the generated ES module
 | --- | --- | --- |
 | `arrange` | `(mode, seed, offset, variation, track) -> String` | arrange over part A (`track<0` = built-in sample, `track>=0` = the loaded score's track) |
 | `load_score` | `(bytes: &[u8]) -> String` | parse an uploaded MIDI or Guitar Pro file, stash the score, return a track summary |
+| `tag_palette_json` | `() -> String` | the swancore tag names in wire order, so the capture UI's indices line up |
+| `detect_boundaries_json` | `(track) -> String` | preview a track's S4 phrase boundaries |
+| `build_chunk_json` | `(track, …meta) -> String` | capture a whole track as one schema-v7 `chunk.json` (ADR-0026) |
+| `split_chunks_json` | `(track, …meta) -> String` | split a track into one `chunk.json` per detected phrase (#2b) |
 
 `mode`: 0 `rhythm_lock`, 1 `register_contrast`, 2 `call_response`,
 3 `support_layer`, 4 `octave_double`, 5 `counter_melody`.
 
 Arrange JSON: `{ppqn, tempo, realized_spread, error, tracks:[{name, role, notes:[{p,s,d,v}]}]}`.
 Load summary JSON: `{error, ppqn, tempo, bars, tracks:[{i, name, notes}]}`.
+Split JSON: `{error, chunks:[{id, title, bar_lo, bar_hi, notes:[{p,s,d,v}], chunk}]}` — each
+`chunk` is a download-ready `chunk.json` (a serialized `corpus::ChunkMeta`).
 
 ## Deploy
 
@@ -62,6 +73,7 @@ Load summary JSON: `{error, ppqn, tempo, bars, tracks:[{i, name, notes}]}`.
 
 - Audio is a placeholder WebAudio synth (sawtooth + envelope, A left / B right).
   A real SoundFont (guitar tone) is a follow-up.
-- You can load your own **MIDI** or **Guitar Pro** (`.gp3/.gp4/.gp5/.gpx`) file and
-  arrange over any of its tracks. Drag-drop and in-browser corpus curation /
-  download are follow-ups.
+- You can load your own **MIDI** or **Guitar Pro** (`.gp3/.gp4/.gp5/.gpx`) file,
+  arrange over any track, and curate corpus chunks from it — capture a whole
+  track or **auto-split it into per-phrase chunks** (#2b), reviewing and playing
+  each before download. Drag-drop is a follow-up.