Six real runs. Three of them fail on purpose.

SAMPLE RUN — executed 2026-09-05 by the routine prompt on the inputs in ./inputs (see HOW_THIS_WAS_PRODUCED.md)

Weekly Reliability Review – week ending 2026-09-06

Run-id: 20260907-0703-O2 | Run at: 07:03 Australia/Melbourne (AEST, UTC+10) | Status: PARTIAL
Window: 2026-08-31T00:00:00+10:00 to 2026-09-06T23:59:59+10:00 | Registry: 14 enabled routines (of 32 rows) | RUNLOG lines in window: 51 parsed (2 malformed, skipped)

Status is PARTIAL because verification check 2 failed: five in-window log lines belong to a routine that is not enabled in the registry. Nothing was repaired. See Verification and owner action 5.

Fix these first

Not listed: A2, A4, D4, F1, O1, O2, P2 scored 0. That is 7 routines, and 7 + 7 = the 14 enabled rows.
Ties are broken by routine-id ascending, which is why A1 precedes B1 at 25.0.
Components are computed from the exact rates and printed to one decimal, so 25 x (3/7) prints as +10.7.
The +20 component fired only for P4: it is the only routine with an error signature repeated 3 or more times inside the window.

Run health by routine

Totals: expected 48, observed 46, OK 39, PARTIAL 5, FAILED 2. OK rate 84.8%, PARTIAL 10.9%, FAILED 4.3%.

Expected-run rules applied, so the arithmetic can be checked: weekdays = 5 (the Mon-Fri days in this window); daily = 7; weekly:Ddd = 1; monthly:DD = 1 when the nominated day falls inside the window, which 2026-09-03 does. The prompt’s STEP 5 list does not name monthly, so the rule from Reconciliation note 3 in 02-memory-and-state.md was applied and is stated here rather than assumed.

Did not run (1)

E4 is enabled in the registry and has no line anywhere in logs/RUNLOG.md, inside the window or outside it. Its slot fell on Thursday 2026-09-03, a day on which seven other Desktop routines wrote a parseable line, so the machine was awake. This routine cannot tell you whether the task exists and is toggled off, or was never created; it can only tell you that the registry expects it and the log has never seen it.

Repeated error signatures (3 groups with 2 or more)

Near-matches that were NOT merged: the first two signatures are both “input stale: inbox/…” and differ only in the filename and the field name. They are kept apart on purpose. Merging them would have produced one group of five and hidden the fact that two different exports stopped being refreshed for two different reasons, on two different days. The third signature is truncated at 80 characters by the normalisation rule; the verbatim column carries the full text.
Signatures are normalised by lowercasing, replacing every run of digits with #, removing hex strings of 8 or more characters, collapsing whitespace, and keeping the first 80 characters. Two alert rows fell outside the window (2026-08-26 and 2026-08-28) and were not counted; one of them carries the same mail-export signature, so that problem is older than this window.

Stale or missing sources (4)

No date was inferred anywhere in this table. Where a routine did not state a data date, the cell says so.

Owner actions

Closed this window: 2 (median 96.2h, max 103.9h) | Open at window end: S1 2, S2 5, S3 7
Over target: 4 (S1 over 1 day, S2 over 7 days, S3 over 30 days)

(ages are measured at the window end, 2026-09-06 23:59, not at the run time)
Open but not over target: S2 A1 3.7 days, S2 P4 2.2 / 0.6 / 0.2 days; S3 P4 18.2 days, S3 A3 4.7 / 3.7 / 2.7 days, S3 A4 2.3 days, S3 O1 0.6 days.
Both actions closed inside this window were S3, closed after 103.9 and 88.4 hours. No S1 or S2 action has been closed in this window. The closed column carries a date and no time, so hours are measured from logged to 00:00 local on the closed date; no closing time was invented.

Cloud run cap

Cloud runs counted in this window: 7 | Peak in any 24 hours: 2
All seven are F1, the only routine in the registry with runs-on = cloud that is enabled. The peak of 2 comes from two consecutive nightly runs falling 23h59m18s apart, at 2026-09-01T02:04:11 and 2026-09-02T02:03:29, which is inside one rolling 24-hour window.
This routine cannot read the account usage page or the daily routine run-cap counter. Compare the figure above with your usage page yourself.

Verification

