Summary
Spec for Session Log — durable session-scoped events chrome (All / Links / Pinned), jump-to-message, hub-backed pins, and in-panel summary filter — as the first subtle product surface of the Overseer events substrate.
Status: dogfooding on fork/soup. No PR yet; PR after dogfood. Upstream can take this now that notify summaries / events emission are landing.
Fork tip (implementation): feat/overseer-readonly-entity @ b9d2f4326 (thin tip on upstream/main).
Local spec doc (fork): docs/plans/2026-08-30-session-log-spec.md
Contracts: Overseer events three-layer model (docs/plans/2026-06-03-overseer-contracts.md).
Mandate (fork): Session Log ships in the same upstream package as events/inbox/entity — not a Log-only PR on bare main.
Related fork issues: Step 2 events (#22), Step 2.5 inbox (#23), Step 3 entity (#25).
Problem
Outline is a client TOC of loaded user turns. Long sessions drop older messages from the window, so Outline cannot be the durable memory of completions, links, or pins. Operators need a hub-backed log that survives partial transcript load and can jump back into chat.
Spec (dogfood = intended upstream shape)
Chrome
- Header control beside Outline (distinct log glyph — not a second Outline).
- Panel lists hub
events for related_session_id = this session.
- Deep link
?log=true (parallel to ?outline=true).
Tabs
| Tab |
Source |
Notes |
| All |
Session events minus carveouts |
Excludes link_seen, stale, operator_pin |
| Links |
event_type = link_seen |
Compact URL; external open preserved |
| Pinned |
event_type = operator_pin |
Hub-durable (not localStorage) |
Summary filter
- Search box above the list; case-insensitive match on event summary (and link labels).
- Filters active tab’s loaded rows (client-side stopgap before full transcript search).
- Complements fleet
search_peers (find sessions); this is in-session summary filter.
Jump-to-message
messageId from payloadJson.
- Same locate path as Outline (
locateOutlineTargetMessage → load older → scrollIntoView).
- Anchors:
hapi-message-${kind}:${id} (e.g. agent-text:<hubUuid>:0).
- Keep Log open after jump (Outline still closes on select).
- No
messageId → non-clickable.
- Links: URL external; row click jumps when
messageId present.
Pins
- Affordance next to Copy on message actions.
POST/DELETE /api/sessions/:id/pins → operator_pin with idempotency session:{sid}:message:{messageId}:operator_pin.
- Survives reload / cross-device via hub.
Substrate packaged with this UI
- Events/inbox ensure-on-boot schema; recorder (notify → typed events; URL scoop →
link_seen; no persist of hub-inferred stale).
- REST:
/api/system-events, /api/inbox-items, /api/overseer/*, pins routes.
- Read-only Overseer entity/tools/
convo_turn (Step 3) rides the same tip for fork dogfood; upstream may split PRs but should not ship Log without events.
Outline vs Session Log — keep both?
Pros of keeping both (v1 / dogfood)
- Different jobs: Outline = cheap local TOC; Log = durable memory + links + pins.
- Lower risk: don’t remove Outline while validating Log jump/pins/filter.
- Mandate: “Log alongside Outline” day one; converge after evidence.
- Outline needs no hub round-trip for in-window navigation.
Cons of keeping both
- Two header controls → cognitive load (“which panel?”).
- Overlapping jump UX with different close rules.
- Dual maintenance (panels, deep-links, locate wiring).
- Operators may never discover Log if Outline “feels enough.”
Recommendation
- Dogfood + first upstream PR: keep both.
- After dogfood: prefer events-primary single panel — Outline becomes a Turns/TOC mode inside Log, or retires once Log jump + turn capture is good enough.
- Do not merge/retire Outline in the first upstream PR without dogfood evidence.
Non-goals
- Full transcript search / FTS over
messages.
- Fleet inbox in the session header.
- Replacing Outline in v1.
- Companion/FCM.
- localStorage pins.
Acceptance (for eventual PR)
Open questions (dogfood)
- Retire Outline, nest TOC in Log, or keep dual chrome?
- Emit durable events for user turns (All-tab TOC parity)?
- Hub
q= / FTS for summaries later, or jump to transcript search?
Test plan (dogfood)
Summary
Spec for Session Log — durable session-scoped events chrome (All / Links / Pinned), jump-to-message, hub-backed pins, and in-panel summary filter — as the first subtle product surface of the Overseer events substrate.
Status: dogfooding on fork/soup. No PR yet; PR after dogfood. Upstream can take this now that notify summaries / events emission are landing.
Fork tip (implementation):
feat/overseer-readonly-entity@b9d2f4326(thin tip onupstream/main).Local spec doc (fork):
docs/plans/2026-08-30-session-log-spec.mdContracts: Overseer events three-layer model (
docs/plans/2026-06-03-overseer-contracts.md).Mandate (fork): Session Log ships in the same upstream package as events/inbox/entity — not a Log-only PR on bare main.
Related fork issues: Step 2 events (#22), Step 2.5 inbox (#23), Step 3 entity (#25).
Problem
Outline is a client TOC of loaded user turns. Long sessions drop older messages from the window, so Outline cannot be the durable memory of completions, links, or pins. Operators need a hub-backed log that survives partial transcript load and can jump back into chat.
Spec (dogfood = intended upstream shape)
Chrome
eventsforrelated_session_id = this session.?log=true(parallel to?outline=true).Tabs
link_seen,stale,operator_pinevent_type = link_seenevent_type = operator_pinSummary filter
search_peers(find sessions); this is in-session summary filter.Jump-to-message
messageIdfrompayloadJson.locateOutlineTargetMessage→ load older →scrollIntoView).hapi-message-${kind}:${id}(e.g.agent-text:<hubUuid>:0).messageId→ non-clickable.messageIdpresent.Pins
POST/DELETE /api/sessions/:id/pins→operator_pinwith idempotencysession:{sid}:message:{messageId}:operator_pin.Substrate packaged with this UI
link_seen; no persist of hub-inferredstale)./api/system-events,/api/inbox-items,/api/overseer/*, pins routes.convo_turn(Step 3) rides the same tip for fork dogfood; upstream may split PRs but should not ship Log without events.Outline vs Session Log — keep both?
Pros of keeping both (v1 / dogfood)
Cons of keeping both
Recommendation
Non-goals
messages.Acceptance (for eventual PR)
?log=truemessageIdOpen questions (dogfood)
q=/ FTS for summaries later, or jump to transcript search?Test plan (dogfood)