<observations>
Date: April 28, 2026
* 🟡 (23:09) Agent committed catalog upgrade fix: `fix(stripe-projects): Add plan tiers to project allowed_updates for non-interactive upgrades` — 2 files changed, +35/-1, commit 0e0088e7f4 on branch `BYK/fix/stripe-projects-catalog-upgrade-path`
* 🟡 (23:10) Agent pushed branch and opened PR #20143: https://github.com/getsentry/getsentry/pull/20143 — adds paid plan tiers (team, business) to project service's `allowed_updates` with `direction: "up"`, switches plans to typed `{service, direction}` format
* 🟡 (23:14) User asked what's left from the spec sync plan
* 🟡 (23:14) Agent presented full spec sync plan status: (0+1) Identity rework ✅ MERGED PR #20125; (2) Service scope field — not started; (3) Service constraints — not started; (4) JWT V2 signature verification — not started, lowest urgency; (5) stripe_price ✅ resolved (AM3 plans have no Stripe Price objects); (6) Non-interactive upgrade fix — PR #20143 open; (7) Provider Push — deferred
* 🟡 (23:14) Agent noted PR #20131 (migrate to `organization_service.find_organization_id_by_option_value`) is CLOSED, needs rebase after sentry-version pin bumps — Alberto driving
* 🟡 (23:14) Agent proposed bundling items #2 (scope) and #3 (constraints) into one small PR — both catalog-only changes in services.py
* 🟡 (23:16) User approved bundling #2 and #3, asked about risk level and potential breakage
* 🟡 (23:16) Agent assessed both as **zero risk to Sentry code** — `scope` and `constraints` are hints to Stripe's orchestrator, not read/enforced by Sentry endpoints; only present in catalog response Stripe polls. Risk is on Stripe side: `count.at_most: 1` would reject duplicate plan provisioning before reaching endpoint (desired behavior). `scope: "account"` tells Stripe to share plan/seer resources across projects on same account. ...