@stage5/lumine 0.2.27 → 0.2.29

package/README.md

@@ -181,6 +181,7 @@ lumine admin subject feature 123 --json
 lumine admin subject unfeature 123 --json
 lumine admin featured reorder --subject-ids 30,20,10 --json
 lumine admin brief --days 3 --json
+lumine admin notable add Minecrarft_guy --json
 lumine admin post recommend comment:456 --anyone-can-reward --reward-twinkles 3 --json
 lumine admin post reward comment:456 --twinkles 3 --json
 lumine admin daily-run complete --json

package/lib/admin.js

@@ -585,6 +585,24 @@ export function parseAdminOperation(options) {
     );
   }
 
+  if (namespace === "notable" && action === "add") {
+    const rawTarget = String(target || "").trim();
+    if (!rawTarget) {
+      throw cliValidationError(
+        "Usage: lumine admin notable add <userId|username>.",
+      );
+    }
+    const body = /^\d+$/.test(rawTarget)
+      ? { userId: parseRequiredInteger(rawTarget, "user ID", 1) }
+      : { username: rawTarget };
+    return writeOperation(
+      "notable.add",
+      "POST",
+      "/cli/admin/notable-users",
+      body,
+    );
+  }
+
   if (namespace === "brief" && !action) {
     if (options.adminDays) {
       const days = Number(options.adminDays);
@@ -683,7 +701,7 @@ export function parseAdminOperation(options) {
   }
 
   throw cliValidationError(
-    "Usage: lumine admin identity|daily-run|recommendations|post|subjects|subject|featured|comment|news|audit|brief ...",
+    "Usage: lumine admin identity|daily-run|recommendations|post|subjects|subject|featured|comment|news|audit|brief|notable ...",
   );
 }
 
@@ -1088,6 +1106,12 @@ function printAdminResult({ operation, result }) {
     }
     return;
   }