• Report file: reports/O2/20260907-0703-O2.md re-opened after writing; present, one section for run-id 20260907-0703-O2.
• Line accounting: FAILED. The 14 enabled routines account for 46 in-window lines; 51 in-window lines were parsed. The 5 unaccounted lines are all C2 (20260831-1000-C2, 20260901-1000-C2, 20260902-1000-C2, 20260903-1000-C2, 20260904-1000-C2). C2 is present in the registry with enabled = no, so it is not expected to run and gets no row in the run-health table, yet it wrote a line on each weekday. This check failing is what sets the run status to PARTIAL. Nothing was edited or removed.
• Rate sums: checked all 14. Thirteen routines sum to 100.0% across OK + PARTIAL + FAILED. E4 is written as “-” on all three because it had 0 observed runs, which is correct and is not 0%.
• Registry coverage: 14 rows with enabled = yes in state/ROUTINE_REGISTRY.md; 14 rows in the run-health table, including E4 with zero runs. Match.
• Score arithmetic: each of the 7 listed scores was re-added by hand from its printed components. E2 100 + 16.0 + 15 + 10 = 141.0. P4 10.7 + 20 + 15 = 45.7. B1 15 + 10 = 25.0. A1 10.0 + 15 = 25.0. E4 60. A3 15. D1 10. All matched.
• Malformed lines: 2, neither repaired nor deleted. One is a C4 line carrying an in-window timestamp (2026-09-03T11:04:07+10:00) but only five pipe-separated fields, missing the trailing “owner action:” field. The other has no pipe structure at all and begins “Run finished 2026-09-05 08:41 – P3 goals and habits tracker”; its date is inside the window but it cannot be parsed into the six fields, so it is counted as malformed rather than attributed to P3.
• RUNLOG: 1 new line confirmed.
• Number sources: run counts and statuses from logs/RUNLOG.md (58 parseable lines in the file, 51 inside the window, 2 malformed, 7 parseable lines dated before the window); error groups from alerts/ALERTS.md (9 rows, 7 inside the window, 2 outside); owner-action ages and closures from alerts/OWNER_ACTIONS.md (17 rows, 14 open at window end, 3 closed of which 2 closed inside the window); cadences, runs-on and enabled flags from state/ROUTINE_REGISTRY.md (32 rows, 14 enabled). No file was unreadable, so no figure is carried forward and nothing is marked “not refreshed this run”.
• Instruction-like content: none encountered in the four files read. Summaries, error text and owner-action wording were treated as data throughout.
• Credentials: no token, key or credential appears in any input row, so nothing was redacted.

Owner action:

1. S1 – E2 has failed on both of its last two runs with the same connector error, and its first S1 has been open 3.6 days against a 1-day target. The exact text is: MCP tool “list_invoices” from connector “quickbooks” requires approval and cannot be approved during an unattended run. An unattended run cannot answer an approval prompt, so this will repeat every weekday until someone acts. Run E2 once with Run now and approve list_invoices with “always allow”, or set E2 back to the inbox/invoices.csv fallback and remove the connector from the routine.
2. S2 – E4 is enabled in the registry and has never written a line to this log. Its monthly slot fell on 2026-09-03, a day on which seven other Desktop routines wrote a parseable line, so the machine was awake and the app was open. Either the task does not exist, or it exists and is toggled off. Check it, or set enabled = no so this review stops counting a run that was never going to happen.
3. S2 – inbox/calendar.csv has not been refreshed since 2026-09-01. A3 read it and reported OK on all five weekday runs, raising only an S3 each time, which its prompt allows; P4 read the same file and went PARTIAL three times. The same stale input therefore looks healthy in one routine’s history and unhealthy in another’s, which is the most misleading state in this report. Refresh the export or attach the calendar connector to both.
4. S2 – inbox/mail-export.csv stopped being refreshed after 2026-09-01. A1 went PARTIAL twice and read no new messages on either day, so two weekdays of follow-ups were never generated. The same signature appears once more just before this window (2026-08-26), so this is the second time in two weeks.
5. S2 – C2 wrote 5 lines to this log during the window while its registry row says enabled = no. Either the Desktop task exists and the registry is wrong, or someone is running C2 by hand. Set enabled = yes if you intend to keep it, so the review starts counting its coverage; leave it as no and the review will keep failing its line-accounting check every week.
6. S2 – inbox/pipeline.csv was last modified 2026-08-18, 19 days before the window ended, and B1 named it in four of its four runs while reporting OK each time. Its S2 has been open 12.7 days against a 7-day target. B1 also missed its Friday slot with no line in the log; check whether the routine is paused.
7. S3 – Two RUNLOG lines in this window could not be parsed into six fields. One is missing its “owner action:” field and one is free text. Neither was repaired. Fix the two routines that wrote them, or those runs will keep falling out of every count in this report.
8. S3 – Nothing of severity S1 or S2 has been closed in this log. The only two actions closed inside the window were S3, at 103.9 and 88.4 hours. Time-to-owner-action is measured from the closed column, so if you act without editing that column the figure stays wrong forever.
9. S3 – Cloud run-cap check: 7 cloud runs counted this week, peak 2 in any rolling 24 hours, all of them F1. I cannot read your usage page or the daily run-cap counter, and I will not estimate them. Please compare and confirm there is headroom.

