feat(workflows): rewrite daily-prep to the strict three-section template

From the template spec Craig wrote 2026-06-10 plus four refinements from his review of the first new-format prep. The doc is now exactly Heads-Up, Day's Priorities, and Meetings / Focus Blocks. Two run modes replace full-prep and standup-only: Create ends with a mandatory priorities review gate (disagreement there signals todo.org staleness), and Update refreshes a day when the world moves. Both run a triage-intake first when none ran in the last hour.

It retires the separate Standup Briefs and Upcoming Deadlines sections, the Anchor Tasks handoff, and the thin-link convention. Priorities entries now mirror their todo.org task heading and carry links and context in the body. Briefs nest under the standup they're reported in, with Blockers: None explicit. Meetings carry what to contribute and get, likely questions with answers, linked prep docs, and day-before prep blocks for unanswered questions. Focus blocks are linked menus, created the day before and marked free.

The spec and the decisions handoff land in docs/design/.

7 files changed, 478 insertions, 845 deletions

diff --git a/.ai/workflows/INDEX.org b/.ai/workflows/INDEX.org
index 218709f..3f54f7c 100644
--- a/.ai/workflows/INDEX.org
+++ b/.ai/workflows/INDEX.org
@@ -30,9 +30,9 @@ This index must list every =.org= file in =.ai/workflows/= except this one and e
   - Triggers: "task review", "review tasks", "let's do a task review", "groom my tasks", "task-review"
 - =task-audit.org= — content reconciliation: take the open tasks and check their recorded facts against reality (sessions, email, chat, ticketing, calendar, meeting recordings), update the stale facts, consolidate duplicates, and flag the judgment calls only the user can answer. Deeper than =task-review.org= (relevance/keep-kill/priority); this one keeps the surviving tasks factually honest.
   - Triggers: "task audit", "audit my tasks", "audit the open tasks", "are my tasks still accurate", "reconcile my tasks", "update the stale tasks"
