Build a demand event forecast for {BRAND} using the BooleanMaths MCP.
DATA
1. list_projects to resolve the projectId.
2. get_mmm_dataset, granularity=week, userTimezone=Asia/Kolkata. Pull in
   52-week chunks — longer windows time out. Go back as far as data exists.
   Drop is_partial rows and zero-revenue weeks. State where history starts
   and how many complete annual cycles that gives me.
3. get_discount_analytics across the same period.
FIND THE EVENTS — do not assume which ones matter
4. Fit a baseline: log(revenue) ~ log(adstocked spend) + trend, on all weeks.
   Iterate: flag outlier weeks, refit excluding them, repeat until stable.
   Report the residual SD — lifts inside 1.5 SD are noise, not events.
5. Rank EVERY flagged week by lift, high and low. Do not pre-filter to
   holidays. Sale weeks, payday cycles, marketplace events, brand
   anniversaries, clearance and unexplained spikes all count. Troughs matter
   too - they show where demand or spend went missing.
6. Classify each event by its AOV signature:
   - orders lift > revenue lift  -> discount-led, volume event
   - revenue lift > orders lift  -> occasion or gifting event
   - both flat, spend down       -> self-inflicted, not a market event
   Cross-check the discount data to separate the brand's own promos from
   calendar demand. Tell me which is which.
7. Only now web-search the exact dates of the relevant calendar events for
   the next 12 months, and ask me for {BRAND}'s planned sale calendar.
   Lunar and religious dates shift year to year — check whether the shift
   moves an event into a different ISO week, or compresses the gap between
   two events.
SIZE THEM
8. Per event: peak week, and uplift vs T-1, T-3 and T-4. Flag any baseline
   week distorted by a spend change rather than real demand.
9. Segment the catalogue yourself before doing SKU work. Pull product
   metadata and derive 3-5 segments from whatever attributes actually
   differentiate this brand's range — price band, pack size, single vs
   multipack or bundle, product line, margin tier. Test which segmentation
   separates event lift most cleanly and use that one. Report lift by
   segment, not per SKU: individual SKU deltas are mostly launch and
   ad-rotation noise.
10. Build the requirement off the last-30-day run rate, apply segment
    multipliers per event, reconcile bottom-up to the top-down forecast.
OUTPUT
11. Weekly forecast table, event ranking table, and a unit requirement for
    the top 10 SKUs across each major event window.
12. Then a standalone responsive HTML report, branded to {BRAND} with
    BooleanMaths as preparer. No CDN dependencies — inline SVG/CSS charts
    only. Section 1: all events ranked, prior-year actual vs forecast.
    Section 2: per-event detail behind a dropdown.
Tell me what the data can't support rather than filling gaps with assumptions.