[KAVentures]

Why

Stripe's merged read-only source adapter is env-variable-only; a Finder-launched macOS or Start Menu Windows app cannot use it without a custom process environment. This is a local, default-off production usability slice independent of the historical Gateway consent PR #236.

Implementation

• A separately authorized local Stripe source verifies the exact account with read-only GET https://api.stripe.com/v1/account before storing any restricted rk_* key.
• macOS Security.framework Keychain and Windows Credential Manager store the key (never plaintext OWG config, shell arguments, MCP output or Gateway). No fallback to unencrypted files on unsupported/locked platforms.
• The local authenticated dashboard exposes explicit connect/revoke and connection-status controls, with credential-management API routes protected by OWG-Session (ordinary API/MCP bearers refused).
• Existing OWG_STRIPE_* environment configuration is unchanged and takes explicit precedence. Source reads still require exact retained observed refs, account verification, opt-in and include_source_status=true.
• Dedicated synthetic tests cover wrong accounts, invalid unrestricted keys, native missing/locked vaults, no key in metadata/status, revocation, local agent bearer denial, and source isolation. No historical consent code or Issue #226: seeded Gateway acceptance test for historical consent and revocation #236 test file touched.

Non-goals and manual gates

This is a single local-user account, not organization-approved Stripe Connect OAuth. Existing Jira OAuth refresh, accepted handoffs and agent study remain pending. No real account or credential was available. Draft until full CI, a platform API review, and signed Mac/Windows live TEST-account acceptance. Do not merge or claim production authorization solely on passing synthetic CI. Issue #226 stays open.