Quotas

1// Quota is Flux-native, not HTTP-request-native. What counts, and
2// gets rolled into your daily report:
3 
4//   Bootstrap Dispatch     — one per LEADER TAB per session, not per
5//                            store. Ten registered stores dispatched
6//                            from one bootstrap call is ONE event,
7//                            not ten.
8//   Hydration Read         — IDB reads. Free in the sense that they
9//                            cost nothing beyond the original fetch,
10//                            but still counted so you can see
11//                            cache-hit health in your own numbers.
12//   Realtime Update
13//   BroadcastChannel Mirror
14//   Queue Replay
15//   Conflict Detected
16//   Conflict Resolved
17//   Delta Catch-up
18 
19// What's NEVER shown or tracked: raw HTTP method counts. A REST
20// endpoint hit five times by five different Flux subsystems in one
21// page load is not "five requests" in any dashboard you'll see —
22// it's whatever Flux-native event type each of those five calls
23// actually was.

1// Unlike a traditional ping-based licensing model, quota usage is
2// NOT computed by TsWorldTech watching your traffic in real time.
3// There is no traffic to watch — verification is fully offline
4// (Section 4.12), so there's nothing for a server to observe.
5 
6// The number comes entirely from YOUR OWN server's daily
7// sendDailyReport() call — specifically the events and users fields
8// you pass in, however you choose to count them server-side:
9 
10await sendDailyReport({
11  key_id: process.env.FLUX_KEY_ID!,
12  project_id: process.env.FLUX_PROJECT_ID!,
13  secret: process.env.FLUX_LICENSE_SECRET!,
14  date: new Date().toISOString().split('T')[0],
15  events: await getEventCount(), // this number is yours to define
16  users: await getUserCount(),
17  features: ['lruCache', 'jobTracker'],
18  domains: ['yourapp.com'],
19})
20 
21// TsWorldTech's dashboard is a MIRROR of what your own report said —
22// not an independent measurement. If your counting logic overcounts
23// or undercounts, that's what shows up on your Usage tab, because
24// there's no second, independent source of truth to reconcile
25// against.

1// Quota by tier — same numbers as pricing, restated here since this
2// is the page someone reads when the number itself is in question:
3 
4//   free         10,000 events/month
5//   starter     100,000 events/month
6//   pro         500,000 events/month
7//   enterprise  unlimited

1// What happens at 90%+ and 100%+ usage — nothing breaks either way,
2// at any percentage:
3 
4// 90%+
5//   The portal's Usage tab shows an amber callout. This is a
6//   PORTAL-SIDE VISUAL ONLY — your running app never sees this,
7//   never reacts to it, has no code path that even checks for it.
8 
9// 100%+
10//   Still nothing breaks. Flux never degrades, disables, or
11//   rate-limits a key mid-subscription for quota reasons.
12//   Enforcement here is dashboard visibility for an informed
13//   upgrade decision — not a kill switch.
14 
15// The ONE place a number from your daily report can change client
16// behavior at all:
17//
18//   a signed token's own "quota" field (Section 4.12's
19//   LicensePayload.quota, set by the license issuer at signing time)
20//   feeds emitQuotaWarning() — a console-only message, never a
21//   block, never a feature disable. This is the ceiling check inside
22//   enforce.ts, unrelated to the portal's Usage tab entirely.

1// If you never wire up sendDailyReport() at all — see
2// license/webhook-setup for the full setup:
3 
4// - The Usage tab shows "Set up usage reporting to see data here"
5//   indefinitely. It never resolves on its own.
6// - Your app is COMPLETELY unaffected. Quota tracking is opt-in
7//   visibility, not an enforcement mechanism your app depends on to
8//   keep running.
9 
10// There's no countdown, no grace period, no eventual lockout for
11// skipping this. The Usage tab simply stays empty until you decide
12// to fill it.