iroha: digest

Synthesize a period rollup across many sessions so the team can see "what did we decide and ship lately?" in one page instead of opening every Session. iroha is a growing memory; digest is how that growth becomes legible. Notion is the single source of truth; everything here is read via notion-search (free plan) and written via the Notion MCP. Write Notion content in the user's conversation language.

1. Preconditions

L="${CLAUDE_PLUGIN_ROOT}/scripts/_lib/config.ts"
bun "$L" get session_ds_id      # empty -> tell the user to run /iroha:init, then stop
bun "$L" get decisions_ds_id
bun "$L" get container_page_id
bun "$L" get digests_folder_id  # the Digests grouping page (fall back to container if empty)

2. Resolve the period

Parse $ARGUMENTS and compute an inclusive [START, END] date window (ISO YYYY-MM-DD):

case "${ARGS:-week}" in
  week|"")  START=$(date -v-7d +%F 2>/dev/null || date -d '7 days ago' +%F);  END=$(date +%F) ;;
  month)    START=$(date -v-30d +%F 2>/dev/null || date -d '30 days ago' +%F); END=$(date +%F) ;;
  *..*)     START="${ARGS%%..*}"; END="${ARGS##*..}" ;;            # explicit YYYY-MM-DD..YYYY-MM-DD
  *)        START="$ARGS"; END=$(date +%F) ;;                       # single date -> through today
esac
echo "$START -> $END"

(date -v is BSD/macOS, date -d is GNU — the fallback covers both.)

3. Gather the period's memory — complete & current via the local index, content via Notion

The committed local index (.iroha/index.ndjson) is the complete enumeration of saved sessions and decisions — the completeness layer notion-search lacks on the free plan (search returns only a semantic top-N and lags writes by minutes, and query-data-sources is paid). Enumerate the window from the index so the digest's counts and lists are exhaustive and include work saved moments ago, then notion-fetch each id for its body.

IDX="${CLAUDE_PLUGIN_ROOT}/scripts/_lib/index.ts"
# Complete window enumeration, newest first — typed range query (no jq); the 4th/5th args are
# optional type / status filters. Sessions in the window, then Active decisions in the window:
bun "$IDX" in-range "$PWD" "$START" "$END" session
bun "$IDX" in-range "$PWD" "$START" "$END" decision Active

• Sessions — the index lines give the complete id / title / date / status. For each,

notion-fetch to read its Summary, Type, Status, the ## Metrics line, and the decisions it made. If the window is large you may cap the fetches (newest ~15) — but the session count comes from the full index enumeration above, so the totals stay honest. If you cap, say so in the digest (never silently drop).

• Decisions — the enumeration above already keeps only Status = Active (mention a

superseded one only if it was superseded within the period). notion-fetch each for Why/Date.

• Still-open — notion-fetch the project State page (bun "$L" get-state "$PWD")

and read its Unfinished / Next list.

• Empty/stale index fallback — a workspace created before the index existed lists nothing.

Then fall back to notion-search over session_ds_id / decisions_ds_id with filters.created_date_range = {start_date: START, end_date: END} (page_size ~25) and note in the digest that the rollup may be incomplete (search returns only a top-N).

4. Compose the digest content (monochrome Notion-flavored Markdown, no emoji)

Sections, in this order:

1. a header <callout color="blue_bg">: the window + a one-line rollup

(N sessions, M decisions; themes: …).

1. ## Metrics — a <callout color="gray_bg"> aggregate dashboard: total sessions,

total decisions, files touched (sum of each session's Files), and a by-Type tally (Implementation ×3 · Fix ×2 · Research ×1). The total sessions / total decisions are the count of the index enumeration in step 3 (complete). Files touched and the by-Type tally are summed from the ## Metrics line of each fetched session — do not invent numbers; if you capped the fetches, label them "across the N fetched of M sessions" so a partial aggregate is never shown as complete.

1. ## Decisions made — a <table header-row="true"> (<tr color="blue_bg"> header):

Decision / Why / Date. One row per Active decision in the window. Wrap code in backticks.

1. ## Sessions — newest first, one bullet each:

- [YYYY-MM-DD — title](url) — Status · <one-line summary>.

1. ## Still open — an orange_bg callout with the State's carried-over - [ ] items.
2. ## Timeline — a one-line caption first ("How the period progressed:" or similar, so

the diagram is never a context-free "what is this?"), then a ``mermaid`` diagram (a simple top-down or left-right timeline of the sessions in the window, labeled by date + short topic) so the arc of the period is visual.

Wrap every file / command / path in backticks, and run the composed content through bun "${CLAUDE_PLUGIN_ROOT}/scripts/_lib/link-lint.ts" before publishing (it flags bare file/path tokens Notion would auto-linkify to http://…; backtick them until it exits 0). Indent callout / table / toggle children with tabs.

5. Write the Digest page

notion-create-pages under the `Digests` folder (digests_folder_id from step 1; fall back to container_page_id only if a pre-folder workspace returns empty):

• properties: { "title": "Digest START..END" }
• icon: https://www.notion.so/icons/calendar_gray.svg
• content: the markdown from step 4.

Digests are disposable rollups, not a source of truth — they link back to the canonical Sessions / Decisions. Do not create a database for them; a page under the Digests folder is enough (grouping them there keeps the container root from filling with one flat digest page per run). If a digest for the exact same window already exists, notion-update-page replace_content it instead of making a duplicate.

6. Report

Give the Digest page URL, the counts (sessions / decisions in the window), and the top 2-3 themes. Note that /iroha:recall <topic> can drill into any session or decision the digest references.

Notes

• Read-only over the canonical DBs except for the one Digest page it writes.
• If the window has zero sessions, say so plainly and suggest a wider range — do not

fabricate a digest.