EOW Summary

Generate a draft end-of-week summary by scanning four sources across the current week's weekdays. Output is one markdown file with three layered sections (personal log, team digest, Guild candidates) that the user reviews and edits before sharing.

When to use

• Explicit invocation: /eow-summary
• User asks "what did I ship this week", "draft my weekly digest", "summarize this week's work"
• Friday-morning cron trigger
• User passes a custom range — honor it, but still drop Sat/Sun activity

Time window

Default: Monday 00:00 through Friday 23:59 of the current week, weekdays only.

• If invoked Mon-Fri: window is this week's Monday through invocation time.
• If invoked Sat/Sun: window is the just-completed Mon-Fri.
• If user passes an explicit range: honor it but exclude Sat/Sun activity within the range.

Compute the Monday boundary on macOS zsh:

START=$(date -v-Mon +%Y-%m-%d)        # if today is Mon-Fri, the most recent Monday
END=$(date -v+Fri +%Y-%m-%d)          # this Friday

If today is Sat/Sun, adjust to the prior Mon-Fri.

Use ISO timestamps (YYYY-MM-DD) when passing to git log --since/--until and find -newermt.

Sources to scan

Run these in parallel where independent.

1. Git activity (ground truth for shipped work)

Scan roots are configurable, and ~/dev/*/ alone is not enough. Repos that live outside ~/dev are invisible to a bare glob, and a repo you don't scan reads as a week with no commits rather than a gap in measurement — a silent undercount of authored work, in the one source this skill treats as ground truth.

Read the roots from ~/dev/eow-summaries/scan-roots.local when it exists — one shell glob or path per line, # for comments — and fall back to ~/dev/*/ when it doesn't. Quote any path containing a space in that file; the loader below honours the quotes, and an unquoted $HOME/My Repo word-splits into two non-existent paths and is skipped in silence:

shopt -s nullglob
ROOTS_FILE="$HOME/dev/eow-summaries/scan-roots.local"
[ -f "$ROOTS_FILE" ] || printf '%s\n' '$HOME/dev/*/' > "$ROOTS_FILE"
while IFS= read -r line; do
  case "$line" in ""|\#*) continue;; esac
  eval "paths=($line)"          # array-eval: expands globs, preserves quoted spaces
  for d in "${paths[@]}"; do
    [ -d "$d/.git" ] || continue
    git -C "$d" log --since="$START" --until="$END 23:59" \
      --pretty=format:'%H|%h|%ad|%s' --date=short --no-merges --all
  done
done < "$ROOTS_FILE"

Run it under bash, not sh — it needs arrays and nullglob. Print the resolved repo count before using the results; if it is lower than you expect, a quoting or glob problem swallowed a root rather than the week being quiet.

Drop any line whose date falls on Sat/Sun. Group by repo. Note branches active in the window via git -C "$d" for-each-ref --sort=-committerdate refs/heads/.

State the roots you scanned in the summary's git section. If a known repo is absent from the config, say so rather than reporting a total that quietly excludes it.

Counting method — pin it, or successive runs will disagree

Report both a repo-wide and an authored count, and derive both the same way every time:

