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.3 KiB
TypeScript
14 lines
1.3 KiB
TypeScript
import { VersionInfo } from '@start9labs/start-sdk'
|
|
|
|
export const v_0_2_136 = VersionInfo.of({
|
|
version: '0.2.136:0',
|
|
releaseNotes: {
|
|
en_US:
|
|
"Subscription auto-queue log clarity. The 'N in queue' counter on the subscription-check status line was counting EVERY item in the autoQueue file regardless of status — pending, approved, processing, AND completed + failed. Since the queue UI hides completed and failed items by default, operators kept asking 'why does it say 29 in queue when the queue panel is empty?' — the answer being 'because 29 includes everything ever queued, most of which is already done or failed.' Now the line splits the number into active vs done so the dashboard semantics match what the UI shows: 'X in library, Y skipped, Z seen — queue: A active, B done (C completed, D failed)'. When any failed items exist, the sub-check log also surfaces a one-liner pointing the operator at the Queue panel's 'Show all' toggle so they can view + retry. (All four counters — library, skipped, seen, and the FULL queue set including done — are still used for new-video dedup; the change is purely presentational so operators stop misreading the active load.)",
|
|
},
|
|
migrations: {
|
|
up: async ({ effects }) => {},
|
|
down: async ({ effects }) => {},
|
|
},
|
|
})
|