# 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.