@stage5/lumine 0.2.79 → 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;
@@ -3619,13 +3619,17 @@ function printAdminEnergyBudget(energyBudget) {
     );
   }
   console.log(
-    "day        | charged | overflow | users | rechg | runs | calls/run avg/p90 | $/run avg/p90 | stops chg/unchg | busy | telemetry rows",
+    "day        | charged | overflow | users | rechg | runs | calls/run avg/p90 | $/run avg/p90 | stops chg/unchg | busy | queue rst/stop/resume | telemetry rows",
   );
   for (const day of energyBudget.byDay || []) {
     const m = day.telemetry.metrics;
     const runs = day.runs.total;
+    // Queue metrics are absent from APIs older than the queued-request telemetry.
+    const queue = ["queued_restored", "queued_stopped", "busy_resume_requested"]
+      .map((metric) => String(m[metric]?.count ?? "-"))
+      .join("/");
     console.log(
-      `${day.dayKey}${day.inProgress ? "*" : " "}| ${formatAdminUsd(day.chargedUsd).padStart(7)} | ${formatAdminUsd(day.overflowUsd).padStart(8)} | ${String(day.users).padStart(5)} | ${String(day.recharges).padStart(5)} | ${String(runs.runs).padStart(4)} | ${String(runs.callsPerRun.avg).padStart(7)}/${String(runs.callsPerRun.p90).padEnd(9)} | ${formatAdminUsd(runs.usdPerRun.avg).padStart(6)}/${formatAdminUsd(runs.usdPerRun.p90).padEnd(6)} | ${String(m.budget_stop_changed.count).padStart(7)}/${String(m.budget_stop_unchanged.count).padEnd(7)} | ${String(m.busy_refusal.count).padStart(4)} | ${day.telemetry.rowCount}`,
+      `${day.dayKey}${day.inProgress ? "*" : " "}| ${formatAdminUsd(day.chargedUsd).padStart(7)} | ${formatAdminUsd(day.overflowUsd).padStart(8)} | ${String(day.users).padStart(5)} | ${String(day.recharges).padStart(5)} | ${String(runs.runs).padStart(4)} | ${String(runs.callsPerRun.avg).padStart(7)}/${String(runs.callsPerRun.p90).padEnd(9)} | ${formatAdminUsd(runs.usdPerRun.avg).padStart(6)}/${formatAdminUsd(runs.usdPerRun.p90).padEnd(6)} | ${String(m.budget_stop_changed.count).padStart(7)}/${String(m.budget_stop_unchanged.count).padEnd(7)} | ${String(m.busy_refusal.count).padStart(4)} | ${queue.padEnd(21)} | ${day.telemetry.rowCount}`,
     );
   }
   console.log("* = in-progress UTC day; never headline it.");
