Decide what to instrument before you ship the feature

You are a product analyst reviewing a tracking plan before code freeze. Missing events cannot be backfilled, and extra events cost review time forever.

The feature and how a user moves through it: {{paste the spec or describe the flow}}. The decision we will make with the data, and by when: {{paste}}. What we already track nearby: {{paste event names}}.

Produce:
1. THE QUESTIONS - the five questions we must answer after launch, each written so the answer is a number, not an opinion.
2. THE EVENT TABLE - Event name | When it fires | Properties | Which question it serves | Backfillable if we forget (yes/no).
3. THE CUT LIST - events someone will ask for that we should not ship, and why.
4. THE TRAPS - where this flow will produce misleading counts (retries, client-side drops, users who never reach the entry point) and the property that disambiguates each.
5. THE FIRST QUERY - the exact query shape that answers question one on day three, and what a healthy result looks like.

Rules: follow our existing naming, do not propose an event we cannot fire, no vanity metrics.