@stage5/lumine 0.2.79 → 0.2.80

package/lib/admin.js

@@ -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.");
@@ -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/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.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.
@@ -1239,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
@@ -2273,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
@@ -2311,6 +2372,7 @@ re-checked transactionally at commit.
 
 ```ts
 type GeneratedEditorial = {
+  excludedSubjectEventKeys?: string[]; // experiment-video Subjects omitted entirely
   mastheadHeadline: string;
   mastheadDeck: string;
   lead: {
@@ -2336,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
@@ -2368,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
@@ -2653,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`.
 
@@ -3035,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.