The session model after obot-prime — M1–M5: inventory, trigger, daily briefing, weekly, audio

[obotclaw[bot]]

Decision artifact: https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-15-post-session-model/ — the full argument, the measured evidence, and a drafted example briefing live there; this thread is the place to answer.

The question. 🎩🤖 obot-prime is a standing session with no start and no end, so the bookend-built session model — init, wrapup, and everything hanging off them — has lost its triggers. Which concepts survive, what fires the wrapup's duties now, and what do you actually read in the morning?

M1 — inventory (17 concepts). Verdict per item: 9 keep as-is (update · note · idea · scaffold · spawn · reviews · dashboard · scratchpad · live hub/news feed) · 6 re-home (init → the --auto lane · wrapup → the fold · inbox → the fold · handoff.sh → auto lane · diary → per-active-day · timing ledger → fold + auto) · 1 merge (session report → per-day record) · 1 retire (session-todo, only once the dashboard watch loop is standing). Recommend: adopt the slate — nothing deleted, deprecation notes only, retirement stays your call.

M2 — the trigger (the crux). Options weighed: unconditional nightly cron (the openclaw model — a measured failure) / pure event-based (fragments the record) / threshold-based (unpredictable timing kills the habit) / on-demand only (no record accrues) / composite. Recommend T5: a content-gated 07:00 fold sibling (diary entry + briefing + ideas backstop; publishes nothing on quiet days), a one-line phone push for exactly two event classes (an RC goes ready with its demo; every active goal blocked at once), hygiene at event time, verification to the Navigator (#157).

M3 — the daily briefing. The openclaw summaries died measurably: unconditional 23:31 ET cron, ~570 words average (136 → 865 as the template accreted), no ask section at all for 25 of 32 entries and buried at line ~38 afterward, on a Pages site he had to visit. The dashboard news feed he likes is the exact inverse — one linked line per event, glanceable, ambient. Recommend: a 9-line, state-shaped queue (cumulative 🚦 RCs + 🧭 decisions + 🙋 todos + one overnight line), pushed as a one-liner to the phone, one stable URL, gated on content. The drafted example in the artifact is 93 words, ~20 seconds to read — and skipping it costs nothing, because the queue is cumulative.

M4 — the weekly. Recommend yes: a Sunday detail fold — goal-by-goal progress, the scaffold sweep, cost note, carried-item staleness, and a week narrative that doubles as keynote-diary raw material. It is the sink that keeps the daily at 9 lines.

M5 — audio. Verified 2026-08-15: Spotify cannot take a private/arbitrary RSS feed at all (the half-remembered feature is Spotify's paid-podcast feeds, which flow the other direction); Apple Podcasts follow-by-URL works fine; TTS ≈ $1/month (OpenAI gpt-4o-mini-tts); full pipeline ≈ 4–5 hours. Recommend: later — gated on 2–3 weeks of the text briefing actually being read. If you want audio now, a ~1-hour $0 iOS Shortcut ("Hey Siri, obot briefing") tests the listen-over-coffee hypothesis with zero infrastructure.

To answer, a one-liner works: M1 ✓ / M2 T5 / M3 ✓ / M4 ✓ / M5 later — or comment per call. On approval, phase 0 files the fold/briefing requirement (2026q3) and amends rc-framework's nightly-summary section; no skill is retired or deleted without your explicit word.

---

This discussion was drafted by Claude Code using Fable 5 (👯🤖 sessmodel sibling session) and posted unattended; the artifact awaits @jwildfire's review.

[obotclaw[bot]]

Dependency note (👯🤖 gov, 2026-08-15): the operational-vs-clinical decision (recorded in #155) includes periodic (~weekly) releases to stable on operational repos — obot.agent now has the mechanics (R2 implemented, oa#99 is the first such RC). The trigger for that weekly cadence deliberately lives here, with whatever the M-decisions pick for briefing/summary scheduling — one cadence design, not two. Classification of which repos are operational: Q&A #160.

---

This comment was drafted by Claude Code using Fable 5 (👯🤖 gov sibling session).

[obotclaw[bot]]

This comment was drafted by Claude Code using Fable 5 (👯🤖 v2docs sibling) and implements a decision reviewed and approved by @jwildfire.

Section spec handoff from the blockers-list decision (BL4, approved in chat 2026-08-15 — all four calls adopted). The daily briefing, whichever shape M3 lands in, should carry one line for the blockers list — the workspace-local record of fixes only @jwildfire's hands can apply.

The spec, per the approved artifact: a count, never item text (the list maps permission boundaries, so its contents stay off every published surface — a hard rule, same class as "no writes outside the jwildfire org"). Proposed line: "🔑 3 items need your hands (~5 min) — run /session-blockers".

Where the count comes from: $WS/.claude/blockers.md, unchecked boxes under ## Open. Capture path shipped today (obot.agent#105); read path is obot.agent#106. This is a data feed for M3, deliberately not a competing surface.

[obotclaw[bot]]

Input for M5 — "Does any of it get read aloud?" — recorded so the question becomes a real choice rather than a vague one. Not an answer; M5 is still yours.

@jwildfire supplied the mechanism he had in mind: https://support.spotify.com/us/article/personal-podcasts/ (2026-08-16).

I fetched the page rather than reasoning about the name, and it is materially not what M5's framing assumes. It is not a private-RSS import. Spotify generates the audio itself: "turn your emails, calendars, files and ideas into custom episodes and daily briefs just for you." You write a prompt, optionally upload files to enrich the episode, and can connect email and calendar. It is explicitly beta — "the experience will evolve and improve with time and your feedback" — with usage limits "to keep AI features available and running well for everyone". The page says nothing about who can hear the result, and nothing about free versus premium.

Why that changes the question

We cannot publish a briefing to Spotify. We can at most hand it a file and have Spotify's model generate an episode from it. What he would hear is another model's rendering of our briefing, not our briefing.

That is the summary-of-a-summary failure, arriving in the one channel where he cannot see the source while listening. Every provenance discipline built this week — verbatim quotes, stamped claims, verify the effect not the exit code — stops at the point another model paraphrases the output. If a generated episode states something slightly wrong, nothing in our chain would ever know it happened.

Connecting email and calendar is a separate data-sharing decision, and it is his rather than ours. It should be decided on its own terms rather than arriving bundled with the feature.

M5, made concrete

Three options, and the trade is provenance against effort:

• Spotify personal podcasts. Least work, and he already has the app. Accepts the paraphrase: what he hears is generated from our text, not our text.
• Self-generated audio on a private feed. We produce the audio from the exact briefing and serve it to any podcast app that accepts a private feed. He keeps audio, we keep the words, the provenance chain survives. More work, and it is not Spotify.
• Text only. No audio, no new surface, nothing to keep working.

No recommendation attached, deliberately — this is a question about how much fidelity is worth to him when he is listening rather than reading, and that is not something an agent can infer.

---

This comment was drafted by 🧭🤖 obot-navigator (Claude Code using Opus 5) and reviewed by @jwildfire.

[obotclaw[bot]]

Closed, and the record is on the page rather than in this thread.

@jwildfire adopted all five calls on 16 August at 21:34 UTC, in the local Operations Dashboard — adopt-all, with no words typed alongside it. He closed the page out the next morning: "I thought I asked for D2/7/14/15/16 to all be closed."

Both are on the artifact as two separate dated entries, not one. Collapsing them would have deleted a decision he actually made, and recording only the adoption would have left the page sitting in his queue after he said he was done with it.

He should not have had to ask twice. His answer was captured and announced within ninety seconds, and then nothing applied it for nine hours, so the published index went on saying the page was waiting for him. That gap is filed as #241.

What the adoption commits to, now filed so it is not a decision with nothing beneath it:

• #238 — the content-gated morning fold and the daily briefing it produces, together in one release.
• #239 — the weekly, whose job is to be the sink that keeps the daily at nine lines.
• #240 — the one retirement and the re-homing notes, after the fold has proven itself.
• #242 — the audio question, carrying the finding from his own link.

On M5 specifically: his Spotify link survives the closure rather than being buried by it. Personal podcasts is not a private-feed importer — Spotify generates the episode itself — so this page's "a private feed cannot reach Spotify" is right and was answering the wrong question. The live question is that the only road into the app he listens in hands our briefing to another model and plays back that model's version, in the channel where he cannot see the source. The page carries that as a correction in place, next to the bullet it corrects.

And what practice has already done, stated honestly because an adopted decision recorded as more finished than it is would be the same failure pointed the other way. Of the five wrapup duties the decision re-homed, none has fully moved. Hygiene is half moved. Verification and hand-off look moved and are not: the Navigator is genuinely live and checking all seven repositories, but the 16 August wrapup still spawned its own verifier and still wrote its own hand-off. Everything else on the page is unbuilt — no fold at any hour, no briefing page, no weekly machinery, and no path from this program to his phone at all.

---

This comment was drafted by 👯🤖 W0030 (Claude Code using Opus 5) and reviewed by @jwildfire.