Circus of Puffins

# Approval: db/schema.rb is drifted from migrations — pick a fix approach

**Filed:** 2026-05-24 21:30 UTC
**Agent:** measure-ta
**Expires:** 2026-05-26 21:30 UTC (48h — test correctness, not customer-impacting)

## TL;DR

`db/schema.rb` on `Turbo-Puffin/measure@main` claims to be at version `2026_05_22_000001` but is missing the tables created by 3 migrations and the columns added by ~4 more, committed between 2026-02-07 and 2026-05-22. The drift has been silent for ~3 months because no test on `main` currently exercises the missing tables. The MCP `list_sites` PR (#50) is the first new test to do so, and its CI `test` job now fails with `PG::UndefinedTable: ERROR: relation "api_keys" does not exist`.

Production is fine. Railway runs `db:migrate`, so the deployed Postgres has all the tables. Only CI's test database — which is built from `db/schema.rb` via `db:schema:load` — is broken.

## What's missing from db/schema.rb

Tables not present:
- `api_keys` (created by `20260226000001`)
- `agent_checkins` (created by `20260226000002`)
- `live_events` (created by `20260418000001`)

Columns not present:
- `daily_stats.human_views`, `agent_views`, `bot_views`, `top_pages_agents` (from `20260214181357` / `20260418000001`)
- `hourly_stats.human_views`, `agent_views`, `bot_views` (from `20260418000001`)
- Probably more from `20260207031415_make_clerk_id_optional.rb`, `20260215015206_create_waitlist_entries.rb`, `20260313000001_add_data_layer_stats.rb`, and `20260522000001_add_lifetime_plan_and_reprice_pro.rb` — not enumerated, will be visible after schema dump.

## Fix options

### A. Regenerate schema.rb from a clean migration run (recommended)

Spin up a fresh Postgres locally (or use Docker), run `bin/rails db:create db:migrate`, then `bin/rails db:schema:dump`. Commit the resulting `db/schema.rb`. This is the canonical Rails approach — schema dump is authoritative.

Cost: ~15 min of TA cycle to install Ruby 3.4.6 + Postgres + bundle install on this box (I had to standalone-install rubocop earlier because the full bundle is heavy; I'll need to bite that bullet for this).

### B. Switch CI to use `db:migrate` instead of `db:schema:load`

One-line change in `.github/workflows/ci.yml` (or wherever test DB is prepared). Workaround that ignores the drift. Test DB always built from migrations.

Risk: slower CI; doesn't fix the underlying drift; future devs running `bin/rails db:reset` locally still get a wrong schema.

### C. Hand-edit schema.rb

Reconstruct the missing tables/columns from the migration files by hand. Deterministic but error-prone — one mistyped index and we get a subtle bug three weeks from now. **Not recommending.**

### D. A + add a CI guard

Same as A, but additionally add a CI step that runs `git diff --exit-code db/schema.rb` after `bin/rails db:migrate` to fail any PR that introduces drift. Prevents this from recurring. **My actual recommendation.**

## Default action (if no response by 2026-05-26 21:30 UTC)

I will execute **option A** (regenerate schema, no CI guard). Reasoning:
- Lowest risk fix that addresses root cause.
- The CI guard (option D) is preferable but adds workflow risk if I get it wrong — better as a follow-up PR with explicit Matt approval.
- I'll open the PR titled `chore: regenerate db/schema.rb — bring in 3 months of migration drift`, merge under charter authority if CI green (no billing/auth/schema-change in customer sense — this is schema dump file maintenance).

## Risks of executing this default

- Regenerated schema may add columns/indexes I don't yet know about. PR diff will show everything. Matt or PO can review before I merge.
- Production is unaffected by this PR (Railway uses migrations, not schema.rb). Zero deploy risk.
- If anyone has been working *around* the missing tables in tests (e.g. mocking models), regenerating schema may surface latent bugs in those tests. I'll watch for new failures.

## What this blocks

- MCP merge backlog (PR #50, #51) — PO's P1.
- Any future PR that adds tests touching `api_keys`, `agent_checkins`, `live_events`, or the missing `daily_stats`/`hourly_stats` columns.

## What this does NOT block

- The stale-pricing string sweep (PO's P2) — pure view-file edits.
- Dependabot merges — they don't add tests against the missing tables.
- Production / customers. Schema is correct on Railway.

# Approval: ~~Production deploy broken on main~~ — SUPERSEDED 2026-05-24 21:00 UTC

**Filed:** 2026-05-24 18:00 UTC
**Superseded:** 2026-05-24 21:00 UTC (see "Update" below)
**Agent:** measure-ta
**Expires:** 2026-05-25 18:00 UTC

## Update — 2026-05-24 21:00 UTC

**This was misdiagnosed. Production is fine.** Closing the P0 ask; opening a P3 cleanup ask in its place.

measure-po's `queue/tech-architect-pending/po-2026-05-24-1850-production-is-on-railway-not-kamal.md` flagged that `lets.measure.events` is served by Railway (region `europe-west4-drams3a`), not by the Kamal target I was watching. I verified:

- `curl -sSI https://lets.measure.events/pricing` returns `server: railway-edge`, `x-railway-edge: railway/europe-west4-drams3a`.
- `lets.measure.events/pricing` HTML contains `$19` and `$999` — i.e. it has commit `37fcbd3` (Lifetime plan) and `7ab1836` ($9→$19), both from ~3 weeks ago. Railway is up-to-date with `main`.
- Repo contains **no** `railway.toml` / `.railway/` / Railway-named config — Railway auto-deploy is wired in the Railway dashboard (out-of-repo), pointing at `Turbo-Puffin/measure@main`.
- Solid Queue workers run in-process via `config/recurring.yml` and the existing Rails Solid Queue gem — same Railway deploy, no separate worker host.

So: **the `.github/workflows/deploy.yml` Kamal step has been failing for weeks while production has continued shipping fine via Railway.** The Kamal config in the repo (`.kamal/secrets`, `Dockerfile`, the `Deploy` workflow) is vestigial — most likely a migration leftover from before the Railway move. Not a P0 incident, not blocking customer code.

### Revised ask (P3 cleanup, not P0 incident)

Matt: do you want me to:
- **A) Delete `.github/workflows/deploy.yml` + `.kamal/` directory + `Dockerfile`** (if Railway uses Nixpacks or a builder that doesn't need our Dockerfile). Clean — no more failing checks, no more dead code.
- **B) Keep Kamal as backup/staging** but fix the SSH credentials so the workflow goes green. (Why? If Railway ever de-platforms us, having a working alt deploy is good. But the host has been unreachable for weeks anyway, so this is bit-rotted in practice.)
- **C) Replace with a real Railway action** so we have an in-repo deploy step that mirrors Railway's auto-deploy (e.g. for explicit-version pinning or rollbacks).

### Default action (if no response by 2026-05-25 18:00 UTC)

I will go with **option A (delete the dead Kamal config)** but:
1. Keep `Dockerfile` (it's standard Rails; Railway Nixpacks aside, it's not harmful and may be used). Only remove the `.kamal/` directory and `.github/workflows/deploy.yml`.
2. Open a PR titled `chore: remove dead Kamal deploy config — production is on Railway`.
3. Merge under charter authority (not a billing/auth touch, not a schema change, not a major-version bump).

This is non-destructive to production. If A turns out to be wrong, the config is recoverable from git history.

### Charter correction

My TA charter (`~/.claude/agents/ta.md`) said "Deploy: hosted on Railway (same pattern as Helm)". That is in fact **correct** — and my initial review wrongly flagged it as drift. The charter was right; the repo had stale Kamal scaffolding misleading me. Not amending the charter.

---

## Original P0 ask (now obsolete — Railway is up, customers are fine)

Every Deploy run on `Turbo-Puffin/measure@main` since at least 2026-05-22 fails with `Net::SSH::ConnectionTimeout` to host `18.118.109.39`. CI passes; only Kamal deploy fails. ~5 commits have landed since the last good deploy — production is running stale code (last known config: pre-$9→$19 price change, pre-lifetime-plan rollout).

(This second sentence was wrong: production was up-to-date the whole time, just via Railway not the Kamal target I was watching.)

### Original "default action" (now obsolete — do NOT execute)

I will:
1. Open an issue on `Turbo-Puffin/measure` titled "P0: production deploy SSH timeout — last good deploy unknown" with the failed-run logs.
2. Block any further merges to main until deploy is green (post comment on each open PR + add `do-not-merge` label).
3. Re-run latest Deploy workflow once more to confirm it's not transient.
4. Drop a follow-up in `queue/escalations/` if still failing.

**Cancelling these.** Steps 2 and 3 were predicated on customer impact that does not exist.

## Context

- Failed run example: https://github.com/Turbo-Puffin/measure/actions/runs/26294184955
- Full review: `specs/2026-05-24-ta-initial-review.md`
- PO's correction handoff: `queue/tech-architect-pending/po-2026-05-24-1850-production-is-on-railway-not-kamal.md`

# Approval: incomplete pricing rollout — authorise a sweep

**Filed:** 2026-05-24 19:10 UTC
**Agent:** measure-po
**Expires:** 2026-05-26 18:00 UTC (~2 days — sales-funnel issue, degrades
the longer it sits)

## Ask

The recent pricing change (Monthly $9 → $19, commits 7ab1836 + 567830e
~3 weeks ago) and the Lifetime $999 launch (commit 37fcbd3 ~3 weeks ago)
appear to have **only updated the pricing page**. Every other surface I
grep'd still quotes the **old `$29/mo`** number, including all five
trial-nurture emails and both `llms.txt` files. Specifically:

**Rails app (`Turbo-Puffin/measure@main`):**
- `app/views/user_mailer/trial_started.{html,text}.erb`
- `app/views/user_mailer/trial_day7.{html,text}.erb`
- `app/views/user_mailer/trial_day12.{html,text}.erb`
- `app/views/user_mailer/trial_end.html.erb`
- `app/views/user_mailer/trial_final_nudge.html.erb`
- `app/views/waitlist/show.html.erb`
- `public/llms.txt`

**Astro marketing site (`measure.events`):**
- Meta description, schema.org JSON-LD, homepage final CTA, `/features`
  page, `llms.txt`. **All show `$29/mo`. None mention the Lifetime plan.**

(For reference, the Rails pricing page at `lets.measure.events/pricing`
correctly shows `$19/month` + `$999 Lifetime`. Stripe checkout
presumably matches but I cannot verify per charter.)

Net effect: someone who lands on measure.events sees $29 → signs up →
gets trial-day-12 email quoting $29 → clicks through to a $19 + $999
checkout. Inconsistent on every touchpoint.

### What I'd like to do

1. Hand the Rails-side fix to measure-ta (handoff already filed at
   `queue/tech-architect-pending/po-2026-05-24-1910-stale-pricing-strings.md`).
   Roughly 11 files / ~15 lines.
2. Update the Astro marketing site to match — but **I don't know which
   repo it lives in.** None of `Turbo-Puffin/measure-marketing`,
   `-measure`, `-turbopuffin-com`, or any other org repo I can see
   contains it. Either it lives in a private repo I can't list, in your
   personal GitHub, or somewhere I'm not looking. **Need you to point
   me / TA at the right repo.**
3. Possibly add a small CI regression guard so the next price change
   doesn't leave the same trail (TA's call whether it's worth the
   complexity).

### Three things I want a yes/no on

1. **Authorise the Rails sweep** (TA executes, ~15 lines changed)?
2. **Where does the Astro marketing site live?** (one-line answer is fine.)
3. **Was the $29 messaging intentional** for any cohort (grandfathered
   pricing, A/B test, segment-specific nurture sequence)? If yes, this
   approval is moot and I'll back off.

## Default action (if no response by 2026-05-26 18:00 UTC)

Assume #3 is "no, it was an incomplete rollout." Proceed with:

- TA executes the Rails-side sweep as filed in the handoff.
- I file a follow-up approval asking only "where does the Astro repo
  live?" without any other ask, so it's a 1-question reply.
- I tell marketing to hold the HN drop (angle #2 in their 2-week plan)
  until both surfaces are aligned.

I will NOT change the *price* anywhere — only the displayed strings.

## Why this is worth interrupting you

Measure is selling at $19 + $999 but advertising at $29. That's not just
a copy bug; it's a funnel telling visitors a different story than the
checkout. Marketing wants to do a Show HN drop next week, and a top
comment catching this is the worst-case opener.

## Context

- Pricing-page-only commits: 7ab1836, 567830e, d2a3aee, 1842ab4, ec4e3c2
- Lifetime launch commit: 37fcbd3 (Merge PR #52)
- Marketing 2-week plan: `specs/marketing-2-week-plan.md`
- Roadmap entry being added under "This week" with this approval as the
  gating signal.

# Approval: marketing-surface strategy

**From:** measure-marketing
**Filed:** 2026-05-24 20:00 UTC
**Updated:** 2026-05-24 20:30 UTC (see "Update" at bottom — half of this is already resolved)
**Expiry:** 2026-05-27 20:00 UTC (72h)

## Ask

Where should Measure's public marketing copy live? The charter says `Turbo-Puffin/measure-marketing` (Astro site at `measure.events`) but that repo doesn't exist, and `lets.measure.events` has no public homepage — `config/routes.rb` does `root "dashboard#show"`. The only public-facing page on the property today is the waitlist (`/sign-up`), and it doesn't mention MCP.

Three concrete options:

1. **Rewrite the waitlist page as the de facto marketing page.** Cheapest. Lives in the existing `Turbo-Puffin/measure` Rails repo. Draft copy ready at `specs/waitlist-mcp-rewrite.md`. Constraint: prospects who type `lets.measure.events` get sign-in, not marketing.
2. **Stand up `Turbo-Puffin/measure-marketing` (Astro) on the bare `measure.events` domain.** Matches charter. New repo, new deploy, ~1 week of plumbing before any copy ships. Cleanly separates marketing from app.
3. **Add a public landing page to the main Rails app, then route unauthenticated `/` to it.** Middle path. New `pages#home` action + view, one routes change. ~1 day of work; lives next to the app it's marketing.

## Recommendation

**Option 1 this week, then Option 3 next week** if conversion data warrants it. Option 2 is the "right" long-term answer but the work to spin up an Astro site competes with shipping content; we can do it after the HN launch validates demand.

## Default action if no reply by expiry

Proceed with **Option 1**: cut the waitlist copy rewrite (specs/waitlist-mcp-rewrite.md) as a PR to `Turbo-Puffin/measure`, hand to TA for review, and ship once green. Will not touch routes or add new pages without explicit approval.

## Why this needs Matt

Touches positioning across the whole property and commits us to a marketing-surface architecture. Also: the charter pointer is stale (no `measure-marketing` repo exists), and that's worth correcting at the same time.

## Related

- `specs/marketing-2-week-plan.md` (updated this cycle)
- `specs/waitlist-mcp-rewrite.md` (draft copy)
- PO bootstrap log noted a recent $9→$19 + Lifetime $999 pricing change; waitlist still shows $29/mo — handoff to PO for resolution (`queue/po-pending/marketing-2026-05-24-pricing-and-surfaces.md`)

---

## Update — 2026-05-24 20:30 UTC

PO's 19:10 work cycle (`queue/marketing-pending/po-2026-05-24-1810-mcp-visibility-answer.md`) landed on this branch right after I filed the original ask. It changes the picture:

- **`measure.events` (bare domain) already has a public Astro marketing site.** I missed it because I only audited the Rails app at `lets.measure.events`. Hero already does the right framing ("Agent-Native Analytics / Analytics your agents can use"). Option 2 in the original ask is therefore moot — the site exists.
- **Pricing inconsistency is bigger than I thought.** PO found 10+ surfaces still on $29 (waitlist, all trial emails, both `llms.txt` files, the whole Astro site) and filed `queue/approvals/po-2026-05-24-1910-stale-pricing-rollout.md` for the full sweep. My pricing concern in the original ask is fully covered by PO's approval — Matt doesn't need to decide it twice.
- **The waitlist rewrite (specs/waitlist-mcp-rewrite.md) still ships** as part of the broader sweep. TA owns the Rails-side execution; my copy gets folded in.

### What's actually still pending Matt's call

Two narrowed questions, not three:

1. **Where does the `measure.events` Astro repo live?** Not in the `Turbo-Puffin` org (verified — no `measure-marketing` repo). PO and I both need to know to ship copy + pricing fixes there. Matt: name the repo / host?
2. **Hero code-sample swap on `measure.events/` before HN day?** I'm recommending yes — replace the REST `GET /api/v1/summary` sample with the Claude Desktop `mcpServers` config block from the measure-mcp-server README. Rationale in `queue/po-pending/marketing-2026-05-24-2030-reply-to-mcp-visibility-answer.md`. PO will file the TA handoff if you agree.

### Revised default action if no reply by expiry

If Matt is silent: assume "yes" on the hero swap (PO files TA handoff), and proceed with the waitlist rewrite via PO's pricing sweep. Astro repo location stays unresolved — I'll add a Discord ping via Wolfgang as the fallback.

# Approval: get me a customer roster

- **From:** measure-support
- **Filed:** 2026-05-24 18:45 UTC
- **Expiry:** 2026-05-28 18:45 UTC (96h — not blocking today's tickets, but blocks proactive outage comms)

## Ask

How do I get a list of current paying Measure customers, ideally as a file I can read on each work cycle?

Specifically I need: customer name, primary contact email, plan tier, signup date. I do **not** need payment details, MRR, or anything PII-heavy beyond contact info.

This is load-bearing for:

1. **Proactive outage comms** — `specs/incident-response-runbook.md` recommends emailing affected customers within 15 min of a confirmed multi-customer incident. I can't do that without knowing who they are.
2. **Per-customer files** — `customers/<slug>.md` convention from the readiness spec is empty today. Should be seeded with current customers so future agents have history to work from.
3. **Renewal / churn signal** — if a customer goes quiet, that's data. Can't notice silence if I don't know who's supposed to be talking.

## Default action

If you don't reply by the expiry, I will:

1. File a handoff to measure-ta (`queue/ta-pending/`) asking them to add an `agents/support/customer-roster.json` export to the Measure Rails app — refreshed nightly via a Rails task, scoped to non-sensitive fields above. They have merge authority so this is self-contained.
2. While waiting, manually seed `customers/` from whatever public signals exist (GitHub stars, Twitter mentions of @measure-events). Not a substitute, but better than nothing.

## Alternatives if you don't like the Rails-task path

- **Direct DB read access** for this agent (least good — credentials sprawl).
- **A Google Sheet you maintain manually** (fine if customer count is small, breaks at scale).
- **Stripe API access** (good source of truth for paying customers, but only paying — misses free-tier).
- **You email me the list once** and I'll keep it updated manually until volume forces automation.

## Context

- Charter notes "live customer base (paying)" but `customers/` is empty.
- Related: `queue/approvals/support-2026-05-24-1800-inbox-confirm.md` (inbox decision). These are independent — answer either in any order.

# Approval: Stripe gem major bump (13.5.1 → 19.0.0) — go or defer?

**Filed:** 2026-05-24 18:30 UTC
**Agent:** measure-po
**Expires:** 2026-05-29 18:00 UTC (5 days)

## Ask

Dependabot PR #45 on `Turbo-Puffin/measure` proposes upgrading the Stripe
gem from `13.5.1` to `19.0.0`. That's six majors of breaking changes,
sitting open since 2026-03-29.

The risk is concentrated: we just bumped Monthly $9 → $19 and launched a
**Lifetime $999 plan** ~3 weeks ago. Stripe is on the critical path for
both. If there's a quiet API incompatibility, the current price-change
window is the worst time to find it.

Three reasonable options. I'd like Matt to pick one:

1. **Schedule the upgrade-and-test work this week.** TA owns. Includes
   reading the Stripe 13→19 changelog, running the full checkout/webhook
   path against Stripe test mode, and validating the Lifetime plan still
   creates correctly.
2. **Defer for now, re-evaluate after MCP backlog ships.** Risk: we drift
   further from upstream; security patches inside the 13→19 range may not
   be backported. Lower acute risk during the price-change window.
3. **Close the PR; revisit at next major-bump cycle.** Same as option 2
   but explicit, so dependabot stops re-nagging us.

## Default action (if no response by expiry)

Take option 2 — defer with comment, leave the PR open so the upgrade
window is still visible. I'll add a calendar reminder to re-surface this
in `roadmap/current.md` two weeks out.

## Context

- PR: https://github.com/Turbo-Puffin/measure/pull/45
- Recent Stripe-touching commits: 077138d (custom_text), 567830e + 7ab1836
  (price change), 37fcbd3 (Lifetime plan)
- Charter: I cannot test against the live Stripe Dashboard myself.

# Approval: Stripe Dashboard pull — post-pricing-change data

**Filed:** 2026-05-24 18:30 UTC
**Agent:** measure-po
**Expires:** 2026-05-30 18:00 UTC (~6 days)

## Ask

Per charter I don't have Stripe Dashboard access, so I'm flying blind on
whether the recent pricing changes worked:

- Monthly $9 → $19 (commits 7ab1836 + 567830e, ~3 weeks ago)
- Lifetime $999 plan launched (commit 37fcbd3, ~3 weeks ago)

To prioritise next-cycle work (specifically: should marketing lean into
Lifetime in their first content push, and is the $19 holding up?) I need
the following pulled from the Dashboard:

1. **Net new paying customers** over the last 30 days, split by plan
   (Monthly vs Lifetime).
2. **Conversion rate** on the pricing page since the change — comparable
   to the same span before the change if easy. Imprecise is fine; I'm
   looking for "up / flat / down by a clear amount", not 2-decimal points.
3. **Refunds / disputes** on the Lifetime plan specifically since launch
   (zero is fine; non-zero needs a follow-up).
4. **MRR delta** vs 30 days ago. Total $ and direction.

A screenshot + 3 lines of commentary is plenty. I don't need a polished
report; I need to know if the new pricing is working.

## Default action (if no response by expiry)

Two-step fallback:

1. Drop a spec into `specs/mcp-stripe-readonly.md` proposing a read-only
   Stripe surface on `measure-mcp-server` so PO can self-serve this query
   on the next cycle (subscription counts, plan distribution, refund
   counts — no PII, no card data, no write access).
2. Hand the spec to measure-ta for sizing. This is the long-term fix
   regardless of how Matt answers this one-shot.

## Context

- Marketing is drafting first content this cycle; pricing/Lifetime angle
  decisions depend on knowing if the change is performing.
- Charter says PO does not touch Stripe directly — this request honours
  that.

# Approval: Click tracking — go, defer, or re-spec?

**Filed:** 2026-05-24 18:30 UTC
**Agent:** measure-po
**Expires:** 2026-05-29 18:00 UTC (5 days)

## Ask

`Turbo-Puffin/measure@main:CLICK_TRACKING_PLAN.md` is 711 lines of detailed
implementation plan covering schema, ingestion, ring buffer, two-tier
classification (generic + named click classes per site, 50-class cap),
hourly + daily aggregation tables, and a public API. The plan was
committed before the recent pricing work and has **zero implementation
PRs against it**.

Three readings of that gap:

1. **Click tracking is the next big feature**, the pricing work was a
   detour, and we should kick off Phase 1 (migrations + model) this week.
2. **Click tracking is shelved**, deprioritised in favour of the pricing
   push / Lifetime plan, and the plan file should be explicitly marked
   `STATUS: paused 2026-05-24` so future readers (and agents) stop
   treating it as a commitment.
3. **Click tracking needs a re-spec** before any code lands — e.g. the
   click-class model needs UI surface design, or the privacy story needs
   review before we add another per-page collection point.

I can't tell which it is from the repo alone.

## Default action (if no response by expiry)

Take option 2 — mark the plan paused with today's date and a one-line
"unblock condition" note (e.g. "resume after Lifetime conversion data
review, see roadmap"). Click tracking comes off the implicit roadmap
until Matt or a customer signal puts it back on.

## Context

- The MCP backlog (#50, #51) is the differentiator and arguably a higher-
  priority data feature than clicks; merging it would also make whatever
  click data we eventually collect agent-readable.
- Schema is sketched against `hourly_click_stats` and `daily_click_stats`
  that follow the existing `daily_stats` pattern, so resumption later is
  not lossy.

# Approval: confirm where support tickets land

- **From:** measure-support
- **Filed:** 2026-05-24 18:00 UTC
- **Expiry:** 2026-05-27 18:00 UTC (72h — not blocking active customer pain today, but blocks every other support workstream)

## Ask

Where do incoming support tickets land today? I need to know so I can wire polling, write the receive-side code/config, and stop guessing in `specs/support-launch-readiness.md`.

Candidates I've considered:

1. **Email alias `support@measure.events`** forwarded to a shared Fastmail/Gmail mailbox we both read.
2. **Resend inbound** webhook into the measure Rails app, persisted to a `support_tickets` table.
3. **Help Scout / Front / Zendesk** — managed vendor, fastest UX, $20-50/mo/seat.
4. **Something already exists** that I just don't have access to yet — please point me at it.

## Default action

If you don't reply by the expiry, I will:

1. Assume option **1 (email alias)** is the path.
2. File a handoff to measure-ta (`queue/ta-pending/`) asking them to register `support@measure.events` DNS + forwarding.
3. File a handoff to measure-marketing (`queue/marketing-pending/`) asking them to publish that address as the support contact on measure.events.
4. Update `specs/support-launch-readiness.md` section 1 with the email-alias plan.

This is the cheapest reversible choice. If you'd prefer Resend inbound or a vendor, we can swap later — the customer-facing address stays stable.

## Context

- Charter (`~/.claude/agents/support.md`) flags this as "TBD — confirm with Matt".
- Live paying customers exist today; if any of them have already emailed support and nobody saw it, that's the actual fire here. Please confirm one way or the other even if the answer is "nobody's written in yet, you're fine."
- Full readiness doc: `specs/support-launch-readiness.md` in measure-company.