refactor(workflows): restructure startup and triage-intake into reading lanes

I split each into lanes so a reader can stop at the level that answers the question: Summary for "what does this do and what does it produce", Execution for the steps to follow, Reference for examples and edge cases, History for old decisions. Both files are large enough that an agent loading them at routing time pays for context it doesn't need yet.

startup.org keeps Summary, Execution, and Reference (workflow discovery and common mistakes moved under Reference). triage-intake.org gets all four, including a History lane for its design notes. Every instruction is preserved. The triage reorder ran through a content-preservation check that compared the multiset of content lines before and after, so only heading depth and lane grouping moved. Nothing was dropped or reworded.

workflow-integrity.py now counts "Summary" as a valid orientation heading, since that's the new top section both files lead with.

This is the pilot from the codex backlog, scoped to the two largest workflows. Whether the lanes actually cut session token use gets evaluated before any wider rollout.

1 files changed, 12 insertions, 4 deletions

diff --git a/.ai/workflows/startup.org b/.ai/workflows/startup.org
index 3d5ac66..c08bd8a 100644
--- a/.ai/workflows/startup.org
+++ b/.ai/workflows/startup.org
@@ -2,13 +2,19 @@
 #+AUTHOR: Craig Jennings & Claude
 #+DATE: 2026-04-25
 
-* Overview
+* Summary
 
 This workflow runs automatically at the beginning of EVERY session. It gives Claude project context, syncs templates, discovers available workflows, and determines session priorities. Do NOT ask Craig if he wants to run it — just execute it.
 
 The workflow is structured into four phases. *Phase A.0* is a sequential pre-flight; *Phase A and Phase B should each run as a single batch of parallel tool calls* — sending one message with multiple Bash / Read calls in it, not sequential round-trips. Phase C is interactive and runs sequentially.
 
-* The Workflow
+Quick contract — runs / produces:
+- *Phase A.0* (sequential): refresh rulesets, then the project repo.
+- *Phase A* (parallel batch): timestamp, session-context check, guarded =.ai/= sync, recent sessions, inbox-status, cross-agent status, notes.org, staleness, language-bundle freshness.
+- *Phase B* (parallel batch): read the crash-recovery anchor if present, the recent session summaries, new inbox items, pending cross-agent messages.
+- *Phase C* (interactive): surface findings, process the inbox, run project startup-extras, ask priorities.
+
+* Execution
 
 ** Phase A.0 — Pre-flight: refresh rulesets and project repo (sequential, runs first)
 
@@ -169,7 +175,9 @@ This phase touches the user and runs sequentially:
 
 Rationale: User-facing work and decisions can't be parallelized — they have to happen one at a time so the user can react.
 
-* Workflow discovery (on demand, not at startup)
+* Reference
+
+** Workflow discovery (on demand, not at startup)
 
 Two directories hold workflows:
 - =.ai/workflows/= — template workflows (synced from claude-templates, never edit in project).
@@ -189,7 +197,7 @@ When the user says "let's run/do the [X] workflow" (or otherwise references a wo
 
 The index is the catalog; the directory is the truth. Drift between them is a bug — catching it on demand keeps the index honest without paying the read cost on every session.
 
-* Common Mistakes
+** Common Mistakes
 
 1. *Running Phase A sequentially.* Send all Phase A calls in one message — sequential rsync + ls + read costs round-trips for nothing.
 2. *Reading the entire notes.org file* — only Project-Specific Context, Active Reminders, Pending Decisions.