@stage5/lumine 0.2.78 → 0.2.80

package/lib/admin.js

@@ -139,6 +139,80 @@ function readBuildReviewContextFile(filePath) {
 const MAX_REWARD_CONFIG_FILE_BYTES = 256 * 1024;
 const REWARD_REVIEW_STATUSES = ["pending", "approved", "all"];
 const REWARD_REVIEW_DECISIONS = ["approve", "reject", "revoke"];
+const REWARD_PROPOSAL_MAX_FILES = 500;
+const REWARD_PROPOSAL_MAX_BYTES = 5 * 1024 * 1024;
+const REWARD_PROPOSAL_SKIPPED_DIRS = new Set([
+  ".git",
+  "node_modules",
+  ".lumine",
+  ".twinkle",
+]);
+
+// Reads a reviewer's edited copy of a reward-review snapshot (a directory
+// written by `show --dir`, then edited) back into project files for
+// `reward-review propose`. Text files only; dotfiles and tool directories
+// are skipped; paths are confined to the directory.
+export function readRewardProposalDirectory(directory) {
+  const requested = String(directory || "").trim();
+  if (!requested) {
+    throw cliValidationError(
+      "Pass the edited snapshot directory with --dir <path>.",
+    );
+  }
+  const root = path.resolve(requested);
+  let rootStat;
+  try {
+    rootStat = lstatSync(root);
+  } catch {
+    throw cliValidationError(`--dir ${root} does not exist.`);
+  }
+  if (!rootStat.isDirectory()) {
+    throw cliValidationError(`--dir ${root} must be a directory.`);
+  }
+  const realRoot = realpathSync(root);
+  const files = [];
+  let bytes = 0;
+  const walk = (dir) => {
+    for (const entry of readdirSync(dir, { withFileTypes: true })) {
+      if (entry.name.startsWith(".") || REWARD_PROPOSAL_SKIPPED_DIRS.has(entry.name))
+        continue;
+      const fullPath = path.join(dir, entry.name);
+      if (entry.isSymbolicLink()) {
+        throw cliValidationError(
+          `Refusing to read symlink inside the proposal directory: ${fullPath}`,
+        );
+      }
+      if (entry.isDirectory()) {
+        walk(fullPath);
+        continue;
+      }
+      if (!entry.isFile()) continue;
+      const buffer = readFileSync(fullPath);
+      if (buffer.includes(0)) {
+        throw cliValidationError(
+          `${fullPath} is not a text file. Twinkle project files must be UTF-8 text; media belongs in build assets.`,
+        );
+      }
+      bytes += buffer.length;
+      const relative = path.relative(realRoot, fullPath).split(path.sep).join("/");
+      files.push({ path: `/${relative}`, content: buffer.toString("utf8") });
+    }
+  };
+  walk(realRoot);
+  if (files.length === 0) {
+    throw cliValidationError(`--dir ${root} holds no project files.`);
+  }
+  if (files.length > REWARD_PROPOSAL_MAX_FILES) {
+    throw cliValidationError(
+      `A proposal may carry at most ${REWARD_PROPOSAL_MAX_FILES} files.`,
+    );
+  }
+  if (bytes > REWARD_PROPOSAL_MAX_BYTES) {
+    throw cliValidationError("A proposal may carry at most 5 MB of files.");
+  }
+  files.sort((a, b) => a.path.localeCompare(b.path));
+  return files;
+}
 
 // The reviewer's earning rules for one Build reward approval: budgets plus
 // server-verified numeric-quiz rules keyed by the rule IDs the app source
@@ -1453,6 +1527,32 @@ export function parseAdminOperation(options) {
         { requiresRun: false, reviewId, snapshotDir },
       );
     }
+    if (action === "propose") {
+      // Offer an edited copy of the snapshot as the condition of approval:
+      // the creator accepts (which publishes it) or declines (which rejects).
+      const reviewId = parseRequiredInteger(target, "Reward review ID", 1);
+      const reason = String(options.adminReason || "").trim();
+      if (reason.length > 1000) {
+        throw cliValidationError("--reason must be at most 1000 characters.");
+      }
+      if (!options.adminConfigFile) {
+        throw cliValidationError(
+          "lumine admin reward-review propose <id> needs --config <rules.json> (the rules the creator's acceptance publishes) and --dir <edited snapshot>.",
+        );
+      }
+      const files = readRewardProposalDirectory(options.dir);
+      return writeOperation(
+        "reward-review.propose",
+        "POST",
+        `/cli/admin/reward-reviews/${reviewId}/propose`,
+        {
+          files,
+          config: readRewardConfigFile(options.adminConfigFile),
+          reason,
+        },
+        { requiresRun: false, reviewId, fileCount: files.length },
+      );
+    }
     if (REWARD_REVIEW_DECISIONS.includes(action)) {
       const reviewId = parseRequiredInteger(target, "Reward review ID", 1);
       const reason = String(options.adminReason || "").trim();
@@ -1484,7 +1584,7 @@ export function parseAdminOperation(options) {
       );
     }
     throw cliValidationError(
-      "Usage: lumine admin reward-review list [--status pending|approved|all] [--cursor <id>] | show <id> [--dir <path>] | approve <id> [--config <rules.json>] [--reason <text>] | reject <id> --reason <text> | revoke <id> --reason <text>.",
+      "Usage: lumine admin reward-review list [--status pending|approved|all] [--cursor <id>] | show <id> [--dir <path>] | approve <id> [--config <rules.json>] [--reason <text>] | propose <id> --dir <edited-snapshot> --config <rules.json> [--reason <text>] | reject <id> --reason <text> | revoke <id> --reason <text>.",
     );
   }
 
