0ae59f3550
Introduces RECAP_MODE=multi alongside single-mode self-host: - Tenant auth + accounts (magic-link via System SMTP), per-tenant credit pool, anonymous trial minting with per-IP/-64 caps - Self-serve Pro/Max purchase: inline Lightning (BTCPay) + card (Zaprite), prepaid 30-day periods, expiry-reminder emails - Core-decoupling: relay owns cloud tier/expiry keyed by Recaps user-id - SQLite (better-sqlite3) schema for multi-mode; filesystem unchanged for single - StartOS actions/versions through 0.2.155
14 lines
1.0 KiB
TypeScript
14 lines
1.0 KiB
TypeScript
import { VersionInfo } from '@start9labs/start-sdk'
|
|
|
|
export const v_0_2_98 = VersionInfo.of({
|
|
version: '0.2.98:0',
|
|
releaseNotes: {
|
|
en_US:
|
|
"Self-healing credit-purchase apply on multi-tenant cloud. When a buyer pays for credits via BTCPay, the relay's webhook credits the operator pool — but the buyer-side polling tab dies on the BTCPay → Recap redirect, so the local pending_purchases row never gets marked applied and the visible balance stays stale. Now every /api/account/whoami and /api/relay/status hit triggers a bounded sweep (max 5 invoices, 30-min lookback) that asks the relay for each unapplied invoice's status and runs apply for any that report settled. Idempotent via the existing applied_at column. Same sweep runs inside linkToUser BEFORE the anon-trial→user credit transfer, so a buy-then-immediately-sign-up flow rolls the just-purchased credits into the new user's balance instead of dropping them on the floor.",
|
|
},
|
|
migrations: {
|
|
up: async ({ effects }) => {},
|
|
down: async ({ effects }) => {},
|
|
},
|
|
})
|