-- =daily-prep.org= — prep brief for the next workday. Two modes: full-prep (default) or standup-only.
-  - Full-prep triggers: "let's prep for tomorrow", "daily prep"
-  - Standup-only triggers: "what's my standup report", "let's do the daily standup report", "give me the standup brief"
+- =daily-prep.org= — builds and maintains the daily prep doc (strict three-section template: Heads-Up / Day's Priorities / Meetings / Focus Blocks). Two run modes: Create (build a future day's prep, ends with a mandatory priorities review gate) or Update (refresh an existing day's prep when the world moved). A standup-brief refresh is an Update-mode run scoped to the standup's entry.
+  - Create triggers: "let's prep for tomorrow", "daily prep"
+  - Update triggers: "update today's prep", "refresh the daily prep", "what's my standup report", "give me the standup brief"
 - =meeting-prep.org= — deep prep doc for one specific upcoming meeting that warrants more than a glance: decode the invite (who/why/timing/objective), gather grounded context, draft the eight-section prep, pre-wire and schedule the prep block, review with Craig, wire into the day's daily-prep, and close the loop post-meeting by extracting action items into =todo.org=. The per-meeting companion to =daily-prep.org='s whole-day brief.
   - Triggers: "let's prep for the <X> meeting", "prep me for the call with <Y>", "build a prep doc for <meeting>", "let's run the meeting-prep workflow", "meeting prep", "let's prep the <name> call"
   - Supporting doc: =meeting-prep.pre-wire.org= (the full Manager Tools pre-wire method, used by Phase 3.5). Not independently triggerable.
diff --git a/.ai/workflows/daily-prep.org b/.ai/workflows/daily-prep.org
index abf70a4..b6989e7 100644
--- a/.ai/workflows/daily-prep.org
+++ b/.ai/workflows/daily-prep.org
@@ -1,12 +1,12 @@
 #+TITLE: Daily Prep Workflow
 #+AUTHOR: Craig Jennings & Claude
-#+DATE: 2026-02-23
+#+DATE: 2026-06-11
 
 * Overview
 
-This workflow prepares Craig for the next workday by reviewing scheduled meetings, identifying priorities, and blocking time on the calendar. It ensures Craig walks into every meeting prepared and has a plan for the day's focused work.
+This workflow builds and maintains the daily prep doc — the single document Craig works from all day. It assembles the day's frame (Heads-Up), the day's work (Day's Priorities), and the day's schedule with everything nested under it (Meetings / Focus Blocks), so Craig walks into every meeting prepared and every open block with a menu of ready, linked work.
 
-This is typically run the evening before or morning of the workday in question.
+The prep doc for a day is normally generated the afternoon before, during the end-of-day review block, and updated whenever the world moves.
 
 * Problem We're Solving
 
@@ -19,520 +19,365 @@ Without daily prep, Craig risks:
 
 *Impact:* Unprepared meetings waste everyone's time. Unplanned days let urgent displace important.
 
+The deepest failure mode this workflow guards against is *prep that exists but can't be reached*: a meeting prep doc that was built days earlier but only mentioned — not linked — under the wrong day's heading, found too late to use. Every meeting entry links its materials directly, and every meeting is verified against the live calendar, because meetings move.
+
 * Exit Criteria
 
-- All meetings for the day are reviewed with prep notes
-- 1:1 meetings have talking points drawn from todo.org and session history
-- Day's priorities are identified and confirmed by Craig
-- Time blocks are placed on the calendar for focused work
+- Every calendar event for the day appears in =* Meetings / Focus Blocks=, verified against the live calendar (build time and update time — times move)
+- Every meeting entry carries its join link, its prep materials as =file:= / URL links (never a bare mention), what Craig needs to contribute, what he needs to get, and likely questions with answers
+- Any "I don't know" answer to a likely question has a prep block scheduled *the day before* the meeting, never day-of
+- Day's Priorities are sourced from both the project tracker and =todo.org=, each entry mirroring its todo.org task and carrying its own context and links
+- Craig has confirmed the Day's Priorities at the mandatory review gate (Create mode)
+- Focus blocks are on the calendar (marked free), created the day before after Craig confirms the prep
+- Drafts the day needs (reschedule messages, replies) are pre-written in the doc, ready to send
 - Any quick tasks (< 5 min) are done during prep itself
-- Craig feels ready for the day
 
 * When to Use This Workflow
 
-- When Craig says "let's prep for tomorrow" or "daily prep" or similar
-- During evening wrap-up if there are meetings the next day
-- Morning of a workday before meetings start
-- When Craig asks for the standup brief alone ("what's my standup report", "let's do the daily standup report", "give me the standup brief") — see Standup-only mode below
-
-* Modes
-
-The workflow runs in one of two modes based on the trigger phrase. Pick the mode at workflow start. Don't switch mid-run.
-
-** Full-prep mode (default)
-
-Trigger: "let's prep for tomorrow", "daily prep", or any general prep-cycle phrase.
-
-Runs Phase A → Phases 1-5 → Phase 6 (only if a standup is on the calendar) → Phase 7 → Phase 8 → Phase 9.
+- End-of-day review block ("What Kind of Day Has It Been?") — generating tomorrow's prep is part of that block's standing agenda
+- "Let's prep for tomorrow" / "daily prep" / similar — Create mode
+- "Update today's prep" / after a triage-intake lands something that changes the day — Update mode
+- A standup-brief refresh ("what's my standup report") is an Update-mode run scoped to the relevant standup's entry — there is no separate standup-only mode anymore
 
-** Standup-only mode
+* Run Modes
 
-Trigger: "what's my standup report", "let's do the daily standup report", "give me the standup brief", or similar standup-specific phrasing.
+There are only two times this workflow runs. Pick the mode at start; don't switch mid-run.
 
-Runs *only* a slim Phase A + Phase 6 + a conditional Phase 8 + Phase 9. Skip Phases 1-5 and Phase 7 entirely.
+** Create
 
-*** Slim Phase A (standup-only)
+Build the prep doc for a future day — normally tomorrow, during the end-of-day review block. Runs the full phase sequence and *ends with a mandatory priorities review gate*: Craig confirms the Day's Priorities or reworks them interactively (add / remove / substitute priorities and blocks). Calendar writes (focus blocks, day-before prep blocks) happen only after the gate.
 
-Fetch only what Phase 6 needs:
+Disagreement at the gate is a signal that =todo.org= is stale — it should be easy to identify Craig's current priorities by looking at the file. When the gate produces substantive rework, surface that and offer a task review.
 
-1. =todo.org= — for WAITING items (blockers) and DONE-since-cutoff (completed work).
-2. Previous prep doc — anchor for the lookback. Glob =daily-prep/*-daily-prep.org=, sort by date, take the file *before* the one the root =daily-prep.org= symlink currently resolves to (i.e. the prior prep day, not today's).
-3. Most recent =.ai/sessions/= summary — for the "what did I do" question.
+** Update
 
-Skip the calendar fetches, the Proton grep, and the [#A]/[#B] todo pull. Phase 6 Step 1's sweep handles the rest.
+Refresh an existing day's prep when the world moved — typically after a triage-intake lands something, a meeting reschedules, or new information changes what the day can achieve. Re-fetch the calendars (never trust the build-time snapshot — times move), re-verify every meeting entry, refresh the affected sections, and surface the delta to Craig. No mandatory gate; the changes themselves are the review surface.
 
-*** Where the brief lands
+** Triage freshness (both modes)
 
-- If a prep doc for today already exists at =daily-prep/YYYY-MM-DD-daily-prep.org=, append or replace its =* Standup Brief= section.
-- If no prep doc for today exists, create =daily-prep/YYYY-MM-DD-daily-prep.org= with only the =* Standup Brief= section populated, then repoint the root symlink at it (=ln -sf daily-prep/YYYY-MM-DD-daily-prep.org daily-prep.org=). Full prep can be added later by re-running in full-prep mode.
+If no triage-intake has run in the last *hour*, run one first — before anything else. Incoming information may change what the day can achieve; the prep reacts to it, never ignores it. The [[file:triage-intake.org][triage-intake engine]] fans out across its source plugins, classifies, synthesizes, and writes Action items into =todo.org= as =:quick:reactive:= tasks (see Phase 3).
 
-See *Phase 8* for the prep-doc home and symlink convention.
+* Prep Doc Template (strict)
 
-*** Phase 8 in standup-only mode
+The prep doc has exactly three top-level sections, in this order. Don't invent new ones. If substantive content surfaces that doesn't fit, mention it in chat after the workflow finishes rather than adding a section.
 
-If standup-only created a new dated file in =daily-prep/= (no prep doc for today existed), repoint the root =daily-prep.org= symlink at it. "Where the brief lands" above already does this; Phase 8 is a no-op when it did. If today's prep doc already existed and the brief was appended to it, the symlink already resolves to it — nothing to do.
+| Section                    | Purpose                                                              |
+|----------------------------+----------------------------------------------------------------------|
+| =* Heads-Up=               | Standing frame for the day — density, events, reminders, look-ahead  |
+| =* Day's Priorities=       | The day's work, task-shaped, mirroring todo.org                      |
+| =* Meetings / Focus Blocks= | The schedule — every calendar event, with all content nested under it |
 
-Use standup-only mode when Craig wants the brief fast (e.g., right before standup) without rebuilding the day's plan.
+The separate =* Standup Briefs= and =* Upcoming Deadlines= sections are *retired*: standup briefs nest under the standup meeting they're reported in, and upcoming deadlines live in the end-of-day review block's content. There is no anchor-tasks handoff section either — carry-forward lands directly in the next day's Day's Priorities, because the next day's prep is built during today's end-of-day block.
 
-* Prep Doc Structure
+** =* Heads-Up=
 
-The prep doc has a fixed set of top-level sections. Don't invent new ones. If substantive content surfaces that doesn't fit one of these headings, mention it in chat after the workflow finishes rather than adding it to the prep doc.
+Items that frame the day. Four standing items are *always* present, plus the look-ahead:
 
-Canonical sections (full-prep mode produces all; standup-only produces just =* Standup Briefs=):
+1. *Meeting-density framing.* One line on the day's shape, e.g. "Meeting-dense morning: 09:00 team discussion, 10:00 standup, 11:00 general standup. Real focus time only opens at noon."
+2. *Calendar events from BOTH calendars* (work + personal): birthdays, holidays, anniversaries, vacations, trips, big events. "Your trip begins Friday." "It's <person>'s birthday today."
+3. *Reminders due, imminently due, or past trigger* — from notes.org Active Reminders plus scheduled/deadline tasks. A reminder tied to a rescheduled meeting reports against the new date.
+4. *Requested metrics* — a slot for any metric Craig has asked to track in the daily prep. Render the slot only when a metric is active; none are active by default. (Metric design is a separate discussion — don't invent metrics.)
+5. *5-Day Look-Ahead* — one day per line, format =Fri 12:= / =Mon 15:=, including clear days marked =clear=. Built by Phase 1's forward scan with the invite quick-read and decline gate applied.
 
-| Section                          | Phase that writes it | Purpose                                                                    |
-|----------------------------------+----------------------+----------------------------------------------------------------------------|
-| =* Heads-up=                     | Phase 7              | Substantial situational context that changes Craig's frame for the day     |
-| =* Day's Priorities=             | Phase 3              | Actionable items for today (thin links to =:quick:reactive:= todo.org tasks) |
-| =* Meetings / Work Blocks=       | Phase 4              | Chronological schedule for the day (meetings + work blocks interleaved)    |
-| =* Standup Briefs=               | Phase 6              | Yesterday / Today / Blockers content for the standup meeting               |
-| =* Upcoming Deadlines=           | Phase 7              | Next 4-6 weeks of relevant deadlines, briefly                              |
-| =* [Next day]'s Anchor Tasks=    | Phase 7              | Explicit forward commitments for tomorrow. Phase 2 of next-day's prep reads this |
+Format: terse, situational, one item per line. Link to sources rather than inlining context.
 
-Order in the prep doc follows the table top-to-bottom: Heads-up first (frame-setter), Day's Priorities next (action surface), then schedule, then standup, then deadlines, then forward-commitment.
+** =* Day's Priorities=
 
-** Day's Priorities entries are thin links to todo.org tasks (2026-05-12 rule)
-
-Each actionable entry under =* Day's Priorities= is a *pointer to a todo.org task*, not a copy of its content. Form:
+The day's work, sourced from BOTH the project's tracker (Linear, where the project uses one) and =todo.org=. Each entry is a task-shaped level-2 header that *mirrors the linked todo.org task exactly* — same status keyword, same priority cookie, same tags:
 
 #+begin_example
-** TODO [#X] <task title> — [[file:../todo.org::*<task title>][todo.org]]
-<one line on why it's today's priority — deadline, blocker, what just landed>
-#+end_example
-
-All the substance — descriptions, drafted messages, research findings, sub-tasks, =VERIFY= asks, recommended-approach blocks — lives in the matching =todo.org= task, created or updated by Phase 3. If a todo.org task doesn't exist yet, create one (with the conventional priority cookie / Linear ID in the heading) and link to it. This keeps everything in one place (todo.org), so the prep doc never accretes content that then has to be transferred back.
+** STATUS [#PRIORITY] TASK-DESCRIPTION :tags:
 
-*The execution link rides with the entry (2026-06-10 rule).* The thin link covers the task's *home*, not the way to *do* it. When a priorities entry is actionable through a URL — a payment portal, a doc to read, a PR, a form — the entry body carries that link directly. If the link isn't already in the todo.org task body, the prep build hunts it down (the source email, the Slack thread) and adds it to BOTH the todo.org body (durable home) and the prep entry. The failure mode this prevents: "Pay NOLA Sewerage & Water Board invoice" linked to todo.org but not to the InvoiceCloud payment URL, so doing the task meant a Gmail dig first.
+   Relevant Information: (rename as appropriate)
+   [todo.org link, tracker ticket, PR, doc — every link the task needs]
+   <what success on this task is; today's achievement goal when the task
+   is bigger than a day; any relevant preparation>
+#+end_example
 
-Exceptions that stay in the prep doc as content (not links):
-- *Completed-today entries* — once a task is done, its heading becomes a dated log entry (=** YYYY-MM-DD Day @ HH:MM ...=, see [[file:../../.claude/...][feedback_done_tasks_become_dated_log_headings]] — i.e. the dated-heading rule) and stays in the prep doc as the day's record. If the work also has a durable todo.org home, the dated entry links to it.
-- The =* Standup Briefs=, =* Heads-up=, =* Upcoming Deadlines=, and =* [Next day]'s Anchor Tasks= sections — those are prep-doc-native and don't map to todo.org tasks.
+Rules:
 
-(Craig's instruction, 2026-05-12, extended 2026-05-15. The triage engine (sub-step 3b) implements the convention: each Action item becomes its own =** TODO= in =todo.org= with =:quick:= + =:reactive:= tags, and the prep doc references it via a thin link under =* Day's Priorities= when it belongs in today's plan. No grouped =** Email Response= / =** Slack Response= / =** Linear Response= / =** PR Review= sub-sections in the prep doc — the source mix lives in the tags on each todo.org task.)
+- *Links live in the content, never in the heading.* The body carries the todo.org link, the tracker ticket, the PR, the doc — along with all the other relevant information. The heading stays plain text (strip link markup when mirroring a task heading that carries one).
+- *Property drawer optional.*
+- *Body carries the entry's own context* — what success is, today's achievement goal when the task is bigger than a day ("Finish phase 2 of the spec and be ready to start phase 3 tomorrow"), and any relevant preparation (e.g. "this is also good prep for when the topic comes up in <meeting> on <day in the look-ahead window>").
+- *Execution links ride with the entry.* When the task is actioned through a URL — a payment portal, a doc, a PR, a form — the body carries that link directly. If the URL isn't in the todo.org task body yet, hunt it down (source email, Slack thread) and add it to BOTH the todo.org body (durable home) and the prep entry.
+- *The daily big-ball chunk is an entry here.* One important-but-not-urgent task per day, slated for a ~15-minute chunk (see Phase 3).
+- Order by urgency (Phase 3's sort). Craig should be able to work top-to-bottom.
 
-** Triage Action items become =:quick:reactive:= todo.org tasks (2026-05-15 rule)
+A "Goal:" or "Recap and Goal:" entry shape is fine for committed deliverables that need narrative context (where it stands, what's owed, to whom, by when) — same rules: links in body, success stated.
 
-Every Action item the triage engine surfaces (sub-step 3b, across email / Slack / Linear / PRs / calendar) becomes its own top-level =** TODO= in =todo.org= with =:quick:= + =:reactive:= tags. The prep doc's =* Day's Priorities= section links to those tasks as thin links per the rule above — no grouped Response sub-sections.
+** =* Meetings / Focus Blocks=
 
-Form:
+The spine of the doc — most content lives here. The schedule renders as a chronological list of level-2 headers, one per calendar event, with ALL content for an event nested directly under its own header:
 
 #+begin_example
-** TODO [#B] Read [[https://linear.app/deepsat/issue/SE-378][SE-378 Kostya Testing Results]] :quick:reactive:kostya:
-** TODO [#B] Re-review Vrezh's PR #167 after fixes :quick:reactive:vrezh:
-** TODO [#B] Reply to Subbu re: RTX action items :quick:reactive:subbu:
+** HH:MM–HH:MM — Exact Calendar Title
 #+end_example
 
-Rules:
+The title is the calendar event's subject *verbatim* — no annotations, no editorializing (not "(personal routine)", not "(recurring)"). Anything under the header must be actionable information or a useful reference during that event.
 
-- Plain-prose heading, lead with the verb (Read / Re-review / Reply / Address / Schedule / Review).
-- Default priority =[#B]=. Bump to =[#A]= only if the item blocks a teammate or a deadline lands inside 7 days.
-- Always =:quick:= + =:reactive:=. Add person/entity tags (=:vrezh:=, =:kostya:=, =:subbu:=, =:rtx:=, etc.) when the dependency is sharp.
-- Link the source in the heading when it has a URL — Linear issue, GitHub PR, Gmail thread, Slack permalink — using =[[url][label]]= form. The recommended approach and response content (when relevant) goes in the task body, not the heading.
-- Placement in =todo.org=: end of =* Work Open Work= (before =* Work Incubate=) unless a =* Triage= / =* Inbox= section exists near the top.
+Per-event-type content rules:
 
-If the item belongs in today's plan, also add a thin link under =* Day's Priorities= in the prep doc:
+*** Morning Prep (first block of the day)
 
-#+begin_example
-** TODO [#B] <task title> — [[file:../todo.org::*<task title>][todo.org]]
-<one line on why it's today's priority — deadline, blocker, what just landed>
-#+end_example
+Morning Prep is where Craig reads the prep doc, mentally walks the schedule, and refreshes his memory on proposals, status, and what to report. The workflow's job here: take what triage-intake surfaced and turn it into strategy, proactively supplying what Craig needs to keep the day on track. Content:
 
-Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via Phase 3 sub-step 3a's =:reactive:= pull.
+- *Conflict resolutions, ready to execute.* When a conflict or reschedule surfaces (e.g. the boss called a meeting overnight that overlaps an existing one — the triggers: who it's from, and that it appeared last night), check BOTH calendars' availability, recommend the best slot, and list the alternatives with their trade-offs ("only 30 minutes — could the agenda be cut to the high-priority topics?"). Close with the offer: "tell me which and I'll handle it." When no mutual free time exists, say so and include the direct-contact draft.
+- *Drafts go IN the prep doc, ready to send* — not an offer to draft one. The Slack reschedule message, the heads-up note, the reply: pre-written, =/voice personal= applied, sitting in the doc so Craig's word (a cj-comment or a "send it") is the only remaining step.
+- *Important FYIs* from triage that Craig must see before the day starts ("you got a [[slack-url][Slack message]] from <person> saying <big news>").
+- A pointer to the next meeting's agenda when reviewing something first would help ("your next meeting discusses X — review the proposal you wrote").
 
-* Approach: How We Work Together
+*** Standups
 
-** Continuous flow (no mid-phase gates)
+The Yesterday / Today / Blockers brief nests *directly under the standup meeting it's reported in* — never in a separate section. Plain section labels, no parenthetical questions in the rendered doc.
 
-Phases A through 7 run continuously. Don't stop between phases for Craig's input or confirmation. Information surfaced in later phases (especially Phase 3 email/Slack/Linear scans) frequently reframes what Craig wants from earlier phases — meeting goals, carry-forward decisions, priority order, time blocking. Stopping at Phase 1 to ask "what do you want from this meeting?" means asking Craig to react with stale context, before scans surface the email that might change his answer.
+- *Blockers is always present.* When there are none, write =Blockers: None= explicitly — silence is ambiguous.
+- *Outcomes, not attendance.* Never "met with <person>" — instead what came out of it: "<person> finished the branch CI/CD work." Never "went to the managers' meeting" — instead the development from it that affects this audience.
+- *No recurring 1:1s or ceremonies* in briefs — they're not news.
+- *Match the standup's altitude.* An engineering standup gets engineering-goal material only: what moved the platform or the demo forward — architecture docs, PRs, tracker tickets, partner meetings with use-case implications, integration discussions, security findings, dataset discoveries. It does NOT get: 1:1s, attending other standups, personal-tooling maintenance, profile updates, sending messages or email, meeting prep, booking travel, or interviews with non-engineering candidates. The three questions are really: (a) how have I moved us closer to the engineering goals, (b) what will I work on that moves us closer, (c) what information do I have that might impact the team or its goals.
+- A business-level (general) standup is different: features finished that leadership wanted, vacation/travel that affects availability or velocity, conference learnings, partner/customer decisions, cross-functional confusion worth clearing up. *Exclude routine maintenance and operational items — PR reviews don't belong here.* Foundational or strategic engineering work does; operations don't.
 
-Build all phases through Phase 7, then present the assembled draft and surface every question and proposed adjustment at the final review.
+(Drafting rules — first-person, deadline precision, recurring-meeting filters, the team-visible test — are in Phase 6.)
 
-Exception: stop only if a scan turns up something that *blocks* further building. Examples: a meeting was canceled and the whole day's structure changes; a security or compliance issue Craig must adjudicate before email triage proceeds. Otherwise keep going.
+*** Meetings
 
-This rule applies to all phases including Phase 1's "collaborative review" line and Phase 2's planned-vs-actual review. Both are framed as collaborative in their phase descriptions; the collaboration happens once, at the end, against the assembled prep doc.
+Every meeting entry carries:
 
-** Phase A: Data Gathering (one parallel batch)
+- *Notable accept/declines* ("only <person> accepted; <other> is out").
+- *Attendees and the join link* — an org link to the conference URL from the calendar event's conference data, so Craig clicks and joins from the prep doc. In-person/phone meetings omit it.
+- *The meeting-prep doc, LINKED* — a =file:= link, never a bare mention. If a prep doc exists anywhere in the project, the meeting entry links it. This is the lesson of a real failure: the prep existed, but it sat unlinked under a different day's heading, and Craig — with minutes to spare — couldn't find it and had to wing a meeting that mattered. Be thorough, check every meeting, find and link all the relevant docs.
+- *Summary* — who this is, why the meeting exists, what's known about the relationship and context.
+- *What Craig needs to contribute* and *what he needs to get* from the meeting.
+- *Likely questions, with answers.* When the honest answer is "I don't know," that forces a prep block scheduled *the day before* the meeting — never day-of. Schedule it in Phase 9.
 
-Before any synthesis or interaction, pull every source the prep doc needs in a *single batch of parallel tool calls*. These reads are all independent — issue them in one message, not as a sequential round-trip per source:
+*Verify every meeting against the live calendar at build AND update time.* Meetings move. A prep entry pointing at yesterday's time is worse than no entry.
 
-1. =mcp__google-calendar__list-events= for the *personal* account, scoped to the day being prepped *plus the next 5 days*. The prep-day subset feeds Phases 1, 4, and 6; the forward window feeds the 5-Day Look-Ahead in Phase 1.
-2. =mcp__google-calendar__list-events= for the *work* account, same scope (prep day + next 5 days).
-3. Grep =~/.emacs.d/data/pcal.org= for items on that day. This is the Proton Calendar export (=pcal= = personal calendar). The same directory has =gcal.org= and =dcal.org= for Google personal + DeepSat, but those are already covered by the MCP queries in steps 1 and 2 — only =pcal.org= adds non-redundant items.
-4. Read =todo.org= — collect [#A] and [#B] tasks plus anything with DEADLINE: or SCHEDULED: touching the day.
-5. List + read the *previous* prep doc. Glob =daily-prep/*-daily-prep.org= (all prep docs live there, born and kept — no separate archive). Sort by date and take the file *before* the one the root =daily-prep.org= symlink currently resolves to — usually yesterday's, but may be older if Craig was off (PTO, weekend, missed days). If the symlink doesn't resolve yet (no prep ever run), take the most recent file by date. The lookback for the standup brief is anchored on this file's date, so accuracy matters.
-6. Read the most recent =.ai/sessions/= summary file (for the standup brief's "What did I do since last standup?" question).
+*** Focus Blocks
 
-Phases 1-5 below all work from this in-memory snapshot. *Do NOT re-query the calendars in Phase 4* — the time-blocking pass uses the same data Phase A fetched. A typical daily-prep used to run 4-5 sequential round-trips just for data gathering; this collapses to one.
+Focus blocks are calendar events *marked free*: others see the time is claimed for focused work and self-select out unless something is genuinely important or urgent. The workflow CREATES them the day before, in Phase 9, after Craig confirms the prep at the gate. They're the first thing to shrink under schedule pressure; lunch shrinks second, with a 30-minute floor.
 
-** Phase 1: Meeting Review
+Content is a *menu, not an assignment* — "no plan survives contact with the enemy." Craig doesn't know what kind of day he'll have, how much sleep he'll get, or what will land on him; he chooses from the menu in the moment. Build it as:
 
-Working from the Phase A calendar snapshot, present each meeting with:
+- *Recommended item first*, then alternates. Recommendation reflects this week's priorities and any accepted deadline that's around the corner — deadline items list even when higher-priority items exist.
+- *Every item LINKED* — this is a moment of action with no time to search. The PR, the tracker queue, the doc to review, the email thread; include a starter draft when the item is a reply.
+- *Size the menu to the block.* Short block (≤30 min): the PR queue, tracker-chore grooming, prep for a later meeting. An hour or more: the bigger Day's Priorities items, even if they won't finish in the time allotted. Typically a rehash of Day's Priorities above, sized and linked.
 
-1. *Time and duration*
-2. *Meeting name*
-3. *Owner* (who scheduled/owns the meeting)
-4. *Official agenda* (from calendar description)
-5. *What Craig needs from this meeting — his objective and contribution.* Not just "attend" but the active role: decisions to drive, points to make, information to convey, people to persuade (the attending-to-contributing reframe). And apply the gate: *is there a purpose here for Craig, or is this a send-regrets candidate?* "He was invited" isn't a reason to attend — if there's no objective and no contribution to make, flag the meeting as a decline candidate for Craig's call at review.
+*** Lunch
 
-For the objective and contribution, Claude may not know Craig's goals for the meeting. Present what's known and Craig will clarify during review.
+30-60 minutes, anywhere 11:00-13:30. An hour typically; 30 minutes on busy days — never less. NO tasks, no meeting prep. Personal time, not work time.
 
-*** 1:1 Meeting Prep
+*** End-of-day review block ("What Kind of Day Has It Been?")
 
-1:1 meetings get deeper preparation:
+The last block of the workday, on the calendar as a recurring event (typically 16:30-17:00). Its content:
 
-1. Check todo.org for tasks tagged with or related to the person
-2. Review session histories since the last 1:1 with that person for relevant events, decisions, and context
-   - Default lookback: since the last 1:1 with that person
-   - Craig may ask to go further back for long-running items
-3. Identify:
-   - Status updates Craig should share (progress on things they care about)
-   - Questions Craig needs to ask
-   - Decisions that need their input
-   - Action items owed to or from them
+- The day's summary — what happened, what landed, what slipped.
+- *Generating tomorrow's prep* — a Create-mode run of this workflow normally happens here.
+- *The upcoming-deadlines list* — this replaces the retired deadlines section. Format: one per line, =Tomorrow: <item>= / =Mon 5/18: <item>= / =5/17–5/21: <event>=, roughly the next 4-6 weeks, chronological.
 
-Capture the meeting list with what's known about each (time, owner, official agenda, who's accepted vs declined, what Craig might need). Don't stop here for Craig's input. Bring questions about meeting goals to the final review at the end of Phase 7, when the cross-source picture from Phase 3 is in hand. The collaborative review of the meeting list happens once, against the assembled prep doc, not as a mid-flow gate.
+* Approach: How We Work Together
 
-*** 5-Day Look-Ahead
+** Continuous flow, one gate at the end
+
+Phases A through 7 run continuously — don't stop between phases for confirmation. Information surfaced in later phases (especially triage) frequently reframes earlier phases; stopping early means asking Craig to react with stale context. Build the whole doc, then present it at the Phase 8 gate with every question and proposed adjustment.
 
-Beyond today, scan the next 5 days from the Phase A forward window — read the calendar today *and the next five days*, reading it rather than glancing. For each meeting in that window, do a quick read (who's invited and who accepted, why it's being held, the timing, the objective) and surface three buckets at the final review:
+Exception: stop only if something *blocks* further building — a canceled meeting that restructures the day, or an issue Craig must adjudicate before triage can proceed.
 
-1. *Meetings that need prep.* A substantive upcoming meeting — an external partner, a negotiation, a review of specific work or data, a first call with someone — that has no =working/<slug>-call-prep/= doc yet. Offer to run the [[file:meeting-prep.org][meeting-prep workflow]], or add a prep task. Some meetings take more than five minutes to prepare; catching them several days out is the whole point of looking ahead.
-2. *Traps.* A time-zone mismatch on a travel day, a double-booking, a talk-heavy meeting that will overrun into the next, a recurring meeting that isn't needed this cycle.
-3. *Focus blocks to protect.* Open mornings or afternoons in the window worth blocking now for big work, before they get booked over.
+** Phase A: Data Gathering (one parallel batch)
 
-This is a scan-and-flag pass, not a full prep — the deep prep for any one meeting is the [[file:meeting-prep.org][meeting-prep workflow]]'s job. Keep it to the three buckets and surface them in =* Heads-up= (Phase 7) or as forward tasks / Anchor Tasks; don't add a new prep-doc section.
+Pull every source in a *single batch of parallel tool calls*:
 
-** Phase 2: Planned vs. Actual Review
+1. =mcp__google-calendar__list-events= for the *personal* account, scoped to the prep day *plus the next 5 days* (prep-day subset feeds Phases 1 and 4; the forward window feeds the look-ahead).
+2. =mcp__google-calendar__list-events= for the *work* account, same scope.
+3. Grep =~/.emacs.d/data/pcal.org= for items on that day (Proton Calendar export; =gcal.org= / =dcal.org= are already covered by the MCP queries).
+4. Read =todo.org= — [#A] and [#B] tasks plus anything with =DEADLINE:= or =SCHEDULED:= touching the day.
+5. Pull the project tracker's view of Craig's plate (assigned issues, items in review, blocked items) where the project has one.
+6. List + read the *previous* prep doc. Glob =daily-prep/*-daily-prep.org=, sort by date, take the file *before* the one the root =daily-prep.org= symlink resolves to. If the symlink doesn't resolve yet, take the most recent file. The standup lookback anchors on this file's date.
+7. Read the most recent =.ai/sessions/= summary (for the standup brief's lookback).
 
-Before setting tomorrow's priorities, review what was planned for today against what actually happened. This catches work that slipped and prevents it from silently disappearing.
+This fetch *is* the live calendar read for build time. In Update mode, re-run the calendar fetches — never reuse the build-time snapshot.
 
-1. Pull the current day's prep doc (if one exists). If it has a populated =* [Today]'s Anchor Tasks= section (written by yesterday's Phase 7 as the explicit handoff), use that as the canonical carry-forward list. Otherwise fall back to inferring carry-forward by listing the day's planned work blocks.
-2. For each block, note: completed, partially done, or not started
-3. For items that didn't happen, identify why (took longer than expected, blocked, deprioritized, meetings ran over)
-4. Carry forward anything that still matters into the priority list for the next day, with updated time estimates based on what we learned today
-5. Add all carried-forward items as =TODO= entries in the new prep doc's Day's Priorities section — don't just note them in the Planned vs Actual table. Unfinished tasks from yesterday become today's tasks automatically unless Craig cuts them.
+** Phase 1: Meeting Review
 
-This step keeps the daily prep honest. If a 1-hour task consistently takes 3 hours, the estimates need to change. If work keeps getting bumped by meetings, that's a pattern worth raising.
+Working from the Phase A snapshot, capture for each meeting: time and duration, the exact calendar title, owner, official agenda, accept/decline status — and *what Craig needs from it*: not "attend" but the active role (decisions to drive, points to make, information to convey, people to persuade). Apply the decline gate: a meeting with no objective and no contribution for Craig is a send-regrets candidate, flagged for his call at the review gate.
 
-** Phase 3: Day's Priorities
+*** 1:1 Meeting Prep
 
-Assemble priorities automatically from multiple sources. No interactive confirmation. Craig reviews the prep doc as a whole when it's done.
+1:1s get deeper preparation: check todo.org for tasks tagged with or related to the person; review session histories since the last 1:1; identify status updates to share, questions to ask, decisions needing their input, and action items owed each way.
 
-Phase 3 pulls priorities from two places: =todo.org= directly (sub-step 3a) and the triage engine's fresh Action items (sub-step 3b, which creates the =:quick:reactive:= tasks per the rule above). Sub-step 3c surfaces the ones that belong in today's plan as thin links under =* Day's Priorities=, sub-step 3d sorts them by urgency, and Craig edits the prep doc directly to add or drop a priority.
+*** 5-Day Look-Ahead
 
-Sources contributing to Day's Priorities: todo.org (3a) plus everything the triage engine covers (email, Slack, Linear, PRs, calendar).
+Scan the forward window — read it, don't glance. For each meeting: the invite quick-read (who's invited and accepted, why it's being held, the timing, the objective). Three buckets:
 
-*** Recommended Approach Pattern (applied by the triage engine when writing reactive-task bodies)
+1. *Meetings that need prep* — substantive meetings with no prep doc yet. Offer to run the [[file:meeting-prep.org][meeting-prep workflow]] or add a prep task; catching these days out is the point.
+2. *Traps* — time-zone mismatch on a travel day, double-booking, a talk-heavy meeting that will overrun, a recurring meeting not needed this cycle.
+3. *Focus blocks to protect* — open mornings/afternoons worth blocking before they're booked over.
 
-When a triage Action item involves a non-trivial decision or judgment that benefits from analysis, the engine includes a =recommended approach= subheader before the response draft in the task body. The approach is the executor's analysis (situation, options, recommendation with rationale, considerations Craig should weigh) so Craig can evaluate the recommendation itself, not just the wording. This pattern is kept here as the shared reference; the triage engine and any response-drafting step follow it.
+Renders in Heads-Up as one line per day (=Fri 12:= … =Mon 15:= …), clear days marked =clear=, with the bucket findings attached to the days they concern.
 
-Skip the approach subheader for routine acknowledgments, simple status replies, or "yep, looks good" approvals.
+** Phase 2: Planned vs Actual (Create mode)
 
-Source-specific examples of when to *include* the approach subheader:
+Before setting tomorrow's priorities, review today's prep doc against what actually happened:
 
-- *Email:* decisions like grant applications, partnership replies, public-facing or sensitive responses
-- *Slack:* @mentions with explicit asks, items where someone is blocked waiting on Craig
-- *Linear:* @mentions requesting input, Blocked tickets Craig owns, Needs-Review items where the call isn't trivially obvious
+1. For each planned item: completed, partially done, or not started.
+2. For items that didn't happen, identify why (ran long, blocked, deprioritized, meetings overran).
+3. *Carry forward anything that still matters directly into the new doc's Day's Priorities*, with updated estimates based on what today taught. There is no hand-off section — the next day's prep is being built right now, so carry-forward lands as priorities entries.
+4. Completed items: note them for the end-of-day summary.
 
-Format (consistent across all three sources):
+This keeps the prep honest. A 1-hour task that consistently takes 3 hours means the estimates change; work that keeps getting bumped by meetings is a pattern worth raising at the gate. Update mode skips this phase.
 
-#+begin_example
-***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended approach
-<situation, options, recommendation with rationale, considerations>
-***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended response
-<draft response text, OR proposed action like a state change>
-#+end_example
+** Phase 3: Day's Priorities
 
-Generate timestamps with =date "+%Y-%m-%d %a @ %H:%M:%S %z"= so they're accurate, not estimated.
+Assemble priorities from both sources; no mid-flow confirmation (the gate handles review).
 
-*** Sub-step 3a: From todo.org
+*** Sub-step 3a: From todo.org and the tracker
 
 1. Pull all [#A] tasks from todo.org.
-2. Add time-sensitive items (DEADLINE: or SCHEDULED: touching the day).
-3. Carry forward unfinished items surfaced by Phase 2 — but skip any item already added by step 1 or 2 above. A task that was [#A] yesterday and didn't finish gets carried forward by Phase 2 and would also re-appear in step 1's [#A] pull. Dedupe by org-mode heading text or =:ID:= property if present.
-4. Pull open =:reactive:= tasks (created by prior preps under the *Triage Action items become =:quick:reactive:= todo.org tasks* convention) — these are pending quick-fire responses that should stay visible until processed. Dedupe against steps 1-3. Surface them as thin links in Day's Priorities; Craig drops the ones that don't fit today's plan.
-5. *Pull one "big ball" — an important-but-not-urgent task to chip at today.* Surface a single Quadrant-2 task from =todo.org= (a strategic or =[#B]=-=[#C]= item that matters but keeps getting deferred because nothing makes it urgent — a spec, a vetting, an arch sweep, a piece of networking, a flashcard batch) and slate a ~15-minute chunk on it for today. The point: big important-not-urgent work only ever gets done when it's broken into small daily pieces — otherwise the urgent perpetually displaces it, which is the failure mode this whole workflow exists to fight. One per day; Craig swaps or drops it at review. Phase 4 gives it a small block.
-
-Priorities typically include:
-- Messages to send (Slack, email)
-- Meetings to schedule
-- Documents to send out for review
-- Follow-ups to make
-- Prep work needed before a meeting
+2. Add time-sensitive items (=DEADLINE:= / =SCHEDULED:= touching the day).
+3. Fold in Phase 2's carry-forward (dedupe against 1-2 by heading text or =:ID:=).
+4. Pull open =:reactive:= tasks (created by prior triage runs) — pending quick-fire responses stay visible until processed. Dedupe against 1-3.
+5. Pull the tracker items that demand action today (assigned with near deadlines, blocked-on-Craig, review requests).
+6. *Pull one "big ball"* — a single important-but-not-urgent (Quadrant-2) task to chip at for ~15 minutes today: a spec, a vetting, an arch sweep, networking, a flashcard batch. Big strategic work only lands when broken into small daily pieces; one per day, Craig swaps or drops it at the gate.
 
 *** Sub-step 3b: Triage external sources (delegate to triage-intake.org)
 
-Don't scan email / Slack / Linear / PRs inline here. Run the =triage-intake.org= engine. It fans out across its source plugins, classifies each item against the shared four-bucket model (Action / FYI / Noise-keep / Noise-trash), synthesizes a single deduped summary, writes every Action item into =todo.org= as its own =:quick:reactive:= task, and executes the triage actions (star / mark-read / trash) on Craig's confirmation. That is the same work sub-steps 3b-3g used to do inline; the engine now owns it, so a source change lives in one plugin instead of being duplicated here.
-
-*Source coverage comes from the engine's Phase 0 plugin load.* triage-intake Phase 0 globs both =.ai/workflows/triage-intake.*.org= (general plugins: cmail, github-prs, personal-calendar, personal-gmail) and =.ai/project-workflows/triage-intake.*.org= (the project's own, e.g. the work account's Gmail, Slack, Linear, and GHE PRs). So everything daily-prep used to scan inline stays covered as long as the project ships its source plugins there. If a source isn't covered, the gap is a missing plugin in =.ai/project-workflows/=, not a daily-prep regression.
-
-The engine tracks its own "since when?" sentinel. Pass it the prior prep doc's mtime as the window if the project wants the prep cadence to drive triage scope; otherwise let it use its sentinel.
-
-*** Sub-step 3c: Surface today's reactive items in Day's Priorities
+Don't scan email / Slack / tracker / PRs inline. Run the =triage-intake.org= engine (if the mode's freshness check already ran one this hour, use its synthesis). It classifies everything new against the four-bucket model, writes every Action item into =todo.org= as its own =:quick:reactive:= task, and executes the routine actions on confirmation. Source coverage comes from its Phase 0 plugin load — both =.ai/workflows/triage-intake.*.org= (general) and =.ai/project-workflows/triage-intake.*.org= (project-specific). A missing source is a missing plugin, not a daily-prep regression.
 
-The engine (3b) and sub-step 3a's =:reactive:= pull have populated =todo.org= with the open quick-fire tasks. For each that belongs in *today's* plan (a deadline, a blocker, or someone waiting decides "today"), add a thin link under =* Day's Priorities=:
+*** Sub-step 3c: Build the entries
 
-#+begin_example
-** TODO [#B] <verb> <Person / topic> — [[file:../todo.org::*<task title>][todo.org]]
-<one line on why today>
-#+end_example
-
-Items that don't fit today stay in =todo.org= and resurface on a future prep via 3a's =:reactive:= pull. Don't duplicate task bodies into the prep doc; the thin link is the whole entry (2026-05-12 rule). One exception to the no-content rule: a URL the task is *done through* (payment portal, doc, PR, form) goes in the entry body per the execution-link rule above — and into the todo.org body if it isn't there yet.
+For each item that belongs in *today's* plan, write a Day's Priorities entry per the template rules: heading mirrors the todo.org task exactly (status, priority cookie, tags — plain text, links stripped from the heading), body carries the links (todo.org, tracker, PR, doc, execution URL), what success is, today's achievement goal when the task outlasts the day, and any relevant preparation. Items that don't fit today stay in =todo.org= and resurface on a future prep via 3a's pulls.
 
 *** Sub-step 3d: Urgency re-sort
 
-Re-order the entries under =* Day's Priorities= by urgency: (1) deadlines today or overdue, (2) Craig blocking someone, (3) deadlines within ~48h, (4) other [#A], (5) time-sensitive lower-stakes, (6) everything else. Entries are all thin links now, so it's a flat reorder of heading lines. Craig refines when he reviews; this just gives a sane starting order.
+Order: (1) deadlines today or overdue, (2) Craig blocking someone, (3) deadlines within ~48h, (4) other [#A], (5) time-sensitive lower-stakes, (6) everything else. The gate refines; this gives a sane starting order.
 
-*** Sub-step 3e: Phase 3 audit footer (forcing function)
+*** Sub-step 3e: Audit footer
 
-After 3a-3d, write a single comment line directly below the =#+DATE:= header recording which sources the triage engine actually covered:
+Write a single comment line below the =#+DATE:= header recording which sources triage actually covered:
 
 #+begin_example
-# Sources checked: todo.org ✓ | email-personal ✓ | email-deepsat ✓ | Slack ✓ | Linear ✓ | prs ✓
+# Sources checked: todo.org ✓ | email-personal ✓ | email-work ✓ | Slack ✓ | tracker ✓ | prs ✓
 #+end_example
 
-Take the per-source marks from the engine's synthesis (its Phase C reports per-plugin coverage). Replace ✓ with ✗ plus a parenthetical reason for any source the engine couldn't reach (e.g. =Slack ✗ (MCP disconnected)=). A source scanned with no items keeps its ✓ — empty is a valid result; this line catches a source that did not run at all.
+Take per-source marks from the engine's synthesis. Replace ✓ with ✗ plus a reason for any source that didn't run (=Slack ✗ (MCP disconnected)=). Scanned-but-empty keeps its ✓.
 
-** Phase 4: Time Blocking
+*** Recommended Approach Pattern (shared reference)
 
-Once priorities are confirmed, block time on the calendar to accomplish them. Phase 4 also writes the prep doc's =* Meetings / Work Blocks= section — a single chronological list interleaving meetings with focused-work blocks, top to bottom in time order.
-
-*** Meeting lines carry clickable join links (2026-06-10 rule)
-
-Every meeting line in =* Meetings / Work Blocks= gets an org link to its join URL, pulled from the calendar event's conference data (=conferenceData.entryPoints= in the Phase A MCP output — already fetched, no extra query). Example:
+When a triage Action item involves a non-trivial decision, the engine includes a =recommended approach= subheader before the response draft in the task body — situation, options, recommendation with rationale, considerations — so Craig can evaluate the recommendation, not just the wording. Skip it for routine acknowledgments and "yep, looks good" approvals. Format:
 
 #+begin_example
-- 10:00–11:00 — SWE weekly sprint planning [recurring; Eric] — [[https://us06web.zoom.us/j/...][join Zoom]]
+***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended approach
+<situation, options, recommendation with rationale, considerations>
+***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended response
+<draft response text, OR proposed action like a state change>
 #+end_example
 
-Craig clicks and joins right from the prep doc instead of digging through the calendar. A meeting with no conference URL (in-person, phone) just omits the link.
+Generate timestamps with =date "+%Y-%m-%d %a @ %H:%M:%S %z"=.
 
-*** Quick Tasks (< 5 minutes)
-Tasks like "schedule a meeting with Ryan" or "send a Slack message" should be done during the prep workflow itself, not scheduled separately. Draft the message or create the calendar event on the spot.
-
-*** Focused Work Tasks
-For anything requiring more than a few minutes:
-
-1. Ask Craig for a time estimate on each item
-2. Use the Phase A calendar snapshot — *do not re-query the calendars*. The same events are already in context.
-3. *Compute the day's active window.* Default 10:00 to 17:00, every day of the week (weekends included). If the prep is being run *same-day* (the prep doc's date matches today's date) and the workflow start-time is later than 10:00, the window starts at the start-time instead. Existing calendar appointments, known personal commitments (guests arriving, travel, off-time blocks Craig flagged), and the last-30-min next-day-prep reservation remove time from the window. Whatever's left is fillable with priorities. Don't auto-treat Saturday or Sunday as "off." Fill the window with tasks. If Craig wants personal time on a weekend, he marks it on the calendar or flags it during prep.
-4. List the schedule with open slots clearly marked. Show the active window's start, end, and remaining fillable minutes after subtracting appointments.
-5. Propose when each task fits, considering:
-   - Meeting proximity (prep work should be near the meeting it supports)
-   - Energy/focus (harder tasks earlier if possible)
-   - A half hour around lunchtime to eat when possible (protein shake or leftovers is fine -- this can be compressed or skipped on heavy days)
-   - Always reserve the last 30 minutes of the workday for daily prep for the following day. This is non-negotiable -- it's what keeps the cycle going.
-6. Craig confirms or adjusts the proposed schedule
-
-*** Placing Calendar Blocks
-- Place time blocks on Craig's personal Google calendar (=Craig Google=)
-- Can also place blocks on DeepSat calendar directly using MCP server with =account_id: "work"=
-- Use the calendar event workflows (add-calendar-event.org) for creating events
-
-** Phase 5: Prep Work
+** Phase 4: Build Meetings / Focus Blocks
 
-With the schedule set, work on anything that needs to be ready for the day's meetings. Examples:
+Write the schedule section: every calendar event as a level-2 header (=** HH:MM–HH:MM — Exact Calendar Title=), chronological, with content per the template's event-type rules.
 
-- Watch tutorial videos and take notes
-- Draft or polish documents for review
-- Prepare talking points or materials
-- Research topics that will come up in meetings
-- Draft messages that are part of the day's priorities
+1. *Verify against the live calendar* — the Phase A fetch at build time; a fresh fetch at update time. Times move; check every event.
+2. *Join links on every meeting line* from the event's conference data (=conferenceData.entryPoints= — already in the Phase A output, no extra query).
+3. *Compute the day's open window* (default 10:00-17:00, weekends included; same-day runs start at the current time). Subtract meetings, known commitments, lunch, and the end-of-day review block. What's left is focus-block space.
+4. *Lay out focus blocks* in the remaining space and write each block's menu per the template rules (recommended first, alternates, everything linked, sized to the block).
+5. *Place lunch* — 30-60 minutes somewhere in 11:00-13:30.
+6. Don't create the calendar events yet — that's Phase 9, after the gate.
 
-This phase is where the bulk of the session time goes. Work through items in priority order, with meeting-related prep taking precedence based on meeting time.
-
-** Phase 6: Standup Brief
-
-Generate the standup brief late in the workflow so the rest of the day's analysis is already done. The brief draws from Phase 2 (Planned vs Actual), Phase 3 (Day's Priorities), and the activity sweep below. Phase 6 writes the prep doc's =* Standup Briefs= section.
-
-Skip this phase entirely on days with no standup on the calendar.
-
-*** Step 1: Sweep recent activity for off-Claude signals
-
-Before drafting, check these sources for activity since the previous prep doc's date (the lookback anchor from Phase A step 5):
-
-1. *Sent email* — both accounts. Outgoing threads from Craig: decisions communicated, replies to action items, follow-ups, intros made.
-2. *Slack* — Craig's recent messages across channels and DMs. Decisions, status updates, threads where Craig participated.
-3. *todo.org* — items marked DONE since the cutoff. New TODOs added that hint at fresh context (new commitments, new blockers).
-4. *Linear* — tickets Craig moved to a new state, commented on, or created. Use the Linear MCP to query.
-
-These surface team-visible work that lives outside session history (work done in mu4e, Slack, the Linear UI, or off-Claude conversations).
-
-*** Step 2: Draft the brief
-
-Combine session history + the Step 1 sweep + Phase 3 priorities + todo.org WAITING items into the three-question structure below.
-
-*Meeting selection.* Recurring meetings are excluded from both the Yesterday and Today sections — they're not news to the team. For non-recurring meetings:
-
-- *Yesterday section:* include only meetings Craig actually attended. Filter on Craig's own response status from the calendar event:
-  - =accepted= → include
-  - =tentative= or =declined= → exclude (don't assume attendance)
-- *Today section:* include all non-recurring meetings regardless of response status. Craig still needs to communicate what he plans to attend or decide between.
-
-The Google Calendar MCP returns =responseStatus= per attendee — filter on Craig's own response, not the event's overall status. Recurring events expose =recurringEventId= or =recurrence=; treat the presence of either as the recurring marker.
-
-*Content rules.*
-
-- *Stay first-person.* Report what Craig did, said, or decided. Don't volunteer others for work or report what others said they would do — that's their standup, not Craig's. If a teammate's commitment is relevant context, frame it as something Craig is waiting on, not as a status update on their behalf.
-- *Match deadline precision to what's actually known.* If a deadline is "early next week," don't tighten it to "Monday." If the commitment is "before the proposal goes out," don't sharpen it to "Friday EOD." Vague is honest when vague is the truth.
-
-1. *What did I do since last standup?* Anchor the lookback at the previous prep doc's date (Phase A step 5). Pull session history, session-context.org, completed tasks, and the Step 1 sweep results from that date forward. Since DeepSat standup is a workday-recurring meeting, the previous prep doc's date is the previous standup date even if intervening days were weekends or PTO. Use explicit day references ("Monday" not "yesterday") since the prep doc may be written the evening before.
-2. *What am I doing today?* Pull from the day's priorities (Phase 3 output). Keep it to 2-3 items max.
-3. *Blockers: mine or yours?* The bar is "did this actually stop me from making progress?", not "is someone else involved?" A WAITING item in todo.org is only a blocker if Craig already tried to move forward and got stopped. Mere dependencies don't qualify unless they've already impaired progress. Default to under-reporting — draft without borderline items and let Craig add them back in Step 3. FYI items (decisions or context worth flagging that aren't blockers) come after blockers and stay loose.
-
-The brief should be concise enough to read aloud in under 60 seconds. Include enough context that Craig doesn't have to think on his feet, but not so much that it turns into a status report.
-
-*** Step 3: Present the draft and ask what's missing
-
-Show Craig the full draft brief — Yesterday, Today, Blockers/FYI sections all populated. Then ask:
-
-#+begin_quote
-Anything I missed? Common categories: off-Claude meetings or phone calls, paperwork or forms submitted, intros made or received, vendor conversations, anything else not captured in session/email/Slack/Linear.
-#+end_quote
-
-Recognition is faster than recall. Craig can react to "did you make any intros?" much faster than to "what did you do?" The categories are prompts, not a checklist.
-
-*** Step 4: Refine and finalize
-
-Apply Craig's additions and any wording adjustments. The brief is now ready for standup.
-
-*** Step 5: Offer to capture learnings
-
-After Step 4, scan Craig's refinements for non-obvious patterns:
-
-- Did he cut a category of item the workflow said to include?
-- Did he add a category the workflow didn't tell you to look for?
-- Did he change wording in a way that suggests a phrasing rule (e.g., "say 'continued focus on X' instead of 'worked on X'")?
-
-If a refinement looks like a generalizable rule, offer it back to Craig:
-
-#+begin_quote
-I noticed you [removed all 1:1 meetings from Yesterday / added the off-Claude phone call with Ryan / changed "completed proposal draft" to "continued focus on proposal"]. Want me to add this to the workflow? Proposed rule: "[concrete rule text]"
-#+end_quote
-
-Wait for explicit confirmation before editing the workflow. Never edit on your own judgment.
-
-If Craig confirms, append the rule to the *Updates and Learnings* section at the bottom of this file with today's date and a one-line description. If the new rule supersedes existing text inside Phase 6, also update the inline text and note "(updated YYYY-MM-DD — see Updates and Learnings)" in the affected section so the audit trail is complete.
-
-If the refinement looks like a one-off, don't propose a rule. Default to under-proposing — false-positive rules clutter the workflow. The bar is "would I want this guidance the next time I draft a brief?" If yes, propose. If no, drop it.
-
-** Phase 7: Final Section Writeups
-
-Three sections remain after Phase 6: =* Heads-up=, =* Upcoming Deadlines=, and the next day's =* [Day]'s Anchor Tasks=. Phase 7 writes them, drawing on what earlier phases already surfaced.
+*** Quick Tasks (< 5 minutes)
 
-Order doesn't matter between the three sub-steps. They write to distinct sections and don't depend on each other.
+"Schedule a meeting with <person>" or "send a quick reply" gets done during the prep itself, not scheduled. Draft the message or create the event on the spot.
 
-*** Sub-step 7a: Heads-up
+** Phase 5: Prep Work
 
-Write a top-level =* Heads-up= section near the top of the prep doc (above =* Day's Priorities=).
+With the schedule drafted, produce what the day's entries need to be self-sufficient:
 
-Heads-up is the executive summary of what would change Craig's frame for the day. Terse, situational, day-shaping. Pull from sources earlier phases surfaced:
+- *Pre-write every draft* the doc promises — reschedule messages, replies, heads-up notes — =/voice personal= applied, sitting in the entry ready to send on Craig's word.
+- Hunt down and link every meeting's materials (prep docs, proposals, resumes, decks). A mention without a =file:= link is a defect.
+- Answer the likely questions for each meeting; for every "I don't know," queue a day-before prep block for Phase 9.
+- Research, talking points, and document polish for the day's meetings, in meeting-time order.
 
-- *Substantial FYIs* from the triage engine's synthesis (sub-step 3b) — items like "Eric quietly progressed two partnership threads on Apr 24" or "Vrezh force-pushed all three branches overnight" that affect what Craig should expect today
-- *Schedule changes* from Phase 1 — "Arusyak 15:00-16:00 is being rescheduled" or "DeepSat GTM declined for tonight"
-- *Urgent deadlines bubbling up* — items in =* Upcoming Deadlines= that hit within ~2 days, surfaced as standalone Heads-up items so Craig sees them immediately
-- *Active Reminders* (from Phase A's notes.org read) that frame today specifically — "first thing in the morning, register for SOFWeek"
+** Phase 6: Standup Briefs
 
-Format: bullet list, one situational note per line, no sub-bullets. Keep each entry to one sentence. If a Heads-up item needs more context, link to the source (email, ticket, prep section) instead of inlining.
+Generate briefs late, so the day's analysis is already done. Each brief is written *under its standup's header* in Meetings / Focus Blocks. Skip on days with no standup.
 
-Lightweight FYIs (status pings, "FYI we shipped", small acknowledgments) stay in =.ai/session-context.org= and don't surface in Heads-up.
+*** Step 1: Sweep recent activity for off-Claude signals
 
-*** Sub-step 7b: Upcoming Deadlines
+Check, since the previous prep doc's date: sent email (both accounts), Slack (Craig's messages across channels and DMs), todo.org DONE-since-cutoff and fresh TODOs, and the tracker (state changes, comments, created items). These surface team-visible work that lives outside session history.
 
-Write a top-level =* Upcoming Deadlines= section.
+*** Step 2: Draft the brief(s)
 
-Source: scan todo.org for =DEADLINE:= entries plus deadlines mentioned in notes.org or knowledge.org. Filter to roughly the next 4-6 weeks. Order chronologically.
+Combine session history + the sweep + Day's Priorities + WAITING items into Yesterday / Today / Blockers, per the template's standup rules (altitude match, outcomes not attendance, =Blockers: None= explicit, no recurring 1:1s/ceremonies). Additional drafting rules:
 
-Format: bullet list, one deadline per line, format =- [Day YYYY-MM-DD] — short description=. Mention the owner if it isn't Craig and the deadline still concerns him (e.g., "Subbu owns; Craig's technical content due ahead of this").
+- *Stay first-person.* Report what Craig did, said, or decided. Don't volunteer others or report their commitments as status — frame a teammate's commitment as something Craig is waiting on, if it's relevant at all.
+- *Match deadline precision to what's known.* "Early next week" doesn't tighten to "Monday." Vague is honest when vague is the truth.
+- *Yesterday* anchors on the previous prep doc's date. Include only non-recurring meetings Craig actually attended (his own =responseStatus= = accepted). Use explicit day references ("Monday," not "yesterday") — the doc is written the evening before.
+- *Today*: 2-3 items max, from Day's Priorities. Include non-recurring meetings regardless of response status.
+- *Blockers*: the bar is "did this actually stop me from making progress?" — not "is someone else involved?" Default to under-reporting; Craig adds borderline items at the gate. FYIs come after blockers and stay loose.
+- *Team-visible filter*: only work that left Craig's local environment — pushed, shared, posted, changed in the tracker, or shifts what the team believes or plans. "If I didn't mention this, would someone make a worse decision or duplicate work?" If no, cut it.
+- Readable aloud in under 60 seconds.
 
-Volume control: if more than ~10 deadlines fit the window, narrow the window or surface only the ones that are blocking, externally-imposed, or have non-trivial prep ahead.
+*** Step 3: Capture learnings
 
-Don't duplicate deadlines that are already today's =* Day's Priorities= entries. Day's Priorities is for action; Upcoming Deadlines is for awareness.
+When Craig's gate-time refinements to a brief look like a generalizable rule (cut a category, added one, a phrasing pattern), offer it back: "Want me to add this to the workflow? Proposed rule: …" Wait for explicit confirmation, then append to *Updates and Learnings* below and update the affected inline text. Default to under-proposing.
 
-*** Sub-step 7c: Next day's Anchor Tasks
+** Phase 7: Heads-Up
 
-Write a top-level =* [Day]'s Anchor Tasks= section. Compute the next day's name from today's date — *don't* skip weekends. For a Friday prep doc this becomes =* Saturday's Anchor Tasks=, for a Saturday prep doc it becomes =* Sunday's Anchor Tasks=, etc. Use known PTO markers if any (a fully-blocked PTO day can be skipped to the next available day).
+Write =* Heads-Up= last, when everything it summarizes exists: the density framing, both calendars' events, due/past-trigger reminders, the metrics slot (only if a metric is active), and the 5-day look-ahead lines from Phase 1. Pull substantial triage FYIs that change Craig's frame for the day; lightweight FYIs stay in =.ai/session-context.org=.
 
-Source: items Craig is explicitly committing to do tomorrow. Pull from:
+Also assemble the end-of-day block's upcoming-deadlines list: =DEADLINE:= entries from todo.org plus deadlines from notes.org, next 4-6 weeks, chronological, one per line. Don't duplicate items already in Day's Priorities — priorities are for action, the deadline list is for awareness.
 
-- Items planned for today that didn't get done (from Phase 2's Planned vs Actual)
-- Items that genuinely fit tomorrow better than today (criterion below)
-- Prep work needed before tomorrow's meetings
-- Anything Craig flagged during today's session as "I'll do this tomorrow"
+** Phase 8: Priorities Review Gate (Create mode — MANDATORY)
 
-*Criterion for pushing an item to tomorrow rather than fitting it today.* Push only if at least one is true:
+Present the assembled doc and ask whether Craig agrees with the Day's Priorities. If not, work with him to add / remove / substitute priorities and blocks until he confirms. Surface here, in one pass: meeting-goal questions, decline candidates, look-ahead flags, carry-forward decisions, and proposed schedule adjustments.
 
-1. *Hard-blocked today* — waiting on a person, a system, or a deadline that hasn't passed yet
-2. *Needs a contiguous block* today's window can't provide
-3. *Prep work for a tomorrow-only meeting* (do the prep close to the meeting)
-4. *Team-dependent* and the team isn't available today (e.g., Craig's at one location and the team's at another)
+If the gate produces substantive rework, say so plainly: that's a =todo.org= staleness signal — the file should make Craig's current priorities obvious. Offer a task review.
 
-If none of those apply, the item stays in today's Day's Priorities and gets a time block in Phase 4. Don't auto-punt independent reading, registration, local-machine work, or "I'll get to it tomorrow" items just because today is a weekend or feels light.
+Update mode replaces the gate with a delta summary: what changed and why.
 
-Items further out than tomorrow (Monday-only items written on a Saturday, for example) stay in =todo.org= with appropriate priority and SCHEDULED markers. Don't list them in the prep doc — they'll resurface in the relevant day's prep via Phase 3 sub-step 3a.
+** Phase 9: Calendar Writes (after the gate)
 
-Format: bullet list or =** TODO= headings, with optional time estimates (e.g., "— 1.5 hrs"). Each item should be a clear task — passive monitoring or context goes elsewhere (Heads-up or session-context).
+Only after Craig confirms:
 
-This section is the explicit handoff to next-day's Phase 2. If it's empty, write the header with "(none flagged)" so the next day's prep doesn't mistake an empty section for a missing one.
+1. *Create the focus blocks* on the calendar for the prepped day — marked *free*, titled for focused work.
+2. *Create day-before prep blocks* for every meeting question that landed on "I don't know" (and for look-ahead meetings needing prep that Craig accepted).
+3. Any reschedules Craig approved at the gate: send the pre-written message, then move the event.
 
-** Phase 8: Repoint the Current-Day Symlink
+Use the project's calendar-event workflow (=add-calendar-event.org=) where it exists; respect existing commitments — don't double-book.
 
-Prep docs are *born* in their permanent home and never move. The home is
-=daily-prep/= at repo root: every prep doc is created directly as
-=daily-prep/YYYY-MM-DD-daily-prep.org= (Phase A onward writes there), and the
-dated files accumulate in place. There is no archive move — =daily-prep/= is
-both the working location and the archive.
+** Phase 10: Repoint the Current-Day Symlink
 
-A single stable symlink at the project root — =daily-prep.org= — points at the
-current day's file. The only day-to-day change is repointing it. After the new
-prep doc exists, point the symlink at it:
+Prep docs are *born* in their permanent home and never move: =daily-prep/YYYY-MM-DD-daily-prep.org=, accumulating in place (working location and archive are the same directory). A single stable symlink at the project root points at the current day's file:
 
 #+begin_src bash
 # Relative target so the symlink stays valid if the project tree moves.
 ln -sf daily-prep/YYYY-MM-DD-daily-prep.org daily-prep.org
 #+end_src
 
-Consumers — the Emacs opener (=C-c p d=), next-day Phase 2, the standup
-lookback — resolve =daily-prep.org= rather than computing a filename or
-searching =inbox/=. Nothing prep-related lands in =inbox/= anymore.
+Consumers — the Emacs opener, next-day Phase 2, the standup lookback — resolve =daily-prep.org= rather than computing a filename. First run in a project: create =daily-prep/=, migrate any =inbox/*-daily-prep.org= or stale =assets/= prep docs into it, then link.
 
-Setup / migration (first run in a project on this convention):
+** Phase 11: Project Extension
 
-- If =daily-prep/= doesn't exist yet, create it.
-- Move any existing =inbox/*-daily-prep.org= (the old born-in-inbox location)
-  into =daily-prep/=, and any stale prep doc under =assets/= (an even older
-  convention) likewise. Then create the root =daily-prep.org= symlink at the
-  most recent one.
-- Don't put prep docs in =deepsat/meetings/= — the prep doc covers personal
-  calendar, all 1:1s, and all projects, not just DeepSat work.
-
-This keeps =inbox/= free of prep-doc churn and makes "today's prep" a single
-predictable path instead of a dated filename that has to be reconstructed.
-
-** Phase 9: Project Extension
-
-If =.ai/project-workflows/daily-prep.org= exists, read and execute its instructions as additional steps appended to this workflow. The project file contains add-ons specific to the project. It is *not* a replacement for this template — it picks up where this workflow's main flow ends.
-
-Surface the extension once per session ("Project has additional daily-prep steps — running them now") so the choice is visible.
-
-This is the project-extension hook from [[file:startup.org][startup.org]]'s workflow discovery rule, made explicit at the workflow level so it's not buried in discovery instructions. Runs in both full-prep and standup-only modes.
+If =.ai/project-workflows/daily-prep.org= exists, read and execute it as *additional* steps appended here — project add-ons (e.g. the project's specific standup names, calendars, recurring-event IDs), not a replacement. Surface once per session ("Project has additional daily-prep steps — running them now"). Runs in both modes.
 
 * Principles to Follow
 
 ** Prep Supports Action
-The goal is for Craig to walk into every meeting and task with what he needs. If prep doesn't lead to better outcomes, it's wasted time.
+Craig should walk into every meeting and block with what he needs *in the doc, linked*. If prep doesn't lead to better outcomes, it's wasted time.
 
 ** Craig Drives Priorities
-Claude surfaces information and proposes priorities, but Craig decides what matters. Don't assume -- ask.
+Claude surfaces information and proposes; Craig decides. The Phase 8 gate is where that happens — once, with full context, not piecemeal mid-flow.
+
+** Be Thorough, Check Every Meeting
+Every meeting verified against the live calendar, every prep doc linked, every likely question answered or scheduled for day-before prep. Consistency is the value — a prep that's excellent four days out of five fails on the day it matters.
 
 ** Quick Tasks: Just Do Them
-If something takes less than 5 minutes, do it during prep rather than scheduling it. Draft the Slack message, create the calendar invite, send the email.
+Under 5 minutes: do it during prep. Draft the message, create the invite, send the email.
 
 ** Respect the Calendar
-When proposing time blocks, respect existing commitments across all calendars. Don't double-book. Account for transition time between meetings.
+Don't double-book. Account for transitions. Focus blocks are marked free by design; lunch has a 30-minute floor.
 
 ** First-Person Perspective
-When preparing 1:1 talking points, frame everything from Craig's perspective -- what does Craig need to communicate, ask, or decide? Not what the other person needs.
+Frame 1:1 talking points from Craig's side — what he needs to communicate, ask, or decide.
 
 * Living Document
 
@@ -541,90 +386,64 @@ Update this workflow based on what works in actual daily prep sessions. Track le
 ** Updates and Learnings
 
 *** 2026-02-23: Initial creation
-Created during first daily prep session. Validated against tomorrow's schedule (2026-02-24: Vrezh 1:1, Standup/IPM, Product Review, Backlog Planning).
+Created during first daily prep session. Validated against tomorrow's schedule (2026-02-24: 1:1, Standup/IPM, Product Review, Backlog Planning).
 
 *** 2026-02-23: Use explicit day references, not relative terms
-When referring to past meetings or events, always include the explicit day (e.g., "from Monday's meeting" not "from this morning's meeting"). The prep doc may be written the day before and read the day of -- relative references like "this morning" or "today" become ambiguous. Include the day name so Craig doesn't have to calculate days in his head while focused on making a point.
+The prep doc may be written the day before and read the day of — "this morning" is ambiguous. Include the day name.
 
 *** 2026-02-23: Prep doc output
-The prep was originally written to =inbox/YYYY-MM-DD-daily-prep.org= where the date is the day being prepped for. (Superseded 2026-06-01 — prep docs now live in =daily-prep/= with a root =daily-prep.org= symlink. See the 2026-06-01 entry below and Phase 8.)
-The startup workflow checks for this file and asks whether to open it. Note: need to resolve where the daily prep reference in startup.org lives so template syncing doesn't overwrite it (see todo.org task).
+Originally =inbox/YYYY-MM-DD-daily-prep.org=. (Superseded 2026-06-01 — born in =daily-prep/= with a root symlink; see Phase 10.)
 
 *** 2026-02-23: Check for dependencies between tasks and meetings
-Tasks and meetings often depend on each other. SkyFi prep needs to happen before the Vrezh 1:1 so Craig can ask informed questions; Linear learning needs to happen before the backlog planning meeting where they'll use it. Always check for these dependencies and ask Craig when unsure.
+Prep work that feeds a meeting schedules before it. Ask Craig when unsure.
 
 *** 2026-02-23: Energy management matters as much as time management
-Front-load high-effort, high-stakes work early in the day (about an hour after waking). Save research, reading, and lighter tasks for late afternoon when energy dips. Craig tries to eat lunch and have coffee/tea around 12:30 PM to sustain energy for the afternoon. This principle should guide time block placement alongside calendar constraints.
+Front-load high-effort, high-stakes work early. Lighter work late afternoon. Lunch ~12:30 sustains the afternoon.
 
 *** 2026-02-23: Link references in the prep doc
-When listing tasks, documents, or directories in the prep doc, include links to the source
-(todo.org line numbers, file paths, directories). Craig shouldn't have to search for context
-when he's in the middle of a meeting or working through the day.
+Tasks, documents, directories — link the source. Craig shouldn't search for context mid-meeting. (Strengthened 2026-06-11: links are now a structural requirement of every entry, not a courtesy.)
 
 *** 2026-02-23: Note dependencies between time blocks
-When an earlier time block feeds into a later meeting, call it out explicitly in the prep doc
-(e.g., "by this point, should have already checked Okta access"). Helps Craig verify he's
-on track as the day progresses.
+When an earlier block feeds a later meeting, say so in the doc.
 
 *** 2026-02-23: Prep doc is a living document through the day
-Craig may annotate the prep doc with "cj:" comments as he works through it. Process those
-when asked or at the start of the next session. Remove the comment markers after acting on them.
+Craig annotates with "cj:" comments; process when asked or next session.
 
 *** 2026-02-23: Ask probing questions about task nature
-When a task like "SkyFi outreach" could mean either a 5-minute email or a 1-hour call, ask. The answer often splits the task into prep + action, which schedule differently. These questions are very helpful and should be a regular part of the workflow.
+"Outreach" could be a 5-minute email or a 1-hour call. Ask; the answer often splits prep from action.
 
 *** 2026-03-08: Keep Day's Priorities, drop separate Time Blocking table
-The output prep doc should have a "Day's Priorities" section followed by a single chronological
-"Meetings / Work Blocks" section that interleaves meetings, prep blocks, and focused work blocks
-in time order. No separate Time Blocking table — the chronological Meetings / Work Blocks section
-serves that purpose.
-
-*** 2026-03-09: Day's Priorities use org-mode TODO headings, not numbered lists
-Each priority is a =** TODO= heading under =* Day's Priorities=, not a numbered list item.
-Format: =** TODO Task name — description. Links to todo.org or other files. ~time estimate.=
-Do not use bold or italic markup in the prep doc — org headings, TODO keywords, and plain text
-provide enough structure.
-Mark completed items as =** DONE= with a =CLOSED:= timestamp on the next line.
-Order by urgency and priority — most important/time-sensitive first. Craig should be able to
-work top-to-bottom and know he's tackling the right thing next.
-This makes priorities trackable in org-mode (agenda, todo filtering) and lets Craig toggle
-status directly in Emacs as the day progresses.
-
-The workflow phases (identify priorities, propose time blocks) still happen during the prep
-conversation — the change is only to the output format.
+Day's Priorities followed by a single chronological schedule section. (The schedule section was renamed Meetings / Focus Blocks 2026-06-11.)
 
 *** 2026-03-08: Always include Planned vs Actual
-Craig finds the Planned vs Actual review table valuable. Always include it in the prep doc
-when a previous day's prep doc exists. This is Phase 2 of the workflow and should never be skipped.
+The review happens every Create run (Phase 2). (Adjusted 2026-06-11: it feeds carry-forward into the new doc's priorities and the end-of-day summary rather than rendering as its own table — the strict template has three sections.)
+
+*** 2026-03-09: Day's Priorities use org-mode TODO headings, not numbered lists
+Priorities are org TODO headings, trackable in agenda/todo filtering, toggleable in Emacs. No bold/italic markup in the prep doc.
 
 *** 2026-04-01: Always use human-readable ticket titles
-When referencing Linear tickets (or any issue tracker IDs), always use the human-readable
-title with the ID in parentheses — e.g., "Setup Database for dev environment (SE-93)" not
-just "SE-93." Craig can't remember what ticket IDs map to, and bare IDs force him to look
-them up. Use the Linear MCP tools to fetch the title if needed.
+"Setup Database for dev environment (SE-93)", never bare "SE-93". Fetch the title via the tracker MCP if needed.
 
 *** 2026-03-27: Standup briefs — only team-visible goals, not personal productivity
-Only include work that left Craig's local environment: pushed to a repo, shared with
-the team, posted in Slack, changed something in Linear, or shifts what the team believes
-or plans. Exclude work whose output lives entirely in Craig's local files (knowledge.org,
-todo.org, session notes, transcript processing, local tooling setup, MCP server config).
-Filter: "If I didn't mention this, would someone on the team make a worse decision or
-duplicate the work?" If no, cut it.
+Only work that left Craig's local environment. Filter: "if I didn't mention this, would someone make a worse decision or duplicate work?"
 
-*** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks — never duplicated content
-Craig's call. The prep doc's =* Day's Priorities= entries point at todo.org tasks (=** TODO [#X] <title> — [[file:../todo.org::*<title>][todo.org]]= plus a one-line "why today"); all the substance — descriptions, drafts, research, sub-tasks, VERIFY asks, recommended-approach — lives in the matching todo.org task, which Phase 3 creates or updates. Completed-today entries still become dated log headings in the prep doc (the day's record), linking to their durable todo.org home if there is one. Full statement in *Prep Doc Structure ▸ Day's Priorities entries are thin links to todo.org tasks* above. Follow-up: Phase 3 sub-steps 3b–3f still say "add to the prep doc" — reword them to "create/update the todo.org task, link from the prep doc" on the next pass. (Supersedes the 2026-03-09 "Day's Priorities use org-mode TODO headings" entry's implication that the content lives in the prep doc — the headings still use TODO keywords / dated-log headings, but the body is a link.)
+*** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks
+Entries pointed at todo.org tasks with all substance in the task body. (Superseded 2026-06-11 — entries now carry their own context, with links in the body. See the 2026-06-11 entry.)
 
 *** 2026-05-15: Triage Action items become =:quick:reactive:= todo.org tasks — no grouped Response sub-sections
-Craig's call, originally landed in the work project's =triage-intake= workflow on 2026-05-15 and propagated here on 2026-05-16. Each Action item surfaced by Phase 3 sub-steps 3b/3d/3e/3f (email, Slack, Linear, PRs) becomes its own =** TODO [#B] <verb-led description> :quick:reactive:[person]:= in =todo.org=. The Day's Priorities section in the prep doc references it via a thin link when it belongs in today's plan, otherwise the task stays in =todo.org= for later. Replaces the prior pattern of building grouped =** Email Response= / =** Slack Response= / =** Linear Response= / =** PR Review= sub-headings under Day's Priorities — those sub-sections no longer exist. Source mix now lives in the tags on each task, not in the prep doc structure. Full statement in *Prep Doc Structure ▸ Triage Action items become =:quick:reactive:= todo.org tasks* above. (Closes the 2026-05-12 follow-up about rewording sub-steps 3b–3f.)
+Each Action item surfaced by triage becomes its own =** TODO [#B] <verb-led description> :quick:reactive:[person]:= in =todo.org=. Source mix lives in the tags, not in prep-doc structure. Still in force — the prep-doc side of the convention (thin links) was superseded 2026-06-11; the todo.org side stands.
 
 *** 2026-05-31: Delegate triage to the triage-intake engine
-Phase 3's inline source scans — sub-steps 3b (email), 3c (mark-read), 3d (Slack), 3e (Linear), 3f (PRs), and 3g's cross-source dedup, ~280 lines — duplicated what the =triage-intake.org= engine has owned since its 2026-05-26 engine/plugin refactor. Collapsed them to four steps: 3b runs the engine (it fans out across general + project source plugins, classifies, synthesizes, writes the =:quick:reactive:= tasks, and executes star/mark-read/trash on confirmation); 3c surfaces today's reactive items as Day's Priorities thin links; 3d re-sorts by urgency; 3e writes the audit footer from the engine's per-source coverage. Source coverage carries because the engine's Phase 0 globs both =.ai/workflows/= and =.ai/project-workflows/= plugins, so the work account's Gmail/Slack/Linear/GHE plugins are still scanned — the delegation must not drop them, and Phase 0's two-dir glob is what guarantees it. The Recommended Approach Pattern stayed here as the shared reference (the engine applies it when writing reactive-task bodies); a future tidy could move it into the engine. Also closes the 2026-05-12 follow-up about rewording sub-steps 3b-3f.
+Phase 3's ~280 lines of inline source scans collapsed into a delegation to the =triage-intake.org= engine; coverage carries via its two-dir plugin glob. The Recommended Approach Pattern stays here as the shared reference.
 
 *** 2026-06-01: Prep docs live in =daily-prep/= with a root =daily-prep.org= symlink — no inbox churn, no archive move
-Craig's call. The prep doc is now *born* in =daily-prep/YYYY-MM-DD-daily-prep.org= and never moves; the dated files accumulate there as both working location and archive. A single stable symlink at the project root — =daily-prep.org= — points at the current day's file, repointed each prep run with =ln -sf=. Replaces the prior model where the doc was born in =inbox/YYYY-MM-DD-daily-prep.org=, yesterday's stayed in =inbox/=, and older docs were =mv='d into the =daily-prep/= archive (old Phase 8). Consumers resolve the root symlink instead of computing a dated filename or searching =inbox/=: the Emacs opener =C-c p d= (=cj/open-project-daily-prep=, repointed from =inbox/today-prep.org= to =daily-prep.org= — handoff filed to the =.emacs.d= project 2026-06-01), next-day Phase 2, and the standup lookback (Phase A step 5, which now globs =daily-prep/= and takes the file before the symlink's target). Touchpoints updated: Phase A step 5 + slim-Phase-A step 2 (lookback), standup-only "Where the brief lands," Phase 8 (rewritten as "Repoint the Current-Day Symlink"). Cross-workflow: =triage-intake.org='s sentinel-anchor fallback dropped its =inbox/= prep-doc path. (=wrap-it-up.org= was left as-is — its =inbox/= references are about =lint-followups.org= routing, not the prep doc, so they stay correct.) Migration is one-time per project: move existing =inbox/*-daily-prep.org= into =daily-prep/= and create the root symlink at the most recent.
+The prep doc is born in =daily-prep/YYYY-MM-DD-daily-prep.org= and never moves; the root symlink repoints each run. Consumers resolve the symlink. Migration is one-time per project.
 
 *** 2026-06-10: Execution links in priorities + join links on meetings
-Two link rules from working the 2026-06-10 prep doc (Craig's asks, verbatim in the handoff: "when adding tasks to the priorities, you will need to include the relevant link" / "we really need to add links to the meetings so I can click and join right from the daily prep document"). (1) A Day's Priorities entry actioned through a URL carries that URL in the entry body; the thin link to todo.org names the task's home, not the way to do it. If the URL isn't in the todo.org task body yet, the prep build finds it (source email, Slack thread) and adds it to both. Worked example: the NOLA water-bill task linked to todo.org but not the InvoiceCloud payment URL, so doing the task meant a Gmail dig first. (2) Every meeting line in Meetings / Work Blocks carries an org link to its join URL from the calendar event's conference data, so Craig joins from the prep doc. Stated in *Prep Doc Structure* (execution-link rule), sub-step 3c, and the new Phase 4 join-links sub-section.
+(1) An entry actioned through a URL carries that URL in its body; if the todo.org task lacks it, the prep build finds it and adds it to both. Worked example: a utility-bill task linked to todo.org but not the payment portal, so doing the task meant an email dig first. (2) Every meeting line carries an org link to its join URL from the event's conference data.
 
 *** 2026-06-10: Manager Tools prep additions — 5-day look-ahead, daily big-ball, decline gate
-Three additions folded in from the Manager Tools / Career Tools casts on preparing-for-your-day and meeting prep. None adds a new prep-doc section (the fixed-section rule holds — the look-ahead feeds Heads-up / Anchor Tasks). (1) *5-Day Look-Ahead* — Phase A widens the calendar fetch from the prep day to the prep day plus the next 5 days, and a new Phase 1 sub-section scans that forward window for three buckets: meetings that need prep, traps (time-zone mismatch, double-booking, overrun, an unneeded recurring meeting), and focus blocks to protect. A scan-and-flag pass, not full prep. (2) *Daily big-ball* — Phase 3 sub-step 3a item 5 pulls one important-but-not-urgent (Quadrant-2) task per day and slates a ~15-minute chunk, since strategic work only lands when broken into small daily pieces. (3) *Decline gate* — Phase 1 item 5 reframes "what Craig needs" from attending to contributing, and adds a send-regrets gate: a meeting with no objective and no contribution is a decline candidate for Craig's call at review. The look-ahead's meeting-prep references link directly to =meeting-prep.org= (promoted to a template 2026-06-10).
+(1) 5-Day Look-Ahead: Phase A widens the fetch to prep day + 5; Phase 1 scans the window for meetings-needing-prep / traps / focus-blocks-to-protect. (2) Daily big-ball: one Quadrant-2 task per day, ~15-minute chunk. (3) Decline gate: "what Craig needs" reframed from attending to contributing; no objective + no contribution = decline candidate.
+
+*** 2026-06-11: Full template rewrite — strict three-section doc, two run modes, mandatory priorities gate
+From Craig's instructive template spec (written 2026-06-10 evening, after reviewing generated preps) plus four refinements from his review of the first new-format prep. The doc is now exactly =* Heads-Up= / =* Day's Priorities= / =* Meetings / Focus Blocks=. Retired: the separate =* Standup Briefs= and =* Upcoming Deadlines= sections (briefs nest under their standup meeting; deadlines live in the end-of-day block), the =* [Day]'s Anchor Tasks= handoff (carry-forward lands directly in the next day's priorities, which are being built in the same sitting), the thin-link convention (entries mirror their todo.org task's heading and carry their own context — links in the body, never the heading), and standup-only mode (a brief refresh is an Update-mode run). New: two run modes (Create, with a MANDATORY end-of-flow priorities review gate whose disagreement signals todo.org staleness; Update, for when the world moves) both preceded by a triage-intake freshness check (no run in the last hour → run one first); event headers are the exact calendar title with ALL content nested under the event; per-event-type content rules (Morning Prep conflict-resolution strategy with drafts pre-written in the doc ready to send, standup altitude matching with =Blockers: None= explicit and operations excluded from business-level briefs, meetings carrying contribute/get/likely-questions with day-before prep blocks for "I don't know" answers and prep docs always =file:=-linked — the lesson of a prep that existed but couldn't be found in the minutes before a meeting that mattered, focus blocks as linked menus created day-before and marked free, lunch floor, the end-of-day "What Kind of Day Has It Been?" block carrying the deadlines list and generating tomorrow's prep); the look-ahead renders one day per line (=Fri 12:= …) with clear days marked =clear=; a requested-metrics Heads-Up slot rendered only when a metric is active (none yet); meetings verified against the live calendar at build and update time.
diff --git a/claude-templates/.ai/workflows/INDEX.org b/claude-templates/.ai/workflows/INDEX.org
index 218709f..3f54f7c 100644
--- a/claude-templates/.ai/workflows/INDEX.org
+++ b/claude-templates/.ai/workflows/INDEX.org
@@ -30,9 +30,9 @@ This index must list every =.org= file in =.ai/workflows/= except this one and e
   - Triggers: "task review", "review tasks", "let's do a task review", "groom my tasks", "task-review"
 - =task-audit.org= — content reconciliation: take the open tasks and check their recorded facts against reality (sessions, email, chat, ticketing, calendar, meeting recordings), update the stale facts, consolidate duplicates, and flag the judgment calls only the user can answer. Deeper than =task-review.org= (relevance/keep-kill/priority); this one keeps the surviving tasks factually honest.
   - Triggers: "task audit", "audit my tasks", "audit the open tasks", "are my tasks still accurate", "reconcile my tasks", "update the stale tasks"
-- =daily-prep.org= — prep brief for the next workday. Two modes: full-prep (default) or standup-only.
-  - Full-prep triggers: "let's prep for tomorrow", "daily prep"
-  - Standup-only triggers: "what's my standup report", "let's do the daily standup report", "give me the standup brief"
+- =daily-prep.org= — builds and maintains the daily prep doc (strict three-section template: Heads-Up / Day's Priorities / Meetings / Focus Blocks). Two run modes: Create (build a future day's prep, ends with a mandatory priorities review gate) or Update (refresh an existing day's prep when the world moved). A standup-brief refresh is an Update-mode run scoped to the standup's entry.
+  - Create triggers: "let's prep for tomorrow", "daily prep"
+  - Update triggers: "update today's prep", "refresh the daily prep", "what's my standup report", "give me the standup brief"
 - =meeting-prep.org= — deep prep doc for one specific upcoming meeting that warrants more than a glance: decode the invite (who/why/timing/objective), gather grounded context, draft the eight-section prep, pre-wire and schedule the prep block, review with Craig, wire into the day's daily-prep, and close the loop post-meeting by extracting action items into =todo.org=. The per-meeting companion to =daily-prep.org='s whole-day brief.
   - Triggers: "let's prep for the <X> meeting", "prep me for the call with <Y>", "build a prep doc for <meeting>", "let's run the meeting-prep workflow", "meeting prep", "let's prep the <name> call"
   - Supporting doc: =meeting-prep.pre-wire.org= (the full Manager Tools pre-wire method, used by Phase 3.5). Not independently triggerable.
diff --git a/claude-templates/.ai/workflows/daily-prep.org b/claude-templates/.ai/workflows/daily-prep.org
index abf70a4..b6989e7 100644
--- a/claude-templates/.ai/workflows/daily-prep.org
+++ b/claude-templates/.ai/workflows/daily-prep.org
@@ -1,12 +1,12 @@
 #+TITLE: Daily Prep Workflow
 #+AUTHOR: Craig Jennings & Claude
-#+DATE: 2026-02-23
+#+DATE: 2026-06-11
 
 * Overview
 
-This workflow prepares Craig for the next workday by reviewing scheduled meetings, identifying priorities, and blocking time on the calendar. It ensures Craig walks into every meeting prepared and has a plan for the day's focused work.
+This workflow builds and maintains the daily prep doc — the single document Craig works from all day. It assembles the day's frame (Heads-Up), the day's work (Day's Priorities), and the day's schedule with everything nested under it (Meetings / Focus Blocks), so Craig walks into every meeting prepared and every open block with a menu of ready, linked work.
 
-This is typically run the evening before or morning of the workday in question.
+The prep doc for a day is normally generated the afternoon before, during the end-of-day review block, and updated whenever the world moves.
 
 * Problem We're Solving
 
@@ -19,520 +19,365 @@ Without daily prep, Craig risks:
 
 *Impact:* Unprepared meetings waste everyone's time. Unplanned days let urgent displace important.
 
+The deepest failure mode this workflow guards against is *prep that exists but can't be reached*: a meeting prep doc that was built days earlier but only mentioned — not linked — under the wrong day's heading, found too late to use. Every meeting entry links its materials directly, and every meeting is verified against the live calendar, because meetings move.
+
 * Exit Criteria
 
-- All meetings for the day are reviewed with prep notes
-- 1:1 meetings have talking points drawn from todo.org and session history
-- Day's priorities are identified and confirmed by Craig
-- Time blocks are placed on the calendar for focused work
+- Every calendar event for the day appears in =* Meetings / Focus Blocks=, verified against the live calendar (build time and update time — times move)
+- Every meeting entry carries its join link, its prep materials as =file:= / URL links (never a bare mention), what Craig needs to contribute, what he needs to get, and likely questions with answers
+- Any "I don't know" answer to a likely question has a prep block scheduled *the day before* the meeting, never day-of
+- Day's Priorities are sourced from both the project tracker and =todo.org=, each entry mirroring its todo.org task and carrying its own context and links
+- Craig has confirmed the Day's Priorities at the mandatory review gate (Create mode)
+- Focus blocks are on the calendar (marked free), created the day before after Craig confirms the prep
+- Drafts the day needs (reschedule messages, replies) are pre-written in the doc, ready to send
 - Any quick tasks (< 5 min) are done during prep itself
-- Craig feels ready for the day
 
 * When to Use This Workflow
 
-- When Craig says "let's prep for tomorrow" or "daily prep" or similar
-- During evening wrap-up if there are meetings the next day
-- Morning of a workday before meetings start
-- When Craig asks for the standup brief alone ("what's my standup report", "let's do the daily standup report", "give me the standup brief") — see Standup-only mode below
-
-* Modes
-
-The workflow runs in one of two modes based on the trigger phrase. Pick the mode at workflow start. Don't switch mid-run.
-
-** Full-prep mode (default)
-
-Trigger: "let's prep for tomorrow", "daily prep", or any general prep-cycle phrase.
-
-Runs Phase A → Phases 1-5 → Phase 6 (only if a standup is on the calendar) → Phase 7 → Phase 8 → Phase 9.
+- End-of-day review block ("What Kind of Day Has It Been?") — generating tomorrow's prep is part of that block's standing agenda
+- "Let's prep for tomorrow" / "daily prep" / similar — Create mode
+- "Update today's prep" / after a triage-intake lands something that changes the day — Update mode
+- A standup-brief refresh ("what's my standup report") is an Update-mode run scoped to the relevant standup's entry — there is no separate standup-only mode anymore
 
-** Standup-only mode
+* Run Modes
 
-Trigger: "what's my standup report", "let's do the daily standup report", "give me the standup brief", or similar standup-specific phrasing.
+There are only two times this workflow runs. Pick the mode at start; don't switch mid-run.
 
-Runs *only* a slim Phase A + Phase 6 + a conditional Phase 8 + Phase 9. Skip Phases 1-5 and Phase 7 entirely.
+** Create
 
-*** Slim Phase A (standup-only)
+Build the prep doc for a future day — normally tomorrow, during the end-of-day review block. Runs the full phase sequence and *ends with a mandatory priorities review gate*: Craig confirms the Day's Priorities or reworks them interactively (add / remove / substitute priorities and blocks). Calendar writes (focus blocks, day-before prep blocks) happen only after the gate.
 
-Fetch only what Phase 6 needs:
+Disagreement at the gate is a signal that =todo.org= is stale — it should be easy to identify Craig's current priorities by looking at the file. When the gate produces substantive rework, surface that and offer a task review.
 
-1. =todo.org= — for WAITING items (blockers) and DONE-since-cutoff (completed work).
-2. Previous prep doc — anchor for the lookback. Glob =daily-prep/*-daily-prep.org=, sort by date, take the file *before* the one the root =daily-prep.org= symlink currently resolves to (i.e. the prior prep day, not today's).
-3. Most recent =.ai/sessions/= summary — for the "what did I do" question.
+** Update
 
-Skip the calendar fetches, the Proton grep, and the [#A]/[#B] todo pull. Phase 6 Step 1's sweep handles the rest.
+Refresh an existing day's prep when the world moved — typically after a triage-intake lands something, a meeting reschedules, or new information changes what the day can achieve. Re-fetch the calendars (never trust the build-time snapshot — times move), re-verify every meeting entry, refresh the affected sections, and surface the delta to Craig. No mandatory gate; the changes themselves are the review surface.
 
-*** Where the brief lands
+** Triage freshness (both modes)
 
-- If a prep doc for today already exists at =daily-prep/YYYY-MM-DD-daily-prep.org=, append or replace its =* Standup Brief= section.
-- If no prep doc for today exists, create =daily-prep/YYYY-MM-DD-daily-prep.org= with only the =* Standup Brief= section populated, then repoint the root symlink at it (=ln -sf daily-prep/YYYY-MM-DD-daily-prep.org daily-prep.org=). Full prep can be added later by re-running in full-prep mode.
+If no triage-intake has run in the last *hour*, run one first — before anything else. Incoming information may change what the day can achieve; the prep reacts to it, never ignores it. The [[file:triage-intake.org][triage-intake engine]] fans out across its source plugins, classifies, synthesizes, and writes Action items into =todo.org= as =:quick:reactive:= tasks (see Phase 3).
 
-See *Phase 8* for the prep-doc home and symlink convention.
+* Prep Doc Template (strict)
 
-*** Phase 8 in standup-only mode
+The prep doc has exactly three top-level sections, in this order. Don't invent new ones. If substantive content surfaces that doesn't fit, mention it in chat after the workflow finishes rather than adding a section.
 
-If standup-only created a new dated file in =daily-prep/= (no prep doc for today existed), repoint the root =daily-prep.org= symlink at it. "Where the brief lands" above already does this; Phase 8 is a no-op when it did. If today's prep doc already existed and the brief was appended to it, the symlink already resolves to it — nothing to do.
+| Section                    | Purpose                                                              |
+|----------------------------+----------------------------------------------------------------------|
+| =* Heads-Up=               | Standing frame for the day — density, events, reminders, look-ahead  |
+| =* Day's Priorities=       | The day's work, task-shaped, mirroring todo.org                      |
+| =* Meetings / Focus Blocks= | The schedule — every calendar event, with all content nested under it |
 
-Use standup-only mode when Craig wants the brief fast (e.g., right before standup) without rebuilding the day's plan.
+The separate =* Standup Briefs= and =* Upcoming Deadlines= sections are *retired*: standup briefs nest under the standup meeting they're reported in, and upcoming deadlines live in the end-of-day review block's content. There is no anchor-tasks handoff section either — carry-forward lands directly in the next day's Day's Priorities, because the next day's prep is built during today's end-of-day block.
 
-* Prep Doc Structure
+** =* Heads-Up=
 
-The prep doc has a fixed set of top-level sections. Don't invent new ones. If substantive content surfaces that doesn't fit one of these headings, mention it in chat after the workflow finishes rather than adding it to the prep doc.
+Items that frame the day. Four standing items are *always* present, plus the look-ahead:
 
-Canonical sections (full-prep mode produces all; standup-only produces just =* Standup Briefs=):
+1. *Meeting-density framing.* One line on the day's shape, e.g. "Meeting-dense morning: 09:00 team discussion, 10:00 standup, 11:00 general standup. Real focus time only opens at noon."
+2. *Calendar events from BOTH calendars* (work + personal): birthdays, holidays, anniversaries, vacations, trips, big events. "Your trip begins Friday." "It's <person>'s birthday today."
+3. *Reminders due, imminently due, or past trigger* — from notes.org Active Reminders plus scheduled/deadline tasks. A reminder tied to a rescheduled meeting reports against the new date.
+4. *Requested metrics* — a slot for any metric Craig has asked to track in the daily prep. Render the slot only when a metric is active; none are active by default. (Metric design is a separate discussion — don't invent metrics.)
+5. *5-Day Look-Ahead* — one day per line, format =Fri 12:= / =Mon 15:=, including clear days marked =clear=. Built by Phase 1's forward scan with the invite quick-read and decline gate applied.
 
-| Section                          | Phase that writes it | Purpose                                                                    |
-|----------------------------------+----------------------+----------------------------------------------------------------------------|
-| =* Heads-up=                     | Phase 7              | Substantial situational context that changes Craig's frame for the day     |
-| =* Day's Priorities=             | Phase 3              | Actionable items for today (thin links to =:quick:reactive:= todo.org tasks) |
-| =* Meetings / Work Blocks=       | Phase 4              | Chronological schedule for the day (meetings + work blocks interleaved)    |
-| =* Standup Briefs=               | Phase 6              | Yesterday / Today / Blockers content for the standup meeting               |
-| =* Upcoming Deadlines=           | Phase 7              | Next 4-6 weeks of relevant deadlines, briefly                              |
-| =* [Next day]'s Anchor Tasks=    | Phase 7              | Explicit forward commitments for tomorrow. Phase 2 of next-day's prep reads this |
+Format: terse, situational, one item per line. Link to sources rather than inlining context.
 
-Order in the prep doc follows the table top-to-bottom: Heads-up first (frame-setter), Day's Priorities next (action surface), then schedule, then standup, then deadlines, then forward-commitment.
+** =* Day's Priorities=
 
-** Day's Priorities entries are thin links to todo.org tasks (2026-05-12 rule)
-
-Each actionable entry under =* Day's Priorities= is a *pointer to a todo.org task*, not a copy of its content. Form:
+The day's work, sourced from BOTH the project's tracker (Linear, where the project uses one) and =todo.org=. Each entry is a task-shaped level-2 header that *mirrors the linked todo.org task exactly* — same status keyword, same priority cookie, same tags:
 
 #+begin_example
-** TODO [#X] <task title> — [[file:../todo.org::*<task title>][todo.org]]
-<one line on why it's today's priority — deadline, blocker, what just landed>
-#+end_example
-
-All the substance — descriptions, drafted messages, research findings, sub-tasks, =VERIFY= asks, recommended-approach blocks — lives in the matching =todo.org= task, created or updated by Phase 3. If a todo.org task doesn't exist yet, create one (with the conventional priority cookie / Linear ID in the heading) and link to it. This keeps everything in one place (todo.org), so the prep doc never accretes content that then has to be transferred back.
+** STATUS [#PRIORITY] TASK-DESCRIPTION :tags:
 
-*The execution link rides with the entry (2026-06-10 rule).* The thin link covers the task's *home*, not the way to *do* it. When a priorities entry is actionable through a URL — a payment portal, a doc to read, a PR, a form — the entry body carries that link directly. If the link isn't already in the todo.org task body, the prep build hunts it down (the source email, the Slack thread) and adds it to BOTH the todo.org body (durable home) and the prep entry. The failure mode this prevents: "Pay NOLA Sewerage & Water Board invoice" linked to todo.org but not to the InvoiceCloud payment URL, so doing the task meant a Gmail dig first.
+   Relevant Information: (rename as appropriate)
+   [todo.org link, tracker ticket, PR, doc — every link the task needs]
+   <what success on this task is; today's achievement goal when the task
+   is bigger than a day; any relevant preparation>
+#+end_example
 
-Exceptions that stay in the prep doc as content (not links):
-- *Completed-today entries* — once a task is done, its heading becomes a dated log entry (=** YYYY-MM-DD Day @ HH:MM ...=, see [[file:../../.claude/...][feedback_done_tasks_become_dated_log_headings]] — i.e. the dated-heading rule) and stays in the prep doc as the day's record. If the work also has a durable todo.org home, the dated entry links to it.
-- The =* Standup Briefs=, =* Heads-up=, =* Upcoming Deadlines=, and =* [Next day]'s Anchor Tasks= sections — those are prep-doc-native and don't map to todo.org tasks.
+Rules:
 
-(Craig's instruction, 2026-05-12, extended 2026-05-15. The triage engine (sub-step 3b) implements the convention: each Action item becomes its own =** TODO= in =todo.org= with =:quick:= + =:reactive:= tags, and the prep doc references it via a thin link under =* Day's Priorities= when it belongs in today's plan. No grouped =** Email Response= / =** Slack Response= / =** Linear Response= / =** PR Review= sub-sections in the prep doc — the source mix lives in the tags on each todo.org task.)
+- *Links live in the content, never in the heading.* The body carries the todo.org link, the tracker ticket, the PR, the doc — along with all the other relevant information. The heading stays plain text (strip link markup when mirroring a task heading that carries one).
+- *Property drawer optional.*
+- *Body carries the entry's own context* — what success is, today's achievement goal when the task is bigger than a day ("Finish phase 2 of the spec and be ready to start phase 3 tomorrow"), and any relevant preparation (e.g. "this is also good prep for when the topic comes up in <meeting> on <day in the look-ahead window>").
+- *Execution links ride with the entry.* When the task is actioned through a URL — a payment portal, a doc, a PR, a form — the body carries that link directly. If the URL isn't in the todo.org task body yet, hunt it down (source email, Slack thread) and add it to BOTH the todo.org body (durable home) and the prep entry.
+- *The daily big-ball chunk is an entry here.* One important-but-not-urgent task per day, slated for a ~15-minute chunk (see Phase 3).
+- Order by urgency (Phase 3's sort). Craig should be able to work top-to-bottom.
 
-** Triage Action items become =:quick:reactive:= todo.org tasks (2026-05-15 rule)
+A "Goal:" or "Recap and Goal:" entry shape is fine for committed deliverables that need narrative context (where it stands, what's owed, to whom, by when) — same rules: links in body, success stated.
 
-Every Action item the triage engine surfaces (sub-step 3b, across email / Slack / Linear / PRs / calendar) becomes its own top-level =** TODO= in =todo.org= with =:quick:= + =:reactive:= tags. The prep doc's =* Day's Priorities= section links to those tasks as thin links per the rule above — no grouped Response sub-sections.
+** =* Meetings / Focus Blocks=
 
-Form:
+The spine of the doc — most content lives here. The schedule renders as a chronological list of level-2 headers, one per calendar event, with ALL content for an event nested directly under its own header:
 
 #+begin_example
-** TODO [#B] Read [[https://linear.app/deepsat/issue/SE-378][SE-378 Kostya Testing Results]] :quick:reactive:kostya:
-** TODO [#B] Re-review Vrezh's PR #167 after fixes :quick:reactive:vrezh:
-** TODO [#B] Reply to Subbu re: RTX action items :quick:reactive:subbu:
+** HH:MM–HH:MM — Exact Calendar Title
 #+end_example
 
-Rules:
+The title is the calendar event's subject *verbatim* — no annotations, no editorializing (not "(personal routine)", not "(recurring)"). Anything under the header must be actionable information or a useful reference during that event.
 
-- Plain-prose heading, lead with the verb (Read / Re-review / Reply / Address / Schedule / Review).
-- Default priority =[#B]=. Bump to =[#A]= only if the item blocks a teammate or a deadline lands inside 7 days.
-- Always =:quick:= + =:reactive:=. Add person/entity tags (=:vrezh:=, =:kostya:=, =:subbu:=, =:rtx:=, etc.) when the dependency is sharp.
-- Link the source in the heading when it has a URL — Linear issue, GitHub PR, Gmail thread, Slack permalink — using =[[url][label]]= form. The recommended approach and response content (when relevant) goes in the task body, not the heading.
-- Placement in =todo.org=: end of =* Work Open Work= (before =* Work Incubate=) unless a =* Triage= / =* Inbox= section exists near the top.
+Per-event-type content rules:
 
-If the item belongs in today's plan, also add a thin link under =* Day's Priorities= in the prep doc:
+*** Morning Prep (first block of the day)
 
-#+begin_example
-** TODO [#B] <task title> — [[file:../todo.org::*<task title>][todo.org]]
-<one line on why it's today's priority — deadline, blocker, what just landed>
-#+end_example
+Morning Prep is where Craig reads the prep doc, mentally walks the schedule, and refreshes his memory on proposals, status, and what to report. The workflow's job here: take what triage-intake surfaced and turn it into strategy, proactively supplying what Craig needs to keep the day on track. Content:
 
-Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via Phase 3 sub-step 3a's =:reactive:= pull.
+- *Conflict resolutions, ready to execute.* When a conflict or reschedule surfaces (e.g. the boss called a meeting overnight that overlaps an existing one — the triggers: who it's from, and that it appeared last night), check BOTH calendars' availability, recommend the best slot, and list the alternatives with their trade-offs ("only 30 minutes — could the agenda be cut to the high-priority topics?"). Close with the offer: "tell me which and I'll handle it." When no mutual free time exists, say so and include the direct-contact draft.
+- *Drafts go IN the prep doc, ready to send* — not an offer to draft one. The Slack reschedule message, the heads-up note, the reply: pre-written, =/voice personal= applied, sitting in the doc so Craig's word (a cj-comment or a "send it") is the only remaining step.
+- *Important FYIs* from triage that Craig must see before the day starts ("you got a [[slack-url][Slack message]] from <person> saying <big news>").
+- A pointer to the next meeting's agenda when reviewing something first would help ("your next meeting discusses X — review the proposal you wrote").
 
-* Approach: How We Work Together
+*** Standups
 
-** Continuous flow (no mid-phase gates)
+The Yesterday / Today / Blockers brief nests *directly under the standup meeting it's reported in* — never in a separate section. Plain section labels, no parenthetical questions in the rendered doc.
 
-Phases A through 7 run continuously. Don't stop between phases for Craig's input or confirmation. Information surfaced in later phases (especially Phase 3 email/Slack/Linear scans) frequently reframes what Craig wants from earlier phases — meeting goals, carry-forward decisions, priority order, time blocking. Stopping at Phase 1 to ask "what do you want from this meeting?" means asking Craig to react with stale context, before scans surface the email that might change his answer.
+- *Blockers is always present.* When there are none, write =Blockers: None= explicitly — silence is ambiguous.
+- *Outcomes, not attendance.* Never "met with <person>" — instead what came out of it: "<person> finished the branch CI/CD work." Never "went to the managers' meeting" — instead the development from it that affects this audience.
+- *No recurring 1:1s or ceremonies* in briefs — they're not news.
+- *Match the standup's altitude.* An engineering standup gets engineering-goal material only: what moved the platform or the demo forward — architecture docs, PRs, tracker tickets, partner meetings with use-case implications, integration discussions, security findings, dataset discoveries. It does NOT get: 1:1s, attending other standups, personal-tooling maintenance, profile updates, sending messages or email, meeting prep, booking travel, or interviews with non-engineering candidates. The three questions are really: (a) how have I moved us closer to the engineering goals, (b) what will I work on that moves us closer, (c) what information do I have that might impact the team or its goals.
+- A business-level (general) standup is different: features finished that leadership wanted, vacation/travel that affects availability or velocity, conference learnings, partner/customer decisions, cross-functional confusion worth clearing up. *Exclude routine maintenance and operational items — PR reviews don't belong here.* Foundational or strategic engineering work does; operations don't.
 
-Build all phases through Phase 7, then present the assembled draft and surface every question and proposed adjustment at the final review.
+(Drafting rules — first-person, deadline precision, recurring-meeting filters, the team-visible test — are in Phase 6.)
 
-Exception: stop only if a scan turns up something that *blocks* further building. Examples: a meeting was canceled and the whole day's structure changes; a security or compliance issue Craig must adjudicate before email triage proceeds. Otherwise keep going.
+*** Meetings
 
-This rule applies to all phases including Phase 1's "collaborative review" line and Phase 2's planned-vs-actual review. Both are framed as collaborative in their phase descriptions; the collaboration happens once, at the end, against the assembled prep doc.
+Every meeting entry carries:
 
-** Phase A: Data Gathering (one parallel batch)
+- *Notable accept/declines* ("only <person> accepted; <other> is out").
+- *Attendees and the join link* — an org link to the conference URL from the calendar event's conference data, so Craig clicks and joins from the prep doc. In-person/phone meetings omit it.
+- *The meeting-prep doc, LINKED* — a =file:= link, never a bare mention. If a prep doc exists anywhere in the project, the meeting entry links it. This is the lesson of a real failure: the prep existed, but it sat unlinked under a different day's heading, and Craig — with minutes to spare — couldn't find it and had to wing a meeting that mattered. Be thorough, check every meeting, find and link all the relevant docs.
+- *Summary* — who this is, why the meeting exists, what's known about the relationship and context.
+- *What Craig needs to contribute* and *what he needs to get* from the meeting.
+- *Likely questions, with answers.* When the honest answer is "I don't know," that forces a prep block scheduled *the day before* the meeting — never day-of. Schedule it in Phase 9.
 
-Before any synthesis or interaction, pull every source the prep doc needs in a *single batch of parallel tool calls*. These reads are all independent — issue them in one message, not as a sequential round-trip per source:
+*Verify every meeting against the live calendar at build AND update time.* Meetings move. A prep entry pointing at yesterday's time is worse than no entry.
 
-1. =mcp__google-calendar__list-events= for the *personal* account, scoped to the day being prepped *plus the next 5 days*. The prep-day subset feeds Phases 1, 4, and 6; the forward window feeds the 5-Day Look-Ahead in Phase 1.
-2. =mcp__google-calendar__list-events= for the *work* account, same scope (prep day + next 5 days).
-3. Grep =~/.emacs.d/data/pcal.org= for items on that day. This is the Proton Calendar export (=pcal= = personal calendar). The same directory has =gcal.org= and =dcal.org= for Google personal + DeepSat, but those are already covered by the MCP queries in steps 1 and 2 — only =pcal.org= adds non-redundant items.
-4. Read =todo.org= — collect [#A] and [#B] tasks plus anything with DEADLINE: or SCHEDULED: touching the day.
-5. List + read the *previous* prep doc. Glob =daily-prep/*-daily-prep.org= (all prep docs live there, born and kept — no separate archive). Sort by date and take the file *before* the one the root =daily-prep.org= symlink currently resolves to — usually yesterday's, but may be older if Craig was off (PTO, weekend, missed days). If the symlink doesn't resolve yet (no prep ever run), take the most recent file by date. The lookback for the standup brief is anchored on this file's date, so accuracy matters.
-6. Read the most recent =.ai/sessions/= summary file (for the standup brief's "What did I do since last standup?" question).
+*** Focus Blocks
 
-Phases 1-5 below all work from this in-memory snapshot. *Do NOT re-query the calendars in Phase 4* — the time-blocking pass uses the same data Phase A fetched. A typical daily-prep used to run 4-5 sequential round-trips just for data gathering; this collapses to one.
+Focus blocks are calendar events *marked free*: others see the time is claimed for focused work and self-select out unless something is genuinely important or urgent. The workflow CREATES them the day before, in Phase 9, after Craig confirms the prep at the gate. They're the first thing to shrink under schedule pressure; lunch shrinks second, with a 30-minute floor.
 
-** Phase 1: Meeting Review
+Content is a *menu, not an assignment* — "no plan survives contact with the enemy." Craig doesn't know what kind of day he'll have, how much sleep he'll get, or what will land on him; he chooses from the menu in the moment. Build it as:
 
-Working from the Phase A calendar snapshot, present each meeting with:
+- *Recommended item first*, then alternates. Recommendation reflects this week's priorities and any accepted deadline that's around the corner — deadline items list even when higher-priority items exist.
+- *Every item LINKED* — this is a moment of action with no time to search. The PR, the tracker queue, the doc to review, the email thread; include a starter draft when the item is a reply.
+- *Size the menu to the block.* Short block (≤30 min): the PR queue, tracker-chore grooming, prep for a later meeting. An hour or more: the bigger Day's Priorities items, even if they won't finish in the time allotted. Typically a rehash of Day's Priorities above, sized and linked.
 
-1. *Time and duration*
-2. *Meeting name*
-3. *Owner* (who scheduled/owns the meeting)
-4. *Official agenda* (from calendar description)
-5. *What Craig needs from this meeting — his objective and contribution.* Not just "attend" but the active role: decisions to drive, points to make, information to convey, people to persuade (the attending-to-contributing reframe). And apply the gate: *is there a purpose here for Craig, or is this a send-regrets candidate?* "He was invited" isn't a reason to attend — if there's no objective and no contribution to make, flag the meeting as a decline candidate for Craig's call at review.
+*** Lunch
 
-For the objective and contribution, Claude may not know Craig's goals for the meeting. Present what's known and Craig will clarify during review.
+30-60 minutes, anywhere 11:00-13:30. An hour typically; 30 minutes on busy days — never less. NO tasks, no meeting prep. Personal time, not work time.
 
-*** 1:1 Meeting Prep
+*** End-of-day review block ("What Kind of Day Has It Been?")
 
-1:1 meetings get deeper preparation:
+The last block of the workday, on the calendar as a recurring event (typically 16:30-17:00). Its content:
 
-1. Check todo.org for tasks tagged with or related to the person
-2. Review session histories since the last 1:1 with that person for relevant events, decisions, and context
-   - Default lookback: since the last 1:1 with that person
-   - Craig may ask to go further back for long-running items
-3. Identify:
-   - Status updates Craig should share (progress on things they care about)
-   - Questions Craig needs to ask
-   - Decisions that need their input
-   - Action items owed to or from them
+- The day's summary — what happened, what landed, what slipped.
+- *Generating tomorrow's prep* — a Create-mode run of this workflow normally happens here.
+- *The upcoming-deadlines list* — this replaces the retired deadlines section. Format: one per line, =Tomorrow: <item>= / =Mon 5/18: <item>= / =5/17–5/21: <event>=, roughly the next 4-6 weeks, chronological.
 
-Capture the meeting list with what's known about each (time, owner, official agenda, who's accepted vs declined, what Craig might need). Don't stop here for Craig's input. Bring questions about meeting goals to the final review at the end of Phase 7, when the cross-source picture from Phase 3 is in hand. The collaborative review of the meeting list happens once, against the assembled prep doc, not as a mid-flow gate.
+* Approach: How We Work Together
 
-*** 5-Day Look-Ahead
+** Continuous flow, one gate at the end
+
+Phases A through 7 run continuously — don't stop between phases for confirmation. Information surfaced in later phases (especially triage) frequently reframes earlier phases; stopping early means asking Craig to react with stale context. Build the whole doc, then present it at the Phase 8 gate with every question and proposed adjustment.
 
-Beyond today, scan the next 5 days from the Phase A forward window — read the calendar today *and the next five days*, reading it rather than glancing. For each meeting in that window, do a quick read (who's invited and who accepted, why it's being held, the timing, the objective) and surface three buckets at the final review:
+Exception: stop only if something *blocks* further building — a canceled meeting that restructures the day, or an issue Craig must adjudicate before triage can proceed.
 
-1. *Meetings that need prep.* A substantive upcoming meeting — an external partner, a negotiation, a review of specific work or data, a first call with someone — that has no =working/<slug>-call-prep/= doc yet. Offer to run the [[file:meeting-prep.org][meeting-prep workflow]], or add a prep task. Some meetings take more than five minutes to prepare; catching them several days out is the whole point of looking ahead.
-2. *Traps.* A time-zone mismatch on a travel day, a double-booking, a talk-heavy meeting that will overrun into the next, a recurring meeting that isn't needed this cycle.
-3. *Focus blocks to protect.* Open mornings or afternoons in the window worth blocking now for big work, before they get booked over.
+** Phase A: Data Gathering (one parallel batch)
 
-This is a scan-and-flag pass, not a full prep — the deep prep for any one meeting is the [[file:meeting-prep.org][meeting-prep workflow]]'s job. Keep it to the three buckets and surface them in =* Heads-up= (Phase 7) or as forward tasks / Anchor Tasks; don't add a new prep-doc section.
+Pull every source in a *single batch of parallel tool calls*:
 
-** Phase 2: Planned vs. Actual Review
+1. =mcp__google-calendar__list-events= for the *personal* account, scoped to the prep day *plus the next 5 days* (prep-day subset feeds Phases 1 and 4; the forward window feeds the look-ahead).
+2. =mcp__google-calendar__list-events= for the *work* account, same scope.
+3. Grep =~/.emacs.d/data/pcal.org= for items on that day (Proton Calendar export; =gcal.org= / =dcal.org= are already covered by the MCP queries).
+4. Read =todo.org= — [#A] and [#B] tasks plus anything with =DEADLINE:= or =SCHEDULED:= touching the day.
+5. Pull the project tracker's view of Craig's plate (assigned issues, items in review, blocked items) where the project has one.
+6. List + read the *previous* prep doc. Glob =daily-prep/*-daily-prep.org=, sort by date, take the file *before* the one the root =daily-prep.org= symlink resolves to. If the symlink doesn't resolve yet, take the most recent file. The standup lookback anchors on this file's date.
+7. Read the most recent =.ai/sessions/= summary (for the standup brief's lookback).
 
-Before setting tomorrow's priorities, review what was planned for today against what actually happened. This catches work that slipped and prevents it from silently disappearing.
+This fetch *is* the live calendar read for build time. In Update mode, re-run the calendar fetches — never reuse the build-time snapshot.
 
-1. Pull the current day's prep doc (if one exists). If it has a populated =* [Today]'s Anchor Tasks= section (written by yesterday's Phase 7 as the explicit handoff), use that as the canonical carry-forward list. Otherwise fall back to inferring carry-forward by listing the day's planned work blocks.
-2. For each block, note: completed, partially done, or not started
-3. For items that didn't happen, identify why (took longer than expected, blocked, deprioritized, meetings ran over)
-4. Carry forward anything that still matters into the priority list for the next day, with updated time estimates based on what we learned today
-5. Add all carried-forward items as =TODO= entries in the new prep doc's Day's Priorities section — don't just note them in the Planned vs Actual table. Unfinished tasks from yesterday become today's tasks automatically unless Craig cuts them.
+** Phase 1: Meeting Review
 
-This step keeps the daily prep honest. If a 1-hour task consistently takes 3 hours, the estimates need to change. If work keeps getting bumped by meetings, that's a pattern worth raising.
+Working from the Phase A snapshot, capture for each meeting: time and duration, the exact calendar title, owner, official agenda, accept/decline status — and *what Craig needs from it*: not "attend" but the active role (decisions to drive, points to make, information to convey, people to persuade). Apply the decline gate: a meeting with no objective and no contribution for Craig is a send-regrets candidate, flagged for his call at the review gate.
 
-** Phase 3: Day's Priorities
+*** 1:1 Meeting Prep
 
-Assemble priorities automatically from multiple sources. No interactive confirmation. Craig reviews the prep doc as a whole when it's done.
+1:1s get deeper preparation: check todo.org for tasks tagged with or related to the person; review session histories since the last 1:1; identify status updates to share, questions to ask, decisions needing their input, and action items owed each way.
 
-Phase 3 pulls priorities from two places: =todo.org= directly (sub-step 3a) and the triage engine's fresh Action items (sub-step 3b, which creates the =:quick:reactive:= tasks per the rule above). Sub-step 3c surfaces the ones that belong in today's plan as thin links under =* Day's Priorities=, sub-step 3d sorts them by urgency, and Craig edits the prep doc directly to add or drop a priority.
+*** 5-Day Look-Ahead
 
-Sources contributing to Day's Priorities: todo.org (3a) plus everything the triage engine covers (email, Slack, Linear, PRs, calendar).
+Scan the forward window — read it, don't glance. For each meeting: the invite quick-read (who's invited and accepted, why it's being held, the timing, the objective). Three buckets:
 
-*** Recommended Approach Pattern (applied by the triage engine when writing reactive-task bodies)
+1. *Meetings that need prep* — substantive meetings with no prep doc yet. Offer to run the [[file:meeting-prep.org][meeting-prep workflow]] or add a prep task; catching these days out is the point.
+2. *Traps* — time-zone mismatch on a travel day, double-booking, a talk-heavy meeting that will overrun, a recurring meeting not needed this cycle.
+3. *Focus blocks to protect* — open mornings/afternoons worth blocking before they're booked over.
 
-When a triage Action item involves a non-trivial decision or judgment that benefits from analysis, the engine includes a =recommended approach= subheader before the response draft in the task body. The approach is the executor's analysis (situation, options, recommendation with rationale, considerations Craig should weigh) so Craig can evaluate the recommendation itself, not just the wording. This pattern is kept here as the shared reference; the triage engine and any response-drafting step follow it.
+Renders in Heads-Up as one line per day (=Fri 12:= … =Mon 15:= …), clear days marked =clear=, with the bucket findings attached to the days they concern.
 
-Skip the approach subheader for routine acknowledgments, simple status replies, or "yep, looks good" approvals.
+** Phase 2: Planned vs Actual (Create mode)
 
-Source-specific examples of when to *include* the approach subheader:
+Before setting tomorrow's priorities, review today's prep doc against what actually happened:
 
-- *Email:* decisions like grant applications, partnership replies, public-facing or sensitive responses
-- *Slack:* @mentions with explicit asks, items where someone is blocked waiting on Craig
-- *Linear:* @mentions requesting input, Blocked tickets Craig owns, Needs-Review items where the call isn't trivially obvious
+1. For each planned item: completed, partially done, or not started.
+2. For items that didn't happen, identify why (ran long, blocked, deprioritized, meetings overran).
+3. *Carry forward anything that still matters directly into the new doc's Day's Priorities*, with updated estimates based on what today taught. There is no hand-off section — the next day's prep is being built right now, so carry-forward lands as priorities entries.
+4. Completed items: note them for the end-of-day summary.
 
-Format (consistent across all three sources):
+This keeps the prep honest. A 1-hour task that consistently takes 3 hours means the estimates change; work that keeps getting bumped by meetings is a pattern worth raising at the gate. Update mode skips this phase.
 
-#+begin_example
-***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended approach
-<situation, options, recommendation with rationale, considerations>
-***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended response
-<draft response text, OR proposed action like a state change>
-#+end_example
+** Phase 3: Day's Priorities
 
-Generate timestamps with =date "+%Y-%m-%d %a @ %H:%M:%S %z"= so they're accurate, not estimated.
+Assemble priorities from both sources; no mid-flow confirmation (the gate handles review).
 
-*** Sub-step 3a: From todo.org
+*** Sub-step 3a: From todo.org and the tracker
 
 1. Pull all [#A] tasks from todo.org.
-2. Add time-sensitive items (DEADLINE: or SCHEDULED: touching the day).
-3. Carry forward unfinished items surfaced by Phase 2 — but skip any item already added by step 1 or 2 above. A task that was [#A] yesterday and didn't finish gets carried forward by Phase 2 and would also re-appear in step 1's [#A] pull. Dedupe by org-mode heading text or =:ID:= property if present.
-4. Pull open =:reactive:= tasks (created by prior preps under the *Triage Action items become =:quick:reactive:= todo.org tasks* convention) — these are pending quick-fire responses that should stay visible until processed. Dedupe against steps 1-3. Surface them as thin links in Day's Priorities; Craig drops the ones that don't fit today's plan.
-5. *Pull one "big ball" — an important-but-not-urgent task to chip at today.* Surface a single Quadrant-2 task from =todo.org= (a strategic or =[#B]=-=[#C]= item that matters but keeps getting deferred because nothing makes it urgent — a spec, a vetting, an arch sweep, a piece of networking, a flashcard batch) and slate a ~15-minute chunk on it for today. The point: big important-not-urgent work only ever gets done when it's broken into small daily pieces — otherwise the urgent perpetually displaces it, which is the failure mode this whole workflow exists to fight. One per day; Craig swaps or drops it at review. Phase 4 gives it a small block.
-
-Priorities typically include:
-- Messages to send (Slack, email)
-- Meetings to schedule
-- Documents to send out for review
-- Follow-ups to make
-- Prep work needed before a meeting
+2. Add time-sensitive items (=DEADLINE:= / =SCHEDULED:= touching the day).
+3. Fold in Phase 2's carry-forward (dedupe against 1-2 by heading text or =:ID:=).
+4. Pull open =:reactive:= tasks (created by prior triage runs) — pending quick-fire responses stay visible until processed. Dedupe against 1-3.
+5. Pull the tracker items that demand action today (assigned with near deadlines, blocked-on-Craig, review requests).
+6. *Pull one "big ball"* — a single important-but-not-urgent (Quadrant-2) task to chip at for ~15 minutes today: a spec, a vetting, an arch sweep, networking, a flashcard batch. Big strategic work only lands when broken into small daily pieces; one per day, Craig swaps or drops it at the gate.
 
 *** Sub-step 3b: Triage external sources (delegate to triage-intake.org)
 
-Don't scan email / Slack / Linear / PRs inline here. Run the =triage-intake.org= engine. It fans out across its source plugins, classifies each item against the shared four-bucket model (Action / FYI / Noise-keep / Noise-trash), synthesizes a single deduped summary, writes every Action item into =todo.org= as its own =:quick:reactive:= task, and executes the triage actions (star / mark-read / trash) on Craig's confirmation. That is the same work sub-steps 3b-3g used to do inline; the engine now owns it, so a source change lives in one plugin instead of being duplicated here.
-
-*Source coverage comes from the engine's Phase 0 plugin load.* triage-intake Phase 0 globs both =.ai/workflows/triage-intake.*.org= (general plugins: cmail, github-prs, personal-calendar, personal-gmail) and =.ai/project-workflows/triage-intake.*.org= (the project's own, e.g. the work account's Gmail, Slack, Linear, and GHE PRs). So everything daily-prep used to scan inline stays covered as long as the project ships its source plugins there. If a source isn't covered, the gap is a missing plugin in =.ai/project-workflows/=, not a daily-prep regression.
-
-The engine tracks its own "since when?" sentinel. Pass it the prior prep doc's mtime as the window if the project wants the prep cadence to drive triage scope; otherwise let it use its sentinel.
-
-*** Sub-step 3c: Surface today's reactive items in Day's Priorities
+Don't scan email / Slack / tracker / PRs inline. Run the =triage-intake.org= engine (if the mode's freshness check already ran one this hour, use its synthesis). It classifies everything new against the four-bucket model, writes every Action item into =todo.org= as its own =:quick:reactive:= task, and executes the routine actions on confirmation. Source coverage comes from its Phase 0 plugin load — both =.ai/workflows/triage-intake.*.org= (general) and =.ai/project-workflows/triage-intake.*.org= (project-specific). A missing source is a missing plugin, not a daily-prep regression.
 
-The engine (3b) and sub-step 3a's =:reactive:= pull have populated =todo.org= with the open quick-fire tasks. For each that belongs in *today's* plan (a deadline, a blocker, or someone waiting decides "today"), add a thin link under =* Day's Priorities=:
+*** Sub-step 3c: Build the entries
 
-#+begin_example
-** TODO [#B] <verb> <Person / topic> — [[file:../todo.org::*<task title>][todo.org]]
-<one line on why today>
-#+end_example
-
-Items that don't fit today stay in =todo.org= and resurface on a future prep via 3a's =:reactive:= pull. Don't duplicate task bodies into the prep doc; the thin link is the whole entry (2026-05-12 rule). One exception to the no-content rule: a URL the task is *done through* (payment portal, doc, PR, form) goes in the entry body per the execution-link rule above — and into the todo.org body if it isn't there yet.
+For each item that belongs in *today's* plan, write a Day's Priorities entry per the template rules: heading mirrors the todo.org task exactly (status, priority cookie, tags — plain text, links stripped from the heading), body carries the links (todo.org, tracker, PR, doc, execution URL), what success is, today's achievement goal when the task outlasts the day, and any relevant preparation. Items that don't fit today stay in =todo.org= and resurface on a future prep via 3a's pulls.
 
 *** Sub-step 3d: Urgency re-sort
 
-Re-order the entries under =* Day's Priorities= by urgency: (1) deadlines today or overdue, (2) Craig blocking someone, (3) deadlines within ~48h, (4) other [#A], (5) time-sensitive lower-stakes, (6) everything else. Entries are all thin links now, so it's a flat reorder of heading lines. Craig refines when he reviews; this just gives a sane starting order.
+Order: (1) deadlines today or overdue, (2) Craig blocking someone, (3) deadlines within ~48h, (4) other [#A], (5) time-sensitive lower-stakes, (6) everything else. The gate refines; this gives a sane starting order.
 
-*** Sub-step 3e: Phase 3 audit footer (forcing function)
+*** Sub-step 3e: Audit footer
 
-After 3a-3d, write a single comment line directly below the =#+DATE:= header recording which sources the triage engine actually covered:
+Write a single comment line below the =#+DATE:= header recording which sources triage actually covered:
 
 #+begin_example
-# Sources checked: todo.org ✓ | email-personal ✓ | email-deepsat ✓ | Slack ✓ | Linear ✓ | prs ✓
+# Sources checked: todo.org ✓ | email-personal ✓ | email-work ✓ | Slack ✓ | tracker ✓ | prs ✓
 #+end_example
 
-Take the per-source marks from the engine's synthesis (its Phase C reports per-plugin coverage). Replace ✓ with ✗ plus a parenthetical reason for any source the engine couldn't reach (e.g. =Slack ✗ (MCP disconnected)=). A source scanned with no items keeps its ✓ — empty is a valid result; this line catches a source that did not run at all.
+Take per-source marks from the engine's synthesis. Replace ✓ with ✗ plus a reason for any source that didn't run (=Slack ✗ (MCP disconnected)=). Scanned-but-empty keeps its ✓.
 
-** Phase 4: Time Blocking
+*** Recommended Approach Pattern (shared reference)
 
-Once priorities are confirmed, block time on the calendar to accomplish them. Phase 4 also writes the prep doc's =* Meetings / Work Blocks= section — a single chronological list interleaving meetings with focused-work blocks, top to bottom in time order.
-
-*** Meeting lines carry clickable join links (2026-06-10 rule)
-
-Every meeting line in =* Meetings / Work Blocks= gets an org link to its join URL, pulled from the calendar event's conference data (=conferenceData.entryPoints= in the Phase A MCP output — already fetched, no extra query). Example:
+When a triage Action item involves a non-trivial decision, the engine includes a =recommended approach= subheader before the response draft in the task body — situation, options, recommendation with rationale, considerations — so Craig can evaluate the recommendation, not just the wording. Skip it for routine acknowledgments and "yep, looks good" approvals. Format:
 
 #+begin_example
-- 10:00–11:00 — SWE weekly sprint planning [recurring; Eric] — [[https://us06web.zoom.us/j/...][join Zoom]]
+***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended approach
+<situation, options, recommendation with rationale, considerations>
+***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended response
+<draft response text, OR proposed action like a state change>
 #+end_example
 
-Craig clicks and joins right from the prep doc instead of digging through the calendar. A meeting with no conference URL (in-person, phone) just omits the link.
+Generate timestamps with =date "+%Y-%m-%d %a @ %H:%M:%S %z"=.
 
-*** Quick Tasks (< 5 minutes)
-Tasks like "schedule a meeting with Ryan" or "send a Slack message" should be done during the prep workflow itself, not scheduled separately. Draft the message or create the calendar event on the spot.
-
-*** Focused Work Tasks
-For anything requiring more than a few minutes:
-
-1. Ask Craig for a time estimate on each item
-2. Use the Phase A calendar snapshot — *do not re-query the calendars*. The same events are already in context.
-3. *Compute the day's active window.* Default 10:00 to 17:00, every day of the week (weekends included). If the prep is being run *same-day* (the prep doc's date matches today's date) and the workflow start-time is later than 10:00, the window starts at the start-time instead. Existing calendar appointments, known personal commitments (guests arriving, travel, off-time blocks Craig flagged), and the last-30-min next-day-prep reservation remove time from the window. Whatever's left is fillable with priorities. Don't auto-treat Saturday or Sunday as "off." Fill the window with tasks. If Craig wants personal time on a weekend, he marks it on the calendar or flags it during prep.
-4. List the schedule with open slots clearly marked. Show the active window's start, end, and remaining fillable minutes after subtracting appointments.
-5. Propose when each task fits, considering:
-   - Meeting proximity (prep work should be near the meeting it supports)
-   - Energy/focus (harder tasks earlier if possible)
-   - A half hour around lunchtime to eat when possible (protein shake or leftovers is fine -- this can be compressed or skipped on heavy days)
-   - Always reserve the last 30 minutes of the workday for daily prep for the following day. This is non-negotiable -- it's what keeps the cycle going.
-6. Craig confirms or adjusts the proposed schedule
-
-*** Placing Calendar Blocks
-- Place time blocks on Craig's personal Google calendar (=Craig Google=)
-- Can also place blocks on DeepSat calendar directly using MCP server with =account_id: "work"=
-- Use the calendar event workflows (add-calendar-event.org) for creating events
-
-** Phase 5: Prep Work
+** Phase 4: Build Meetings / Focus Blocks
 
-With the schedule set, work on anything that needs to be ready for the day's meetings. Examples:
+Write the schedule section: every calendar event as a level-2 header (=** HH:MM–HH:MM — Exact Calendar Title=), chronological, with content per the template's event-type rules.
 
-- Watch tutorial videos and take notes
-- Draft or polish documents for review
-- Prepare talking points or materials
-- Research topics that will come up in meetings
-- Draft messages that are part of the day's priorities
+1. *Verify against the live calendar* — the Phase A fetch at build time; a fresh fetch at update time. Times move; check every event.
+2. *Join links on every meeting line* from the event's conference data (=conferenceData.entryPoints= — already in the Phase A output, no extra query).
+3. *Compute the day's open window* (default 10:00-17:00, weekends included; same-day runs start at the current time). Subtract meetings, known commitments, lunch, and the end-of-day review block. What's left is focus-block space.
+4. *Lay out focus blocks* in the remaining space and write each block's menu per the template rules (recommended first, alternates, everything linked, sized to the block).
+5. *Place lunch* — 30-60 minutes somewhere in 11:00-13:30.
+6. Don't create the calendar events yet — that's Phase 9, after the gate.
 
-This phase is where the bulk of the session time goes. Work through items in priority order, with meeting-related prep taking precedence based on meeting time.
-
-** Phase 6: Standup Brief
-
-Generate the standup brief late in the workflow so the rest of the day's analysis is already done. The brief draws from Phase 2 (Planned vs Actual), Phase 3 (Day's Priorities), and the activity sweep below. Phase 6 writes the prep doc's =* Standup Briefs= section.
-
-Skip this phase entirely on days with no standup on the calendar.
-
-*** Step 1: Sweep recent activity for off-Claude signals
-
-Before drafting, check these sources for activity since the previous prep doc's date (the lookback anchor from Phase A step 5):
-
-1. *Sent email* — both accounts. Outgoing threads from Craig: decisions communicated, replies to action items, follow-ups, intros made.
-2. *Slack* — Craig's recent messages across channels and DMs. Decisions, status updates, threads where Craig participated.
-3. *todo.org* — items marked DONE since the cutoff. New TODOs added that hint at fresh context (new commitments, new blockers).
-4. *Linear* — tickets Craig moved to a new state, commented on, or created. Use the Linear MCP to query.
-
-These surface team-visible work that lives outside session history (work done in mu4e, Slack, the Linear UI, or off-Claude conversations).
-
-*** Step 2: Draft the brief
-
-Combine session history + the Step 1 sweep + Phase 3 priorities + todo.org WAITING items into the three-question structure below.
-
-*Meeting selection.* Recurring meetings are excluded from both the Yesterday and Today sections — they're not news to the team. For non-recurring meetings:
-
-- *Yesterday section:* include only meetings Craig actually attended. Filter on Craig's own response status from the calendar event:
-  - =accepted= → include
-  - =tentative= or =declined= → exclude (don't assume attendance)
-- *Today section:* include all non-recurring meetings regardless of response status. Craig still needs to communicate what he plans to attend or decide between.
-
-The Google Calendar MCP returns =responseStatus= per attendee — filter on Craig's own response, not the event's overall status. Recurring events expose =recurringEventId= or =recurrence=; treat the presence of either as the recurring marker.
-
-*Content rules.*
-
-- *Stay first-person.* Report what Craig did, said, or decided. Don't volunteer others for work or report what others said they would do — that's their standup, not Craig's. If a teammate's commitment is relevant context, frame it as something Craig is waiting on, not as a status update on their behalf.
-- *Match deadline precision to what's actually known.* If a deadline is "early next week," don't tighten it to "Monday." If the commitment is "before the proposal goes out," don't sharpen it to "Friday EOD." Vague is honest when vague is the truth.
-
-1. *What did I do since last standup?* Anchor the lookback at the previous prep doc's date (Phase A step 5). Pull session history, session-context.org, completed tasks, and the Step 1 sweep results from that date forward. Since DeepSat standup is a workday-recurring meeting, the previous prep doc's date is the previous standup date even if intervening days were weekends or PTO. Use explicit day references ("Monday" not "yesterday") since the prep doc may be written the evening before.
-2. *What am I doing today?* Pull from the day's priorities (Phase 3 output). Keep it to 2-3 items max.
-3. *Blockers: mine or yours?* The bar is "did this actually stop me from making progress?", not "is someone else involved?" A WAITING item in todo.org is only a blocker if Craig already tried to move forward and got stopped. Mere dependencies don't qualify unless they've already impaired progress. Default to under-reporting — draft without borderline items and let Craig add them back in Step 3. FYI items (decisions or context worth flagging that aren't blockers) come after blockers and stay loose.
-
-The brief should be concise enough to read aloud in under 60 seconds. Include enough context that Craig doesn't have to think on his feet, but not so much that it turns into a status report.
-
-*** Step 3: Present the draft and ask what's missing
-
-Show Craig the full draft brief — Yesterday, Today, Blockers/FYI sections all populated. Then ask:
-
-#+begin_quote
-Anything I missed? Common categories: off-Claude meetings or phone calls, paperwork or forms submitted, intros made or received, vendor conversations, anything else not captured in session/email/Slack/Linear.
-#+end_quote
-
-Recognition is faster than recall. Craig can react to "did you make any intros?" much faster than to "what did you do?" The categories are prompts, not a checklist.
-
-*** Step 4: Refine and finalize
-
-Apply Craig's additions and any wording adjustments. The brief is now ready for standup.
-
-*** Step 5: Offer to capture learnings
-
-After Step 4, scan Craig's refinements for non-obvious patterns:
-
-- Did he cut a category of item the workflow said to include?
-- Did he add a category the workflow didn't tell you to look for?
-- Did he change wording in a way that suggests a phrasing rule (e.g., "say 'continued focus on X' instead of 'worked on X'")?
-
-If a refinement looks like a generalizable rule, offer it back to Craig:
-
-#+begin_quote
-I noticed you [removed all 1:1 meetings from Yesterday / added the off-Claude phone call with Ryan / changed "completed proposal draft" to "continued focus on proposal"]. Want me to add this to the workflow? Proposed rule: "[concrete rule text]"
-#+end_quote
-
-Wait for explicit confirmation before editing the workflow. Never edit on your own judgment.
-
-If Craig confirms, append the rule to the *Updates and Learnings* section at the bottom of this file with today's date and a one-line description. If the new rule supersedes existing text inside Phase 6, also update the inline text and note "(updated YYYY-MM-DD — see Updates and Learnings)" in the affected section so the audit trail is complete.
-
-If the refinement looks like a one-off, don't propose a rule. Default to under-proposing — false-positive rules clutter the workflow. The bar is "would I want this guidance the next time I draft a brief?" If yes, propose. If no, drop it.
-
-** Phase 7: Final Section Writeups
-
-Three sections remain after Phase 6: =* Heads-up=, =* Upcoming Deadlines=, and the next day's =* [Day]'s Anchor Tasks=. Phase 7 writes them, drawing on what earlier phases already surfaced.
+*** Quick Tasks (< 5 minutes)
 
-Order doesn't matter between the three sub-steps. They write to distinct sections and don't depend on each other.
+"Schedule a meeting with <person>" or "send a quick reply" gets done during the prep itself, not scheduled. Draft the message or create the event on the spot.
 
-*** Sub-step 7a: Heads-up
+** Phase 5: Prep Work
 
-Write a top-level =* Heads-up= section near the top of the prep doc (above =* Day's Priorities=).
+With the schedule drafted, produce what the day's entries need to be self-sufficient:
 
-Heads-up is the executive summary of what would change Craig's frame for the day. Terse, situational, day-shaping. Pull from sources earlier phases surfaced:
+- *Pre-write every draft* the doc promises — reschedule messages, replies, heads-up notes — =/voice personal= applied, sitting in the entry ready to send on Craig's word.
+- Hunt down and link every meeting's materials (prep docs, proposals, resumes, decks). A mention without a =file:= link is a defect.
+- Answer the likely questions for each meeting; for every "I don't know," queue a day-before prep block for Phase 9.
+- Research, talking points, and document polish for the day's meetings, in meeting-time order.
 
-- *Substantial FYIs* from the triage engine's synthesis (sub-step 3b) — items like "Eric quietly progressed two partnership threads on Apr 24" or "Vrezh force-pushed all three branches overnight" that affect what Craig should expect today
-- *Schedule changes* from Phase 1 — "Arusyak 15:00-16:00 is being rescheduled" or "DeepSat GTM declined for tonight"
-- *Urgent deadlines bubbling up* — items in =* Upcoming Deadlines= that hit within ~2 days, surfaced as standalone Heads-up items so Craig sees them immediately
-- *Active Reminders* (from Phase A's notes.org read) that frame today specifically — "first thing in the morning, register for SOFWeek"
+** Phase 6: Standup Briefs
 
-Format: bullet list, one situational note per line, no sub-bullets. Keep each entry to one sentence. If a Heads-up item needs more context, link to the source (email, ticket, prep section) instead of inlining.
+Generate briefs late, so the day's analysis is already done. Each brief is written *under its standup's header* in Meetings / Focus Blocks. Skip on days with no standup.
 
-Lightweight FYIs (status pings, "FYI we shipped", small acknowledgments) stay in =.ai/session-context.org= and don't surface in Heads-up.
+*** Step 1: Sweep recent activity for off-Claude signals
 
-*** Sub-step 7b: Upcoming Deadlines
+Check, since the previous prep doc's date: sent email (both accounts), Slack (Craig's messages across channels and DMs), todo.org DONE-since-cutoff and fresh TODOs, and the tracker (state changes, comments, created items). These surface team-visible work that lives outside session history.
 
-Write a top-level =* Upcoming Deadlines= section.
+*** Step 2: Draft the brief(s)
 
-Source: scan todo.org for =DEADLINE:= entries plus deadlines mentioned in notes.org or knowledge.org. Filter to roughly the next 4-6 weeks. Order chronologically.
+Combine session history + the sweep + Day's Priorities + WAITING items into Yesterday / Today / Blockers, per the template's standup rules (altitude match, outcomes not attendance, =Blockers: None= explicit, no recurring 1:1s/ceremonies). Additional drafting rules:
 
-Format: bullet list, one deadline per line, format =- [Day YYYY-MM-DD] — short description=. Mention the owner if it isn't Craig and the deadline still concerns him (e.g., "Subbu owns; Craig's technical content due ahead of this").
+- *Stay first-person.* Report what Craig did, said, or decided. Don't volunteer others or report their commitments as status — frame a teammate's commitment as something Craig is waiting on, if it's relevant at all.
+- *Match deadline precision to what's known.* "Early next week" doesn't tighten to "Monday." Vague is honest when vague is the truth.
+- *Yesterday* anchors on the previous prep doc's date. Include only non-recurring meetings Craig actually attended (his own =responseStatus= = accepted). Use explicit day references ("Monday," not "yesterday") — the doc is written the evening before.
+- *Today*: 2-3 items max, from Day's Priorities. Include non-recurring meetings regardless of response status.
+- *Blockers*: the bar is "did this actually stop me from making progress?" — not "is someone else involved?" Default to under-reporting; Craig adds borderline items at the gate. FYIs come after blockers and stay loose.
+- *Team-visible filter*: only work that left Craig's local environment — pushed, shared, posted, changed in the tracker, or shifts what the team believes or plans. "If I didn't mention this, would someone make a worse decision or duplicate work?" If no, cut it.
+- Readable aloud in under 60 seconds.
 
-Volume control: if more than ~10 deadlines fit the window, narrow the window or surface only the ones that are blocking, externally-imposed, or have non-trivial prep ahead.
+*** Step 3: Capture learnings
 
-Don't duplicate deadlines that are already today's =* Day's Priorities= entries. Day's Priorities is for action; Upcoming Deadlines is for awareness.
+When Craig's gate-time refinements to a brief look like a generalizable rule (cut a category, added one, a phrasing pattern), offer it back: "Want me to add this to the workflow? Proposed rule: …" Wait for explicit confirmation, then append to *Updates and Learnings* below and update the affected inline text. Default to under-proposing.
 
-*** Sub-step 7c: Next day's Anchor Tasks
+** Phase 7: Heads-Up
 
-Write a top-level =* [Day]'s Anchor Tasks= section. Compute the next day's name from today's date — *don't* skip weekends. For a Friday prep doc this becomes =* Saturday's Anchor Tasks=, for a Saturday prep doc it becomes =* Sunday's Anchor Tasks=, etc. Use known PTO markers if any (a fully-blocked PTO day can be skipped to the next available day).
+Write =* Heads-Up= last, when everything it summarizes exists: the density framing, both calendars' events, due/past-trigger reminders, the metrics slot (only if a metric is active), and the 5-day look-ahead lines from Phase 1. Pull substantial triage FYIs that change Craig's frame for the day; lightweight FYIs stay in =.ai/session-context.org=.
 
-Source: items Craig is explicitly committing to do tomorrow. Pull from:
+Also assemble the end-of-day block's upcoming-deadlines list: =DEADLINE:= entries from todo.org plus deadlines from notes.org, next 4-6 weeks, chronological, one per line. Don't duplicate items already in Day's Priorities — priorities are for action, the deadline list is for awareness.
 
-- Items planned for today that didn't get done (from Phase 2's Planned vs Actual)
-- Items that genuinely fit tomorrow better than today (criterion below)
-- Prep work needed before tomorrow's meetings
-- Anything Craig flagged during today's session as "I'll do this tomorrow"
+** Phase 8: Priorities Review Gate (Create mode — MANDATORY)
 
-*Criterion for pushing an item to tomorrow rather than fitting it today.* Push only if at least one is true:
+Present the assembled doc and ask whether Craig agrees with the Day's Priorities. If not, work with him to add / remove / substitute priorities and blocks until he confirms. Surface here, in one pass: meeting-goal questions, decline candidates, look-ahead flags, carry-forward decisions, and proposed schedule adjustments.
 
-1. *Hard-blocked today* — waiting on a person, a system, or a deadline that hasn't passed yet
-2. *Needs a contiguous block* today's window can't provide
-3. *Prep work for a tomorrow-only meeting* (do the prep close to the meeting)
-4. *Team-dependent* and the team isn't available today (e.g., Craig's at one location and the team's at another)
+If the gate produces substantive rework, say so plainly: that's a =todo.org= staleness signal — the file should make Craig's current priorities obvious. Offer a task review.
 
-If none of those apply, the item stays in today's Day's Priorities and gets a time block in Phase 4. Don't auto-punt independent reading, registration, local-machine work, or "I'll get to it tomorrow" items just because today is a weekend or feels light.
+Update mode replaces the gate with a delta summary: what changed and why.
 
-Items further out than tomorrow (Monday-only items written on a Saturday, for example) stay in =todo.org= with appropriate priority and SCHEDULED markers. Don't list them in the prep doc — they'll resurface in the relevant day's prep via Phase 3 sub-step 3a.
+** Phase 9: Calendar Writes (after the gate)
 
-Format: bullet list or =** TODO= headings, with optional time estimates (e.g., "— 1.5 hrs"). Each item should be a clear task — passive monitoring or context goes elsewhere (Heads-up or session-context).
+Only after Craig confirms:
 
-This section is the explicit handoff to next-day's Phase 2. If it's empty, write the header with "(none flagged)" so the next day's prep doesn't mistake an empty section for a missing one.
+1. *Create the focus blocks* on the calendar for the prepped day — marked *free*, titled for focused work.
+2. *Create day-before prep blocks* for every meeting question that landed on "I don't know" (and for look-ahead meetings needing prep that Craig accepted).
+3. Any reschedules Craig approved at the gate: send the pre-written message, then move the event.
 
-** Phase 8: Repoint the Current-Day Symlink
+Use the project's calendar-event workflow (=add-calendar-event.org=) where it exists; respect existing commitments — don't double-book.
 
-Prep docs are *born* in their permanent home and never move. The home is
-=daily-prep/= at repo root: every prep doc is created directly as
-=daily-prep/YYYY-MM-DD-daily-prep.org= (Phase A onward writes there), and the
-dated files accumulate in place. There is no archive move — =daily-prep/= is
-both the working location and the archive.
+** Phase 10: Repoint the Current-Day Symlink
 
-A single stable symlink at the project root — =daily-prep.org= — points at the
-current day's file. The only day-to-day change is repointing it. After the new
-prep doc exists, point the symlink at it:
+Prep docs are *born* in their permanent home and never move: =daily-prep/YYYY-MM-DD-daily-prep.org=, accumulating in place (working location and archive are the same directory). A single stable symlink at the project root points at the current day's file:
 
 #+begin_src bash
 # Relative target so the symlink stays valid if the project tree moves.
 ln -sf daily-prep/YYYY-MM-DD-daily-prep.org daily-prep.org
 #+end_src
 
-Consumers — the Emacs opener (=C-c p d=), next-day Phase 2, the standup
-lookback — resolve =daily-prep.org= rather than computing a filename or
-searching =inbox/=. Nothing prep-related lands in =inbox/= anymore.
+Consumers — the Emacs opener, next-day Phase 2, the standup lookback — resolve =daily-prep.org= rather than computing a filename. First run in a project: create =daily-prep/=, migrate any =inbox/*-daily-prep.org= or stale =assets/= prep docs into it, then link.
 
-Setup / migration (first run in a project on this convention):
+** Phase 11: Project Extension
 
-- If =daily-prep/= doesn't exist yet, create it.
-- Move any existing =inbox/*-daily-prep.org= (the old born-in-inbox location)
-  into =daily-prep/=, and any stale prep doc under =assets/= (an even older
-  convention) likewise. Then create the root =daily-prep.org= symlink at the
-  most recent one.
-- Don't put prep docs in =deepsat/meetings/= — the prep doc covers personal
-  calendar, all 1:1s, and all projects, not just DeepSat work.
-
-This keeps =inbox/= free of prep-doc churn and makes "today's prep" a single
-predictable path instead of a dated filename that has to be reconstructed.
-
-** Phase 9: Project Extension
-
-If =.ai/project-workflows/daily-prep.org= exists, read and execute its instructions as additional steps appended to this workflow. The project file contains add-ons specific to the project. It is *not* a replacement for this template — it picks up where this workflow's main flow ends.
-
-Surface the extension once per session ("Project has additional daily-prep steps — running them now") so the choice is visible.
-
-This is the project-extension hook from [[file:startup.org][startup.org]]'s workflow discovery rule, made explicit at the workflow level so it's not buried in discovery instructions. Runs in both full-prep and standup-only modes.
+If =.ai/project-workflows/daily-prep.org= exists, read and execute it as *additional* steps appended here — project add-ons (e.g. the project's specific standup names, calendars, recurring-event IDs), not a replacement. Surface once per session ("Project has additional daily-prep steps — running them now"). Runs in both modes.
 
 * Principles to Follow
 
 ** Prep Supports Action
-The goal is for Craig to walk into every meeting and task with what he needs. If prep doesn't lead to better outcomes, it's wasted time.
+Craig should walk into every meeting and block with what he needs *in the doc, linked*. If prep doesn't lead to better outcomes, it's wasted time.
 
 ** Craig Drives Priorities
-Claude surfaces information and proposes priorities, but Craig decides what matters. Don't assume -- ask.
+Claude surfaces information and proposes; Craig decides. The Phase 8 gate is where that happens — once, with full context, not piecemeal mid-flow.
+
+** Be Thorough, Check Every Meeting
+Every meeting verified against the live calendar, every prep doc linked, every likely question answered or scheduled for day-before prep. Consistency is the value — a prep that's excellent four days out of five fails on the day it matters.
 
 ** Quick Tasks: Just Do Them
-If something takes less than 5 minutes, do it during prep rather than scheduling it. Draft the Slack message, create the calendar invite, send the email.
+Under 5 minutes: do it during prep. Draft the message, create the invite, send the email.
 
 ** Respect the Calendar
-When proposing time blocks, respect existing commitments across all calendars. Don't double-book. Account for transition time between meetings.
+Don't double-book. Account for transitions. Focus blocks are marked free by design; lunch has a 30-minute floor.
 
 ** First-Person Perspective
-When preparing 1:1 talking points, frame everything from Craig's perspective -- what does Craig need to communicate, ask, or decide? Not what the other person needs.
+Frame 1:1 talking points from Craig's side — what he needs to communicate, ask, or decide.
 
 * Living Document
 
@@ -541,90 +386,64 @@ Update this workflow based on what works in actual daily prep sessions. Track le
 ** Updates and Learnings
 
 *** 2026-02-23: Initial creation
-Created during first daily prep session. Validated against tomorrow's schedule (2026-02-24: Vrezh 1:1, Standup/IPM, Product Review, Backlog Planning).
+Created during first daily prep session. Validated against tomorrow's schedule (2026-02-24: 1:1, Standup/IPM, Product Review, Backlog Planning).
 
 *** 2026-02-23: Use explicit day references, not relative terms
-When referring to past meetings or events, always include the explicit day (e.g., "from Monday's meeting" not "from this morning's meeting"). The prep doc may be written the day before and read the day of -- relative references like "this morning" or "today" become ambiguous. Include the day name so Craig doesn't have to calculate days in his head while focused on making a point.
+The prep doc may be written the day before and read the day of — "this morning" is ambiguous. Include the day name.
 
 *** 2026-02-23: Prep doc output
-The prep was originally written to =inbox/YYYY-MM-DD-daily-prep.org= where the date is the day being prepped for. (Superseded 2026-06-01 — prep docs now live in =daily-prep/= with a root =daily-prep.org= symlink. See the 2026-06-01 entry below and Phase 8.)
-The startup workflow checks for this file and asks whether to open it. Note: need to resolve where the daily prep reference in startup.org lives so template syncing doesn't overwrite it (see todo.org task).
+Originally =inbox/YYYY-MM-DD-daily-prep.org=. (Superseded 2026-06-01 — born in =daily-prep/= with a root symlink; see Phase 10.)
 
 *** 2026-02-23: Check for dependencies between tasks and meetings
-Tasks and meetings often depend on each other. SkyFi prep needs to happen before the Vrezh 1:1 so Craig can ask informed questions; Linear learning needs to happen before the backlog planning meeting where they'll use it. Always check for these dependencies and ask Craig when unsure.
+Prep work that feeds a meeting schedules before it. Ask Craig when unsure.
 
 *** 2026-02-23: Energy management matters as much as time management
-Front-load high-effort, high-stakes work early in the day (about an hour after waking). Save research, reading, and lighter tasks for late afternoon when energy dips. Craig tries to eat lunch and have coffee/tea around 12:30 PM to sustain energy for the afternoon. This principle should guide time block placement alongside calendar constraints.
+Front-load high-effort, high-stakes work early. Lighter work late afternoon. Lunch ~12:30 sustains the afternoon.
 
 *** 2026-02-23: Link references in the prep doc
-When listing tasks, documents, or directories in the prep doc, include links to the source
-(todo.org line numbers, file paths, directories). Craig shouldn't have to search for context
-when he's in the middle of a meeting or working through the day.
+Tasks, documents, directories — link the source. Craig shouldn't search for context mid-meeting. (Strengthened 2026-06-11: links are now a structural requirement of every entry, not a courtesy.)
 
 *** 2026-02-23: Note dependencies between time blocks
-When an earlier time block feeds into a later meeting, call it out explicitly in the prep doc
-(e.g., "by this point, should have already checked Okta access"). Helps Craig verify he's
-on track as the day progresses.
+When an earlier block feeds a later meeting, say so in the doc.
 
 *** 2026-02-23: Prep doc is a living document through the day
-Craig may annotate the prep doc with "cj:" comments as he works through it. Process those
-when asked or at the start of the next session. Remove the comment markers after acting on them.
+Craig annotates with "cj:" comments; process when asked or next session.
 
 *** 2026-02-23: Ask probing questions about task nature
-When a task like "SkyFi outreach" could mean either a 5-minute email or a 1-hour call, ask. The answer often splits the task into prep + action, which schedule differently. These questions are very helpful and should be a regular part of the workflow.
+"Outreach" could be a 5-minute email or a 1-hour call. Ask; the answer often splits prep from action.
 
 *** 2026-03-08: Keep Day's Priorities, drop separate Time Blocking table
-The output prep doc should have a "Day's Priorities" section followed by a single chronological
-"Meetings / Work Blocks" section that interleaves meetings, prep blocks, and focused work blocks
-in time order. No separate Time Blocking table — the chronological Meetings / Work Blocks section
-serves that purpose.
-
-*** 2026-03-09: Day's Priorities use org-mode TODO headings, not numbered lists
-Each priority is a =** TODO= heading under =* Day's Priorities=, not a numbered list item.
-Format: =** TODO Task name — description. Links to todo.org or other files. ~time estimate.=
-Do not use bold or italic markup in the prep doc — org headings, TODO keywords, and plain text
-provide enough structure.
-Mark completed items as =** DONE= with a =CLOSED:= timestamp on the next line.
-Order by urgency and priority — most important/time-sensitive first. Craig should be able to
-work top-to-bottom and know he's tackling the right thing next.
-This makes priorities trackable in org-mode (agenda, todo filtering) and lets Craig toggle
-status directly in Emacs as the day progresses.
-
-The workflow phases (identify priorities, propose time blocks) still happen during the prep
-conversation — the change is only to the output format.
+Day's Priorities followed by a single chronological schedule section. (The schedule section was renamed Meetings / Focus Blocks 2026-06-11.)
 
 *** 2026-03-08: Always include Planned vs Actual
-Craig finds the Planned vs Actual review table valuable. Always include it in the prep doc
-when a previous day's prep doc exists. This is Phase 2 of the workflow and should never be skipped.
+The review happens every Create run (Phase 2). (Adjusted 2026-06-11: it feeds carry-forward into the new doc's priorities and the end-of-day summary rather than rendering as its own table — the strict template has three sections.)
+
+*** 2026-03-09: Day's Priorities use org-mode TODO headings, not numbered lists
+Priorities are org TODO headings, trackable in agenda/todo filtering, toggleable in Emacs. No bold/italic markup in the prep doc.
 
 *** 2026-04-01: Always use human-readable ticket titles
-When referencing Linear tickets (or any issue tracker IDs), always use the human-readable
-title with the ID in parentheses — e.g., "Setup Database for dev environment (SE-93)" not
-just "SE-93." Craig can't remember what ticket IDs map to, and bare IDs force him to look
-them up. Use the Linear MCP tools to fetch the title if needed.
+"Setup Database for dev environment (SE-93)", never bare "SE-93". Fetch the title via the tracker MCP if needed.
 
 *** 2026-03-27: Standup briefs — only team-visible goals, not personal productivity
-Only include work that left Craig's local environment: pushed to a repo, shared with
-the team, posted in Slack, changed something in Linear, or shifts what the team believes
-or plans. Exclude work whose output lives entirely in Craig's local files (knowledge.org,
-todo.org, session notes, transcript processing, local tooling setup, MCP server config).
-Filter: "If I didn't mention this, would someone on the team make a worse decision or
-duplicate the work?" If no, cut it.
+Only work that left Craig's local environment. Filter: "if I didn't mention this, would someone make a worse decision or duplicate work?"
 
-*** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks — never duplicated content
-Craig's call. The prep doc's =* Day's Priorities= entries point at todo.org tasks (=** TODO [#X] <title> — [[file:../todo.org::*<title>][todo.org]]= plus a one-line "why today"); all the substance — descriptions, drafts, research, sub-tasks, VERIFY asks, recommended-approach — lives in the matching todo.org task, which Phase 3 creates or updates. Completed-today entries still become dated log headings in the prep doc (the day's record), linking to their durable todo.org home if there is one. Full statement in *Prep Doc Structure ▸ Day's Priorities entries are thin links to todo.org tasks* above. Follow-up: Phase 3 sub-steps 3b–3f still say "add to the prep doc" — reword them to "create/update the todo.org task, link from the prep doc" on the next pass. (Supersedes the 2026-03-09 "Day's Priorities use org-mode TODO headings" entry's implication that the content lives in the prep doc — the headings still use TODO keywords / dated-log headings, but the body is a link.)
+*** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks
+Entries pointed at todo.org tasks with all substance in the task body. (Superseded 2026-06-11 — entries now carry their own context, with links in the body. See the 2026-06-11 entry.)
 
 *** 2026-05-15: Triage Action items become =:quick:reactive:= todo.org tasks — no grouped Response sub-sections
-Craig's call, originally landed in the work project's =triage-intake= workflow on 2026-05-15 and propagated here on 2026-05-16. Each Action item surfaced by Phase 3 sub-steps 3b/3d/3e/3f (email, Slack, Linear, PRs) becomes its own =** TODO [#B] <verb-led description> :quick:reactive:[person]:= in =todo.org=. The Day's Priorities section in the prep doc references it via a thin link when it belongs in today's plan, otherwise the task stays in =todo.org= for later. Replaces the prior pattern of building grouped =** Email Response= / =** Slack Response= / =** Linear Response= / =** PR Review= sub-headings under Day's Priorities — those sub-sections no longer exist. Source mix now lives in the tags on each task, not in the prep doc structure. Full statement in *Prep Doc Structure ▸ Triage Action items become =:quick:reactive:= todo.org tasks* above. (Closes the 2026-05-12 follow-up about rewording sub-steps 3b–3f.)
+Each Action item surfaced by triage becomes its own =** TODO [#B] <verb-led description> :quick:reactive:[person]:= in =todo.org=. Source mix lives in the tags, not in prep-doc structure. Still in force — the prep-doc side of the convention (thin links) was superseded 2026-06-11; the todo.org side stands.
 
 *** 2026-05-31: Delegate triage to the triage-intake engine
-Phase 3's inline source scans — sub-steps 3b (email), 3c (mark-read), 3d (Slack), 3e (Linear), 3f (PRs), and 3g's cross-source dedup, ~280 lines — duplicated what the =triage-intake.org= engine has owned since its 2026-05-26 engine/plugin refactor. Collapsed them to four steps: 3b runs the engine (it fans out across general + project source plugins, classifies, synthesizes, writes the =:quick:reactive:= tasks, and executes star/mark-read/trash on confirmation); 3c surfaces today's reactive items as Day's Priorities thin links; 3d re-sorts by urgency; 3e writes the audit footer from the engine's per-source coverage. Source coverage carries because the engine's Phase 0 globs both =.ai/workflows/= and =.ai/project-workflows/= plugins, so the work account's Gmail/Slack/Linear/GHE plugins are still scanned — the delegation must not drop them, and Phase 0's two-dir glob is what guarantees it. The Recommended Approach Pattern stayed here as the shared reference (the engine applies it when writing reactive-task bodies); a future tidy could move it into the engine. Also closes the 2026-05-12 follow-up about rewording sub-steps 3b-3f.
+Phase 3's ~280 lines of inline source scans collapsed into a delegation to the =triage-intake.org= engine; coverage carries via its two-dir plugin glob. The Recommended Approach Pattern stays here as the shared reference.
 
 *** 2026-06-01: Prep docs live in =daily-prep/= with a root =daily-prep.org= symlink — no inbox churn, no archive move
-Craig's call. The prep doc is now *born* in =daily-prep/YYYY-MM-DD-daily-prep.org= and never moves; the dated files accumulate there as both working location and archive. A single stable symlink at the project root — =daily-prep.org= — points at the current day's file, repointed each prep run with =ln -sf=. Replaces the prior model where the doc was born in =inbox/YYYY-MM-DD-daily-prep.org=, yesterday's stayed in =inbox/=, and older docs were =mv='d into the =daily-prep/= archive (old Phase 8). Consumers resolve the root symlink instead of computing a dated filename or searching =inbox/=: the Emacs opener =C-c p d= (=cj/open-project-daily-prep=, repointed from =inbox/today-prep.org= to =daily-prep.org= — handoff filed to the =.emacs.d= project 2026-06-01), next-day Phase 2, and the standup lookback (Phase A step 5, which now globs =daily-prep/= and takes the file before the symlink's target). Touchpoints updated: Phase A step 5 + slim-Phase-A step 2 (lookback), standup-only "Where the brief lands," Phase 8 (rewritten as "Repoint the Current-Day Symlink"). Cross-workflow: =triage-intake.org='s sentinel-anchor fallback dropped its =inbox/= prep-doc path. (=wrap-it-up.org= was left as-is — its =inbox/= references are about =lint-followups.org= routing, not the prep doc, so they stay correct.) Migration is one-time per project: move existing =inbox/*-daily-prep.org= into =daily-prep/= and create the root symlink at the most recent.
+The prep doc is born in =daily-prep/YYYY-MM-DD-daily-prep.org= and never moves; the root symlink repoints each run. Consumers resolve the symlink. Migration is one-time per project.
 
 *** 2026-06-10: Execution links in priorities + join links on meetings
-Two link rules from working the 2026-06-10 prep doc (Craig's asks, verbatim in the handoff: "when adding tasks to the priorities, you will need to include the relevant link" / "we really need to add links to the meetings so I can click and join right from the daily prep document"). (1) A Day's Priorities entry actioned through a URL carries that URL in the entry body; the thin link to todo.org names the task's home, not the way to do it. If the URL isn't in the todo.org task body yet, the prep build finds it (source email, Slack thread) and adds it to both. Worked example: the NOLA water-bill task linked to todo.org but not the InvoiceCloud payment URL, so doing the task meant a Gmail dig first. (2) Every meeting line in Meetings / Work Blocks carries an org link to its join URL from the calendar event's conference data, so Craig joins from the prep doc. Stated in *Prep Doc Structure* (execution-link rule), sub-step 3c, and the new Phase 4 join-links sub-section.
+(1) An entry actioned through a URL carries that URL in its body; if the todo.org task lacks it, the prep build finds it and adds it to both. Worked example: a utility-bill task linked to todo.org but not the payment portal, so doing the task meant an email dig first. (2) Every meeting line carries an org link to its join URL from the event's conference data.
 
 *** 2026-06-10: Manager Tools prep additions — 5-day look-ahead, daily big-ball, decline gate
-Three additions folded in from the Manager Tools / Career Tools casts on preparing-for-your-day and meeting prep. None adds a new prep-doc section (the fixed-section rule holds — the look-ahead feeds Heads-up / Anchor Tasks). (1) *5-Day Look-Ahead* — Phase A widens the calendar fetch from the prep day to the prep day plus the next 5 days, and a new Phase 1 sub-section scans that forward window for three buckets: meetings that need prep, traps (time-zone mismatch, double-booking, overrun, an unneeded recurring meeting), and focus blocks to protect. A scan-and-flag pass, not full prep. (2) *Daily big-ball* — Phase 3 sub-step 3a item 5 pulls one important-but-not-urgent (Quadrant-2) task per day and slates a ~15-minute chunk, since strategic work only lands when broken into small daily pieces. (3) *Decline gate* — Phase 1 item 5 reframes "what Craig needs" from attending to contributing, and adds a send-regrets gate: a meeting with no objective and no contribution is a decline candidate for Craig's call at review. The look-ahead's meeting-prep references link directly to =meeting-prep.org= (promoted to a template 2026-06-10).
+(1) 5-Day Look-Ahead: Phase A widens the fetch to prep day + 5; Phase 1 scans the window for meetings-needing-prep / traps / focus-blocks-to-protect. (2) Daily big-ball: one Quadrant-2 task per day, ~15-minute chunk. (3) Decline gate: "what Craig needs" reframed from attending to contributing; no objective + no contribution = decline candidate.
+
+*** 2026-06-11: Full template rewrite — strict three-section doc, two run modes, mandatory priorities gate
+From Craig's instructive template spec (written 2026-06-10 evening, after reviewing generated preps) plus four refinements from his review of the first new-format prep. The doc is now exactly =* Heads-Up= / =* Day's Priorities= / =* Meetings / Focus Blocks=. Retired: the separate =* Standup Briefs= and =* Upcoming Deadlines= sections (briefs nest under their standup meeting; deadlines live in the end-of-day block), the =* [Day]'s Anchor Tasks= handoff (carry-forward lands directly in the next day's priorities, which are being built in the same sitting), the thin-link convention (entries mirror their todo.org task's heading and carry their own context — links in the body, never the heading), and standup-only mode (a brief refresh is an Update-mode run). New: two run modes (Create, with a MANDATORY end-of-flow priorities review gate whose disagreement signals todo.org staleness; Update, for when the world moves) both preceded by a triage-intake freshness check (no run in the last hour → run one first); event headers are the exact calendar title with ALL content nested under the event; per-event-type content rules (Morning Prep conflict-resolution strategy with drafts pre-written in the doc ready to send, standup altitude matching with =Blockers: None= explicit and operations excluded from business-level briefs, meetings carrying contribute/get/likely-questions with day-before prep blocks for "I don't know" answers and prep docs always =file:=-linked — the lesson of a prep that existed but couldn't be found in the minutes before a meeting that mattered, focus blocks as linked menus created day-before and marked free, lunch floor, the end-of-day "What Kind of Day Has It Been?" block carrying the deadlines list and generating tomorrow's prep); the look-ahead renders one day per line (=Fri 12:= …) with clear days marked =clear=; a requested-metrics Heads-Up slot rendered only when a metric is active (none yet); meetings verified against the live calendar at build and update time.
diff --git a/inbox/2026-06-11-0037-from-work-2026-06-10-daily-prep-template-spec.org b/docs/design/2026-06-10-daily-prep-template-spec.org
index f267afd..f267afd 100644
--- a/inbox/2026-06-11-0037-from-work-2026-06-10-daily-prep-template-spec.org
+++ b/docs/design/2026-06-10-daily-prep-template-spec.org
diff --git a/inbox/2026-06-11-0037-from-work-handoff-daily-prep-rewrite.org b/docs/design/2026-06-11-daily-prep-rewrite-handoff.org
index e788230..e788230 100644
--- a/inbox/2026-06-11-0037-from-work-handoff-daily-prep-rewrite.org
+++ b/docs/design/2026-06-11-daily-prep-rewrite-handoff.org
diff --git a/inbox/2026-06-11-0056-from-work-four-template-refinements-from-craig-s.org b/inbox/2026-06-11-0056-from-work-four-template-refinements-from-craig-s.org
deleted file mode 100644
index 13550f9..0000000
--- a/inbox/2026-06-11-0056-from-work-four-template-refinements-from-craig-s.org
+++ /dev/null
@@ -1,5 +0,0 @@
-#+TITLE: Four template refinements from Craig's review of the first n
-#+SOURCE: from work
-#+DATE: 2026-06-11 00:56:20 -0500
-
-Four template refinements from Craig's review of the first new-format daily prep (2026-06-11) — fold into the daily-prep rewrite already in your inbox (0037 handoff): (1) When Morning Prep surfaces a scheduling question, the Slack/email draft itself goes IN the prep doc, ready to send on Craig's word — not an offer to draft one. (2) The 5-day look-ahead renders one day per line, format 'Fri 12:', 'Mon 15:', including clear days marked 'clear'. (3) Standup briefs always carry a Blockers line — 'Blockers: None' explicitly when there are none. (4) General (business-level) standup briefs exclude routine maintenance and operational items like PR reviews; foundational/strategic engineering work belongs, operations don't.