@@ -3519,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.");
@@ -3794,6 +3898,32 @@ function printRewardReviewResult({ operation, data }) {
     console.log(
       `Decision recorded: ${operation.decision}. ${review.reason ? `Reason: ${review.reason}` : ""}`.trim(),
     );
+    if (review.published) {
+      console.log(
+        `Published on approval: version ${review.published.version} (artifact ${review.published.artifactVersionId}, ${review.published.transition}). The app is live now.`,
+      );
+    }
+  }
+  if (operation.name === "reward-review.propose") {
+    console.log(
+      `Proposal offered to the creator (${operation.fileCount} file(s) sent). They can accept (which publishes your version with these rules) or decline (which rejects the request).`,
+    );
+  }
+  if (review.proposal) {
+    const summary = review.proposal.diffSummary || {};
+    console.log(
+      `Proposal: ${summary.total ?? 0} file(s) changed (${summary.added ?? 0} added, ${summary.updated ?? 0} updated, ${summary.deleted ?? 0} deleted)${review.proposal.note ? ` · note: ${review.proposal.note}` : ""}${review.status === "changes_offered" ? " · waiting for the creator" : ""}`,
+    );
+    for (const file of review.proposal.changedFiles || [])
+      console.log(`  ${file.status}: ${file.path}`);
+  }
+  if (review.status === "rejected" && review.declinedByCreator) {
+    console.log("The creator declined the proposed changes; the request is closed.");
+  }
+  if (review.status === "approved" && review.publishedArtifactVersionId) {
+    console.log(
+      `Approved and published (artifact version ${review.publishedArtifactVersionId}).`,
+    );
   }
   if (Array.isArray(review.detectedRuleIds)) {
     console.log(
@@ -3831,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 : [];
@@ -3842,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/commands.js

@@ -2902,7 +2902,8 @@ export function printHelp() {
   lumine admin reward-review list [--status pending|approved|all] [--cursor <id>] [--json]
   lumine admin reward-activity [--date YYYY-MM-DD] [--days <1..31>] [--build <id>] [--json]
   lumine admin reward-review show <review-id> [--dir <path>] [--json]
-  lumine admin reward-review approve <review-id> [--config <rules.json>] [--reason <text>] [--json]
+  lumine admin reward-review approve <review-id> [--config <rules.json>] [--reason <text>] [--json]   (approval publishes the approved version)
+  lumine admin reward-review propose <review-id> --dir <edited-snapshot> --config <rules.json> [--reason <text>] [--json]
   lumine admin reward-review reject|revoke <review-id> --reason <text> [--json]
   lumine admin recommendations list [--since-run|--after <date>|--include-legacy] [--all --checkpoint <file> [--resume]] [--content-types comment,dailyReflection] [--unviewed|--viewed] [--cursor <cursor>] [--json]
   lumine admin builds candidates [--since-run|--after <date>|--include-legacy] [--all --checkpoint <file> [--resume]] [--cursor <cursor>] [--limit <number>] [--json]
@@ -3015,7 +3016,7 @@ Options:
   --preview-url <url>   Twinkle Build preview origin
   --auth-file <path>    Saved login path
   --auth-token <token>  Override saved login
-  --dir <path>          Directory for pulled project files or a reward-review source snapshot
+  --dir <path>          Directory for pulled project files, a reward-review source snapshot, or the edited snapshot a reward-review proposal sends
   --config <file>       Replacement earning rules JSON for reward-review approve (default: the app's own proposal)
   --provider <agent>    Subscription agent for lumine agent: codex or claude-code
   --provider-path <p>   Override the selected agent CLI executable

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.78",
+  "version": "0.2.80",
   "description": "Command line tools for launching Lumine builds on Twinkle.",
   "type": "module",
   "bin": {

package/sdk/BUILD_SDK_INDEX.md

@@ -2,7 +2,7 @@
 
 Version: 1.45.0
 Updated: 2026-09-14
-Generated: 2026-09-14T06:42:36.041Z
+Generated: 2026-09-15T02:06:06.654Z
 
 ## Notes
 - This SDK is injected into Build iframes via the Build preview/runtime.
@@ -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.
@@ -1065,9 +1093,16 @@ and answer keys from a private question sheet the creator's Lumine uploads with
 readable by every player). **Send for review** freezes the code and proposes
 `rewards.json` merged with the sheet. Approval is Mikey's decision: read the
 frozen code, check that the amounts are right and that the app cannot be
-farmed, change anything that is wrong, approve. These commands need no daily
-run and can be used whenever a request arrives (the reviewer also receives a
-DM card per request).
+farmed, change anything that is wrong, approve. **Approval publishes** (since
+2026-09-15): the exact frozen snapshot goes live in the same transaction, with
+no Publish click by the creator; the app's previous release stays up until
+that commit lands. Instead of approving, the reviewer may **propose changes**:
+edit a copy of the frozen snapshot and offer it as the condition of approval.
+The creator sees every changed line and either accepts (the proposed version
+is approved and published) or declines (the request is rejected). Nothing in
+that flow joins the creator's team. These commands need no daily run and can
+be used whenever a request arrives (the reviewer also receives a DM card per
+request).
 
 ```bash
 lumine admin reward-review list --json                       # pending (default)
@@ -1077,7 +1112,10 @@ lumine admin reward-review show 2 --json                     # summary + file si
 lumine admin reward-review show 2 --dir /private/tmp/reward-review-2 --json
 lumine admin reward-review approve 2 --json                  # approve exactly what the app proposed
 lumine admin reward-review approve 2 --config rules.json \
-  --reason "Halved the stage amounts" --json                 # approve with changes
+  --reason "Halved the stage amounts" --json                 # approve with changes (publishes)
+lumine admin reward-review show 2 --dir /private/tmp/reward-review-2 --json   # then edit that directory…
+lumine admin reward-review propose 2 --dir /private/tmp/reward-review-2 \
+  --config rules.json --reason "Moved the claim after the stage clears" --json  # …and offer it
 lumine admin reward-review reject 2 --reason "Rewards fire on game over; nothing is earned" --json
 lumine admin reward-review revoke 2 --reason "Farmable; pausing until redesigned" --json
 ```
@@ -1156,12 +1194,49 @@ Arcade Typing (Mikey, 2026-09-12): XP for clearing campaign stages, up to
 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.
 
-Approval freezes these rules with the reviewed snapshot; an approval without at
-least one rule is refused. Rejection and revocation require a `--reason` the
-creator reads verbatim in their workspace. Approval never publishes: the creator
-publishes the approved version themselves, and a later code save needs a new
-request. Never approve without reading the code; never approve a request whose
-`isLatest` is false.
+Approval freezes these rules with the reviewed snapshot and publishes that
+snapshot immediately (the result carries `published.version`); an approval
+without at least one rule is refused, and an approval whose creator has saved
+past the frozen version is refused as `build_reward_review_stale` (the request
+also closes itself on that save). Rejection and revocation require a
+`--reason` the creator reads verbatim in their workspace. A later code save
+needs a new request. Never approve without reading the code; never approve a
+request whose `isLatest` is false.
+
+`propose <id> --dir <edited> --config rules.json [--reason]` sends the edited
+directory (text files only; dotfiles and tool folders skipped) as the
+reviewer's proposal: the review moves to `changes_offered`, the creator's card
+and workspace show the note and every changed line, and the creator's
+**Accept & go live** publishes exactly those files with these rules (their
+workspace is replaced by the accepted version). **No thanks** rejects the
+request (`declinedByCreator: true`). A proposal must still use the rewards
+SDK, must differ from the submitted snapshot, and is refused once the creator
+saves past the submitted version. Offering again replaces the earlier offer;
+approving or rejecting while an offer is out decides the request as
+submitted. The website equivalent is the Management panel's "Edit a copy to
+propose changes" (a private workspace copy owned by the reviewer) followed by
+"Offer my copy with these rules".
+
+Each offer has a server-owned revision. Changing the files, rules or note
+creates a new revision; a creator looking at an older comparison or decline
+confirmation cannot answer the replacement offer. The creator sees its reward
+amounts as well as its file changes. Proposed rules stay separate from the
+submitted rules until acceptance, so `approve` without `--config` still uses
+the original submitted configuration. The CLI audits the offer atomically
+and includes file contents in its retry fingerprint.
+
+Approval also attempts a free preview thumbnail when the app has none. That
+capture uses the published version and cannot overwrite a later release or a
+thumbnail the creator chooses while it runs. It is best effort: a capture
+failure leaves publication successful and does not spend AI-image credits.
+
+The review copy carries independent copies of referenced uploaded media.
+Before freezing an offer, the server reuses the creator's original media and
+copies new reviewer media into the creator's library within their storage
+quota. Its final URLs are included in the comparison, so acceptance publishes
+those exact files and does not depend on keeping the review copy. Re-offers
+reuse the media; a failed transaction cleans up its copied objects. Declining
+leaves the offered media as unused uploads in the creator's library.
 
 ### Reward activity report (standing duty, every full daily review; added 2026-09-12)
 
@@ -1192,6 +1267,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
@@ -2226,6 +2319,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
@@ -2264,6 +2372,7 @@ re-checked transactionally at commit.
 
 ```ts
 type GeneratedEditorial = {
+  excludedSubjectEventKeys?: string[]; // experiment-video Subjects omitted entirely
   mastheadHeadline: string;
   mastheadDeck: string;
   lead: {
@@ -2289,6 +2398,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
@@ -2321,17 +2444,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
@@ -2606,14 +2729,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`.
 
@@ -2988,9 +3111,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.