foldrun 4.0.1 → 5.0.1

package/docs/api.md

@@ -41,7 +41,7 @@ read (a deploy with issues, an `Idempotency-Key` reused with a different body),
 than the person who minted it, and opens every route below with that — except
 the ones that are about people: `/api/team` (invite, roles, scope, remove,
 transfer), `/api/auth/*` (profile, password, MFA, sessions), a user's
-`/api/avatars/user/<id>`, and the super admin console. Those need a signed-in
+`/api/avatars/user/<id>`. Those need a signed-in
 session and answer a key with `401` (a user's avatar answers a key with
 `403`: the key is read, then refused because it is not that person). Everything a workspace or an account
 *does* — files, runs, secrets, shares, schedules, hooks, storage, billing —
@@ -404,7 +404,7 @@ person: a key names an account, never a who.
 | `/api/billing/wallet` | GET, PUT | the balance summary (burn, runway, daily spend, month to date, the suggested top-up), the refill rule and the low-balance email — GET `{ enabled, stripe, summary, cardSaved, autoTopUp, email, dunning }`, PUT `autoTopUp`, `email`. `dunning.status` is `none`, `grace` (a plan invoice failed; runs go on until `graceUntil`) or `suspended` (new runs paused until it is paid), with `payUrl`, `amountDue` (minor units) and `currency` |
 | `/api/billing/plans` | GET | the catalogue (four plans: fee, credits, per-credit price, runs at once, workspaces, lane), where this account stands (plan, status, this cycle's credits and what is left, when it resets), the balance in dollars and credits, and any overdraft the platform has allowed |
 | `/api/billing/subscribe` | POST, DELETE | POST `plan` — starter, creator, pro or scale. With no subscription yet, answers `url`: a Stripe Checkout in subscription mode; the return trip starts the first cycle. With a live one, changes it at Stripe at once, prorated (an upgrade is invoiced today and the bigger bundle lands with it; a downgrade comes back as credit on the next invoice), and answers `changed: true` — only once its prorated invoice is paid: when the payment needs the customer (a declined card, 3-D Secure) the change waits at Stripe as a pending update, nothing about the plan moves, and the answer is 402 `{ pending: true, payUrl }` — paying that invoice applies it; unpaid, Stripe drops it and voids the invoice after 23 hours. A plan set to stop and changed this way stays set to stop once paid — resuming it is the customer's own choice (`resume: true`); nothing resumes on its own. A plan set to stop at the period's end is still that live subscription: choosing a plan takes the stop off (and changes it if it is another plan) — never a second Checkout. With no subscription known here but one still billing at Stripe for the account's customer, 409: a second is not started. POST `resume: true` takes a pending cancellation off — nothing is charged and no cycle moves. DELETE ends the plan with the current cycle: the credits stand until then, and credits bought on top are kept |
-| `/api/billing/stripe` | POST | Stripe's webhook — signature-verified, not for you. Every delivery is logged (see `/api/admin/stripe-events`). Beside top-ups it turns plan cycles: one grant per (subscription, plan, period), whichever of the checkout, `invoice.paid` (either invoice shape) or `customer.subscription.updated` arrives first; `invoice.payment_failed` marks the plan past due and starts dunning (an email, a grace period, then new runs paused — see budgets-and-billing.md), `invoice.paid` and `invoice.voided` end it, `customer.subscription.deleted` ends the plan that subscription paid for — what is left of the bundle expires, the levers come off, money the customer added stays. `charge.refunded` debits a refunded top-up (never a plan fee), `charge.dispute.created` debits a chargeback and `charge.dispute.closed` returns it when won. Answers 500 — so Stripe redelivers — only when a lookup the event needs failed. The full event list is in budgets-and-billing.md |
+| `/api/billing/stripe` | POST | Stripe's webhook — signature-verified, not for you. Every delivery is logged. Beside top-ups it turns plan cycles: one grant per (subscription, plan, period), whichever of the checkout, `invoice.paid` (either invoice shape) or `customer.subscription.updated` arrives first; `invoice.payment_failed` marks the plan past due and starts dunning (an email, a grace period, then new runs paused — see budgets-and-billing.md), `invoice.paid` and `invoice.voided` end it, `customer.subscription.deleted` ends the plan that subscription paid for — what is left of the bundle expires, the levers come off, money the customer added stays. `charge.refunded` debits a refunded top-up (never a plan fee), `charge.dispute.created` debits a chargeback and `charge.dispute.closed` returns it when won. Answers 500 — so Stripe redelivers — only when a lookup the event needs failed. The full event list is in budgets-and-billing.md |
 
 ## Versions
 

package/docs/budgets-and-billing.md

@@ -198,7 +198,7 @@ and on the audit; it is a term, never a surprise.
 
 **Charges an account does not pay.** The platform can waive any of the three
 meters for one account: model tokens, sandbox time, network. It is set per
-account from the admin console, never as an install-wide rate, because a
+account by the platform, never as an install-wide rate, because a
 rate turned off globally would quietly stop charging every customer. The
 meters still run and the Usage page still shows everything measured; what
 changes is the bill. Every run still writes a ledger line — at zero when
@@ -390,26 +390,6 @@ runs, schedules stop firing — while the platform team settles the last
 invoice and any refund. Nothing is deleted by the request itself; people can
 still sign in and take the copy.
 
-## The admin console's money levers
-
-Each customer (account) in the super admin console has a Billing tab with
-every lever that changes what the customer pays, each behind a confirmation
-that names the amount and the account: **credit or debit** with a reason on
-the ledger (the console sends an idempotency key, so a double click is one
-line), **extend the trial** (more trial credits as a grant, with whatever
-trial credit is left carried into it; not for an account on a plan), the
-**plan** (grant a cycle by hand, end it, and the lane and limits that ride
-with it), **going into minus**, and **charges this account does not pay**.
-The overview beside it holds the contact on record (name, email, phone,
-company, ABN), notes, suspension, and the customer's Stripe customer and
-subscription with links into Stripe's own dashboard — test or live, read
-from the install's key.
-
-Revenue has a CSV per month for the accountant (`GET /api/admin/export`):
-one row per customer and a total, charges by leg, fees, top-ups, grants,
-expiries, refunds, disputes, adjustments and net, with Stripe's own figures
-for the month beside them when Stripe is connected.
-
 ## The wallet
 
 Usage is settled from a credit balance. Add credit by card, once or with
@@ -469,11 +449,7 @@ dispute-won, plan, trial, grant-expired, credits-expired — and lines written
 before the field have theirs derived from their key and note. Statements
 label lines by it. **Burn**, the 30-day spend and month-to-date count usage
 and the daily fees only — not expiries, refunds, chargebacks or an
-operator's debit. The admin console's **charged** figure is usage (runs and
-account pod sessions) in the customer list and the money report alike;
-**paid in** is top-ups paid plus plan fees from the invoices Stripe said
-were paid; **held in wallets** is credit bought and unspent — granted
-credit is shown apart, because nobody paid for it by the dollar.
+operator's debit.
 
 **Hand-placed plans renew.** A plan the super admin grants runs a month and
 is renewed by the hourly sweep at its period's end, with the same grant and
@@ -482,9 +458,6 @@ rollover rules. Granting a plan to an account Stripe is billing is refused
 the subscription at Stripe first, at once, and changes nothing if Stripe
 refuses.
 
-**An operator's credit or debit is written once** per idempotency key the
-console sends, and audited once.
-
 **Stripe.** Every call pins its API version (`2025-03-31.basil`;
 `STRIPE_API_VERSION` overrides) — create the webhook endpoint on the same
 version — and charges in `FOLDRUN_CURRENCY` (default `usd`), which is also
@@ -513,12 +486,10 @@ kept too, for the types above only, up to 256 KB, set when it first
 arrives and emptied after **180 days**: Stripe keeps events for 30, and a
 replay after that needs a copy. It carries what Stripe sends (names,
 emails, addresses, a card's last four digits — never a full card number),
-so only the super admin's console reads it and lists never load it. The
-super admin lists the log at `GET /api/admin/stripe-events` and replays
-one event with `POST /api/admin/stripe-events/<id>/replay` — Stripe's copy
-while Stripe has it, the kept copy after — through the same handler; every
-write it makes is keyed once, so a replay of an event that was handled
-changes nothing.
+so it is never shown to the account. The platform can replay an event
+through the same handler — Stripe's copy while Stripe has it, the kept
+copy after; every write it makes is keyed once, so a replay of an event
+that was handled changes nothing.
 
 ## Plan gates
 

package/docs/cli.md

@@ -449,7 +449,7 @@ this way: they can take it back without changing a password.
 
 **You reset it, as the platform.** Only the platform's own super admin can,
 only on the hosted platform, and it ends every session that account had:
-`/admin/<account>` → the member → **reset password**. The new password is
+from its console, the member → **reset password**. The new password is
 shown once. Sign in as them in a private window, then `foldrun login
 --profile <name>` and approve the code in that window.
 

package/docs/feature-flags.md

@@ -46,11 +46,8 @@ foldrun flags --json
 
 ## Running the platform yourself
 
-On a hosted install the super admin changes flags at **/admin → Flags**:
-the install-wide on/off and rollout, and an override per account. The same
-is `PUT`/`DELETE /api/admin/flags/<flag>` and
-`/api/admin/flags/<flag>/accounts/<account>` (see the API reference's
-super admin section). Every change is on the platform's audit as
+On the hosted platform the operator changes flags from its own console:
+the install-wide on/off and rollout, and an override per account. Every change is on the platform's audit as
 `operator.flag.global`, `operator.flag.global_cleared`,
 `operator.flag.account` or `operator.flag.account_cleared`, with who made
 it and what it was before. The settings are rows in Postgres

package/docs/status.md

@@ -46,8 +46,7 @@ not see a network problem between you and the platform — the page saying
 
 ## Incidents and maintenance
 
-The super admin posts them from **Admin → Incidents** (or
-`/api/admin/incidents`): a title, what customers should read, the impact
+The platform's operator posts them from its console: a title, what customers should read, the impact
 (minor or major) and the components affected. Each update adds a line with
 a status — `investigating`, `identified`, `monitoring`, `resolved`.
 Maintenance is a window with a start and an end; it shows as upcoming before

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "foldrun",
-  "version": "4.0.1",
+  "version": "5.0.1",
   "description": "Agents are just folders. Write them, check them, run them — on your machine.",
   "license": "FSL-1.1-ALv2",
   "type": "module",
@@ -11,7 +11,7 @@
     "node": ">=22"
   },
   "dependencies": {
-    "@foldrun/core": "^3.0.0"
+    "@foldrun/core": "^4.0.0"
   },
   "files": [
     "bin",