@stage5/lumine 0.2.85 → 0.2.86

package/lib/api.js

@@ -439,6 +439,39 @@ export async function adoptBuildThumbnailSuggestion({
   });
 }
 
+export async function suggestBuildTitleToOwner({
+  options,
+  auth,
+  rootBuildId,
+  contributionBuildId,
+  title,
+  note,
+}) {
+  return await requestJson({
+    method: "POST",
+    url: `${options.apiUrl}/build/${rootBuildId}/contributions/${contributionBuildId}/suggest-title`,
+    authToken: auth.token,
+    body: { title, note },
+    timeoutMs: options.timeoutMs,
+  });
+}
+
+export async function adoptBuildTitleSuggestion({
+  options,
+  auth,
+  rootBuildId,
+  contributionBuildId,
+  suggestionMessageId,
+}) {
+  return await requestJson({
+    method: "POST",
+    url: `${options.apiUrl}/build/${rootBuildId}/contributions/${contributionBuildId}/adopt-title`,
+    authToken: auth.token,
+    body: { suggestionMessageId },
+    timeoutMs: options.timeoutMs,
+  });
+}
+
 export async function mergeContributionIntoMain({
   options,
   auth,

package/lib/commands.js

@@ -22,6 +22,7 @@ import {
 } from "./constants.js";
 import {
   adoptBuildThumbnailSuggestion,
+  adoptBuildTitleSuggestion,
   createBuild,
   fetchAllRuntimeAssets,
   forkBuild,
@@ -45,6 +46,7 @@ import {
   resolveBranchBuild,
   saveProjectFiles,
   suggestBuildThumbnailToOwner,
+  suggestBuildTitleToOwner,
   updateBuildMetadata,
   upgradeBuildProjectLimits,
 } from "./api.js";
@@ -523,11 +525,22 @@ export async function forum(options) {
 
 export async function sendSuggestion(options) {
   const suggestionType = String(options.suggestionAction || "").trim();
-  if (suggestionType !== "branch" && suggestionType !== "thumbnail") {
+  if (!["branch", "thumbnail", "title"].includes(suggestionType)) {
     throw new Error(
-      "Usage: lumine suggest branch [--note <message>] | lumine suggest thumbnail",
+      'Usage: lumine suggest branch [--note <message>] | lumine suggest thumbnail | lumine suggest title "New Name" [--note <why>]',
     );
   }
+  const suggestedTitle =
+    suggestionType === "title"
+      ? String(
+          options.title || (options.positional || []).slice(1).join(" "),
+        )
+          .replace(/\s+/g, " ")
+          .trim()
+      : "";
+  if (suggestionType === "title" && !suggestedTitle) {
+    throw new Error('Pass the name: lumine suggest title "New Name" [--note <why>]');
+  }
   const auth = await resolveAuth(options);
   await assertAuthScope({ options, auth, scope: "build:write" });
   const build = await loadTargetBuildMetadata({ options, auth });
@@ -548,6 +561,21 @@ export async function sendSuggestion(options) {
     return;
   }
 
+  if (suggestionType === "title") {
+    await suggestBuildTitleToOwner({
+      options,
+      auth,
+      rootBuildId,
+      contributionBuildId,
+      title: suggestedTitle,
+      note: options.note,
+    });
+    console.log(
+      `Suggested the name "${suggestedTitle}" to the owner of Build #${rootBuildId}. They can use it from their chat or with \`lumine suggestions adopt-title\`.`,
+    );
+    return;
+  }
+
   await suggestBuildThumbnailToOwner({
     options,
     auth,
@@ -696,8 +724,38 @@ export async function suggestions(options) {
     return;
   }
 
+  if (action === "adopt-title") {
+    if (suggestion.type !== "title") {
+      throw new Error(`Suggestion #${suggestionId} is not a name suggestion.`);
+    }
+    if (!options.assumeYes) {
+      const confirmed = await confirmPrompt(
+        `Rename Build #${rootBuildId} from "${suggestion.currentTitle}" to "${suggestion.suggestedTitle}"? [y/N] `,
+      );
+      if (confirmed === null) {
+        console.log("Not a TTY — re-run with --yes to rename the Build.");
+        return;
+      }
+      if (!confirmed) {
+        console.log("Aborted. Name unchanged.");
+        return;
+      }
+    }
+    const adoptResult = await adoptBuildTitleSuggestion({
+      options,
+      auth,
+      rootBuildId,
+      contributionBuildId,
+      suggestionMessageId: suggestionId,
+    });
+    console.log(
+      `Renamed Build #${rootBuildId} to "${String(adoptResult?.build?.title || suggestion.suggestedTitle)}" (suggestion #${suggestionId}).`,
+    );
+    return;
+  }
+
   throw new Error(
-    "Usage: lumine suggestions [build] | lumine suggestions merge|replace-main|adopt-thumbnail <suggestion-id> [--build <id>]",
+    "Usage: lumine suggestions [build] | lumine suggestions merge|replace-main|adopt-thumbnail|adopt-title <suggestion-id> [--build <id>]",
   );
 }
 
@@ -723,8 +781,8 @@ export function printBuildSuggestions({
   if (!suggestions.length) {
     console.log(
       hasMore
-        ? "No open branch or thumbnail suggestions on this page."
-        : "No open branch or thumbnail suggestions.",
+        ? "No open branch, thumbnail or name suggestions on this page."
+        : "No open branch, thumbnail or name suggestions.",
     );
     if (hasMore && nextCursor > 0) {
       console.log(
@@ -761,6 +819,17 @@ export function printBuildSuggestions({
       );
       continue;
     }
+    if (suggestion.type === "title") {
+      console.log(
+        `[#${suggestionId}] ${contributor} suggested a new name from ${branchLabel} (${createdAt})`,
+      );
+      console.log(`  "${suggestion.currentTitle}" → "${suggestion.suggestedTitle}"`);
+      if (suggestion.note) console.log(`  ${suggestion.note}`);
+      console.log(
+        `  apply: lumine suggestions adopt-title ${suggestionId} --build ${rootBuildId}`,
+      );
+      continue;
+    }
     console.log(
       `[#${suggestionId}] ${contributor} suggested a thumbnail from ${branchLabel} (${createdAt})`,
     );
@@ -2342,6 +2411,7 @@ export function parseArgs(args) {
     "merge",
     "replace-main",
     "adopt-thumbnail",
+    "adopt-title",
   ]);
   const suggestionAction =
     command === "suggest"
@@ -2840,10 +2910,12 @@ export function printHelp() {
   lumine forum listen [twinkle-build-url-or-id] [--cursor <sequence>] [--poll-ms <ms>] [--json]
   lumine suggest branch [message] [--target <twinkle-branch-url>]
   lumine suggest thumbnail [--target <twinkle-branch-url>]
+  lumine suggest title "New Name" [--note <why>] [--target <twinkle-branch-url>]
   lumine suggestions [twinkle-build-url-or-id]
   lumine suggestions merge <suggestion-id> [--build <id>]
   lumine suggestions replace-main <suggestion-id> [--build <id>]
   lumine suggestions adopt-thumbnail <suggestion-id> [--build <id>] [--yes]
+  lumine suggestions adopt-title <suggestion-id> [--build <id>] [--yes]
   lumine explore [search terms]
   lumine select [twinkle-build-url]
   lumine pull [twinkle-build-url]

package/lib/constants.js

@@ -225,11 +225,14 @@ lumine save --summary "Describe the change"
 
 - After saving contribution-branch work, use \`lumine suggest branch "Ready for review"\`
   when the user wants to notify the project owner. Use \`lumine suggest thumbnail\`
-  when the branch's current thumbnail should be offered to the owner.
+  when the branch's current thumbnail should be offered to the owner. Only the
+  owner can rename the project: when the user wants a different app name, use
+  \`lumine suggest title "New Name" --note "why"\` instead of renaming.
 - On an owned canonical team project, \`lumine suggestions\` lists the owner's
-  currently open branch and thumbnail suggestions. Act on the exact suggestion
-  id it prints with \`lumine suggestions merge\`, \`replace-main\`, or
-  \`adopt-thumbnail\`; do not infer an action from stale local branch state.
+  currently open branch, thumbnail and name suggestions. Act on the exact
+  suggestion id it prints with \`lumine suggestions merge\`, \`replace-main\`,
+  \`adopt-thumbnail\` or \`adopt-title\`; do not infer an action from stale
+  local branch state.
 
 ## Assets (Runtime Media)
 

package/lib/sdk.js

@@ -204,7 +204,11 @@ export const SDK_CLI_METHODS = {
     operation: "claim",
     scopes: ["rewards:claim"],
     write: true,
-    mapArgs: (args) => ({ challengeId: args.challengeId, answers: args.answers }),
+    mapArgs: (args) => ({
+      challengeId: args.challengeId,
+      answers: args.answers,
+      ...(args.completionToken !== undefined ? { completionToken: args.completionToken } : {}),
+    }),
   },
   // Leaderboards use the public leaderboard routes (regular login auth, no
   // build API token). args.boardKey selects the board; remaining args are

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stage5/lumine",
-  "version": "0.2.85",
+  "version": "0.2.86",
   "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.47.0
 Updated: 2026-09-21
-Generated: 2026-09-23T00:59:59.504Z
+Generated: 2026-09-23T02:44:06.901Z
 
 ## Notes
 - This SDK is injected into Build iframes via the Build preview/runtime.
@@ -36,7 +36,7 @@ Generated: 2026-09-23T00:59:59.504Z
 - 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.
-- Optional reward rule controls: maxLifetimeClaims caps one learner’s receipts for that rule across every day and release; completionProof: classic-tower-v1 requires a server-simulated Classic Tower finish in addition to minSeconds. These are server-enforced controls. Existing completion rules without completionProof still verify elapsed time only. Registered proof profiles also include breadface-v1, breadface-v2 and breadface-v3 (server-simulated Breadface inputs; each is one reviewed release's exact physics, chosen by the reviewer) and study-record-v1 (a private study record reviewed by JEV, billed to the learner’s AI Energy). Profiles are platform-owned; an app cannot invent a verifier or authorize its own reward.
+- Optional reward rule controls: maxLifetimeClaims caps one learner’s receipts for that rule across every day and release; completionProof: classic-tower-v1 requires a server-simulated Classic Tower finish in addition to minSeconds. These are server-enforced controls. Existing completion rules without completionProof still verify elapsed time only. Registered proof profiles also include breadface-v1, breadface-v2 and breadface-v3 (server-simulated Breadface inputs; each is one reviewed release's exact physics, chosen by the reviewer) study-record-v1 (a private study record reviewed by JEV, billed to the learner’s AI Energy), and Groove Lab's groove-lab-song-v1 (a song the learner published today, checked on the server for length, notes and originality) and groove-lab-heard-v1 (three established accounts finished the learner's songs today). Profiles are platform-owned; an app cannot invent a verifier or authorize its own reward.
 
 ## AI decision design
 - When planning a new app or an improvement, consider whether model-based judgments would materially improve the requested experience. Twinkle.ai.decide runs JEV, a model for narrow decisions over supplied text or structured state. Potential uses include interpreting a player's request to an NPC, choosing among legal game actions, classifying user content, ranking supplied candidates, and adapting an activity to evidence about the learner. These are examples to reason from, not a keyword checklist or a requirement to add AI to every app.
@@ -1050,7 +1050,7 @@ world.updatePresence({ x, y, z, facing });
   - Errors: build_reward_not_scheduled when the rule has no questions for today; build_reward_daily_claims_reached when the viewer already earned today’s cap. attemptsRemaining is null for unlimited rules.
   - For a completion rule call start when the activity begins (the moment the stage starts); the challenge's age is what the claim is measured against. In preview mode start also works for the owner (a stateless simulation).
   - For completionProof: classic-tower-v1, start also returns completion { profile, token, maxFrames, completed, failed }. A new start resets only the simulated climb to its canonical spawn; it cannot reset daily or lifetime rewards. Record inputs from the first physics frame. The completion token is bound to the viewer, challenge, rule and published release.
-  - For breadface-v1, breadface-v2 and breadface-v3, pass the zero-based canonical levelIndex. Record [dt, inputBits] from the first physics frame; start returns its server token and maxFrames. For study-record-v1, start returns completion { profile, usesAiEnergy: true }; there is no client-authored proof token.
+  - For breadface-v1, breadface-v2 and breadface-v3, pass the zero-based canonical levelIndex. Record [dt, inputBits] from the first physics frame; start returns its server token and maxFrames. For study-record-v1, start returns completion { profile, usesAiEnergy: true }; there is no client-authored proof token. For groove-lab-song-v1 and groove-lab-heard-v1, start returns completion { profile }; there is no progress step.
 - await Twinkle.rewards.progress({ challengeId, completionToken?, frames?, record?, requestId? }) | scopes: rewards:claim
   - Returns: { mode: "live" | "preview", completion: { profile, token?, completed, failed?, decision?, message?, maxFrames? }, aiUsagePolicy? }
   - Verify a bounded batch of inputs for an approved server-simulated climb.
@@ -1066,7 +1066,7 @@ world.updatePresence({ x, y, z, facing });
   - A wrong answer within two seconds of the previous one is refused with build_reward_throttled (HTTP 429) and does not count; wait for the person to try again rather than retry-looping.
   - Completion rules take no answers: claim({ challengeId }) when the activity is finished. build_reward_too_fast (HTTP 409) means fewer than minSeconds passed since start; show nothing and let play continue. In preview mode the receipt carries preview: true and nothing is paid.
   - A completionProof rule also requires the signed completionToken from a successful rewards.progress response. The server simulates the registered game physics and must reach the goal. A timer, forged position, client win flag, altered inventory or token from another viewer, challenge or release cannot authorize payment. maxLifetimeClaims is enforced from receipts in the same award transaction. build_reward_lifetime_claims_reached means all rewards for this rule have been collected; do not retry it.
-  - For study-record-v1, the server verifies the settled private review row and its viewer, app, exact release, challenge and day binding. It never trusts the client’s decision, requested award amount or AI answer. Each successful daily study record is claimable once; display only canonical receipt/balances.
+  - For study-record-v1, the server verifies the settled private review row and its viewer, app, exact release, challenge and day binding. It never trusts the client’s decision, requested award amount or AI answer. Each successful daily study record is claimable once; display only canonical receipt/balances. For groove-lab-song-v1, pass completionToken as the published song's sharedDb entry id; for groove-lab-heard-v1, pass none. The server reads the app's own groove-lab-songs, groove-lab-song-parts and groove-lab-listens rows and refuses with build_reward_completion_proof_required and a plain reason when the song or listeners do not qualify.
 - await Twinkle.rewards.getLeaderboard({ metric?: "xp" | "coins", period?: "day" | "week" | "all", limit? }) | scopes: rewards:claim
   - Returns: { mode: "live", metric, period, limit, dayKey, from, available: { xp, coins }, entries: [{ rank, userId, username, profilePicUrl, xp, coins, claims, lastAt }], me: { rank, xp, coins, claims } | null } | { mode: "preview", metric, period, available, entries: [], me: null, message }
   - 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.

package/sdk/LUMINE_ADMIN.md

@@ -2997,7 +2997,18 @@ Mikey"** section carrying only
 the deltas and anomalies worth his time, next to the escalation list. Never
 dump raw sections at him.
 
-### Jev serving and audits (standing duty, every full daily review; updated 2026-09-20)
+### Jev serving and audits (standing duty, every full daily review; updated 2026-09-23)
+
+**September 23, 2026: LLM audits retired.** Mikey judged the Jev experiment a
+success and asked to drop the LLM comparison on served routes. Comments, chat
+routing and Lumine Auto no longer run any background LLM audit; the LLM runs
+only when Jev cannot decide. From that day, audit coverage, paired/served
+disagreements and the `jev_reply_gate_audit`, `jev_chat_routing_audit` and
+`jev_lumine_model_audit` operations read zero by design; do not report that as
+missing evidence. Report fallback rates and reasons instead. Auto rows served
+without a comparison carry `baselineStatus: not_run`; its fallback LLM spend is
+`lumine_model_fallback`. The eight comparison-only routing families below are
+unchanged. The rest of this section describes the pre-September-23 pilot.
 
 Read `data.jevPilot` from `lumine admin brief --json` and carry it into
 the full report for Mikey. The active `daily-run report --json` also includes
@@ -4430,8 +4441,8 @@ shown above are the canonical interface.
 
 September 21 routing expansion: read `jevRoutingShadow` alongside `jevPilot` in
 both the admin brief and full daily report. The reviewed `chat-routing-v3` path
-is primary; report actual selection latency, chat baseline calls avoided, audit
-coverage and `jev_chat_routing_audit` cost separately from v1/v2. New routing
+is primary; report actual selection latency, chat baseline calls avoided and
+fallback reasons (no audits since September 23). New routing
 families remain comparison-only until Mikey reviews each one and explicitly
 promotes it. Report every registered family, including zero-sample and skipped
 families; no traffic is not a pass. Show paired counts, exact differing fields,
@@ -4444,15 +4455,16 @@ proof an action was performed. Do not call agreement accuracy or infer speedups
 from shadow timings. Full daily costs must include these operations once only.
 
 September 21 Auto exception: Mikey approved JEV as Lumine Auto's primary model
-selector immediately, with an independent LLM comparison for every choice.
+selector immediately. Its per-choice LLM comparison was retired September 23;
+the LLM runs only as the fallback when JEV cannot decide.
 Auto is the new default; stored manual preferences remain manual. Review
 `jevRoutingShadow` / `byRoute.lumine_model` separately from the eight
 comparison-only families: selected model/effort, both decisions, exact selection
 context, confidence, fallback, actual selection latency, missing evidence and
-observed task outcome. Report `jev_lumine_model_serve` and the additional
-`jev_lumine_model_audit` spend separately, using canonical AI-cost totals without
-double-counting. JEV choice confidence and LLM agreement are not correctness
-scores. The other eight families still require review before promotion.
+observed task outcome. Report `jev_lumine_model_serve` and the fallback
+`lumine_model_fallback` spend separately, using canonical AI-cost totals without
+double-counting. JEV choice confidence is not a correctness score. The other
+eight families still require review before promotion.
 
 
 ### September 21 verified reward follow-up