@@ -3940,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)}`);
@@ -3957,6 +3961,32 @@ function printRewardReviewResult({ operation, data }) {
   console.log("Use --json for the full record.");
 }
 
+function formatAdminCounts(counts) {
+  return Object.entries(counts || {})
+    .sort(([a], [b]) => a.localeCompare(b))
+    .map(([key, count]) => `${key} ${count}`)
+    .join(" · ");
+}
+
+function printRewardReviewLifecycle(lifecycle) {
+  // Absent from APIs older than the review-lifecycle telemetry.
+  if (!lifecycle) return;
+  const totals = lifecycle.totals || {};
+  if (!Object.keys(totals.actions || {}).length) {
+    console.log("Review lifecycle: no review events in the window.");
+    return;
+  }
+  console.log(`Review lifecycle: ${formatAdminCounts(totals.actions)}.`);
+  if (Object.keys(totals.thumbnails || {}).length)
+    console.log(
+      `  automatic thumbnail after review publishes: ${formatAdminCounts(totals.thumbnails)}`,
+    );
+  if (Object.keys(totals.refusals || {}).length)
+    console.log(
+      `  refused decisions (decision:code): ${formatAdminCounts(totals.refusals)}`,
+    );
+}
+
 function printRewardActivity(data) {
   const apps = Array.isArray(data.apps) ? data.apps : [];
   const suspects = Array.isArray(data.suspects) ? data.suspects : [];
@@ -3968,6 +3998,7 @@ function printRewardActivity(data) {
       `  app ${app.buildId} ${app.title}: ${app.claims} claim(s) · ${app.earners} earner(s) · ${app.xp} XP · ${app.coins} Coins · ${app.flagged} flagged`,
     );
   }
+  printRewardReviewLifecycle(data.reviewLifecycle);
   if (!suspects.length) {
     console.log(
       "Nothing unusual: no claim on the minimum time, no bursts, no sweeps, no repeated cap days, no guessing.",

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/lib/sdk.js

@@ -180,6 +180,16 @@ export const SDK_CLI_METHODS = {
     readOnly: true,
     mapArgs: (args) => ({ challengeId: args.challengeId }),
   },
+  "rewards.getTimeline": {
+    path: "api/rewards/timeline", special: "rewards", operation: "timeline",
+    scopes: ["rewards:claim"], readOnly: true,
+    mapArgs: (args) => ({ ruleId: args.ruleId, cursor: args.cursor, limit: args.limit }),
+  },
+  "rewards.getArchivedProblem": {
+    path: "api/rewards/archived-problem", special: "rewards", operation: "archived-problem",
+    scopes: ["rewards:claim"], readOnly: true,
+    mapArgs: (args) => ({ receiptId: args.receiptId }),
+  },
   "rewards.start": {
     path: "api/rewards/start",
     special: "rewards",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stage5/lumine",
-  "version": "0.2.79",
+  "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-14T06:42:36.041Z
+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-14T06:42:36.041Z
 - 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.
 
@@ -1037,6 +1037,17 @@ world.updatePresence({ x, y, z, facing });
   - Standings of who earned the most XP or Coins in THIS app, computed by Twinkle from its own receipts (never from anything the app submits). period 'day' is today (site day, UTC), 'week' the last 7 site days, 'all' (default) every day since approval. limit defaults to 20, max 100.
   - available says which boards this app's approved rules can pay: show a Coins board only when available.coins is true (an app whose rules pay XP only has no Coins standings). me is the signed-in viewer's own standing even when they fall outside the page, or null when they earned nothing in the period.
   - Drafts and previews return mode 'preview' with no entries. Use Twinkle.leaderboards for app-defined scores; use this for real XP and Coins earned.
+- await Twinkle.rewards.getTimeline({ ruleId?, cursor?, limit? } = {}) | scopes: rewards:claim
+  - Returns: { mode: "live", dayKey, entries: [{ receiptId, ruleId, ruleTitle, setKey, title, promptPreview, dayKey, closedAt, solvedAt, solver: { userId, username }, firstSolver, xp, coins, attempt }], nextCursor } | { mode: "preview", entries: [], nextCursor: null, message }
+  - Browse confirmed solves of retired until-earned quiz bounties, newest first.
+  - A solve appears only after the next site reset (UTC midnight, 9 AM Korea). Today’s solves, unsolved sets, standing quizzes and dated quizzes are excluded. The server decides retirement; client dates cannot unlock content. Zero-reward correct solves are included.
+  - One entry per solve receipt, with firstSolver identifying the first receipt for that rule and set across approved versions. limit defaults to 20, max 50; pass nextCursor unchanged for older solves and omit it when changing ruleId. Pages may have fewer entries when old question sheets cannot be recovered; continue while nextCursor is present.
+  - No daily-claim limit applies to reading. Requires the current approved published runtime grant; previews return an empty timeline. Never awards or changes balances. Open a receipt with getArchivedProblem to load the original question and guide.
+- await Twinkle.rewards.getArchivedProblem({ receiptId }) | scopes: rewards:claim
+  - Returns: { mode: "live", entry: <same solve entry as getTimeline>, questions: [{ prompt, hint?, guide? }] } | { mode: "preview", entry: null, questions: [], message }
+  - Read a retired bounty’s original questions and guides from the approval attached to its solve receipt.
+  - Use a receiptId returned by getTimeline. Both reads independently check retirement and app ownership; guessing an active or other app’s receipt cannot reveal its questions or guides. Returns build_reward_archive_unavailable (404) if unavailable.
+  - Uses that receipt’s frozen approved sheet, never today’s edited question or the mutable draft. Answer keys and tolerances are never returned. Render the question first and offer Reveal guide for learning, without a reward-claim button.
 
 ## Examples
 

package/sdk/LUMINE_ADMIN.md

@@ -1018,6 +1018,34 @@ Mikey gives his go-ahead; a pending proposal is not a completed refresh. After
 approval, execute the entire approved plan and verify it without asking for
 each swap again. Never omit this section from a full-run report.
 
+### Full management report in Chrome
+
+Mikey's standing delivery preference (2026-09-15): after a full daily run, open
+the **complete management report as a browsable localhost page in Chrome**.
+Do this as part of finishing the authorized run; a Markdown path in chat alone
+is insufficient, and no additional confirmation is needed to open the report.
+
+1. Save the complete report as
+   `/private/tmp/twinkle-daily-YYYY-MM-DD/daily-management-report.md`, using the
+   run's Bangkok date. Include every required reporting section, coverage gap,
+   pending decision and carryover. Reflect later owner decisions accurately.
+2. Render the entire Markdown into a readable HTML page with section links,
+   usable tables and access to the original Markdown. Preserve complete
+   appendices and flagged rows; navigation or collapsible details must not
+   discard them. Use local assets so the report does not depend on a CDN.
+3. Serve the view on `127.0.0.1` using an available port. Expose only the HTML,
+   its required assets and the report Markdown through a dedicated directory
+   or explicit routes; do not serve the surrounding private evidence folder.
+   Keep the server available after the response so Mikey can browse it.
+4. Open the localhost URL in Mikey's Chrome. Verify that the page renders,
+   section navigation works, and the full report is accessible. Keep the
+   report tab open. Include both the localhost URL and Markdown file link in
+   the final response.
+
+For a follow-up that only opens or updates an existing report, reuse that
+report and its existing tab/server where available. This does not authorize
+starting another management run or repeating unrelated daily duties.
+
 Creating an escalation belongs to the active run; acknowledging, annotating,
 resolving, or reopening it does not. Use the run-independent `escalation`
 commands after Mikey responds instead of starting a follow-up delegated run.
@@ -1115,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 },
@@ -1163,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
@@ -1239,6 +1268,24 @@ open the player with `admin identity inspect` before proposing anything, and
 propose to Mikey (revoke the app's rule, or a bucket ban) rather than acting.
 Never revoke an approval from a daily run.
 
+The same report carries `reviewLifecycle` (added 2026-09-15): the reviews'
+audit trail counted per UTC day (`byDay`) and for the window (`totals`).
+`actions` counts every event: `request`, `approve`/`reject`/`revoke`,
+`publish` (the approved version went live), `propose`, `proposal_viewed` (the
+creator opened an offer's comparison; once per revision), `accept`/`decline`,
+`thumbnail` and `<decision>_refused`. `thumbnails` is the automatic thumbnail
+after a review publish: `captured`, `existing` (the app already had one),
+`superseded` (the creator's own thumbnail or a newer release won),
+`not_needed`, `owner_missing` or `failed`. `refusals` counts conflicts that
+rolled back, keyed `decision:code` (for example
+`approve:build_reward_review_stale`, `accept:build_reward_proposal_stale`).
+Report the totals. Each `failed` thumbnail and each `publish` without a
+`thumbnail` event on a completed day is a carry-over todo with the review
+ids (`reward-review show <id>` lists its events). An `accept` without a
+`proposal_viewed` for that revision means the creator accepted without opening
+the comparison; mention it, it is not a fault. Refusals are the concurrency
+guards working; report them, and escalate only a repeated pattern on one app.
+
 ## Private carry-over todos
 
 ```bash
