create-battle-plan 1.3.0 → 1.4.0

package/template/CLAUDE.md.backup-2026-05-11

@@ -0,0 +1,310 @@
+# Battle Plan — System Prompt
+
+You are helping manage an interconnected documentation system. Every document stays in sync through a cascade protocol. Follow these rules exactly.
+
+---
+
+## Two-View Model — Read This First
+
+**The cascade is your orientation layer. `docs/today.md` is the user's operating surface. The chat is the user's only UI.**
+
+The user should never have to look at the cascade, the battle plan, `tasks.yml`, or any internal markdown to operate the system. The chat with you is the UI; the cascade is your memory; `docs/today.md` is a thin clickable surface in their editor for ticking through the day. Everything else exists for *you*, not them.
+
+- **Your view (the cascade):** `docs/battle-plan.md` at the top, source docs below it, `metrics.yml` as numeric truth, `tasks.yml` as the structured task log. Narrative, deep, linked. You read and write this freely — it is how you reconstruct project state and cascade new information.
+- **User's view:** `docs/today.md`, generated by `tools/tasks/render-today.js` from `tasks.yml`. Rendered in Obsidian Tasks plugin format — query blocks project pill-styled lists over a raw `## Task data` section at the bottom (lane-grouped within each priority bucket). The user checks boxes in Obsidian; `tools/tasks/flush-today.js` reconciles those edits back into `tasks.yml`. When they want deep context, they ask you in chat — you traverse the cascade on their behalf.
+
+**Rules:**
+- Never grow the battle plan's TL;DR into a wall of prose. Keep header blocks terse; append Daily Log entries chronologically.
+- When the user drops new tasks, add them via `node tools/tasks/add.js "..." [--due YYYY-MM-DD] [--tag X] [--priority 1|2|3] [--lane LANE] [--implication PATH]`. Don't bury tasks in battle plan prose.
+- After any task mutation (add, complete, snooze, triage), run `node tools/tasks/render-today.js` so `docs/today.md` stays fresh.
+- `verify-cascade.sh` Check 6 confirms `today.md` is not stale relative to `tasks.yml`.
+
+---
+
+## Task Lanes — what goes where
+
+Every task has a `lane` (groups by *primary action*, not topic). The default vocabulary:
+
+| Lane | Primary action |
+|---|---|
+| `build` | Build, design, or document the product itself (MVP, demos, architecture, integrations) |
+| `outreach` | Cold DMs / InMails / posts / templates / cold-email infra-as-pipeline |
+| `discovery` | Chase or nurture a *named human relationship* — warm intros, follow-ups, scheduling specific calls |
+| `infra` | Plumbing — DNS, GCP/AWS, deploy, env, secrets, cold-email domain warm-up |
+| `fundraising` | Apply to or maintain relationships with accelerators / VCs / angels |
+| `meta` | Doc/process work with no other natural lane (default fallback) |
+
+**Adapt this set to your project.** Lanes are configurable in `tools/tasks/lib/tasks.js` (`VALID_LANES`) — when you change them, also update `tools/tasks/migrate-lanes.js` keyword buckets and the `LANE_DISPLAY` / `LANE_ORDER` tables in `tools/tasks/render-today.js`.
+
+**Personalities don't get their own lane.** A specific advisor or co-founder's input flows into all the action lanes. A task like "ask <advisor> about X" is `discovery` (relationship), `build` (product feedback), or `meta` (process), depending on what *closing* the task produces.
+
+### Strategic vs routine — what belongs in `tasks.yml`
+
+`tasks.yml` is for **ad-hoc strategic / build / discovery-protocol / high-stakes individual conversations.** Examples: a milestone call with a specific stakeholder where multiple people join; a piece of pitch copy that needs to be written by a specific date; a load-bearing architecture decision that gates other work.
+
+Routine lead-by-name follow-ups ("X accepted, send DM") belong in the **outreach blitz pipeline**, not in `tasks.yml`. The blitz already surfaces those through `daily-targets.js` + `leads.csv` flags + accepted-not-replied detection on timers. Don't duplicate that work as tasks.
+
+When uncertain, default to the blitz. `tasks.yml` is a journal of strategic intent, not a worklist.
+
+---
+
+## Weekly Triage — `/weekly-triage`
+
+Run weekly to keep `tasks.yml` honest. The skill (`.claude/commands/weekly-triage.md`) walks the user through every open task one at a time using `AskUserQuestion`'s arrow-key UI. Each decision (`done` / `snooze N` / `demote` / `merge X` / `delete` / `lane LANE` / `priority N` / `keep`) is applied to `tasks.yml` immediately — no batching.
+
+Two automation layers support this:
+
+- **`tools/tasks/triage.js`** — read-only data layer. Surfaces overdue/stale tasks, recent commits mentioning each task ID (signals "this is probably done"), and *implications drift* (when a task's linked doc hasn't been modified since the task was created — meaning the cascade hasn't actually reached the doc). Output as Markdown by default, JSON via `--json` for programmatic consumers.
+- **`tools/tasks/triage-due.js`** — lightweight SessionStart-hook nudge. Silent unless one of three thresholds trips: time-based (≥7d since last triage), stale-task (≥20 open tasks ≥14d old), or volume (≥60 open). Wired in `.claude/settings.json`. The skill stamps `last_triage_at` in `tasks.yml` on completion to suppress the nudge until the next cycle.
+
+When you see the SessionStart nudge fire, mention it in chat ("📋 Last triage was 9d ago — want to run `/weekly-triage`?") but never auto-invoke. The user decides.
+
+### Implications field
+
+Tasks may carry `implications: [docs/path-a.md, docs/path-b.md]` — a list of docs that should change when the task closes. `triage.js` flags drift when a linked doc's last git commit predates the task: the status flip happened, but the cascaded doc-update didn't. When you create a task whose closure should mutate a specific doc, pass `--implication path/to/doc.md` to `add.js` so triage can hold you accountable later.
+
+### `blocked_by` field
+
+Tasks may also carry `blocked_by: [TASK-IDs]` — an array of TASK-IDs that must close before this task is actionable. Set via `add.js --blocked-by N` (repeatable; comma-separated also accepted; each ID validated against existing rows). When at least one blocker is still open:
+
+- `triage.js` shows a `🚧 Blocked by:` line listing each blocker's id, status, and title (open ones flagged 🚧, closed ones ✅).
+- The stale-flag and snooze-or-demote suggestion are **suppressed** — a task waiting on a deliberate blocker shouldn't be penalized for not progressing.
+- The replacement suggestion becomes "blocked — chase blocker(s) or demote".
+- Stats gain a `Blocked by another open task: N` line.
+- `render-today.js` emits a `🚧 blocked-by:TASK-N,TASK-M` token on the task's line — but only for *still-open* blockers, so the token disappears once the blocker closes.
+
+When the user describes a task that genuinely depends on another, set the blocker explicitly (`--blocked-by N`) instead of letting the dependency live in prose. Closure of the blocker doesn't auto-close the dependent — the user picks the action during the next triage.
+
+---
+
+## Task archive — `node tools/tasks/archive.js`
+
+`tasks.yml` is append-only by design (audit trail), but it shouldn't grow forever. The archive script moves any `status: done|cancelled` row with `done_at < today - 14d` into `tasks-archive.yaml` (created on first run, same schema, sorted by `done_at` ascending).
+
+- **Default retention:** 14 days. Pass `--days N` to override, or `--all` to archive every closed row regardless of age.
+- **Idempotent:** dedups by `id` against the existing archive. Safe to run on every `/wrap-up`.
+- **Wired into `/wrap-up` Step 4.5b** — runs daily as part of end-of-day routine.
+- **Backfill safety:** closed rows missing `done_at` get stamped today and kept one cycle (so a date-less row doesn't get archived without chronological position).
+- **Re-importing a task:** intentional friction. Manually move the row from `tasks-archive.yaml` → `tasks.yml` and set `status: open`.
+
+---
+
+## The Cascade Protocol
+
+**Trigger:** Any incoming information that relates to the project — calls, messages, research, signals, status changes, decisions.
+
+When triggered, update in this exact order:
+
+### Step 0: Update `metrics.yml`
+If any key metric changed, update `metrics.yml` first. This is the numeric source of truth.
+
+### Step 1: Update Battle Plan (`docs/battle-plan.md`)
+- Update the **TL;DR** with current status
+- Update the **Key Metrics** table (numbers reference metrics.yml)
+- Update **Today's Priorities** if relevant
+- Append to **Daily Log** for today
+
+### Step 2: Update Cascade Docs
+Update only the docs relevant to the new information. Route new info to the appropriate domain doc under `docs/`. Common patterns:
+
+| Info type | Route to... |
+|-----------|------------|
+| Conversation, call, or meeting | `docs/external-insights.md` — append as new dated session |
+| Evidence for/against a hypothesis | The relevant domain doc — amend the claim with an `[UPDATE]` block |
+| Outreach sent/received | The relevant market or sales doc — update tracking tables |
+| Competitor intel | The relevant strategy or market doc |
+| New foundational knowledge | The relevant research or domain doc |
+
+If no doc exists for the info, append it to the closest domain overview doc. Only create a new file if the info doesn't fit anywhere.
+
+### Step 3: Update Dates
+Run `tools/touch-date.sh` on every file you modified in this session:
+
+```bash
+tools/touch-date.sh docs/battle-plan.md docs/validation/hypotheses.md [etc.]
+```
+
+### Step 4: Verify
+Run `tools/verify-cascade.sh` and fix any issues it reports:
+
+```bash
+tools/verify-cascade.sh
+```
+
+---
+
+## Source Reference Rules
+
+### Registry Metrics (Tier 1 — deterministic)
+Numbers defined in `metrics.yml`. Reference as: `[**N**](metrics.yml#field_name)`
+
+This renders as a bold clickable number. Example: `[**42**](metrics.yml#outreach_sent)`
+
+These are verified by exact numeric comparison via `tools/check-metrics.sh`.
+
+### Inline Metrics (Tier 2 — LLM-verified)
+Less common numbers from another doc. Reference as: `[**N**](source-doc.md#section-slug)`
+
+Example: `60% of time on evidence [**60**](external-insights.md#session-2-key-insights)`
+
+**Rule:** Every number referenced from another document MUST include a source annotation. Only numbers native to a doc (where they originate) have no annotation.
+
+---
+
+## Document Format
+
+Every doc in `docs/` must have this frontmatter:
+
+```markdown
+# Document Title
+
+**Last Updated:** 2026-04-07
+**Status:** Active | Draft | Archived
+**Role:** source-of-truth | cascade-target
+**Compression:** chronological | amended | none
+
+**TL;DR:** One paragraph summary with key numbers and source references.
+
+---
+```
+
+- **Last Updated** must match today's date on any file modified in the current session.
+- **Status:** `Active` = live, `Draft` = WIP, `Archived` = excluded from cascade.
+- **Role:** `source-of-truth` = authoritative for its numbers. `cascade-target` = references numbers from elsewhere.
+- **Compression:** required field. One of `chronological`, `amended`, or `none` (see Compression Modes section below).
+- **TL;DR** must exist and contain all key metrics that appear in the doc.
+
+---
+
+## Compression Modes & Timestamping Rules
+
+Every doc declares a `Compression:` mode in frontmatter. This tells the `/distill` command (and humans) how new info gets added to the doc and how old info gets compressed when it grows too long. The mode IS the timestamping rule for new info.
+
+### `Compression: chronological`
+The doc is an append-only log of dated entries. Each new piece of info goes in a new dated section.
+
+- **Timestamping rule:** every new entry MUST start with a dated heading: `## Session N (YYYY-MM-DD) — <title>`, `## YYYY-MM-DD — <title>`, or `## DD Month YYYY — <title>`. No exceptions.
+- **Examples:** `docs/battle-plan.md` (daily log), `docs/validation/external-insights.md` (conversation journal).
+- **`/distill` behavior:** keeps the N most recent dated sections verbatim, archives the rest into `docs/archive/<same-path>`, replaces them with a thorough summary.
+
+### `Compression: amended`
+The doc is a living reference. Claims are amended in place over time.
+
+- **Timestamping rule:** every new finding that revises an existing claim MUST be added as an inline `> **[UPDATE YYYY-MM-DD · Source: ...]**` block placed immediately above the claim it modifies. Brand-new claims with no prior version don't need a stamp; they're stamped implicitly by the doc's `Last Updated` date and git history.
+- **Examples:** `docs/validation/hypotheses.md`, `docs/market/icp-and-targets.md`, `docs/market/competitive-landscape.md`.
+- **`/distill` behavior:** collapses old `[UPDATE]` blocks into the body text (preserving their content as integrated current-state), archives the raw blocks verbatim. Keeps the N most recent amendments per section inline.
+
+### `Compression: none`
+The doc is a static thesis or reference. It gets rewritten, not amended. Git history is the timeline.
+
+- **Timestamping rule:** none. Just edit the doc and let `Last Updated` + git track changes.
+- **Examples:** `docs/strategy/product-thesis.md`, `docs/research/domain-101.md`.
+- **`/distill` behavior:** refuses to run. If a `none` doc has grown unwieldy, rewrite it manually or change its `Compression:` mode first.
+
+### Why this matters
+The TL;DR is current state, not history. It can't tell `/distill` what's new vs old. The `Compression:` mode + timestamping rule is the only mechanism that makes distillation deterministic. Skipping the timestamp on a new entry in a `chronological` or `amended` doc is a bug; it will get silently absorbed into the wrong era during distillation.
+
+When in doubt about which mode a new doc should use: chronological logs choose `chronological`, claim trackers choose `amended`, everything else is `none`.
+
+---
+
+## Vault Rules
+
+1. **Update, don't duplicate.** Amend with `> **[UPDATE YYYY-MM-DD · Source: ...]**`
+2. **Cross-link everything.** Claims reference their source doc.
+3. **Confidence levels:** `Unvalidated` | `Soft signal` | `Practitioner-validated` | `Data-validated`
+4. **Source everything.** Who said it, when, confidence level.
+5. **Minimize file count.** Append, don't create new files.
+
+---
+
+## The `/wrap-up` Protocol
+
+When the user says `/wrap-up`, run this end-of-day sequence:
+
+**Step 1 — Scan:** Read the battle plan. Identify all tasks for today. Categorize: done, partially done, not started, new.
+
+**Step 2 — Present:** Show the user: "Here's today's status: [list]. Does this look right?"
+
+**Step 3 — Prompt:** Ask: "Anything else happen today? Even small things — a reply, an accept, a thought, a link. Everything counts."
+
+**Step 4 — Cascade:** With all info gathered, run the full cascade (Steps 0-4 above).
+
+**Step 5 — Report:** Print:
+- Metrics changed today (before → after)
+- Docs updated
+- Verification warnings (if any)
+- Tomorrow's top priorities
+
+**Step 6 — Commit:** Ask: "Want me to commit today's updates?" If yes, commit with message: `eod YYYY-MM-DD: [summary]`
+
+---
+
+## Outreach System (Add-on)
+
+**Trigger:** If `outreach/leads.csv` exists in the project, the outreach system is active.
+
+### Overview
+
+The outreach system tracks a LinkedIn (or any channel) outreach pipeline through `outreach/leads.csv`. This CSV is the **single source of truth** for all outreach metrics — `metrics.yml` is derived from it, never edited directly for outreach numbers.
+
+### First-Time Setup
+
+If `outreach/leads.csv` exists but `.outreach-initialized` does NOT exist, read `outreach/README.md` and follow the Interactive Setup instructions to onboard the user.
+
+### Daily Workflow Integration
+
+The outreach system plugs into the cascade protocol:
+
+1. User runs `node tools/outreach/daily-targets.js` → generates blitz checklist
+2. User sends messages, ticks checkboxes
+3. User runs `node tools/outreach/flush-targets.js` → updates leads.csv
+4. `flush-targets.js` calls `sync-metrics.js` → derives metrics.yml from CSV
+5. `sync-metrics.js` calls `update-dashboard.js` → regenerates mermaid dashboard
+6. The cascade protocol takes over: metrics.yml → battle-plan.md → domain docs
+
+### Scripts Reference
+
+| Script | Purpose |
+|--------|---------|
+| `tools/outreach/daily-targets.js [N]` | Generate daily blitz checklist |
+| `tools/outreach/flush-targets.js` | Process checked items from blitz |
+| `tools/outreach/flush-updates.js` | Parse free-form natural language updates |
+| `tools/outreach/flush-accepts.js` | Batch-process connection accepts |
+| `tools/outreach/flush-inbox.js` | Add leads from manual URL list |
+| `tools/outreach/sync-metrics.js` | Derive metrics.yml from leads.csv |
+| `tools/outreach/update-dashboard.js` | Regenerate mermaid conversion dashboard |
+| `tools/outreach/stats.js` | Print pipeline summary |
+| `tools/outreach/lookup.js "Name"` | Fuzzy-search leads |
+
+### Metrics Derivation
+
+These metrics in `metrics.yml` are **derived** from leads.csv (never hand-edit):
+
+- `outreach_sent` = leads with status past `new` or `contacted_at` set
+- `responses` = `replied_at` set or status past `replied`
+- `invitations_accepted` = leads tagged `accepted`
+- `discovery_calls` = `call_at` in the past or status `call_done`
+- `calls_booked` = status `call_booked` (snapshot)
+- `verbal_commitments` = status `verbal`, `loi`, or `paying`
+
+### Template System
+
+Message templates live in `tools/outreach/templates.json`. The daily blitz assigns templates based on the `country_template_map` field (or round-robin if no mapping). Template performance (sent/accepted/replied/calls) is tracked automatically and displayed in the blitz checklist.
+
+### Mermaid Dashboard
+
+`docs/analysis/icp-conversion.md` is auto-generated — never hand-edit. It contains:
+- Overall funnel chart (contacted → accepted → replied → call → verbal)
+- Conversion breakdown by role, company size, country, company type
+- Template A/B comparison
+- Kill/Keep/Scale verdicts per segment
+
+View in any mermaid-capable renderer (GitHub, VS Code preview, etc.).
+
+### Adapting the System
+
+- **Different metrics:** Edit the derivation rules in `tools/outreach/sync-metrics.js`
+- **Different time horizon:** The system tracks weekly breakdowns — adjust `daily-targets.js` count parameter
+- **Different channels:** The `channel` column supports any value (connection, inmail, email, etc.)
+- **Different statuses:** Add to `VALID_STATUS` in `tools/outreach/lib/leads.js` and update derivation rules

package/template/events-archive.yml

@@ -0,0 +1,5 @@
+# events-archive.yml — past/completed events. Mirrors events.yml schema.
+# Wrap-up gate moves events here after transcript + insights captured.
+last_updated: 2026-05-11
+next_id: 1
+events:

package/template/events.yml

@@ -0,0 +1,5 @@
+# events.yml — single source of truth for future time-based events (calls, demos, meetings).
+# Past/completed events live in events-archive.yml. Tasks (deadline-only, no time-span) live in tasks.yml.
+last_updated: 2026-05-11
+next_id: 1
+events:

package/template/tools/events/add.js

@@ -0,0 +1,64 @@
+#!/usr/bin/env node
+// tools/events/add.js — add or update a future event in events.yml.
+//
+// Usage:
+//   node tools/events/add.js --title "Demo v1 — Acme/CIO" \
+//     --start "2026-05-14T14:00:00+02:00" [--end "..."] [--duration-min 30] \
+//     [--type demo|discovery|investor|admin|personal|unspecified|other] \
+//     [--status scheduled|in_progress|done|cancelled|no_show|rescheduled] \
+//     [--lead-id <linkedin_url_or_company_key>] [--attendee "Name"] (repeatable) \
+//     [--location "..."] [--notes "..."] [--source flush-updates|manual-chat|hand-edit] \
+//     [--id <existing EVT id>]   # update an existing event
+//
+// Idempotent — if (lead_id + start) matches an existing row, that row is updated.
+// Default: type=unspecified, status=scheduled, duration=30 minutes.
+
+const E = require('./lib/events');
+
+function parseArgs(argv) {
+  const out = { attendees: [] };
+  for (let i = 2; i < argv.length; i++) {
+    const k = argv[i];
+    const v = argv[i + 1];
+    if (k === '--attendee') { out.attendees.push(v); i++; continue; }
+    if (k.startsWith('--')) { out[k.slice(2).replace(/-/g, '_')] = v; i++; }
+  }
+  return out;
+}
+
+function main() {
+  const a = parseArgs(process.argv);
+  if (!a.title && !a.id) {
+    console.error('Usage: node tools/events/add.js --title "..." --start "ISO" [--type ...] [--lead-id ...]');
+    process.exit(1);
+  }
+  if (!a.start && !a.id) {
+    console.error('--start required (ISO 8601, e.g. "2026-05-14T14:00:00+02:00").');
+    process.exit(1);
+  }
+
+  const state = E.load();
+  const event = {};
+  if (a.id) event.id = parseInt(a.id, 10);
+  if (a.title) event.title = a.title;
+  if (a.start) event.start = a.start;
+  if (a.end) event.end = a.end;
+  else if (a.start) {
+    const d = parseInt(a.duration_min || '30', 10);
+    event.end = E.defaultEnd(a.start, d);
+  }
+  event.type = a.type && E.VALID_TYPE.has(a.type) ? a.type : (a.type || 'unspecified');
+  event.status = a.status && E.VALID_STATUS.has(a.status) ? a.status : 'scheduled';
+  event.attendees = a.attendees;
+  event.lead_id = a.lead_id || null;
+  event.location = a.location || null;
+  event.notes = a.notes || null;
+  event.source = a.source || 'manual-chat';
+
+  const result = E.upsert(state, event);
+  E.save(state);
+  console.log(`${result.action}: EVT-${result.event.id} · ${result.event.title} · ${result.event.start}`);
+}
+
+if (require.main === module) main();
+module.exports = { parseArgs };

package/template/tools/events/archive.js

@@ -0,0 +1,55 @@
+#!/usr/bin/env node
+// tools/events/archive.js — move gated/completed/cancelled events from events.yml → events-archive.yml.
+// Mirrors tools/tasks/archive.js.
+//
+// An event is archivable when:
+//   - status ∈ {done, cancelled, no_show, rescheduled} AND gate_completed_at is set (normal path), OR
+//   - end-time > 14 days ago (auto-no-show sweep for stale scheduled events)
+//
+// Flags: --dry-run, --days N (override stale threshold)
+
+const E = require('./lib/events');
+
+const args = process.argv.slice(2);
+const dry = args.includes('--dry-run');
+const daysIdx = args.indexOf('--days');
+const staleDays = daysIdx >= 0 ? parseInt(args[daysIdx + 1], 10) : 14;
+
+const cutoff = new Date(Date.now() - staleDays * 86400 * 1000).toISOString();
+const live = E.load();
+const archive = E.loadArchive();
+
+const archivable = [];
+const remaining = [];
+for (const e of live.events) {
+  const terminal = ['done', 'cancelled', 'no_show', 'rescheduled'].includes(e.status);
+  const gated = !!e.gate_completed_at;
+  const ref = e.end || e.start;
+  const stale = ref && ref < cutoff;
+  if (terminal && (gated || stale)) {
+    archivable.push(e);
+  } else if (!terminal && stale) {
+    e.status = 'no_show';
+    archivable.push(e);
+  } else {
+    remaining.push(e);
+  }
+}
+
+console.log(`Archivable: ${archivable.length}  ·  Remaining in events.yml: ${remaining.length}`);
+for (const e of archivable) {
+  console.log(`  EVT-${e.id}  ${e.start.slice(0, 16).replace('T', ' ')}  [${e.status}]  ${e.title}`);
+}
+
+if (dry) { console.log('\nDry-run.'); process.exit(0); }
+if (!archivable.length) process.exit(0);
+
+const archiveIds = new Set(archive.events.map(e => e.id));
+for (const e of archivable) {
+  if (!archiveIds.has(e.id)) archive.events.push(e);
+}
+live.events = remaining;
+
+E.save(live);
+E.saveArchive(archive);
+console.log(`\nMoved ${archivable.length} event(s) to events-archive.yml.`);

package/template/tools/events/due-for-gate.js

@@ -0,0 +1,31 @@
+#!/usr/bin/env node
+// tools/events/due-for-gate.js — events whose end-time has passed but no gate_completed_at yet.
+// The wrap-up skill walks these one-by-one and asks for: transcript path, hypothesis impacts,
+// spawned tasks, lead status change. Then stamps gate_completed_at and archives.
+// Flags: --json
+// Used by wrap-up (mandatory gate) and good-morning (warns when context-debt > 2 days old).
+
+const E = require('./lib/events');
+
+const asJson = process.argv.includes('--json');
+const events = E.dueForGate();
+
+if (asJson) {
+  console.log(JSON.stringify(events, null, 2));
+  process.exit(0);
+}
+
+if (!events.length) {
+  console.log('(no events due for wrap-up gate)');
+  process.exit(0);
+}
+
+console.log(`${events.length} event(s) past end-time, awaiting wrap-up gate:`);
+for (const e of events) {
+  const start = e.start.slice(0, 16).replace('T', ' ');
+  console.log(`  EVT-${e.id}  ${start}  [${e.type}]  ${e.title}`);
+  if (e.lead_id) console.log(`    lead: ${e.lead_id}`);
+  if (!e.transcript_path) console.log('    · transcript: MISSING');
+  if (!e.hypothesis_impacts || !e.hypothesis_impacts.length) console.log('    · hypothesis impacts: MISSING');
+  if (!e.spawned_tasks || !e.spawned_tasks.length) console.log('    · spawned tasks: none recorded');
+}