tune(backend): narrate up to 36 events, not 30 (#600) #601

Merged

claude-bot merged 1 commit from tune/compose-cap-36 into main

2026-09-11 14:00:39 +00:00

claude-bot commented

2026-09-11 13:44:29 +00:00

Contributor

Closes #600 once measured on dev.

_COMPOSE_MAX_BEATS was sized to what "3-6 paragraphs" holds when a real session produced about 26 beats. Gemma 4 26B now verifies 85–95 events on the replay session. Even after #596 folds out the table admin, that leaves 43–60 story events, so the cap always binds. The #589 time-stratified pick then gives a dense stretch, like six reveals in three minutes, about two slots, and details there come and go between runs: the Thieves' Cant was in run 5's prose but not in runs 3, 4 or 6.

Change

_COMPOSE_MAX_BEATS goes from 30 to 36, and the compose prompt's "3-6 paragraphs" becomes "3-7 paragraphs", so the two instructions still agree.
The prose fallback prompts in audio_service are untouched. They summarise the transcript directly and aren't bound by this cap.
The comment, two docstrings and the unreleased #568 CHANGELOG entry now say 36. That entry ships in the same release, so it's corrected rather than contradicted by a second entry.
#568's "short summary plus full event log" decision stands. This widens the narration by a fifth; it doesn't narrate everything.

Checked

239 passed across test_compose_selection.py, test_event_log.py, test_beat_service.py, test_table_admin_beats.py and test_empty_hook.py. Every selection test refers to the constant, not the number.
ruff 0.4.4 check and format --check are clean.

Measurement

One summary-only dev rerun against run 6 (03b3acfa, 2,573 characters), looking at:

the length, which should stay short (roughly 3,000 characters at most)
whether dense-stretch details such as the Cant appear
whether the opening and hook hold

If the length grows past that or coverage doesn't move, this gets reverted in favour of bucket weighting.

🤖 Generated with Claude Code

Closes #600 once measured on dev. `_COMPOSE_MAX_BEATS` was sized to what "3-6 paragraphs" holds when a real session produced about 26 beats. Gemma 4 26B now verifies 85–95 events on the replay session. Even after #596 folds out the table admin, that leaves 43–60 story events, so the cap always binds. The #589 time-stratified pick then gives a dense stretch, like six reveals in three minutes, about two slots, and details there come and go between runs: the Thieves' Cant was in run 5's prose but not in runs 3, 4 or 6. ## Change - `_COMPOSE_MAX_BEATS` goes from 30 to **36**, and the compose prompt's "3-6 paragraphs" becomes **"3-7 paragraphs"**, so the two instructions still agree. - The prose fallback prompts in `audio_service` are untouched. They summarise the transcript directly and aren't bound by this cap. - The comment, two docstrings and the unreleased #568 CHANGELOG entry now say 36. That entry ships in the same release, so it's corrected rather than contradicted by a second entry. - **#568's "short summary plus full event log" decision stands.** This widens the narration by a fifth; it doesn't narrate everything. ## Checked - 239 passed across `test_compose_selection.py`, `test_event_log.py`, `test_beat_service.py`, `test_table_admin_beats.py` and `test_empty_hook.py`. Every selection test refers to the constant, not the number. - ruff 0.4.4 `check` and `format --check` are clean. ## Measurement One summary-only dev rerun against run 6 (`03b3acfa`, 2,573 characters), looking at: - the length, which should stay short (roughly 3,000 characters at most) - whether dense-stretch details such as the Cant appear - whether the opening and hook hold If the length grows past that or coverage doesn't move, this gets reverted in favour of bucket weighting. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-09-11 13:44:30 +00:00

tune(backend): narrate up to 36 events, not 30 (#600 )

CI / Bot/backend version sync (pull_request) Successful in 48s

Details

CI / Backend lint (ruff) (pull_request) Successful in 1m0s

Details

CI / Summarisation accuracy eval harness (stub provider) (pull_request) Successful in 1m29s

Details

CI / Bot tests and audit (pull_request) Successful in 2m37s

Details

CI / Frontend tests, audit, and build (pull_request) Successful in 2m43s

Details

CI / Docker image build (pull_request) Successful in 4m50s

Details

CI / Backend migration, tests, and audit (pull_request) Successful in 12m27s

Details

CI / Synthetic session harness (no GPU, no LLM) (pull_request) Successful in 15m12s

Details

18e6e9f907

_COMPOSE_MAX_BEATS was sized to what "3-6 paragraphs" holds when a real
session produced about 26 beats, so the typical session sat under it.
Gemma 4 26B now verifies 85-95 events on the replay session and, after
#596 folds out the table admin, still leaves 43-60 story events: the cap
always binds, and the time-stratified pick (#589) gives a dense stretch
like six reveals in three minutes about two slots, so details there came
and went between runs.

36 widens that by a fifth. The compose prompt now says "3-7 paragraphs"
so the two instructions still agree, and the short-summary-plus-event-log
decision from #568 stands. Every selection test refers to the constant,
not the number, and all pass; the unreleased #568 changelog entry is
corrected to match rather than contradicted by a second one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

claude-bot scheduled this pull request to auto merge when all checks succeed

2026-09-11 13:44:48 +00:00

claude-bot merged commit c8116d7d54 into main

2026-09-11 14:00:39 +00:00

claude-bot deleted branch tune/compose-cap-36

2026-09-11 14:00:39 +00:00

claude-bot referenced this pull request from a commit

2026-09-11 14:00:40 +00:00

Merge pull request 'tune(backend): narrate up to 36 events, not 30 (#600)' (#601) from tune/compose-cap-36 into main

claude-bot referenced this pull request

2026-09-11 14:15:57 +00:00

Raise the compose cap from 30 to 36 now that table admin no longer competes for it #600