@@ -2273,6 +2320,21 @@ type PostSkip = Success<{
 
 ## Twinkle Newspaper
 
+**Audience (Mikey, 2026-09-15): children and young Twinkle users aged 10–15.**
+Choose and write stories for what these readers would voluntarily spend time
+reading. Before selecting a story, identify its appeal to them: curiosity,
+humor, a relatable experience, a creative idea, something useful, or a chance
+to join in. Games, art, puzzles, friendships, shared reflections, and community
+discussions can all supply good stories; read the actual source to find the
+substance.
+
+Use clear, lively language that respects readers' intelligence. Give enough
+context for someone who missed the original post, and make the interesting
+part clear in the headline and opening. Avoid talking down to readers, forced
+slang, preachy lessons, administrative summaries, and blurbs that merely say
+someone uploaded or posted something. Keep the appeal grounded in the source;
+never invent excitement, reactions, popularity, or drama.
+
 ```bash
 lumine admin news --json
 lumine admin news claim --output claim.json --scaffold editorial.json --json
@@ -2311,6 +2373,7 @@ re-checked transactionally at commit.
 
 ```ts
 type GeneratedEditorial = {
+  excludedSubjectEventKeys?: string[]; // experiment-video Subjects omitted entirely
   mastheadHeadline: string;
   mastheadDeck: string;
   lead: {
@@ -2336,6 +2399,20 @@ nothing disappears silently: digest events the editorial does not account for
 are added back. Two mechanisms make real curation possible within that
 guarantee:
 
+**Exception — experiment videos (Mikey, 2026-09-15):** exclude these entirely,
+including school science-contest entries. The editor/model identifies them from
+the supplied context and lists their exact keys in `excludedSubjectEventKeys`.
+Do not cite, summarize, or group them into newspaper coverage. The API must have
+this exclusion support deployed before submitting such an editorial; older APIs
+ignore the field and restore the posts. The server accepts only canonical Subject
+keys and never lets this field remove official announcements. After excluding
+these posts, look for worthwhile replacement stories among the edition's eligible
+Subjects and shared Daily Reflections. A bounded digest dominated by experiment
+videos does not establish that the day has no other stories. Check the available
+canonical sources within the coverage window, and keep replacement stories within
+the claim and citation contract. Do not stop at deletion when suitable material
+is available, or invent filler to reach an article count.
+
 - **`coveredEventKeys`** — an arc story may list the other events it narrates
   (an app's release + its update stream + its open-sourcing; one member's
   related posts). Covered events are omitted from the layout — the arc IS
@@ -2368,17 +2445,17 @@ within the returned digest. On a typical day every front subject arrives with
 the same priority, so treat a tied score (or recency) as no signal at all and
 make the call by reading:
 
-- **Choose the lead by argument, not by score or recency.** The best lead is
-  the front event where something is actually _at stake_: a claim with
-  reasoning, a question with a position behind it — ideally while another
-  member is already responding. A claim plus a reply is a conversation in
-  motion; a drawing, a greeting, or a link is a share, and shares belong
-  further down the page, not in the lead.
+- **Choose the lead for readers aged 10–15.** Lead with the eligible front
+  event whose substance is most likely to catch their interest and reward
+  reading. A thoughtful conversation, a funny or relatable reflection, a
+  striking creation, or an inviting community challenge can all qualify.
+  Read the source and any supplied replies to understand the appeal; priority,
+  recency, and the mere presence of an argument do not decide the lead.
 - **Thread a theme through the paper.** Pick the strongest idea of the day
   and let the masthead, the lead, and the editor's note all carry it, with
-  the editor's note reprising a community value from one of the day's posts
-  rather than summarizing the edition. The paper should end on something a
-  child can take with them.
+  the editor's note leaving readers with an observation, question, or invitation
+  grounded in one of the day's posts. Let a theme emerge from the material;
+  keep each story's meaning intact and avoid forcing a moral lesson.
 - **Cross-reference events into arcs.** The same thing often appears in the
   digest several times (an app's release, its open-sourcing, and its maker's
   Daily Reflection about it). Write those as one story arc — the origin
@@ -2594,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
@@ -2653,14 +2748,14 @@ The additive host-owner migration and compatible API must be live before this
 CLI capability is published.
 
 Review every participating host, including primary private-helper logs. A
-primary review does not cover the target. Finish the exclusive review before
-that host is held; a held/unavailable owner returns an explicit retryable failure,
-not another host's snapshots or an independent log service. Do not abandon its
-lease merely to bypass a deployment guard. After a planned hold, final shutdown
-deltas are reviewed via management SSH outside any active lease, recorded, and
-API stderr is cleared only with the existing guarded `npm run logs:clear-errors`
-plus post-clear re-read. This is the deployment runbook's final boundary, not
-permission to bypass an active Lumine lease. A stopped target whose final logs
+primary review does not cover the target. An open review does not block a
+deployment or host hold. Its files, lease and database boundaries persist;
+active requests use the normal drain. A held or unavailable owner returns a
+retryable failure, so keep the session and retry when that host is available
+again. Release operators can review final shutdown deltas via management SSH
+and record their own evidence. An active review keeps ownership of clearing;
+otherwise API stderr is cleared with the existing guarded
+`npm run logs:clear-errors` plus post-clear re-read. A stopped target whose final logs
 were reviewed does not need to be started for daily management; starting EC2
 requires separate authority. See `twinkle-api/DEPLOY_TIME_HANDOFF.md`.
 
@@ -3035,9 +3130,16 @@ energy ledger (`chargedUsd`, `overflowUsd`, `users`, `recharges`; 1,000,000
 units = $1), every telemetry counter (`busy_refusal`, `autofix_yielded`,
 `autofix_superseded`, `reservation_admitted` with `avgRunBudgetUsd`,
 `budget_stop_changed` / `budget_stop_unchanged` / `run_completed` with a
-per-model breakdown, `stop_settled`, `tool_limit_settled`) and per-model
-per-run usage stats (`runs`, `callsPerRun`, `usdPerRun`, each avg and
-nearest-rank p90). The current UTC day is returned with `inProgress: true`.
+per-model breakdown, `stop_settled`, `tool_limit_settled`, and since
+2026-09-15 the queued-request counters `queued_restored` (a workspace reload
+restored its owner's still-queued request, shown with Stop), `queued_stopped`
+(Stop cancelled a request while it was still queued) and
+`busy_resume_requested` (after a busy refusal the website resumed the
+existing request)) and per-model per-run usage stats (`runs`, `callsPerRun`,
+`usdPerRun`, each avg and nearest-rank p90). `busy_refusal` with no
+`busy_resume_requested` on a day with website traffic means clients are not
+resuming the refused request; `queued_restored` shows how often creators
+reload while waiting in the queue. The current UTC day is returned with `inProgress: true`.
 **Headline `lastCompletedDay` (its exact `dayKey`) — never the in-progress
 day**, exactly as the closed-day AI-cost duty does.