+  if (data.notableUser) {
+    console.log(
+      `${result.status || "success"}: ${data.notableUser.username || "unknown"} (#${data.notableUser.userId}).`,
+    );
+    return;
+  }
   if (data.skip) {
     console.log(
       `${result.status}: ${data.skip.contentType}:${data.skip.contentId} skipped.`,

package/lib/commands.js

@@ -2528,6 +2528,7 @@ export function printHelp() {
   lumine admin comment post --draft-id <id> [--json]
   lumine admin comment edit <comment-id> --file <comment.md> [--json]
   lumine admin brief [--days <1..30>] [--json]
+  lumine admin notable add <user-id|username> [--json]
   lumine admin audit [list] [--run current|last|<run-id>] [--target <target>] [--actions <a,b>] [--full] [--cursor <cursor>] [--json]
 
 Examples:

package/package.json

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

package/sdk/LUMINE_ADMIN.md

@@ -139,6 +139,17 @@ Escalate, with the canonical `https://www.twin-kle.com/subjects/<id>` or
   pay-me-to-win contests, and anything that teaches other children a method for
   any of these. Note the recommendation count: a manipulation how-to that other
   kids are recommending is spreading, and that is the urgent part.
+- **AI-cost exploits** — patterns that convert free AI allowances into farmable
+  value: clusters of young accounts with heavy AI/battery usage, one person
+  operating many accounts that feed a single build through team branches,
+  plus-tagged or dot-variant email families (`kid+1@`, `k.id@`) behind multiple
+  active accounts, repeated first exchanges across accounts already linked by
+  independent evidence, or a rescue claim by an account created under 30 days
+  ago (the API maturity gate should make that last case impossible). A new
+  member's one first exchange is intended onboarding and is not suspicious by
+  itself. The daily battery is real provider money; treat farming signatures
+  with the same seriousness as coin farming. Escalate the account list and
+  evidence; never auto-enforce.
 - **Bug reports** the run encountered, even secondhand in a comment thread.
 
 Two rules that keep the list worth reading:
@@ -1041,6 +1052,8 @@ type NewsSubmit = NewsStatus; // "success"; newspaper includes revisionNumber
 ```bash
 lumine admin brief --json
 lumine admin brief --days 3 --json
+lumine admin notable add 12647 --json
+lumine admin notable add Minecrarft_guy --json
 ```
 
 Read-only management insights for the delegated workflow, windowed since the
@@ -1066,21 +1079,44 @@ Four sections (Mikey's chosen cut, 2026-08-10):
   report period can begin up to one day before or after the exact brief window,
   so use those bounds when describing it. Flag accounts that jumped tiers or
   dominate that report period. May be `{ unavailable: true }` if the cost
-  report fails; say so rather than guessing.
+  report fails; say so rather than guessing. This section is also the run's
+  AI-cost exploit watch: while reading it, actively look for the signatures the
+  brief actually exposes — one risk group spanning several user IDs, repeated
+  plus-tag or dot-variant email families among top accounts, or heavy spend by
+  accounts that `economy.topGainers` or `notableCandidates` independently marks
+  as recent signups. Cross-check those signals against the escalation
+  categories. Missing join-date or community data is unknown, not evidence that
+  an account is young or empty. A run that reads the spending report without
+  asking "could any of this be one person with many accounts?" has skipped a
+  duty.
 - `notableCandidates` — kids (never bots, staff `userType`s, or users already
   on the Notable Users list) ranked by authored activity in the window, with
   `isNewUser` marking window-new signups. Use it to find the overlooked and
   rising users the editorial priorities exist for, and propose additions to
-  Mikey's Notable Users list in the report — the run never edits that list
-  itself.
-- `teachers` — every `userType='supermod'` account with per-window
-  `subjectsPosted`, `commentsPosted`, `recommendationsGiven`, `rewardsGiven`,
-  `rewardTwinklesGiven`, `lastActive`/`daysSinceActive`, ordered by an
-  engagement score. Mikey's standing question here: which teachers genuinely
-  use the website to its fullest and which only work through it. Authored
-  posts and comments signal personal engagement; recommendations and rewards
-  are the "work" verbs — report the contrast, not just the totals, and treat
-  it as notable-users-but-for-teachers.
+  Mikey's Notable Users list in the report. When Mikey approves additions,
+  execute them with `lumine admin notable add <userId|username>` (idempotent —
+  an existing member returns `already_done`; requires the `notable:write`
+  scope, audited as `notable.add`, and writes through the management page's
+  own canonical service). Without his approval the run only proposes.
+- `teachers` — the mentor/sage achievement holders (the accounts the website
+  titles teacher/headteacher): real classroom teachers, NOT the
+  `userType='supermod'` Korean operations staff, whose work-only usage is
+  expected and deliberately excluded. Mikey's standing question here: which
+  teachers genuinely use the website for themselves and which only work
+  through it. Recommendations and rewards are classroom "work" verbs and
+  count for nothing toward interest; genuine personal interest is measured by
+  what a teacher does for themselves — authored subjects/comments,
+  `reflections` (Daily Reflections answered), `dailyTasksCompleted`,
+  `wordlePlays`, `buildsTouched` (Lumine builds they own that changed in the
+  window), `aiStories`, and bounded `xpEvents` (XP-ledger activity). Shape:
+  `genuinelyInterested` (interestScore > 0, ordered by it, each row carrying
+  all the per-window counters plus `rank: mentor|sage` and `workScore`),
+  `workOnly` (classroom verbs only, zero personal signals), `activeButSilent`
+  (window-active log-ins with nothing at all, capped at 40), and `totals`.
+  Daily-task counts use canonical whole-day indices and can begin up to one
+  calendar day before the exact `window.sinceTs`.
+  Report the contrast between the buckets, and treat `genuinelyInterested` as
+  notable-users-but-for-teachers.
 
 The command needs only an active run's `content:read` scope and mutates
 nothing; reading the brief is not audited content action. Window boundaries
@@ -1089,6 +1125,27 @@ on the big append-only ledgers are found by binary-searching the PRIMARY key
 is still bounded to the selected 1–30 day window.
 
 ```ts
+type TeacherInsight = {
+  userId: number;
+  username: string | null;
+  rank: 'mentor' | 'sage';
+  lastActive: number | null;
+  daysSinceActive: number | null;
+  subjectsPosted: number;
+  commentsPosted: number;
+  reflections: number;
+  dailyTasksCompleted: number;
+  wordlePlays: number;
+  buildsTouched: number;
+  aiStories: number;
+  xpEvents: number;
+  recommendationsGiven: number;
+  rewardsGiven: number;
+  rewardTwinklesGiven: number;
+  interestScore: number;
+  workScore: number;
+};
+
 type InsightsBrief = Success<{
   window: {
     sinceTs: number;
@@ -1124,18 +1181,16 @@ type InsightsBrief = Success<{
     isNewUser: boolean;
     lastActive: number | null;
   }>;
-  teachers: Array<{
-    userId: number;
-    username: string | null;
-    lastActive: number | null;
-    daysSinceActive: number | null;
-    subjectsPosted: number;
-    commentsPosted: number;
-    recommendationsGiven: number;
-    rewardsGiven: number;
-    rewardTwinklesGiven: number;
-    engagementScore: number;
-  }>;
+  teachers: {
+    genuinelyInterested: TeacherInsight[];
+    workOnly: TeacherInsight[];
+    activeButSilent: TeacherInsight[];
+    totals: {
+      total: number;
+      activeInWindow: number;
+      interestedInWindow: number;
+    };
+  };
   aiSpending:
     | {
         days: number;