• Dedup by full commit hash (%H), never by subject. Subjects repeat across branches after a rebase or cherry-pick; hashes don't.
• Union mirrored repos before counting; never sum them. Where one repo mirrors another, the same commit appears in both with the same hash — summing the per-repo rows double-counts every mirrored commit. Concatenate the hash lists, sort -u, then count.
• Authored = filter on every git identity the user commits under (git log --author= accepts repeated flags, OR'd). A single-identity filter silently drops work committed under the other one; check git log --pretty=%an\ <%ae> | sort -u per repo if unsure.
• Print the method alongside the number. Two defensible methods over the same window can differ by 30%+; a bare count with no stated basis cannot be reconciled against last week's.

A worked check that the numbers are internally consistent: per-repo unioned counts must sum to the all-repo deduped total. If they don't, a mirror is being double-counted somewhere.

Branch / PR drift — commits are not the whole picture

Also report branch/PR drift per repo, not just commits. An un-merged branch is work that shipped without landing, and it is exactly what a --since commit scan misses once the branch's commit dates fall out of the window — the week reads as clean while the work sits unlanded:

Resolve each repo's default branch — don't hardcode main. A repo whose default is master (or anything else) makes rev-list main..$b fail; the error goes to /dev/null, the count reads as empty, and the repo reports no drift when it may have plenty. That is the same failure shape as the roots bug: a measurement gap wearing the costume of a clean result.

base=$(git -C "$d" symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null)
base=${base#origin/}
if [ -z "$base" ]; then
  for cand in main master trunk; do
    git -C "$d" rev-parse --verify --quiet "$cand" >/dev/null && { base=$cand; break; }
  done
fi
if [ -z "$base" ]; then
  echo "$d: SKIPPED — default branch unresolved, drift NOT measured"
else
  git -C "$d" for-each-ref --format='%(refname:short)' refs/heads/ | while read -r b; do
    [ "$b" = "$base" ] && continue
    ahead=$(git -C "$d" rev-list --count "$base".."$b" 2>/dev/null) || ahead=""
    [ -n "$ahead" ] && [ "$ahead" -gt 0 ] && echo "$d $b ahead:$ahead (base:$base)"
  done
fi

Flag any branch ahead of its base with no open PR — gh pr list --head "$b" returns empty. Report it as an open thread, not as shipped work. This is the failure mode a roots misconfiguration and a stale window produce together: a pushed-but-un-PR'd branch in an unscanned repo is invisible twice over, and tends to surface only by accident from a hand-written note elsewhere.

Report the skips. A SKIPPED line is a hole in the measurement and must appear in the summary's git section — never let an unresolved base, or a repo the roots config missed, read as "no drift."

2. ~/dev/deliverables/ entries (polish signal)

find ~/dev/deliverables -name '*.md' -newermt "$START" ! -newermt "$END 23:59"

Anything new or modified here is a Guild-candidate by definition. Read each to extract the deliverable name and core five (Problem / Solution / AI proficiency / Value / Links).

3. Project memory

find ~/.claude/projects/-Users-anthonyli/memory -name 'project_*.md' \
  -newermt "$START" ! -newermt "$END 23:59"

Read each modified file. Surface status changes, decisions, new initiatives. Skip files that only had cosmetic edits.

4. Claude Code transcripts (last-resort context)

find ~/.claude/projects -maxdepth 2 -name '*.jsonl' \
  -newermt "$START" ! -newermt "$END 23:59"

Group by project subdirectory. Use sparingly — surface blockers, exploratory threads, and work that left no git/deliverables/memory trace. Never paste raw transcript content. Synthesize.

5. EOD recaps — Slack-communicated commitments (~/dev/eod-recaps/)

The companion eod-recap skill writes one dated file per day (YYYY-MM-DD.md) holding the action items, deliverables, commitments, and decisions the user communicated in Slack that day — already classified and noise-filtered. This is the only source that captures what the user told people they'd do; git, deliverables, and memory don't see Slack.

Filenames are ISO dates, so a lexical range over the window selects the right files:

for f in ~/dev/eod-recaps/*.md; do
  d=$(basename "$f" .md)
  [[ "$d" > "$START" || "$d" == "$START" ]] && [[ "$d" < "$END" || "$d" == "$END" ]] && echo "$f"
done

Drop any whose date is Sat/Sun. Pull the already-tagged items straight through — don't re-derive them. Feed [commitment] and still-open [action] items into the personal log and the team digest's commitments line; cross-check [deliverable] items against git + the deliverables folder before claiming something shipped.

• Carry redaction forward verbatim. Items already marked [private — checkpoint comms] stay collapsed — never expand them, even though the EOW output is also a draft.
• Flag gaps. If a weekday in the window has no eod-recap file, note it (e.g. "No eod-recap for Tue 06-03 — Slack-communicated items not captured that day.") so the user knows the Slack layer is partial, not that nothing was said.

6. Surface-triage tally (~/dev/eow-summaries/.surface-triage.jsonl)

The user's global CLAUDE.md carries a surface-triage rule: a CC session whose first 20 turns produce no file edits, no git ops, and no memory writes "was a Claude.ai session in disguise — flag it in the next /eow-summary." A SessionEnd hook (~/dev/surface-triage-check.sh) records the verdict per session, because the judgement can't be made from inside the session it's about.

Read the window's lines and count by verdict:

jq -c --arg s "$START" --arg e "$END" \
  'select(.date >= $s and .date <= $e)' ~/dev/eow-summaries/.surface-triage.jsonl

Four verdicts, and they are not interchangeable:

• Report flag counts, never a flag verdict as fact about a specific piece of work. The signal is "this session should probably have been a web chat", which is a prompt to reconsider surface choice — not evidence about output quality. Give the count, the projects (cwd), and leave the read to the user.
• Surface unknown separately. A week of unknown means the hook is running but seeing nothing, which looks identical to a clean week if you fold them together.
• No tally file, or no lines in the window, is not "zero flagged sessions." It means the hook didn't run — say so, the same way a missing eod-recap file is reported as a gap rather than silence.

Classification rubric

For each project cluster, classify the week's work:

• Shipped — merged commits + matching deliverables entry, OR clear "done" status in memory
• In-progress — commits but no deliverables entry yet, or memory marks it active
• Blocked — transcript, memory, or an eod-recap mentions an unresolved blocker
• Exploratory — Claude Code activity but no commits, deliverables, or memory updates
• Committed — an eod-recap holds a [commitment]/[action] with neither a matching shipped artifact nor a later recap fulfillment/closer note (something promised in Slack, still genuinely outstanding — not merely lacking a git trail; see the closure rule under "Computing the metrics rollup")

Source weighting when signals conflict: for shipped work, git > deliverables > memory > transcripts. For what was communicated or committed, the eod-recaps are authoritative — git/deliverables/memory can't see Slack, so don't down-rank a recap'd commitment just because there's no commit behind it yet.

Output

Write to ~/dev/eow-summaries/YYYY-MM-DD.md where YYYY-MM-DD is the Friday of the week being summarized.

• If ~/dev/eow-summaries/ doesn't exist, create it.
• If the file already exists for that date, append a ## Re-run at HH:MM section rather than overwriting.
• Always a draft. Header must say so explicitly.

File template

# EOW Summary — <Mon date> through <Fri date> YYYY

_Draft generated <ISO timestamp>. Edit before sharing._

## 1. Personal log

Everything touched this week, by project. One bullet per project; sub-bullets for commits, decisions, blockers, dead-ends. This section is for your records — keep it complete.

- **<Project>** — <classification>
  - Commits: <hash short subjects>
  - Decisions: <one-liners>
  - Commitments: <open [commitment]/[action] items from eod-recaps — who it's to + by when>
  - Blockers: <if any>

**Surface triage** _(from the SessionEnd tally — sessions that may have belonged in web chat)_
- <N> of <total> sessions flagged: 20+ turns, no edits / git / memory writes — <projects>
- <N> unknown (hook ran, transcript unreadable) · omit this line at zero
- _If the tally has no lines in the window: "No surface-triage data — the SessionEnd hook didn't record this week."_

## 2. Team digest

Scannable view for the immediate team. Skip exploratory work here.

**★ Key wins** _(the 2–4 flagship deliverables — the highlight reel you'd paste into a checkpoint or manager update)_
- <flagship win> — <one-line value/outcome + link>

Pick the wins on **impact/visibility**, not volume: a launch, a shipped prototype, a closed negotiation, a program milestone. Distinct from "Shipped this week" below (which is the exhaustive list) — these are the headline few, each with its *value*, not just what it was. Skip routine/maintenance work here even if it shipped. If nothing rose above routine this week, write "_No flagship wins this week — see Shipped below._" rather than padding it.

**Shipped this week**
- <project> — <one-line outcome + link to deliverable or PR>

**Decisions**
- <one-line decision + rationale>

**Commitments outstanding** _(from eod-recaps — what I told people I'd do, not yet shipped)_
- <commitment> — to <whom> · <by when>

**Blocked / needs input**
- <project> — <what's blocking + what unblocks it>

## 3. Guild candidates

Anything that crossed a ship threshold this week — present in `~/dev/deliverables/` or marked shipped in memory — AND fits the AI Design Guild automation frame.

**Exclude Claude Code skills by default.** The Guild's canonical examples (UXR Budget Bot, UXR Tech Pulse, ReOps UXR Standup) are orchestration automations, not workflow tooling. A Claude Code skill qualifies only if it orchestrates external systems beyond Claude Code itself (e.g. wraps a Slack/Snowflake/Miro API call as part of its execution). Pure dev-workflow skills (audit, summary, doc-drafting) are logged in the personal log + team digest but not in this section. When excluded, add a one-line note at the top of the Guild section explaining why so the user can override on review.

Pre-format each candidate in Anthony's Format A bullet style (per `reference_ai_design_guild_summaries.md`):

- **<Automation name>**
  - Tools: <comma-separated stack>
  - Pathway: <trigger> → <step> → <step> → <output>
  - AI role: <what the LLM specifically does — or "None — pure workflow orchestration">
  - Replicability: <one sentence on what other use cases this pattern fits>
  - Metric: <concrete number with math shown>
  - Gain: <one sentence on the win>

If nothing crossed the threshold this week, write: _No Guild candidates this week._

## 4. Metrics

The numerical layer — for the user's own reference and performance audits. Computed from the eod-recap items' category tags + git/deliverables. See "Computing the metrics rollup" below.

**Coverage this week** _(items per category; a workstream at 0 is the signal)_
- <cat>: <n>  ·  <cat>: <n>  ·  … · Off-plan: <n>   _(Meta/checkpoint-comms excluded)_

**Deliverables** — shipped this week: <n>  ·  vs prior week: <n> (<Δ>)

**Commitments** — made this week: <n>  ·  shipped/closed: <n>  ·  **closure rate: <x>%**

**Open commitments** _(all-time, scanned across eod history)_ — <n> open, <n> overdue
- <commitment> · made <date> · age <d>d · <OVERDUE if past due> · to <whom>

**Shipped-vs-said** — <deliverables with a real git/deliverables artifact> / <total deliverable claims> = <x>%

_If `~/dev/eod-recaps/taxonomy.local.md` is absent or no eod-recap files fell in the window, note that and emit only the metrics derivable from git/deliverables._

Computing the metrics rollup

• Coverage — tally the category tags on items in this week's eod-recap files. Carry the tags straight from the files; don't re-categorize. Exclude Meta/[private — checkpoint comms] items. Surface any category at 0.
• Closure rate — of [commitment] items logged this week, how many are closed. A commitment counts as closed if either (a) it has a matching shipped artifact (a commit/PR in git or a deliverables entry), or (b) a later eod-recap contains a matching fulfillment/closer note (a [deliverable] or an explicit "closes X" — the "X/Y booked", "invites sent", "screener live" recruitment signals the daily is told to capture). Best-effort match on project/topic + recipient. Ambiguous matches count as open, labeled "(unverified)".
  • No-git commitments need a Slack/recap match, not a git one. Recruitment, participant-ops, email sends, and other ReOps promises leave no git/deliverables artifact by design — do not default them to "overdue" for lacking one. Their closure evidence lives only in a later eod-recap. If a due date has passed and you find neither an artifact nor a recap closer, flag it "unconfirmed — no artifact + no-git delivery; confirm with the user", NOT a hard "overdue" — a thin/missed daily recap (the sweep under-pulls DMs) is a known failure mode that has mis-flagged a delivered commitment as overdue.
  • Four standing defaults resolve most no-git items without asking. These are the user's own operating cadences, confirmed 2026-08-06 during the 103-commitment adjudication pass. Apply them to reach closed rather than parking everything at "unconfirmed" — a pass that asks about seventy items is a pass the user stops running:
    1. Reward sheets go out end-of-week, on Fridays. A "send rewards by EOW" commitment is closed on that Friday.
    2. An audience list is sent the same day it is built. Treat list-built as list-sent; the user flags it explicitly when a send slips off the build day.
    3. A scheduled send completes as planned. Once a send is scheduled or rescheduled to a date, that date is met — don't carry it open because no recap re-confirms the firing.
    4. Silence in the requester's channel is closure evidence. No chase, no error, no "still waiting" from the counterparty means it landed. Requesters reliably speak up when something is late.
    • Escalate to the user only when evidence actively conflicts with a default (a participant chasing a missing reward, a requester reporting a broken send), not when evidence is merely absent. Absence is the expected state for this class of work.
• Open commitments + aging — scan all ~/dev/eod-recaps/YYYY-MM-DD.md files (the daily files are the persistence — no separate ledger). For each [commitment] with neither a shipped artifact nor a later recap closer note: age = window-end date − the date it was first logged; overdue = a stated due date now past. For a no-git-class commitment (recruitment/participant/send ops) past its due date with no match, prefer "unconfirmed — confirm with user" over "overdue" (see closure rule above). Only files named as ISO dates — skip taxonomy.local.md and anything else.
• Shipped-vs-said — [deliverable] items with a real artifact behind them (git/deliverables) ÷ all [deliverable] items this week.
• Throughput — deliverables shipped this week vs. the prior week's eow-summary metrics block (if present).

These are activity/coverage/follow-through signals, not impact. Git + the Deliverables Log remain the outcome evidence; the metrics complement them. Never present a raw count as if it were performance.

Monthly promotion pass (Tier 1 → Tier 2 — first eow of the month only)

The Deliverables Log (~/dev/deliverables/) is the durable evidence base for shipped work — it feeds the downstream reporting that reads from it (see its README.md → "Tiers & promotion cadence"). It's Tier 2: curated, human-gated. The eod-recaps/eow-summaries are Tier 1: cheap automatic capture. Things ship in Slack (recruitment sends, audience pulls, participant-ops, study launches) that leave no git trail and never get a Tier-2 entry — so they evaporate from the evidence base unless deliberately promoted while the numbers are fresh.

Trigger: only when this is the first eow-summary of a calendar month (i.e. no other eow-summaries/*.md exists for the current month). Otherwise skip this section silently.

When triggered:

1. Walk the last ~4 weeks of eod-recaps + eow-summaries. Collect every [deliverable] that crossed a real ship threshold, especially no-git ones (recruitment/participant-ops/sends/study launches).
2. Cross-check each against ~/dev/deliverables/*.md — is there already an entry? Label each candidate "likely new" or "possibly overlaps <file> — confirm distinct vs. append." (Overlap is a label for a human call, not an auto-skip — a study vehicle vs. its audience pull can both be real.)
3. Surface the list and offer to draft — do NOT auto-write. Writing to Tier 2 stays confirmed, per the same gate the daily eod-recap uses. On confirmation, draft core-five entries via TEMPLATE.md, quantifying impact from the captured numbers (never invent), and add each to the README index.
4. Verify authorship/facts before writing — e.g. a PR you authored is not a PR you reviewed; a "test email sent" is not a "study launched". Check before promoting (this is the judgment the gate exists to protect).

This is the safety net that makes the durable evidence base actually durable. Keep it a prompt, not an auto-dump — the folder's credibility at review time depends on everything in it being deliberate and true.

Regenerate the living dashboard (multi-source HTML)

After the weekly markdown is written, refresh the living operating dashboard — a single, stable, overwritten HTML file that always reflects the latest cumulative picture, so it can be printed at any checkpoint without a one-off build.

• Path: ~/dev/eow-summaries/<dashboard>.html (a fixed filename — overwrite it each run; it is NOT dated). If the file already exists, reuse its CSS + component structure as the template (refresh only the numbers/bars) so styling stays consistent and correct — don't re-derive the layout. If creating it fresh, match the deliverables share-HTML one-pagers (inline CSS, no JS, print-friendly). Note: bar fills must be display:block (a <span> fill inside a grid-item track is inline and renders nothing otherwise).
• Multi-source, not Slack-only. Compute its numbers from the reconciled rollup across the full eod-recap history plus git and the deliverables log to date — not just this week, not just Slack.
• Two lenses, side by side: "Communicated" (from eod-recaps) and "Shipped" (git commits/PRs + deliverables entries). Present them separately and surface the delta — don't merge fuzzy tags into one count. The gap between communicated and shipped is itself a finding.
• Include: category coverage (from the taxonomy tags), commitment closure (closed / open / overdue), and the weekly activity trend.
• Local-only. This file carries category/taxonomy substance; never push it to a public repo or git init the folder.
• Carry redaction forward — never expand [private — checkpoint comms] items into the dashboard.
• Preserve human-curated sections verbatim. If the dashboard has a manually-curated section (e.g. a "Collaboration & peer signal" section quoting other people), carry it through unchanged — never auto-generate, rewrite, or drop peer quotes. Attribution of others' words stays human-curated; the auto-run only refreshes the computed metrics (coverage, closure, trend), not the curated signal.

Refresh the machine-readable JSON export too

If a metrics generator script exists (e.g. ~/dev/eow-summaries/gen-metrics.py), run it after the dashboard so the JSON export stays in lockstep with the HTML — don't hand-write the JSON. The script parses the eod files deterministically and merges an editable sidecar (metrics-inputs.json) for judgment inputs (commitment statuses, peer signal, shipped/git numbers).

• Keep the JSON's window consistent with the dashboard's.
• During the rollup you already re-scan git and re-assess commitment closures — write those updated figures into the sidecar (shipped numbers + any status changes) before running the script, so the JSON reflects this week, not the seed. New commitments default to open and are flagged; resolve them in the sidecar.
• Both artifacts are local-only.

Lean carry file (portable, on-the-go)

After the weekly markdown is written, also emit a lean one-page carry file — the artifact to read on a phone or paste into a Claude.ai web chat when continuing on another device without Claude Code, the filesystem, or memory. It complements (does not replace) the full summary and the dashboard, and rides the existing Drive backup (01-EOW captures) so it's already reachable on mobile.

• Path: ~/dev/eow-summaries/CARRY_YYYY-MM-DD.md (Friday date, matching the main file).
• Overwrite on re-run — unlike the main summary (which appends), the carry file is a derived snapshot that should always reflect the latest state and stay lean. Regenerate it whole each run.
• Keep it to ~1 page. Only what carries forward — not the exhaustive personal log. If it doesn't help someone resume on Monday from a phone, leave it out.
• Redacted-by-default (public-safe). This is the one EOW artifact designed to leave the machine, so it must be safe to paste anywhere:
  • Reference any personal-plan workstreams by slug only — never the plan's substance, criteria, or manager-feedback (per feedback_public_artifacts_no_private_info).
  • Carry the [private — checkpoint comms] collapse forward verbatim — never expand those items here.
  • Omit the plan-relative metrics interpretation. A bare coverage line is fine; "thin against criteria X" is not.
  • When in doubt, drop it — the full local-only summary already holds the complete record.

Carry file template

# Carry — week of <Mon date>–<Fri date> YYYY

_Lean handoff. Read on the go, or paste the resume block below into a fresh chat on another device. Regenerated each run; edit before relying on it._

## State of play
<2–3 lines: where things stand at week's end — the flagship wins + anything mid-flight.>

## Live threads (carry forward)
- <open commitment / thread — to whom · by when — checkpoint-private items stay collapsed>
- <blocker + what unblocks it>

## Next move
<one concrete sentence — specific name/path/number; the first thing to do next session>

---

### Paste-to-resume (for Claude.ai web / another device)
```
I'm Anthony Li (Research Operations at Miro), continuing work from last week in a chat without my Claude Code setup (no filesystem, no memory). Here's where I left off — help me pick up from the "next move".

Week of <Mon>–<Fri>: <one-line what the week covered>
Flagship: <the 1–2 headline wins>
Open threads: <the live threads above, one line each>
Next move: <the next-move line>

Ask me for anything you need; don't assume access to my files.
```

The paste-to-resume block deliberately mirrors the close-chat BOOTSTRAP "session covered" shape, pre-filled — so it drops straight into that fuller closeout flow if the user wants it, or stands alone as a quick resume.

After writing the file

1. Print to the user:
   • The output file path + that the living dashboard HTML was refreshed + the CARRY_<date>.md path (the lean portable copy)
   • A 3-line summary: # projects touched, # shipped, # Guild candidates — and name the ★ key wins (the flagship few)
   • The metrics headline: coverage by category (flag any at 0), closure rate, open/overdue commitments
   • Reminder: "Draft — edit before sharing."
2. Self-schedule next week's run (works around the 7-day cron auto-expiration):
   • Use CronCreate with recurring: false, durable: true, prompt "Friday EOW summary — invoke the eow-summary skill.", and a cron expression pinned to next Friday at 11:30am local / Amsterdam (e.g. "30 11 <next-fri-dom> <next-fri-month> *").
   • Compute next Friday's date with date -v+Fri -v+1w +'%d %m' (zsh on macOS) and substitute the day-of-month and month.
   • Tell the user when the next run is scheduled.

Rules

• Draft, not final. Header always says "Draft generated — edit before sharing."
• No invented metrics. Pull from project memory and deliverables entries. If a metric isn't recorded, write Metric: TBD — pull from <source>.
• Category-agnostic skill. Read categories from the user's local ~/dev/eod-recaps/taxonomy.local.md; never hardcode a category scheme here. The metrics layer is coverage/follow-through, not impact — don't present a raw count as performance.
• Honest about AI role. When an automation is pure orchestration, say so (Format A house rule).
• Weekday-only. Drop Sat/Sun activity even if a calendar-week range is passed.
• Source weighting. Git is ground truth for what shipped; transcripts are last-resort context.
• Never report a git count without its basis. Hash-deduped, mirrors unioned, roots named. An unqualified commit count cannot be reconciled against the prior week's and will read as a discrepancy.
• Don't paste raw transcript content — synthesize, don't quote.
• Read-only on sources. Never modify git repos, deliverables files, or memory files.
• One file per Friday. Re-runs append, not overwrite.
• Self-perpetuate the cron. Always schedule next Friday before exiting.