<observations>
Date: April 29, 2026
* 🔴 (23:23) User prioritized 2-way sync (Provider Push) over JWT V2 migration — wants Provider Push explored first, JWT migration as follow-up
* 🟡 (23:23–23:28) Agent explored Stripe APP Provisioning spec (spec.md) for Provider Push endpoints: 3 orchestrator APIs discovered:
1. `POST /v2/provisioning/provider/resources/update` — push resource state change (id, access_configuration?, service_ref?)
2. `POST /v2/provisioning/provider/resources/add` — push new resource creation (id, service_ref, project_id)
3. `POST /v2/provisioning/provider/resources/remove` — push resource removal (id only)
* 🟡 (23:25) Agent examined stripe-app.json manifest: app ID `com.getsentry.sentry`, version `0.2.0`, current capabilities are `resources:deprovision`, `resources:update_service`, `resources:rotate_credentials` — does NOT yet include `provisioning_resource_write` permission needed for push
* 🟡 (23:26) Agent confirmed existing resource ID format: `project:<project_id>`, `plan:<org_id>`, `seer:<org_id>` — built by `_build_resource_id()` in resources endpoint
* 🟡 (23:26) Agent reviewed spec authentication: Push endpoints use bearer token (`Authorization: Bearer <orchestrator_token>`) + `<orchestrator>-Account: <account_id>` header. Orchestrator→provider calls use JWT V2 signature (`EdDSA`, `typ=JWT`, claims: `htu` = normalized URL, `htm` = HTTP method)
* 🟡 (23:28) Key finding: `Push update` and `Push remove` only need resource ID + Stripe-Account header (both already available). ...