[clbotdev]

Implements docs/wip/plan-limits.md: Pro and Business plans on courselit.app, a cardless 14-day trial with Business features, plan limits, abuse controls, and the security requirements from the reviews (S1–S31). Every milestone was browser-tested on the local stack.

What's in it

Billing and plan state

• Platform billing moves from Dodo to Lemon Squeezy, using @codelitdev/billing 0.12.0 (planLimits, paid-through entitlement end, store-checked variants).
• School states (pending_checkout, imported, read_only, suspended) are enforced by a fail-closed allowlist at the dispatch edge.
• schoolPlan() checks a paid plan first, then a running trial, and returns unknown when billing can't be read.

Trial and lifecycle

• The account's first school starts a 14-day trial. Later schools wait for checkout, and their site stays offline until then.
• When a trial or plan ends, the school goes read-only for 15 days and the owner is emailed. The admin shows banners for read-only and offline schools.
• A staff CLI (bun run staff) can suspend, unsuspend and import schools, recorded in platform_audit_events.

Plan features

• A "Powered by CourseLit" badge shows on the site, in the course viewer and learner dashboard sidebars, and on learner email. The Remove CourseLit branding checkbox now saves; removing the badge needs a paid plan.
• During a trial, injected code runs only for the owner, fetched through their own session (S25).
• SCORM is gated to Business: no new SCORM lessons or package changes without it.
• New audit log tab (Business). billing.* events are shown only to the owner in a browser session.
• getSchoolPlanFeatures lets every team member's screens explain what the plan includes.

Limits

• Marketing email:
  • SendLit team quotas are set from the plan (S20, S3).
  • Drip pauses when the quota runs out.
  • Learner mail goes through platform streams with daily caps.
• Storage (S1, S2, S24):
  • The school is checked before an upload is sealed, the declared size is reserved at authorize, and the real size is checked at finalize under a school lock.
  • Each learner gets a budget (Settings → Storage). Learners together may use 25% of the school's storage, can't upload past 90%, and are limited to 20 uploads an hour.
  • Community uploads need a membership that can post, are always private, and are limited to images, video, audio and PDFs. Uploads no post uses are deleted after a day.
• Invites: 50 per school per day and at most 200 pending (S6).
• Usage: the plan page shows meters. The owner gets an 80% banner and email (getSchoolBillingUsage, owner-only and off MCP).

Abuse handling

• "Report this site" appears on every public page and the certificate page, on every plan.
• The docs gain an acceptable use policy and a report-abuse page.
• Reserved subdomains (www, app, login, billing…) can't be taken.

Docs: frontlit/docs is updated for all of the above.

Fixes found along the way:

• LearnerLink rendered a span, so storefront links didn't navigate.
• An empty lesson told enrolled learners they weren't enrolled.

Testing

• API suite: 718 pass. Admin, storefront and contract suites pass.
• Browser e2e on the local stack, including:
  • a real Lemon Squeezy test checkout;
  • real MediaLit uploads;
  • trial expiry to read-only with the owner email in Mailpit;
  • the learner upload rules;
  • usage warning emails;
  • invite limits;
  • the injected-code checks for the owner and for other learners.

Before merging / follow-ups

• GitGuardian flags a fake test key in ef14c018 (base64 of "key-key-key…"). The test now builds the key at runtime, but the incident needs marking as a false positive.
• The abuse@courselit.app mailbox must exist.
• Lemon Squeezy variants still need creating at the new prices ($19/$190, $79/$790).
• Not in this PR:
  • the badge in the page-editor preview (needs a slot in FrontLit's PageBuilder);
  • school deletion;
  • the SendLit platform organization and team keys;
  • moving the QA environment to Lemon Squeezy.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
40087217	Triggered	Generic Encryption Key	ef14c01	apps/api/src/billing-config.test.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}