Incremental (append-only) session summarization — stop re-summarizing settled history

Completed Brief #60 on branch flower/incremental-summarization. Commit: - 9afc4e8 Add incremental session summarization Scope: - Added session_segments.start_event_ordinal/end_event_ordinal and sessions.summarized_until_event_ordinal with model casts. - Made SegmentSummarizer/AiSegmentSummarizer accept an optional tail start ordinal and preserve normalized event boundary ordinals. - Reworked SegmentSession to preserve settled segment rows, summarize only from the active segment start, update the active row in place, append newly detected tail segments, and regenerate sessions.summary cheaply from persisted segment summaries. - Kept #58 too_large/subdivide/failure circuit breaker behavior intact. - Confirmed EmbedChunks keys by segment morph/id and added coverage that settled segment chunk/embedding identity survives a growing-session resummary. Verification: - ~/bin/php vendor/bin/pint app/Jobs/SegmentSession.php app/Models/Session.php app/Models/SessionSegment.php app/Services/Summarize/AiSegmentSummarizer.php app/Services/Summarize/SegmentSummarizer.php database/migrations/2026_07_02_090000_add_incremental_summarization_boundaries.php tests/Feature/FoundationTest.php tests/Feature/SegmentSessionTest.php tests/Feature/SessionEventCompressionTest.php - ~/bin/php artisan test --filter='SegmentSessionTest|ChunkedSummarizerTest|OpenRouterProviderPinTest|SessionEventCompressionTest|FoundationTest' - ~/bin/php artisan test Safety: sqlite tests only. Did not run migrate, live LLM, or mutating tinker from the worktree. Handoff flag: SegmentSession is Horizon job code and this includes a migration; MAIN needs migrate plus graceful Horizon reload after merge.

Implemented the incremental summarization path and schema locally. Added event ordinal boundaries on session_segments plus sessions.summarized_until_event_ordinal, made the summarizer accept an optional tail start ordinal, and changed SegmentSession to preserve settled rows while updating only the active tail. Focused sqlite tests pass after Pint: SegmentSessionTest, ChunkedSummarizerTest, OpenRouterProviderPinTest, SessionEventCompressionTest, FoundationTest. Full suite still pending.

Started implementation on branch flower/incremental-summarization from master. Grounded with recall_brief #60 and prior summarizer memory. Scope: incremental/append-only SegmentSession behavior, settled segment immutability, tail-only re-summary, cheap roll-up from segment summaries if applicable, and embedding only changed/new chunks. Safety boundary acknowledged: sqlite php artisan test only; no live LLM, migrate, or mutating tinker from the worktree. Will flag MAIN migrate + graceful Horizon reload on handback.

## Operator question (2026-07-02) — HOLD FOR OPERATOR GREENLIGHT (major summarization-architecture change) Mike: "shouldn't we only re-summarize from the start of the 'segment' of active sessions? What can we do to be smart about how we're re-summarizing?" ## Finding — today we FULL-REGEN every time `SegmentSession::handle()` does `$session->segments()->delete()` then recreates ALL segments from scratch on every run (the class comment even says "re-running replaces the prior [segments]"). Because `flower:watch` re-ingests a session whenever its transcript file changes and IngestSession re-summarizes on a 10-min debounce, **an active/growing session re-summarizes its ENTIRE transcript from event 1 every ~10 minutes** — for a giant session that's re-processing hundreds of millions of tokens per cycle. This is the ROOT inefficiency behind the summarization timeouts (FLOWER-16 / #58 tackle the symptom; this tackles the cause). ## Proposed design — incremental / append-only segmentation Segments are already "goal-scoped" (semantic, not just size chunks). Make re-summary O(new events) instead of O(whole session): - **Freeze settled segments.** Once a segment is complete (a later segment exists after it / a new goal has started), never re-summarize it. - **Only re-summarize from the start of the ACTIVE (last/open) segment forward**, incorporating new events — exactly Mike's phrasing. Persist a watermark (the last frozen segment's end event ordinal/id). - **New events** either extend the active segment (re-summarize just that segment) or, when a new goal boundary is detected at the tail, close the active segment (freeze it) and open a new one. - Requires: preserve prior segment boundaries instead of re-deriving all of them each run; detect boundaries incrementally on the tail only. ## Why it matters / how it composes - Turns each re-summary into a small tail operation → largely eliminates the timeout root cause (giant sessions only summarize their growing tail, not 356M tokens). - Complementary to #58 (adaptive subdivide + failed-attempt circuit breaker): #58 is the safety net for a single large chunk / persistent failure; this removes most of the load that triggers them. - Interacts with the too_large guard (#53) — a giant session's SETTLED history stays summarized; only its tail is at risk, and the tail is small. ## Open design questions for the operator 1. Boundary stability: is it acceptable that a re-derived tail boundary might occasionally re-split the most recent segment (settled ones are frozen)? 2. Do we keep a cheap session-level roll-up regenerated from segment summaries (hierarchical), or is the concatenation of segment summaries enough? 3. Re-embedding: only new/changed segments get re-embedded (EmbedChunks already keys on chunks — confirm no full re-embed). ## Acceptance (once approved) - Re-summary of an active session only processes events after the last frozen segment's watermark; settled segments untouched (and not re-embedded). - Giant/active sessions no longer re-summarize full history each tick; tests simulate a growing session across two ingests and assert only the tail is re-summarized. - Suite green; pint. FLAG: SegmentSession is Horizon job code → graceful reload on merge; likely a migration for the watermark. ## Provenance Operator question 2026-07-02 while dispatching #58. This is the architectural counterpart to #58's tactical robustness. Held at idea pending operator greenlight (significant change to core summarization).