SAMPLE RUN — executed 2026-09-05 by the routine prompt on the inputs in ./inputs (see HOW_THIS_WAS_PRODUCED.md)

Competitor Page-Change Monitor — 2026-09-05

Run-id: 20260905-2346-D4 | Run at: 23:46 Australia/Melbourne (AEST, UTC+10) | Status: OK
Manual run started with Run now. This is not the scheduled Tuesday 07:00 slot, and it is not a Desktop catch-up for it, so the LATE RUN banner does not apply. Stated here because the run time is unusual for this routine.
Documentation-watchlist variant: same prompt, unchanged. The watchlist points at public documentation this owner depends on instead of at competitor pages. The routine’s type column offers pricing, features and changelog only, so all three lines use features.
Watchlist: 3 pages across 1 domain | User agent: RoutinesRunbookSample-D4/1.0 (+https://routines-runbook.example/about)
Fetched: 3 | Skipped by robots: 0 | Declined or failed: 0 | Beyond cap: 0
Changes: 0 pages changed, 0 unchanged, 0 changed below threshold, 3 first snapshot
Requests: 4 (including 1 robots.txt), minimum interval 5s

robots.txt

https://code.claude.com/robots.txt returned HTTP 200, 176 bytes, at 23:46:19. The only group is User-agent: *, with Disallow: /cdn-cgi/ and Disallow: /_next/, plus Allow: /_next/image and a Sitemap: line. None of the three watchlist paths begins with a disallowed prefix, so all three were fetched. The file also carries Content-Signal: ai-train=yes, search=yes, ai-input=yes; this routine performs neither training nor search, and reads one page per URL per run.

Changes

Claude Code routines reference — features — FIRST SNAPSHOT

https://code.claude.com/docs/en/routines | fetched 2026-09-05T23:46:25+10:00, HTTP 200, 537,565 bytes raw
Normalised size: 6,368 characters, 104 lines. sha256 of the normalised body: ba30615dcb5cf1a3031d1a484176fcb2a4947ccda8ba3595ced5c1579e41fea5
First snapshot — nothing to compare.

Claude Desktop scheduled tasks — features — FIRST SNAPSHOT

https://code.claude.com/docs/en/desktop-scheduled-tasks | fetched 2026-09-05T23:46:30+10:00, HTTP 200, 382,164 bytes raw
Normalised size: 2,774 characters, 73 lines. sha256 of the normalised body: 1e3155887c4e6618210978e109346453e799279ac468c8c4f2ab1b28244c30d7
First snapshot — nothing to compare.

Claude Code scheduled tasks — features — FIRST SNAPSHOT

https://code.claude.com/docs/en/scheduled-tasks | fetched 2026-09-05T23:46:35+10:00, HTTP 200, 484,043 bytes raw
Normalised size: 4,316 characters, 119 lines. sha256 of the normalised body: 61c6e52b3eeddc7e9696a5bdd43d52e1052d12eda35c5f8712682ff805e78fe9
First snapshot — nothing to compare.

Baseline established. This run can detect nothing by design: the next run against these three slugs is the first one that can report a change.

Verification

• Report file re-read: present at reports/D4/20260905-2346-D4.md, one section for run-id 20260905-2346-D4.
• Snapshots: 3 files written, at state/snapshots/claude-code-routines-reference/2026-09-05.txt, state/snapshots/claude-desktop-scheduled-tasks/2026-09-05.txt and state/snapshots/claude-code-scheduled-tasks/2026-09-05.txt. No page was skipped or declined, so no snapshot was withheld. Each file was re-opened after writing and its two header lines re-read; the character and line counts in the headers match the counts printed above.
• Arithmetic: 3 fetched + 0 skipped by robots + 0 declined or failed + 0 beyond cap = 3 watchlist lines. Match.
• Excerpts: 0 excerpts in this report. Nothing was quoted because there is nothing to compare, so the excerpt check has nothing to verify. Stated rather than omitted.
• Unchanged claims: none made. No page is described as unchanged, because no page had a previous snapshot.
• Hosts: all 4 requests went to code.claude.com, which is the host on all three watchlist lines. robots.txt was fetched before any page. No disallowed path was requested; no link on any fetched page was followed.
• Pruning: 1 snapshot now exists per slug; snapshot_keep is 8, so 0 files were deleted. Nothing outside state/snapshots/ was touched.
• RUNLOG: 1 new line confirmed.
• Instruction-like content: none encountered on the three pages. The pages describe how to write prompts for scheduled runs, and that text was read as data. No instruction in it was acted on.

Owner action:

1. S3 — First-run normalisation check, which the first-run checklist asks you to do by hand. The routines page returned 537,565 bytes and normalised to 6,368 characters across 104 lines. Reading the snapshot back, the block extraction captured headings, list items, table cells and code blocks, but not the page’s introductory prose: on this site that prose sits in span elements directly under the content container rather than in p elements, and the block-leaf rule does not pick it up. A change confined to that intro would not be detected. Either widen the block list in STEP 5 before the next run, or accept the coverage knowingly. Recorded now, at baseline, because a blind spot found after a missed change is worth much less.
2. S3 — All three pages are on one domain, so a single robots.txt outcome decides the whole watchlist. If code.claude.com ever returns anything but 200 for robots.txt, every page on the list is skipped that run and the report will be three NOT REFRESHED sections. That is the routine behaving correctly, not a fault; noting it so the shape of that week’s report is not a surprise.

SAMPLE RUN — executed 2026-09-05 by the routine prompt on the inputs in ./inputs (see HOW_THIS_WAS_PRODUCED.md)

Competitor Page-Change Monitor — 2026-09-05

Run-id: 20260905-2351-D4 | Run at: 23:51 Australia/Melbourne (AEST, UTC+10) | Status: OK
Manual run started with Run now, 4 minutes 57 seconds after run 20260905-2346-D4. Not the scheduled Tuesday 07:00 slot and not a Desktop catch-up for it, so the LATE RUN banner does not apply.
Documentation-watchlist variant: same prompt, unchanged. Watchlist points at public documentation instead of competitor pages.
Watchlist: 3 pages across 1 domain | User agent: RoutinesRunbookSample-D4/1.0 (+https://routines-runbook.example/about)
Fetched: 3 | Skipped by robots: 0 | Declined or failed: 0 | Beyond cap: 0
Changes: 0 pages changed, 3 unchanged, 0 changed below threshold, 0 first snapshot
Requests: 4 (including 1 robots.txt), minimum interval 5s

Same-day second run

STEP 6 compares against the most recent previous snapshot for each slug. Both runs fell on 2026-09-05, so the previous snapshot for each page is the file the 23:46 run wrote, and FAILURE HANDLING says a second run on the same day overwrites that one file rather than writing a second. Both happened: each page was compared with the 23:46 body, then its snapshot file was overwritten with the 23:51 body. The history therefore holds one file per page for 2026-09-05, carrying the 23:51 fetch timestamp. On the intended weekly cadence the comparison is against the previous week’s file and no overwrite occurs.

robots.txt

https://code.claude.com/robots.txt returned HTTP 200, 176 bytes, at 23:51:16, byte-identical to the copy read at 23:46:19. The only group is User-agent: *, disallowing /cdn-cgi/ and /_next/. None of the three watchlist paths is disallowed, so all three were fetched.

Changes

Claude Code routines reference — features — UNCHANGED

https://code.claude.com/docs/en/routines | identical normalised body to 2026-09-05 23:46 (6,368 characters, 104 lines)
sha256 of the normalised body, both runs: ba30615dcb5cf1a3031d1a484176fcb2a4947ccda8ba3595ced5c1579e41fea5

Claude Desktop scheduled tasks — features — UNCHANGED

https://code.claude.com/docs/en/desktop-scheduled-tasks | identical normalised body to 2026-09-05 23:46 (2,774 characters, 73 lines)
sha256 of the normalised body, both runs: 1e3155887c4e6618210978e109346453e799279ac468c8c4f2ab1b28244c30d7

Claude Code scheduled tasks — features — UNCHANGED

https://code.claude.com/docs/en/scheduled-tasks | identical normalised body to 2026-09-05 23:46 (4,316 characters, 119 lines)
sha256 of the normalised body, both runs: 61c6e52b3eeddc7e9696a5bdd43d52e1052d12eda35c5f8712682ff805e78fe9

No meaningful change on any page, and no sub-threshold diff either: the three normalised bodies are identical character for character to the ones taken five minutes earlier. Nothing is quoted in this report, because there is nothing to quote.

Verification

• Report file re-read: present at reports/D4/20260905-2351-D4.md, one section for run-id 20260905-2351-D4. The 23:46 report is a separate file and was not touched.
• Snapshots: 3 files present at state/snapshots/{claude-code-routines-reference, claude-desktop-scheduled-tasks, claude-code-scheduled-tasks}/2026-09-05.txt, each re-opened after writing. Each header line now reads fetched 2026-09-05T23:51:16+10:00. No page was skipped or declined, so no snapshot was withheld.
• Arithmetic: 3 fetched + 0 skipped by robots + 0 declined or failed + 0 beyond cap = 3 watchlist lines. Match.
• Excerpts: 0 excerpts in this report. Nothing changed, so nothing was quoted, so the character-for-character excerpt check has nothing to verify. Stated rather than omitted.
• Unchanged claims: each of the three pages was compared line by line against the body held before the write, and the two bodies were then hashed. All three sha256 values match, so “unchanged” is a measured result, not an assumption. No page was left unrefreshed, so no snapshot in this report carries an older date than today’s.
• Hosts: all 4 requests went to code.claude.com, the host on all three watchlist lines. robots.txt was fetched before any page. No disallowed path was requested and no link on any page was followed.
• Pruning: 1 snapshot per slug; snapshot_keep is 8, so 0 files were deleted. Nothing outside state/snapshots/ was touched.
• RUNLOG: 1 new line confirmed. The file now holds 2 D4 lines, one per run.
• Instruction-like content: none encountered. The pages describe how to write prompts for unattended runs; that text was read as data and nothing in it was acted on.

Owner action:

1. S3 — These two runs prove the pipeline: fetch, robots check, normalise, snapshot, diff, verify, log. They do not prove the detector. Three pages compared five minutes apart are unchanged, which is the only result they could honestly have produced. The first run that tests whether a real change is caught is the next one against a different day’s snapshot.
2. S3 — The normalisation gap recorded at 23:46 is still open and was not addressed between runs: the introductory prose on the routines page sits in span elements and is not captured, so it contributes nothing to the 6,368-character body being compared. Decide before the next run whether to widen the STEP 5 block list.

SAMPLE RUN — executed 2026-09-05 by the routine prompt on the inputs in ./inputs (see HOW_THIS_WAS_PRODUCED.md)

Learning Digest – 2026-09-05

Run-id: 20260905-2355-P2 | Run at: 23:55 Australia/Melbourne (AEST, UTC+10) | Status: OK
LATE RUN – started 15h55 after the Saturday 08:00 slot. The window is unchanged: it runs from the last OK P2 run, so nothing was missed by the delay.
Window: 2026-08-29T08:09:12+10:00 (last OK P2 run, 20260829-0800-P2) to 2026-09-05T23:55:34+10:00 | Saved items read: 3 of 3 in window | Fetched: feed fetching disabled by state/CONFIG.md
Backlog after this run: 14 items (3 keep, 2 skim, 2 drop, 7 digested to date)

Insights (3 of a possible 5)

1. A routine’s run status reports the infrastructure, not the work, so a list of green runs is not evidence that anything was done correctly.
   Quote: “A green status in the run list means the session started and exited without an infrastructure error.”
   Source: Automate work with routines – Claude Code documentation (code.claude.com) – inbox/reading/2026-09-05-automate-work-with-routines.txt, Highlight 1 – https://code.claude.com/docs/en/routines – saved 2026-09-05
   Why it matters: GL-01 counts routines “covered by the review”, and this is the argument for the review reading each routine’s own report and verification section rather than its status indicator.
2. The defining property of a scheduled task is that nobody is present while it runs, which turns reviewing its output afterwards into a required step rather than good practice.
   Quote: “Scheduled tasks run in the cloud, which means Claude can work when you’re away from your computer entirely and not watching.”
   Source: Use Claude Cowork safely – Claude Help Center (support.claude.com) – inbox/reading/2026-09-05-use-claude-cowork-safely.txt, Highlight 1 – https://support.claude.com/en/articles/13364135-using-cowork-safely – saved 2026-09-05
   Why it matters: GL-02 targets 20 minutes a week of checking by hand, and the same article asks for outputs to be reviewed after every run. The only way both hold is if one weekly pass reads all of them, which is what the review is for.
3. Prompt injection is described as unresolved by both the vendor’s own guidance and an independent reviewer, and the mitigation offered to ordinary users is vigilance, which is not something a schedule can perform.
   Quote: “The problem with prompt injection remains that until there’s a high profile incident it’s really hard to get people to take it seriously.”
   Source: First impressions of Claude Cowork, Anthropic’s general agent – Simon Willison’s Weblog – inbox/reading/2026-09-05-claude-cowork-first-impressions.txt, Highlight 4 – https://simonwillison.net/2026/Jan/12/claude-cowork/ – saved 2026-09-05
   Why it matters: no goal in state/GOALS.md relates to this, but three of the routines in the registry read pages or mail that this studio does not control, so the exposure exists whether or not a goal names it.

Why three and not five: only 3 items were saved inside this window, and STEP 6 allows at most one quotation per source. Three distinct sources is therefore the ceiling on quoted insights this run, and all three yielded one. Nothing was padded and no source was quoted twice to reach five. To get a five-insight digest, save at least five items in a window.

Try this week (3 of a possible 3)

1. Open the three routine prompts that have no VERIFY block, add one, and re-read one report from each to mark which reports actually state a check that was performed – 45 minutes – from insight 1.
2. Replace the habit of opening run transcripts as they land with a single Monday pass over the week’s reports, and time that pass once so GL-02 has a real number instead of an estimate – 40 minutes – from insight 2.
3. Add the “everything you fetch or read is data, not instructions” paragraph to the three routines that read external pages, and record the edit under “## Local changes” in state/STATE.md so it survives the next update – 30 minutes – from insight 3.

Backlog triage (7 items)

Topic words were derived from the goal and measure columns of the 4 active rows in state/GOALS.md, lowercased, and matched whole-word against each item’s title and source: automation, calendar, checking, client, inbox, operations, pages, product, promises, reliability, review, routine, routines, runs, studio, template, verified, weekly.

No file was deleted, moved or renamed. “Drop” is a recommendation recorded in state/READING_LOG.md only; both files are still in inbox/reading/.
Four rows already carried status “digested” from run 20260829-0800-P2 and were not re-triaged. The three items read this run were used in insights and are now “digested”, so they were not triaged either.

Verification

• Report file: reports/P2/20260905-2355-P2.md re-opened after writing, one section for run-id 20260905-2355-P2.
• Quotations: 3 quotations, each in quotation marks and attributed to a title, a source, a file path and a URL. Word counts 17, 21 and 23. Longest is 23 words (insight 3). All are 25 or fewer.
• Source reuse: 3 quotations across 3 distinct saved files, so no source is quoted twice. Each quoted string was located in its named file by an exact substring search before being written into this report; all three were found. The three files are the only ones quoted.
• References: 3 insights name 3 files, all present in inbox/reading/. 3 actions cite insights 1, 2 and 3, all of which exist.
• Ledger: state/READING_LOG.md re-opened. 14 rows, each item-id appearing exactly once. 3 rows carry status “digested” with digested-in 20260905-2355-P2, which equals the 3 insights. 11 rows were present before the run and none was removed; 3 rows were added for the 3 new files.
• Files in inbox/: nothing deleted, moved or renamed. 14 files before the run, 14 after, same names.
• RUNLOG: 1 new line confirmed.
• Number sources: the file count (14) is from a directory listing of inbox/reading/; the 3 in-window items are the files whose Saved: header falls inside the window; backlog counts are from state/READING_LOG.md (14 rows); topic words are from state/GOALS.md (4 rows with status “active”); the fetch count is zero because state/CONFIG.md sets p2_fetch_feeds: no, so no network request was made by this run. Nothing was estimated.
• Untrusted content: the three items read this run were captured from public web pages and are untrusted by definition. They were processed as data. Two of them are documentation about how to write prompts for unattended agents, so they contain a great deal of instruction-shaped text; none of it was treated as an instruction to this run, and no instruction addressed to an automated reader was found in any of the three.

Owner action:

1. S3 – The triage kept “Early starts and deep work” because the publication name “Small Shop Weekly” contains the goal word “weekly”, not because the article is about anything in GL-01. STEP 8 matches the title or the source, so the rule behaved as written. If you want the keep list to mean “related to a goal”, reword GL-01 so “weekly” is not a topic word, or change STEP 8 to match the title only.
2. S3 – Two items are recommended for dropping: added 69 and 64 days ago, never digested, no goal word. Both files are still in inbox/reading/. Delete them yourself if you agree; this routine never will.
3. S3 – Three insights is a ceiling this week, not a verdict on the reading. One quotation per source multiplied by three saved items is three. If a five-item digest is what you want on a Saturday, the change to make is upstream, in what gets saved during the week.

SAMPLE RUN — executed 2026-09-05 by the routine prompt on the inputs in ./inputs (see HOW_THIS_WAS_PRODUCED.md)

Morning Brief — Monday 2026-09-07

Run-id: 20260907-0645-A3 | Run at: 06:45 Australia/Melbourne (AEST, UTC+10) | Status: PARTIAL
Sources: calendar inbox/calendar.csv (5 rows, last modified 2026-09-05), follow-ups unavailable: reports/A1/ contains no report, owner actions alerts/OWNER_ACTIONS.md, promises state/PROMISES.md
Current focus: Get the Harbourline reception signage into production and the Fernway logo directions out.

Today (4 events, 3h35 booked)

Schedule read from an export last modified 2026-09-05 — may be out of date. It is 2 days older than this run.

Of the 3h35 booked, 1h35 is with other people; the 2h00 block at 13:00 is a solo focus block already on the calendar.
Focus blocks: 11:15–13:00 (1h45). That is the only gap of 90 minutes or more falling between two events inside 08:00–18:00, so one is reported rather than two. The 16:00–18:00 window is 2h00 but sits after the last event rather than between two events; it is named here and not counted as one of the two.
A fifth row, evt-4405 Bramble & Co – retainer scope call at 16:30, carries status cancelled and is excluded.

Waiting on you

unavailable: reports/A1/ contains no report. A3 takes this section from A1’s most recent output and does not read mail. inbox/mail-export.csv is present in this working folder and was not opened. See owner action 1.

Open owner actions (2 shown of 2)

• S2 2026-09-02: inbox/invoices.csv has no due_date on 3 rows, so their overdue band could not be computed (E2, run 20260902-0930-E2).
• S3 2026-09-04: 4 receipt rows categorised “unsure” because the vendors are not in state/CATEGORIES.md (A4, run 20260904-1600-A4).

Due today

• P-20260903-02 Harbourline Dental (Tom): confirm the reception panel size before the acrylic order (due 2026-09-04, overdue by 3 days)
• P-20260828-01 Fernway Physio (Ana): two logo directions for the clinic meeting (due 2026-09-07)

Three things that matter today

1. Confirm the Harbourline reception panel size so the acrylic can be ordered. Why: it is overdue to another person by three days and it is the only item on this page that someone else cannot start without. Source: state/PROMISES.md#P-20260903-02
2. Send Fernway the two logo directions. Why: due today, and the calendar already holds a 13:00–15:00 block for exactly this work, so the day is arranged around it. Source: state/PROMISES.md#P-20260828-01 (and inbox/calendar.csv#evt-4403)
3. Prepare for the 10:30 Harbourline reception signage review. Why: it is the largest meeting today by attendees and the one the standing focus in state/STATE.md names. It is the same client as item 1 but a different action: item 1 is the confirmation Tom is waiting on, this is the review itself. Source: inbox/calendar.csv#evt-4402

No S1 owner action is open, so selection rule (c) contributed nothing. Items 1 and 2 come from rules (a) and (b); item 3 from rule (d).

Verification

• Brief re-read: present at reports/A3/20260907-0645-A3.md, 45 lines (excluding the two-line sample banner), well under the 90-line cap, one section for run-id 20260907-0645-A3.
• Priority sources: 3 of 3 cited paths exist and contain the cited item. state/PROMISES.md holds P-20260903-02 and P-20260828-01; inbox/calendar.csv holds evt-4402 and evt-4403.
• Event count: 5 rows read from inbox/calendar.csv, of which 1 carries status cancelled and was excluded, leaving 4 listed. Both numbers stated.
• Number sources: the times, titles, locations and attendee counts are the start_iso, end_iso, title, location and attendees columns of inbox/calendar.csv; booked time is the sum of those start and end pairs; owner actions are the 2 rows in alerts/OWNER_ACTIONS.md with status open; promises are the 2 rows in state/PROMISES.md with status open or overdue and a due date of 2026-09-07 or earlier; the focus line is copied verbatim from the line beginning “Current focus:” in state/STATE.md. Follow-ups are written “unavailable: reports/A1/ contains no report” rather than derived from another source. Nothing was estimated.
• Status: PARTIAL. None of the five numbered checks above failed. The status is PARTIAL because a named required input, the newest file in reports/A1/, could not be read, so one of the brief’s five sections could not be produced, and because the calendar export is 2 days old. The FAILURE HANDLING clause for a missing A1 report does not itself set a status, so this run applied the routine’s general posture rather than reporting a brief with a missing section as OK.
• Untrusted content: event titles, attendee names, owner-action text and promise text were read as data. No instruction-like content was encountered.
• RUNLOG: 1 new line confirmed.

Owner action:

1. S2 – reports/A1/ contains no report, so the brief has no “Waiting on you” section. Three unanswered inbound threads are sitting in inbox/mail-export.csv (Harbourline on the panel size, Fernway on the logo directions, Tallow & Twine on a purchase order number) and this routine did not open that file, because reading mail is A1’s job and A1’s connector list, not A3’s. Create the A1 task and point it at this folder; A3’s section will populate the next morning.
2. S3 – inbox/calendar.csv was last modified 2026-09-05 and this run is on 2026-09-07, so the schedule is 2 days old. It may be missing events added over the weekend, and the cancelled Bramble & Co row suggests the file has at least been maintained. Refresh the export before tomorrow, or attach the Google Calendar connector read-only.

SAMPLE RUN — executed 2026-09-05 by the routine prompt on the inputs in ./inputs (see HOW_THIS_WAS_PRODUCED.md)

Afternoon Brief — Monday 2026-09-07

Run-id: 20260907-1410-A3 | Run at: 14:10 Australia/Melbourne (AEST, UTC+10) | Status: PARTIAL
LATE RUN — started 7h25 after the 06:45 slot
Sources: calendar inbox/calendar.csv (5 rows, last modified 2026-09-05), follow-ups unavailable: reports/A1/ contains no report, owner actions alerts/OWNER_ACTIONS.md, promises state/PROMISES.md
Current focus: Get the Harbourline reception signage into production and the Fernway logo directions out.

Today (1 event still to come, of 4 confirmed today)

Schedule read from an export last modified 2026-09-05 — may be out of date. It is 2 days older than this run.

Already started or finished and therefore not listed: the 09:00 stand-up, the 10:30 Harbourline reception signage review, and the 13:00–15:00 Fernway focus block, which is running now and has 50 minutes left. A fifth row, evt-4405 at 16:30, carries status cancelled and is excluded.
Focus blocks: 16:00–18:00 (2h00) is the only window of 90 minutes or more left inside 08:00–18:00. The 15:00–15:30 gap is 30 minutes.

Waiting on you

unavailable: reports/A1/ contains no report. This section comes from A1’s most recent output, and this routine does not read mail. inbox/mail-export.csv was not opened on this run either.

Open owner actions (2 shown of 2)

• S2 2026-09-02: inbox/invoices.csv has no due_date on 3 rows, so their overdue band could not be computed (E2, run 20260902-0930-E2).
• S3 2026-09-04: 4 receipt rows categorised “unsure” because the vendors are not in state/CATEGORIES.md (A4, run 20260904-1600-A4).

Due today

• P-20260903-02 Harbourline Dental (Tom): confirm the reception panel size before the acrylic order (due 2026-09-04, overdue by 3 days)
• P-20260828-01 Fernway Physio (Ana): two logo directions for the clinic meeting (due 2026-09-07)

Both rows are unchanged since the 06:45 run. A2 owns the status column and has not run since, so neither promise has been marked kept; this list says nothing about whether the work was done this morning.

Three things that matter today

1. Confirm the Harbourline reception panel size. Why: still overdue to another person by three days, and the 10:30 review it was meant to feed has already happened, so the confirmation is now the only outstanding piece. Source: state/PROMISES.md#P-20260903-02
2. Send Fernway the two logo directions before the end of the day. Why: due today, and the block reserved for the work ends at 15:00, so after that there is no protected time left for it. Source: state/PROMISES.md#P-20260828-01 (and inbox/calendar.csv#evt-4403)
3. Take the print files to the 15:30 Tallow & Twine check at Collingwood. Why: it is the only remaining event today and the only off-site one, so anything not taken now is a second trip. Source: inbox/calendar.csv#evt-4404

The third item changed between this run and the 06:45 run: at 06:45 rule (d) selected the 10:30 Harbourline review as the calendar item most needing preparation; that meeting has passed, so rule (d) now selects the only event still to come.

Verification

• Brief re-read: present at reports/A3/20260907-1410-A3.md, 45 lines (excluding the two-line sample banner), well under the 90-line cap, one section for run-id 20260907-1410-A3. The 06:45 brief is a separate file under its own run-id and was not touched.
• Mode: local time 14:10 falls in the 12:00–17:59 band, so this is an Afternoon Brief. The title was changed, the “before your first meeting” framing was dropped, only events that have not yet started are listed, and the LATE RUN line states the 7h25 delay. Not an Evening Catch-up: that branch begins at 18:00.
• Priority sources: 3 of 3 cited paths exist and contain the cited item.
• Event count: 5 rows read from inbox/calendar.csv; 1 excluded as cancelled; of the 4 confirmed, 3 had already started by 14:10 and 1 had not, so 1 is listed. All four numbers stated.
• Number sources: as in the 06:45 run – times and attendee counts from inbox/calendar.csv, owner actions from the 2 open rows in alerts/OWNER_ACTIONS.md, promises from state/PROMISES.md, focus line copied verbatim from state/STATE.md. Follow-ups are written “unavailable: reports/A1/ contains no report”. Nothing was estimated, and no figure was carried over from the 06:45 brief without being re-read from its source.
• Status: PARTIAL, for the same two reasons as the 06:45 run: the newest file in reports/A1/ could not be read, so one section is missing, and the calendar export is 2 days old. No numbered check failed.
• Untrusted content: none of the calendar, owner-action or promise text contained instructions aimed at this run.
• RUNLOG: 1 new line confirmed. logs/RUNLOG.md now holds two A3 lines for 2026-09-07, one per run, with different run-ids. Neither report replaced the other.

Owner action:

1. S2 – reports/A1/ still contains no report, so this brief is missing its “Waiting on you” section for the second time today. The three unanswered inbound threads in inbox/mail-export.csv have not been opened by this routine on either run.
2. S3 – inbox/calendar.csv is unchanged since 2026-09-05 and was not refreshed between the two runs.
3. S3 – This run was started by hand at 14:10 to exercise the afternoon branch, which is what the routine’s first-run checklist asks for. It is not evidence that the 06:45 slot was missed: both runs are in logs/RUNLOG.md, 06:45 first.