@stage5/lumine 0.2.80 → 0.2.81

package/lib/admin.js

@@ -221,7 +221,7 @@ export function readRewardConfigFile(filePath) {
   const normalizedPath = String(filePath || "").trim();
   if (!normalizedPath) {
     throw cliValidationError(
-      "Pass the earning rules with --config <rules.json> (dailyXP, dailyCoins, userDailyXP, userDailyCoins, lifetimeXP, lifetimeCoins, rules[]).",
+      "Pass the earning rules with --config <rules.json> (userDailyXP, userDailyCoins, optional userDailyClaims, rules[]).",
     );
   }
   let contents;
@@ -3944,7 +3944,7 @@ function printRewardReviewResult({ operation, data }) {
   const config = review.config || {};
   if (Array.isArray(config.rules)) {
     console.log(
-      `Budgets: day ${config.dailyXP} XP/${config.dailyCoins} Coins · per user/day ${config.userDailyXP} XP/${config.userDailyCoins} Coins${config.userDailyClaims ? ` · ${config.userDailyClaims} claim(s)` : ""} · lifetime ${config.lifetimeXP} XP/${config.lifetimeCoins} Coins`,
+      `Budgets: per user/day ${config.userDailyXP} XP/${config.userDailyCoins} Coins${config.userDailyClaims ? ` · ${config.userDailyClaims} claim(s)` : ""}`,
     );
     for (const rule of config.rules)
       console.log(`  ${formatRewardRuleLine(rule)}`);

package/lib/rewards.js

@@ -214,7 +214,7 @@ function printRewardsHelp() {
   lumine rewards sheet --show       Summarize the sheet on file (never prints answer keys)
 
 rewards.json (project root) declares the economy the reviewer approves:
-  { "dailyXP", "dailyCoins", "userDailyXP", "userDailyCoins", "lifetimeXP", "lifetimeCoins", "userDailyClaims"?,
+  { "userDailyXP", "userDailyCoins", "userDailyClaims"?,
     "rules": [{ "id", "title", "xp", "coins", "verifier": "numeric-quiz" | "completion",
                 "maxAttempts"?, "retry"?: { "xpPercent", "coinsPercent", "paidAttempts"? }, "minSeconds"? (completion), "progression"?: "dated" | "until-earned" (quiz) }] }
 Questions and answer keys never go in project files; they belong in the sheet.`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stage5/lumine",
-  "version": "0.2.80",
+  "version": "0.2.81",
   "description": "Command line tools for launching Lumine builds on Twinkle.",
   "type": "module",
   "bin": {

package/sdk/BUILD_SDK_INDEX.md

@@ -1,8 +1,8 @@
 # Build SDK Index
 
-Version: 1.45.0
+Version: 1.45.2
 Updated: 2026-09-14
-Generated: 2026-09-15T02:06:06.654Z
+Generated: 2026-09-19T04:22:12.342Z
 
 ## Notes
 - This SDK is injected into Build iframes via the Build preview/runtime.
@@ -33,7 +33,7 @@ Generated: 2026-09-15T02:06:06.654Z
 - Use Twinkle.live for one-way app livestreams and Twinkle.chat for the accompanying thread. Free livestreams require a verified host, end after at most 15 minutes, and issue at most 10 private viewer grants. Twinkle keeps platform-owned live-status/end controls above active hosts, so app code cannot hide or replace the broadcaster's Stop path.
 - Media Energy is separate from AI Energy. Replace Media Energy UI only from canonical mediaEnergy/getUsage responses; never decrement, reserve, or synthesize it in app code.
 - Twinkle.rewards awards real XP and Coins only in the current approved published release. Drafts, local previews, private apps and superseded releases cannot earn. The server supplies a published-runtime grant; app code cannot choose a recipient or award amount.
-- The creator's agent designs the rewards. Declare the economy in a project file `rewards.json` at the root: budgets (dailyXP, dailyCoins, userDailyXP, userDailyCoins, lifetimeXP, lifetimeCoins, optional userDailyClaims) and rules [{ id, title, xp, coins, verifier: 'numeric-quiz' | 'completion', maxAttempts?, retry?: { xpPercent, coinsPercent, paidAttempts? }, minSeconds? (completion), progression?: 'dated' | 'until-earned' (quiz) }]. Wire the matching Twinkle.rewards calls with those literal rule ids. Questions and answer keys NEVER go in project files (published source is readable by every player): quiz rules get them from the private question sheet uploaded with `lumine rewards sheet <file.json>` ({ rules: { <ruleId>: { questions?, sets? } } }); `lumine rewards check` validates both together. A review request freezes the code and proposes rewards.json merged with the sheet; the administrator reads the code, checks the amounts and whether the app is exploitable, may change any amount, and approves. Creators are kids and teens: show approval status and one Send for review action; do not ask them to fill in technical forms. Every code update that retains rewards needs a new approval before publishing. Removing the SDK automatically clears its gate. Apps read amounts, tries and sets from getStatus, never from their own file.
+- The creator's agent designs the rewards. Declare the economy in a project file `rewards.json` at the root: budgets (userDailyXP, userDailyCoins, optional userDailyClaims; there is no app-wide daily or lifetime budget, only what one learner can earn per day) and rules [{ id, title, xp, coins, verifier: 'numeric-quiz' | 'completion', maxAttempts?, retry?: { xpPercent, coinsPercent, paidAttempts? }, minSeconds? (completion), progression?: 'dated' | 'until-earned' (quiz) }]. Wire the matching Twinkle.rewards calls with those literal rule ids. Questions and answer keys NEVER go in project files (published source is readable by every player): quiz rules get them from the private question sheet uploaded with `lumine rewards sheet <file.json>` ({ rules: { <ruleId>: { questions?, sets? } } }); `lumine rewards check` validates both together. A review request freezes the code and proposes rewards.json merged with the sheet; the administrator reads the code, checks the amounts and whether the app is exploitable, may change any amount, and approves. Creators are kids and teens: show approval status and one Send for review action; do not ask them to fill in technical forms. Every code update that retains rewards needs a new approval before publishing. Removing the SDK automatically clears its gate. Apps read amounts, tries and sets from getStatus, never from their own file.
 - Verifiers: 'numeric-quiz' pays for server-checked numeric answers (retry share, attempt limits, dated sets or until-earned sets that stay up until somebody earns them, after-answer guides). 'completion' pays when the app reports an activity finished — a cleared stage, a finished round — at least minSeconds after start({ ruleId }); the server checks only the elapsed time, once per learner per site day (UTC midnight), and the budgets. Call start when the activity begins and claim({ challengeId }) with no answers when it ends; keep completion amounts and userDailyXP small enough that a player scripting the calls would not matter, because nothing else is verified.
 - Numeric quiz answers are verified on the server; client scores, privateDb state, timers and completion booleans are not verified reward evidence. Limits reset at UTC midnight. Rules are earned once per viewer per UTC day; attempt limits and retry payouts come from the approved rule. Challenges expire at the UTC day boundary. Budgets apply across release changes.
 

package/sdk/LUMINE_ADMIN.md

@@ -1143,17 +1143,18 @@ Review questions to settle with Mikey before approving:
   it, then the next one comes up the following site day (UTC midnight, 9:00 AM Korea)) keep them honest.
 - Do the rule IDs in `rewards.json` match what the code starts? Unknown IDs
   simply never pay.
-- Are the amounts and the per-user, per-app and lifetime budgets conservative
-  for what the app actually asks of people?
+- Are the amounts and the per-learner daily budgets right for what the app
+  actually asks of people? There is no app-wide budget, per day or lifetime:
+  a good app keeps paying everyone who plays it. Older configs may still
+  carry `dailyXP`/`dailyCoins`/`lifetimeXP`/`lifetimeCoins`; the API accepts
+  and ignores them, so never add or tune them.
 
 `rules.json` (what `--config` takes, and what the app's `rewards.json` plus
 sheet compose into):
 
 ```json
 {
-  "dailyXP": 2000000, "dailyCoins": 0,
   "userDailyXP": 10000, "userDailyCoins": 0,
-  "lifetimeXP": 200000000, "lifetimeCoins": 0,
   "rules": [
     { "id": "stage-1", "title": "Clear Stage 1", "xp": 300, "coins": 0,
       "verifier": "completion", "minSeconds": 20 },
@@ -1191,8 +1192,8 @@ day, elementary 50,000 XP + 1,000 Coins, middle 70,000 + 5,000, high
 `userDailyClaims` 1; until-earned sets authored from the Korean curriculum.
 Arcade Typing (Mikey, 2026-09-12): XP for clearing campaign stages, up to
 10,000 XP per learner per day, no Coins. Platform ceilings: 100,000 XP /
-10,000 Coins per rule and per learner per day, 10,000,000 XP / 1,000,000 Coins
-per app per day, 1,000,000,000 XP / 100,000,000 Coins per app lifetime.
+10,000 Coins per rule and per learner per day. No app-wide ceiling exists,
+per day or lifetime.
 
 Approval freezes these rules with the reviewed snapshot and publishes that
 snapshot immediately (the result carries `published.version`); an approval
@@ -2670,6 +2671,24 @@ Read every line, and put these in the daily report verbatim:
   line;
 - the `day-over-day … worker_heap=…` delta.
 
+**The memory report looks back only 24 hours; the run's window is often longer.**
+On 2026-09-19 a four-day window hid two heap-OOM aborts (09-16 and 09-17) that
+`memory-daily` no longer showed. In every full review, also search the reviewed
+error log for `[cluster] worker exited` lines that are not planned or operator
+recycles, across the whole window since the last completed full run, and treat
+each one exactly like a non-zero `oom_aborts` / `unexpected_worker_exits`.
+
+Each unexpected exit is followed by a `[cluster] worker last work slot=… pid=…
+in_flight=[…] recent=[…]` line (added 2026-09-19). The worker writes that trail
+synchronously as each piece of work begins and ends, so it survives an abort
+inside a single synchronous burst. `in_flight` names the requests or socket
+events that were running when the process died; `recent` lists the last
+sixteen begin/label/end records with their age before exit. Quote both lists
+verbatim in the report and in the todo: they are the evidence that pinpoints
+the code path. `unavailable (no trail file)` means the worker died before its
+trail existed or an older generation is still running; say so rather than
+guessing.
+
 Escalate in the report (a todo, and a note for Mikey) when any of these hold:
 `oom_aborts` > 0, `service_restarts` > 0, `unexpected_worker_exits` > 0, any
 worker `heap_high_water_pct` ≥ 95, or `heap_recycles` ≥ 4 in a day (the