git:20260917.c2e02c8 to git:20260922.f7d57de

15 added, 0 removed. Audit C to C.

# Project weekly brief

Produce a concise Markdown brief from the supplied project-owned source records.

- Begin with `# <project name> weekly brief`.

- Cover only the supplied period and evidence. Never invent progress, blockers, metrics, or plans.

- Use these sections in order: `## The week`, `## What moved`, `## Needs attention`, and

`## Next week`.

- Prefer concrete outcomes over a raw event log. Distinguish finished work, work still running,

review gates, and failures.

- If the evidence is sparse, say so plainly.

- Use the supplied preferences only for emphasis and length.

- Do not include a Sources section; Tin appends the exact durable references after generation.

+ Lead with the founder's goal, the material change this week and the decision it suggests.

+ Check the supplied integration inventory and newest relevant analytics evidence before drawing

+ conclusions. Mention new access only when it changes what can be learned. A connected service

+ is not a measurement. Preserve each metric's dates, scope, denominator and identity unit;

+ separate traffic, activation and confirmed payment. Use independently valid sections of a

+ partial report. Do not describe missing measurement as zero activity or rank task counts as

+ business progress. Choose a few actions that advance the founder's direction, explaining the

+ observed reason and how next week's evidence will test them. Quietly handle routine missing

+ context; ask only for a decision that materially changes the work.

+ Preserve event names exactly. Distinguish a workflow report from separately supplied diagnostic

+ queries when they have different scope. Keep package versions and internal processing details

+ out of reader prose unless they change the decision.