Weekly reports and the scheduled research refresh.

Weekly is a different job, not a longer brief CORE

It is tempting to think of a weekly report as a morning brief with more input — seven days’ inbox instead of one, seven days’ calendar, seven days of research notes. That framing produces a bad artifact. A seven-day version of a morning brief is a wall of categorized messages and events; nobody reads it.

A weekly report answers three specific questions the morning brief cannot:

• What did I actually get done this week? Not “what was on my calendar” — what moved. Shipped commits. Finished research notes. Replies sent. Drafts closed. Things that left a mark.
• What did I say I would do that I didn’t do? Carried commitments. Open threads still waiting on me. Drafts that sat in the drafts folder for seven days. A weekly report is where the honest accounting of not-done lives.
• What changed in the world of the thing I’m working on? If the student has a research topic, a project, a school unit, a competition — the weekly report summarizes changes in that world over the past seven days. New arguments, new sources, new deadlines.

That framing sets up the whole lesson. A weekly report is a synthesis and accountability artifact; a morning brief is a routing artifact. They compose different inputs, use different section shapes, and ask the student for different kinds of review attention.

One consequence: the weekly report’s audience is still you, but your reviewing posture is different. A morning brief is read at 7 AM, scanned in two minutes, used as routing. A weekly report is read at the start of a planning block on Monday, read slowly, used to decide what the next seven days will look like. The artifact is longer — three to four pages, not one — because the reviewer is slower.

The weekly report’s structure and its three inputs CORE

A weekly report that follows a predictable structure is cheaper to audit later. The recommended five-section shape:

1. Header line. Run timestamp, week ID (week-2026-17), the date range the report covers (2026-04-20 through 2026-04-26).
2. Shipped this week. A numbered list, max ten items. Each item is a link or path to evidence — a commit hash, a saved research note, a thread URL, a capstone file name — plus one sentence of what it is. The link to evidence constraint is the integrity rail: the agent cannot claim shipped work without a pointer to it.
3. Said-I-would, didn’t. A numbered list of carried commitments. Each item: what was supposed to happen, what blocked it, whether it carries to next week or drops. This is the section students want to skip; it is the section the report is for.
4. World changes in the topic. A synthesis (no more than eight sentences) of what changed in the research topic the student is tracking. This section is produced by the scheduled research refresh (Block 3) and pasted into the weekly report at compose time.
5. Health footer. Same shape as the morning brief. What the agent could not do this week. What sources were unavailable. What went silent.

The three inputs the prompt names, and the recipe wires up:

• Commit history for the student’s project repos. git log output for the past seven days across the student’s active repos, scoped to their own authorship. The prompt tells the agent to attribute commits specifically — do not claim commits it did not see, do not invent messages, do not round up.
• The capstone folder’s changes. Any file under /capstone/ modified in the past seven days. Diff the my-first-loop.md file against its state seven days ago and report the sections that changed.
• The research refresh’s latest diff. The output of a scheduled research refresh (defined in Block 3) becomes section 4 of the weekly report. This couples the two tasks — the refresh runs on its own schedule; the weekly report composes its latest result into the synthesis.

If the student has no active repos (common for younger students early in the course), the commit-history input is replaced by the capstone folder input alone. That is fine. The report still reads as a report.

Scheduled research refresh: watching a topic across runs CORE

Module 4 taught directed research — a one-time or multi-session investigation into a topic, producing a research brief. A scheduled research refresh is a research agent rigged to re-run the same investigation on an interval and report only what changed since last time.

Examples of the shape:

• A student tracking a specific court case wants to know weekly whether any new filings, decisions, or commentary appeared.
• A student tracking a legislative bill wants to know weekly whether new hearings, amendments, or votes happened.
• A student doing a research paper on a fast-moving topic (a recent technology, a current policy debate) wants to know weekly whether new peer-reviewed sources or reputable news analyses appeared.

The refresh framing changes the job. A one-time Module 4 research agent summarizes a topic. A scheduled refresh summarizes the delta — what’s new and, equally importantly, what stayed the same but moved in emphasis. The artifact is a short run note: three to eight sentences, explicit about what changed and what did not.

Why does this belong in a module on automation rather than in Module 4? Two reasons. First, refresh is an automation pattern — it is defined by the schedule and the idempotency key, not by the depth of the investigation on any one run. Second, the refresh is the thing you feed into the weekly report; wiring them together is the point of the lesson.

The refresh’s output should be small. A run note that’s two pages long is not a refresh; it’s a re-run of the initial brief. If the agent cannot summarize this week’s changes in eight sentences it probably found too many things and is including everything instead of deciding. The prompt will put a ceiling on output length and instruct the agent to rank by relevance, not count.

The diff contract: what counts as meaningful change CORE

The hardest part of a scheduled research refresh is deciding what counts as a change worth reporting. A naive refresh that reports every new URL it found will produce twenty sentences of noise a week, which the student will stop reading, and the automation is now worse than no automation.

The diff contract is a short paragraph in the prompt that defines “meaningful change” for this specific refresh. It has three parts:

• What to include. Concrete types. “New primary-source filings, decisions, or hearings. New analyses from recognized legal scholars or national news outlets. New official statements from named parties.”
• What to exclude. Concrete types. “Opinion columns in regional news. Reposts or syndications of items already reported last week. Commentary on commentary.”
• What counts as ‘new.’ Specifically. “Published after [date of last run]. If a piece has been updated since last run, include it only if the update itself is material — a new section, a substantive correction, a reversal.”

The contract is not universal. The examples above fit a court-case refresh; the contract for a technology-announcement refresh or a policy-debate refresh will look different. The research-refresh prompt template provides three contract examples the student can adapt.

One more discipline: the diff contract also names a zero-state behavior. If a refresh run finds nothing meaningful, the artifact should say so explicitly — “No meaningful changes this week” — and not fabricate items to fill space. This is the same anti-confabulation rail you met in Lesson 6.2. It is more important here, because the agent has a bias toward producing something from a research task, and an empty refresh is a valid and useful output.

The idempotency keys for both tasks CORE

Weekly report: key is the ISO week number in the canonical time zone. week-2026-17.md is the week of April 20–26, 2026, which is ISO week 17. A re-run in the same week overwrites. Why ISO weeks instead of “Sunday-to-Saturday” or “Monday-to-Sunday”? Because ISO week 17 is the same week number in every tool — your calendar, your git log, any service that reports weeks — and you want a label that is stable across tools.

Scheduled research refresh: key is the query ID plus run timestamp. research/q-supreme-court-patel/run-2026-04-22T0800.md, with a latest.md symlink in the same folder pointing to the most recent run. The refresh is fundamentally re-runnable within the same interval — maybe you want to pull a refresh twice on a busy day — so the timestamped filename is the key, and the latest.md symlink is what the weekly report reads from.

The subtle bit is how the diff is computed. The refresh’s prompt must know where to look for the prior run’s content so the agent can compute the delta. The simplest form: the prompt tells the agent “read research/q-supreme-court-patel/latest.md (if it exists) as the prior-run summary; your job is to produce a new summary and a short diff paragraph.” The recipe wires this in. The student does not have to write the logic, but should understand that the refresh’s “state” — the thing that makes it scheduled rather than one-time — lives in that one file.

One failure mode to watch for: the agent reads latest.md, decides nothing has changed, and quietly writes “no meaningful changes” even when the underlying world has moved a lot. This is a silent failure because the artifact still has the expected shape. The defense is the same one you met in the morning brief: a health footer, every run, that reports what the agent searched and how many sources it read, so the student can detect a run that was lazy rather than uneventful.