# Lumine delegated-administrator contracts `lumine admin` exposes deterministic community-management primitives. It does not decide whether content is good, harmful, original, deserving of effort, or worth commenting on. An LLM or human operator makes those judgments from the canonical structured data. ## Security and run model - The saved Lumine login always authenticates the real operator. The API reloads that user's current role from the writer database on every request. - Only the server-configured administrator with authoritative administrator management authority may delegate. Effective Level 5 alone is rejected. Only the immutable server-owned Zero and Ciel user IDs are approved. Usernames and CLI flags are not authority. - `daily-run start` creates or returns a six-hour `delegated-admin` run with one allowlisted run scope and one public actor. `--scope full` is the full daily-management review. `--scope featured` is only an authorization envelope for a specifically requested Featured slice; it does not authorize or imply the newspaper, queues, conduct review, logs, costs, AI Energy budget health, sponsors, carry-over work, or final full-run report. Every run-scoped CLI command loads the canonical active run and sends its ID; the API rejects a missing, expired, scope-mismatched, or actor-mismatched run. - `--scope newspaper` is a newspaper-only authorization envelope. It grants newspaper status/claim/submit/print and completion only, with comment mode `off`. It cannot inspect queues, conduct, logs, Builds, or Featured. Completion does not advance full-review windows or carry-over telemetry. Its distinct `/daily-runs/start/newspaper` endpoint fails closed on older APIs. - The public content actor is Zero or Ciel. Mikey's operator ID is retained in private audit rows and is not embedded in public comment metadata. - Delegated HTTP work never authenticates as the bot, opens a bot socket, changes bot sessions, or updates bot presence/typing state. Normal content mutations still emit Twinkle's canonical real-time content events. - One deliberate exception to the last-seen rule: a delegated mutation that actually changed something stamps the acting bot's `users.lastActive`, so Zero's and Ciel's public "last online" reflects the real day they commented on and rewarded kids' posts instead of whenever a socket last closed. It is written after the audit transaction commits, throttled to once a minute, and best-effort — it can never fail or deadlock the content mutation. Presence is still untouched: no socket is opened and no `online_status_changed` is emitted, so the bots remain absent from the online list. Note that `lastActive` is the ordering key for the People directory, so the bots now surface there after a run; that is the intended consequence of the timestamp being truthful. - A later human reply to a delegated Zero/Ciel comment enters the existing server-side autonomous comment-assistant pipeline. For Build threads this is limited to comments carrying the private reviewed-management provenance described below. The human's normal AI Energy and sponsor path applies; Lumine does not need to remain running. `--output ` saves the canonical JSON result for ordinary admin commands, whether or not `--json` is also used. Files are atomically replaced with mode `0600`. Paginated scans keep their existing streaming-to-file path; `news claim` keeps its claim/scaffold contract. If saving fails after a server mutation, the structured error includes `canonicalResult`: inspect it rather than repeating a successful mutation to recover an output file. The Zero/Ciel shift is assigned by **Asia/Bangkok calendar day, not by run**. The schedule is anchored with 2026-08-31 assigned to Zero and alternates by elapsed Bangkok dates from there. Every automatic primary, supplemental, retry, read-only, or resumed run started on one date uses that date's same actor; a skipped date still counts in the alternation. Completing, failing, abandoning, or expiring a run never changes the schedule. An explicit `--identity zero` or `--identity ciel` is an auditable override for that run only: it does not rewrite the scheduled identity. Automatic runs expire at the next Bangkok midnight so yesterday's actor cannot continue as today's automatic identity. Reusing a live run key still returns the original run and identity. `identity use zero|ciel` is the separate, explicit persistent override for future starts; it remains in force until `identity use auto`, and does not alter the underlying calendar schedule reported by status commands. Comment mode is stored only on the current run: - `off` (default): no draft or post scope. - `draft`: server-generated drafts, no public comment. - `post`: drafts plus idempotent publication through the ordinary comment path. A Featured-only run always uses comment mode `off` and grants Featured subject inspection, subject reveal, Featured mutation, review-bound Featured comment encouragement (`featured:comments`), and run completion. It does not grant generic recommendation/reward authority or comment publication. It can complete without a sponsor-integrity scan. Completing it does not advance any full-run content/cost/conduct window, queue-coverage record, last-completed identity, or carry-over surfacing telemetry. Start one only when Mikey requested that slice; never turn a small request into a full review merely because the technical command needs a run. The API enforces these scopes, and the CLI also rejects out-of-scope operations before calling endpoints outside the Lumine Admin router (notably Build review). Featured capacity and delegated addition authority are separate policies: the website editor supports 100 Subjects, while delegated additions are limited to a board of 20. `maximum` remains the delegated limit for compatibility; `maximumScope`, `delegatedMaximum`, and `websiteMaximum` label the distinction. A board of 25 is not a website overflow or an instruction to remove five pins. Equal-size replacements and complete-set reorders accept up to the website's 100-Subject capacity without exercising delegated growth authority. ### Private AI-bucket maintenance AI identity buckets are private operator bookkeeping, not a Zero/Ciel public action. They therefore do not require or attach to a delegated daily run: ```bash lumine admin ai-bucket create --label Lemon \ --note "Quota accounting only; not a moderation flag." --json lumine admin ai-bucket get --bucket-id 10 --json lumine admin ai-bucket accounts add --bucket-id 10 \ --user-ids 3127,13037,15410,16288 \ --note "operator-confirmed account family" --json lumine admin ai-bucket note set --bucket-id 10 \ --note "Quota accounting only; not a moderation flag." --json ``` `create` inserts a new unbanned quota bucket through the same helper the management page uses. `--label` is required (at most 120 characters). `--note` is required and follows the same 255-character quota-context rule as `note set`. It cannot create a banned bucket, copy an existing one, or infer members. The response returns the canonical bucket, including its id for later `get` / `accounts add` / `note set` calls. `accounts add` accepts 1-500 unique positive user IDs, preflights the complete batch before writing, adds one exact canonical user rule per requested account, re-attributes current-day AI usage, and returns the canonical bucket members. It never infers or adds email aliases: shared verified addresses can belong to unrelated accounts, so email rules require a separate explicit operator action. The command is idempotent to retry. The API records the real operator in the private Lumine audit log; no public bot identity is involved. `note set` records up to 255 characters of private operational context on the canonical bucket. Use it to distinguish quota bookkeeping from moderation; the note itself changes no access, ban, or identity rules. The commands above are quota bookkeeping only. They cannot ban accounts, block signup, add IP/device/risk-key rules, or infer an account family (the explicit restricted-bucket commands below can, on Mikey's instruction). Identification remains a human/LLM evidence judgment and must be explicitly requested by Mikey; routine administrator runs still escalate suspected alternate accounts and never auto-enforce. `accounts add` and `note set` still accept only an existing **unbanned** bucket. For an exact device Mikey explicitly authorizes blocking, use the separate signup-only action after reviewing `identity inspect`: ```bash lumine admin ai-bucket device block-signup --bucket-id 10 --user 3127 \ --device-key 0123456789abcdef --user-ids 3127 \ --note "Mikey approved this reviewed device for the household signup block" --json ``` `--user` is the source account ID; `--user-ids` is the complete reviewed list of accounts observed on that device, not every member of the household. The API resolves the inspection handle internally, rechecks bounded 365-day device evidence, requires the exact expected account set, and rejects devices used by anyone outside the existing bucket. Incomplete history, unresolved handles and a rule belonging to another bucket stop the action. The bucket must already have an active **signup-only** restriction. This cannot turn on a bucket ban, change full-site bans, add network rules or infer membership. The response confirms the canonical rule and restriction without returning the raw device ID. The private audit records the request before evidence is read and records successful completion separately. Routine reviews still never auto-enforce; this action requires Mikey's explicit instruction for the device. ### Restricted buckets: inspect, rules and restrictions These are the operator path for buckets with a restriction (and for adding email, IP and device rules to any bucket). They use the same shared operations as the Management page, so each change has the same side effects there (current-day usage re-attribution, ban cache, member notification and kicks, live quota updates). Use them only on Mikey's explicit instruction for that bucket, rule or restriction. ```bash lumine admin ai-bucket inspect --bucket-id 4 --reason "todo 79 review" --json lumine admin ai-bucket restrict --bucket-id 4 --mode signup --dry-run lumine admin ai-bucket restrict --bucket-id 4 --mode signup --confirm lumine admin ai-bucket rule add --bucket-id 4 --type user --user 18559 --dry-run lumine admin ai-bucket rule add --bucket-id 4 --type user --user 18559 --confirm lumine admin ai-bucket rule add --bucket-id 4 --type email \ --email family@example.com --confirm-email-rule --confirm lumine admin ai-bucket rule add --bucket-id 4 --type ip --ip 58.151.12.59 \ --scope signup [--include-prefix] --confirm lumine admin ai-bucket rule add --bucket-id 4 --type device --user 18559 \ --device-key 0123456789abcdef --scope signup --user-ids 18559,20001 \ --note "Mikey approved this reviewed device" --confirm lumine admin ai-bucket rule disable --bucket-id 4 --rule-id 77 --dry-run ``` `inspect` works for unrestricted and restricted buckets. It returns the canonical bucket (label, note, restriction `none|signup|full`, message), every active rule (id, kind, scope, effective restriction, match), the canonical members, every account a full restriction would reach, and for each member (first 25) their devices (inspection keys, never raw IDs) and network addresses with how many accounts share each. A device or address used by many accounts (an academy, a school) is counted, marked shared and never listed or treated as family evidence. Addresses and email-rule addresses (in evidence, rules and rule notes) are masked unless `--include-private-evidence`; every other output, and the audit, keeps them masked (with a keyed hash in the audit). `--reason` is required; the API commits an access receipt before reading evidence. `--dry-run` on `restrict`, `rule add` and `rule disable` is a read: it returns the current and resulting restriction, the accounts newly affected or released, the accounts whose sessions a full restriction drops, admin conflicts and any blocker, and changes nothing. Device, IP and email previews read private evidence, so they record an access receipt; the others record nothing. A real run is audited (request receipt with the idempotency key and payload fingerprint, then the completed result) and returns the bucket read back from the database and checked (`verified: true`); the CLI refuses a result that does not confirm the requested state. A failure after the change started is recorded as failed; a replay with the same idempotency key returns the stored result instead of running again. - `restrict` always needs `--confirm`. `signup` blocks only new accounts: existing logins and existing bans (`users.banned`) stay as they are. `full` drops members' sessions and is refused while any member is an admin. `none` lifts the restriction; each member gets its effective ban state pushed again. Without `--message` the current message is kept. The preview and the result list every IP, prefix and device rule whose effective restriction changes, with how many accounts it reaches (exact IPs from site activity; prefixes and devices from a year of AI usage, a lower bound). A rule that gets stronger on a shared network (more than 8 accounts) or whose reach can't be measured refuses the change unless `--allow-shared-network` is passed; use it only on Mikey's explicit word. The CLI prints the override. Saving a full bucket again (even only a new message) re-kicks its members, as on the Management page; the preview lists them. - `rule add` / `rule disable` always need `--confirm` too: on an unrestricted bucket a rule still pools AI Energy, on a restricted one it changes who is blocked. On a fully restricted bucket an account or email rule re-kicks every account the bucket reaches (as on the Management page); the preview lists them. Email rules cover every account with that verified address and also need `--confirm-email-rule`. IP and device rules need `--scope`; IP prefix rules (`--include-prefix`, the whole /24 or /64) are opt-in, their reach measured as above. A shared exact address or prefix, or an unmeasured prefix under a full restriction, is refused unless `--allow-shared-network`. An address or prefix rule held by another bucket is refused, never moved. Device rules keep the `device block-signup` guards: the reviewed `--user-ids` must equal the accounts seen on the device, all inside the bucket; a device more than 9 accounts used is shared (counted, not listed, refused). Disabling an exact IP rule leaves its prefix rules active (the preview names them). `rule disable` keeps `--note` in the audit receipt only. ### Shared verified-email policies A verified address proves that an account can use that mailbox; it does not always prove that every account using the mailbox is one person. When a teacher, school, or other provisioning owner intentionally verifies separate people's accounts with one address, record that confirmed operational fact explicitly: ```bash lumine admin ai-email-policy get --email teacher@example.com --json lumine admin ai-email-policy set --email teacher@example.com \ --mode separate_accounts \ --note "Teacher-confirmed classroom provisioning address" --json ``` `separate_accounts` preserves ordinary email verification and recovery while giving every current and future account whose stable verified address matches its own AI Energy and AI Card quota identity. The mutation re-attributes the current day's per-account usage, updates all affected live quota projections from canonical server state, and records the real operator in the private Lumine audit log. It is a provisioning policy, not an alternate-account finding or moderation flag, and must never be inferred from account count, usernames, devices, IPs, or email-provider heuristics. The CLI accepts a successful `set` only when the writer response confirms the requested policy and reports every matching account on its exact expected durable projection. A missing or mismatched projection fails closed instead of letting an operator mistake a stored policy row for completed account repair. Use `--mode automatic` with a new explanatory `--note` to restore Twinkle's default verified-email grouping. Both modes are durable and apply to later signups and later verifications without another code change. An active email-wide manual identity rule conflicts with `separate_accounts`, so the API rejects either operation until the operator explicitly resolves the conflict. Exact per-user manual bucket rules remain authoritative in both modes. ### Audited identity inspection Account-family evidence is private operator work, never a Zero/Ciel public action and never a reason to browse unrelated user activity. Use the dedicated lookup instead of direct database queries: ```bash lumine admin identity inspect Jay1216 \ --reason "Confirm the account family before updating its quota bucket" --json lumine admin identity inspect Jay1216 \ --reason "Mikey requested DOB and email evidence for this decision" \ --include-private-evidence --json ``` The default result resolves the exact username or user ID from the writer, returns the canonical current AI bucket, orders candidate accounts oldest first, identifies the oldest account within the strongest canonical family boundary (bucket before email; never device alone) when that family fits in the bounded evidence set, reports whether each account has a DOB, and explains whether the link came from explicit bucket membership, a verified-email match, or bounded exact- device evidence. It does **not** reveal email addresses, DOB values, device IDs, IP evidence, private messages, or unrelated activity. `--include-private-evidence` adds DOB values and verified email addresses only; exact device IDs are never returned. `sharedDevices[].usage` reports recorded event counts, first/last observed Unix timestamps, an `eventsByType` breakdown, and the same details per account. These come from `ai_usage_session_evidence`, which records the exact device identifier; `users_actions` has account/IP activity but no device identifier. Counts include events such as login, logout, socket binding and AI use, **not unique visits or physical-device sessions**. Only events attached to an account are counted. Usage `status: complete` means the queried device's records fit inside the 365-day lookback and read limit. `partial` counts are lower bounds, with observed dates and `truncatedBy` explaining the gap. `not_read` has a null event count, never zero. `accountsTruncated` separately marks a capped account-detail list; its totals still include omitted accounts. Device discovery can be truncated even when an individual device's usage is complete: always check the overall `evidenceCoverage` too. Human-readable CLI output includes these distinctions; older APIs explicitly report that usage counts are unavailable. The CLI sends `identity inspect` and `identity network` as reads, so it keeps no copy of the result on disk; the server still records who looked, when and why, one audit row per call. When a case needs a kept copy (a bullying or police matter, say), add `--output `: the result is written there with owner-only (0600) permissions, and nowhere else. Every inspection requires a concrete `--reason`. Before loading the evidence, the API commits a private `identity.inspect` audit receipt containing the real operator, requested target, reason, and whether private evidence was requested. The evidence itself is deliberately not copied into the audit log. Inspection is run-independent and has no public actor. Results are **candidate accounts for human judgment**, not an automatic ownership finding and never automatic grounds for moderation, bans, or bucket changes. ### Audited private investigations Use reason-required, bounded drill-downs when an aggregate management signal needs causal evidence: ```bash lumine admin economy trace lock --days 3 \ --reason "Investigate the anomalous three-day coin gain" --json lumine admin rescue wordle-audit --days 30 \ --reason "Identify recorded Wordle breaks, streak lengths, and rescue status" --json ``` `economy trace` reads the canonical append-only coin ledger for one exact account. It returns an exact action/target breakdown for the window, the largest ledger entries, direct transfer counterparties, AI Card sale/offer provenance, and whether a counterparty is already in the same effective exact-account AI bucket. It never reads or returns chat messages, bucket labels, verified addresses, device evidence, or private identity values. Same-bucket transfers and concentration are investigation signals, not automatic abuse findings. `rescue wordle-audit` separates expired unredeemed Wordle/strict-Wordle rescue offers from offers still inside their seven-day promise and from redeemed offers. Each row identifies the account and labels the cause: regular Wordle is an uncovered dodge, while strict Wordle is a completed but non-strict game. The stored offer-time streak snapshot is reported as the broken streak length. `claim_ready` requires a durable first user exchange in Lumine history; a reservation claim is reported separately and is not treated as completion. An open offer is never labelled a refusal, and non-redemption does not establish intent. The underlying rescue table stores one current row per account; an expired row may be replaced by a later offer, so the command reports exact current-row evidence and explicitly marks that it is not a complete immutable history of every offer ever shown. Both commands are run-independent private operator actions. Each requires a concrete reason and commits a minimized private access receipt before loading the evidence. Windows are limited to 1-30 days, and neither command mutates coins, streaks, buckets, messages, or public content. ## Editorial priorities The CLI never makes the qualitative judgments in this section; they are the standing instruction for the operator or agent and apply to every verb below: recommends, rewards, effort levels, Featured, skips, comments, and replies. It does enforce deterministic server-provable boundaries documented below, such as the posting-date and lifetime-history gates for a new Featured addition. Public text authored as Ciel must be English. This is an operator and generation instruction, not a script or keyword test: writing systems do not identify a language reliably, and the API must not pretend otherwise. This is a presentation rule, not an invitation to correct or lecture a member who writes in another language; reply naturally in concise English. **Twinkle is not Reddit.** Do not rank a run's attention by popularity, recommendation count, or polish. Most users here are young children, and the posts that most need Zero or Ciel are the ones nobody else answered. These outreach priorities do not replace the full daily Featured-comment review below: active threads need encouragement too. Featured selection has its own primary objective: invite genuine member-to-member engagement, not assemble the most thought-provoking posts. - **Look first at new, quiet, and overlooked users.** A child's first post, or a post from someone who rarely gets replies, is worth more of a run's attention than another well-liked post that already has a lively thread. - **Clumsy is not the same as low-effort.** Bad spelling, a one-line description, a title that is just "hi", a drawing that did not come out right — these are usually a child trying, not a child spamming. Read for the real thing they were reaching for and respond to that. - **Zero engagement is a reason to act, not to skip.** A post sitting at no recommendations and no comments is the strongest signal in the queue that someone should notice it. - **Thought-provoking posts deserve substantive replies.** When a child asks a real question or makes a real argument and the thread is empty, it is a strong case for a Zero/Ciel reply, not an automatic top Featured ranking. Engage with the idea itself: answer it, add a perspective or a counter-consideration, and leave the author somewhere to go next. A good question that nobody answered teaches a child that thinking hard is not worth it; that is the outcome these runs exist to prevent. This cuts both ways with the point above — the two ends of the queue, the beginner nobody noticed and the strong idea nobody engaged, both outrank the popular post that already has a lively thread. - **Always answer Twinkle usage questions.** "How do I change my username", "why can't I reward", "what unlocks the Summoner" — a child stuck on the site cannot use it. Answer concretely and verify anything you are unsure of against the canonical rules before publishing; say you will check with Mikey rather than guessing at mechanics. - **Always respond to bug reports, and tag `@mikey` in the comment.** The mention is what notifies him (`postComment` runs `processMentions` / `postMentions` and emits `new_targeted_upload`), so a bug-report comment without `@mikey` fails its main job. Restate what the child observed; never promise a fix or a timeline. This reporting duty does not suspend the acting bot's character: the public comment must still sound like Zero or Ciel talking naturally to that member, not like an operator, ticket, or incident report. Read the full thread first. If the bot already noticed, explained, or apologized for the bug, do not post another reply that treats it as a fresh discovery or repeats the same acknowledgement. Continue from what the bot already said and add only what is missing, such as naturally bringing `@mikey` into the conversation. Put the formal defect summary, evidence, and review request in the private run escalation. - **Guide users through the website, without waiting to be asked.** A post can show that a child is stuck, confused, or unaware a feature exists without ever containing a question — someone begging for coins who does not know about daily rewards, someone reposting because they could not find their own post. Give them a short, friendly crash course on the exact thing they are stuck on. Teaching a child to use the site is worth more than any single recommend. - **Reserve `post skip` for genuine noise** — card-sale and coin-begging spam, keyboard mash, duplicates, engagement farming — not for sincere posts that merely look unimpressive. - **Effort levels are not a verdict on the child.** Level 1 on a thin post is ordinary bookkeeping; it never means the author deserves less attention, and it pairs well with a warm comment. Judge the depth the Subject invites, not merely the number of words in its prompt: a genuinely thought-provoking question should normally receive Level 3. Level 3 is the highest delegated setting, and the level tells respondents that substantial, carefully reasoned answers are wanted. - **Ongoing series are participation, not noise.** Daily records, journals, logs, recurring updates, and serialized creative work are not spam, filler, engagement farming, or duplicates merely because they reuse a title or format, or because one installment is concise. Review the series context and what the current entry contributes. Never lower effort, skip, withhold a recommendation or comment, or propose Featured removal solely because of that recurring format or brevity; only an actual duplicate or genuine noise is treated as such. - **Sincere requests for personal help are Featured material.** Posts asking the community for advice about school, friendships, loneliness, or other ordinary real-life problems embody Twinkle's purpose; being personal is never a reason to suppress them or judge them unsuitable. Receiving meaningful support does not reduce their value. They still participate in the daily Featured refresh below: rotating the spotlight is not withdrawing support, and a good post does not require an indefinite pin. - **Speculative privacy is never an editorial signal.** Do not lower, remove, unfeature, or escalate content because it might identify someone, mentions a school, city, class, or ordinary location, or invites everyday community context. Those possibilities carry zero weight in Featured decisions. An actual sensitive disclosure or an author's explicit removal request follows the separate concrete-safety path; it does not make the post low-quality. - **Featured prioritizes engagement, participation, and child voice.** Choose the recent eligible Subjects most likely to get members commenting on other members' Subjects and responding to one another. Accessible questions, everyday experiences, playful prompts, drawings, invitations, personal help, and ongoing records or creative series can outperform a polished essay for this purpose. Being thought-provoking is a bonus, not the primary ranking criterion. Explain the concrete invitation to participate, using the full Subject and thread as context; do not rank by adult polish, intellectual depth, existing popularity, or raw recommendation counts. Genuine engagement does not mean bait, spam, or reward farming. Age, brevity, simplicity, prior recognition, or a modest description does not make a Subject low-quality. Daily rotation is an independent editorial reason to refresh a good post's slot; do not invent a defect to justify it. - **Aim to replace all of yesterday's Featured Subjects each day.** During a full daily management review, plan a complete refresh of the previous day's board with recent, never-before-Featured Subjects, ordered by likely genuine engagement. A small handful of swaps is not the default target. Use the Bangkok calendar day, not the number of runs: do not churn pins newly added today because a follow-up starts another session. Quality and eligibility still apply. If there are too few eligible candidates, a current explicit keep instruction, an unread thread, or another concrete constraint, explain each retained pin and the shortfall; do not pad the list or silently settle for a partial refresh. An earlier positive assessment is not a permanent keep instruction. New installments can carry a series forward without treating earlier ones as noise. This daily target changes editorial judgment, not mutation authority: show the full proposed rotation and obtain Mikey's go-ahead before removing or reordering any pins. One go-ahead for that exact complete plan authorizes executing all its swaps, not just the first one; carry it through and verify the final board without seeking per-item approval. - **A "new" Featured addition has two non-negotiable eligibility gates.** When Mikey asks for new Featured subjects, additions, or replacements, a candidate must both (1) have been posted recently and (2) have never appeared on the Featured board before. Unless Mikey gives a different recency window, "recently" means the preceding seven calendar days; do not widen into older inventory merely to fill capacity or produce a longer proposal list. Absence from the current `featured list` proves only that a Subject is not Featured now — it does not prove that the Subject has never been Featured. Verify lifetime Featured history from canonical evidence before recommending or adding it. If the available CLI/API cannot prove that history, leave the candidate out and report the capability gap instead of guessing. Quality is still required after both eligibility gates pass; recent and never-Featured does not make filler acceptable. - **The live Featured board is Mikey's word.** Do not remove or reorder a currently Featured subject without first showing Mikey the planned removals and replacements and getting his go-ahead. Additions have standing approval when a fresh `featured list` is below its delegated-admin maximum: proactively feature genuinely reviewed, editorially strong new subjects without asking case by case. This is judgment, not a quota — never add filler merely because capacity exists. If a subject that was Featured or pinned during an earlier run is no longer on `featured list`, treat that as Mikey having removed it deliberately — never re-feature it to "restore" the board, even when space is available, and never treat any subject as a permanent fixture from memory or old run notes. Derive the board fresh from `featured list` at the start of every Featured review or mutation; the only pins that exist are the ones currently on it. Sensitive disclosures, active disputes, and anything needing crisis or medical judgment remain out of scope for a bot comment no matter how neglected the post is. Those go to Mikey. ### Daily Featured comments and refresh This is a standing duty for every **full daily management review**, after the newspaper duty. It is not an instruction to start or repeat a full run when Mikey requests a small edit, proposal, or other scoped action. A request only to discuss Featured candidates authorizes discussion, not recommendations or pin changes. The technical `--scope featured` envelope permits the review-bound comment workflow below only when encouragement is in Mikey's requested slice; it never authorizes unrelated daily work or generic recommendation commands. 1. **Read all comments on every current Featured Subject each day.** Start from a fresh `featured list`, save the dated board, and inspect each full Subject and all top-level comments and nested replies. Include old and already-viewed comments, not just new ones, the recommendation queue, or a sample of the thread. Review outgoing Subjects before their approved rotation so their commenters are not missed; review any newly added Subjects' threads too. Use `featured comments scan --checkpoint ` to download every snapshot-bound page, then actually read every listed page file before `featured comments acknowledge --checkpoint --reviewed`. Fetching does not acknowledge reading. A fresh scan after rotation covers the incoming board. `commentsIncluded: false` or a locked secret is not an empty thread: use the ordinary authorized reveal path, never bypass secret semantics, and report any inaccessible or unfinished coverage. Preserve the reviewed snapshot boundaries so "all" describes actual reads. 2. **At least recommend most comments that are not genuinely worthless.** The purpose is to encourage members to comment on other users' Subjects and to give those contributions visibility. A sincere answer, friendly reaction, relevant joke, question, attempt to help, or conversational follow-up is usually enough; it need not be profound, long, polished, or Twinkle-worthy. Read in context and lean toward encouragement. A one-line or emoji response can be worthwhile; brevity or "nothing for the bot to add" is not a reason to withhold a recommendation. Do not restrict recognition to a few standout replies. Do not mechanically approve everything: genuine spam, meaningless noise, harassment, or exploit promotion is not deserving merely because it appears on Featured. System/view notifications and the bots' own comments are context to read, not user participation to boost or count toward this duty. Leave narrow concrete-safety cases for Mikey under the existing rules. 3. **Separate encouragement from reward eligibility.** The ordinary action is a selected item in `featured comments recommend --file `, omitting `anyoneCanReward` and `rewardTwinkles` (defaults: `false` and `0`). Turn on the UI's "everyone can reward" option (`anyoneCanReward: true`) only when the comment independently deserves that stronger endorsement; direct Twinkle rewards are selective too. Do not withhold a basic recommendation just because rewards are not deserved, and do not mass-enable rewards to satisfy this duty. Honor canonical Zero/Ciel deduplication: already-recommended comments still get read, but do not need a second recommendation or daily reward. A bare recommend does not revoke an existing reward permission; never claim it switched one off. This duty is not authority to downgrade past decisions. 4. **Propose the whole daily refresh, get approval, then execute it.** Identify carryover pins from the saved board and canonical Featured history, without assuming missing pins should be restored. Review replacements under the recency and never-Featured gates above and rank them by the engagement they invite. Show Mikey a specific old-Subject -> new-Subject mapping with titles, IDs, canonical URLs, reasons, and the proposed final order, plus any retained pins and specific constraints. Explicitly ask for his go-ahead and wait before performing the proposed rotation. Daily freshness and giving new conversations a turn are sufficient editorial reasons; a prior Subject need not become bad or unsuitable first. Keep existing removal/reorder approval and addition-capacity boundaries intact. After Mikey approves the exact plan, autonomously perform **all approved swaps and the approved ordering**, without per-item approval or asking him to operate the website. Prepare the server-stored `featured plan` before presenting it, then use `featured apply --file --approve ` only after that exact plan gets his go-ahead. Membership and final ordering commit together; the server rechecks the original board, history revision, and new-candidate eligibility inside the board transaction. Verify the exact final membership and order from the server, then report completion. Recover retryable failures within the approved scope; if intervening owner changes, eligibility changes, or an API limit require a materially different plan, preserve the new state, report what actually completed, and seek approval for that difference instead of substituting candidates or overwriting changes. Report proposals separately from completed actions. Approval is for the presented plan, not future boards. 5. **Make coverage and encouragement auditable.** In the final full-run report, state Subjects covered, comments read, new basic recommendations, already-recommended comments, selective reward-eligibility grants/direct rewards, and genuinely skipped categories. Use canonical results, not attempted commands, for action counts. Report any unread Subjects/pages explicitly; never call a sample, a filtered queue, or a blocked thread a completed all-Featured-comment review. Include refresh progress and any carryovers as required in the `Featured rotation` report section below. ## Math Lab content duty in full daily management Mikey added Math Lab question design and publishing to the full daily workflow on 2026-09-08. Follow [Math Lab daily question publishing](../../agent-guides/math-lab-daily.md) for the canonical Build 2460, owner account, twelve grade queues of ordered until-earned puzzles, verification, repeat-run recovery, release gates, and final reporting. Every full daily run reports each grade's current question, whether it was cleared today, uncleared published questions remaining, and refill status. Count distinct cleared keys across all users and the app's full history against the live approved sheet; the recent usage window and draft additions are not the live inventory. At two or fewer remaining, prepare a refill to at least ten, with complete interactive guides, and track it until approved publication. Report one or zero remaining prominently. Details are in the linked guide's **Daily queue monitoring and refill** section. Read this inventory with `lumine admin math-lab queue --json`. Its receipt binds the published artifact and live reward review, includes all twelve grades, and reports incomplete coverage explicitly. Today’s cleared set stays current until UTC midnight, but no longer counts as unearned inventory. This is not part of Featured-only or newspaper-only work and is not a new scheduler, delegated API scope, or automatic extension of admin permissions. Use the expressly authorized owner Build workflow for Math Lab; retain the normal Zero/Ciel actor separation for other administration. Mikey authorized Math Lab's initial launch, completed on 2026-09-12. Routine refills follow the standing duty but still need his exact-version approval and explicit publication authorization. Local edits and draft saves do not require release approval. Real XP/Coins may be changed only by the currently published, approved artifact through server-verified reward claims; private builds, previews, local tests, unpublished branches, and superseded versions cannot award real balances. These reward controls are a required design contract, not a claim that a reward SDK or server enforcement has already been implemented. See the guide before adding reward capabilities. ## Escalation to Mikey Before closing a full run, reconcile three explicit handoffs: pending reward approvals (`rewardReviews` in intake/report), every carryover todo (with new evidence or a concrete blocker and next action), and earlier-day telemetry that meets a reopening condition. `carryoverWithoutProgressThisRun` in the report identifies surfaced todos without a progress update. A pending human decision can remain open; it must be named with its exact request/version, recommendation and next owner. Never equate reading a summary with inspecting frozen implementation, clearing a stuck flag with producing the intended image, or deploying code with verifying its live outcome. The September 14 omissions were execution failures under already explicit duties; these fields make them visible, not optional. A full daily management run is not finished when the mutations are done. Curation surfaces things only a human owner can decide, and a finding nobody reports is a finding that did not happen. **Every full run ends with an escalation list**, and it belongs in the run's final report whether or not anyone asks for it. Keep that list narrow enough to be useful. Escalate concrete child-safety, exploitation, targeted harassment, or platform/system-abuse risk — not ordinary children experimenting, arguing, making rumors, proposing informal in-site loans or contests, asking where media can be found, or making an unverified ownership claim. Those may merit a normal age-appropriate response, but they are not escalations without credible harmful conduct or a real victim. Hypothetical identifiability and ordinary school, city, class, or location references are not escalation signals. Escalate, with the canonical `https://www.twin-kle.com/subjects/` or `/comments/` URL, a one-line summary, and why it needs him: - **Child-safety and wellbeing** — distress or mental-health disclosures, anything about self-harm, a child asking for a photo of themselves to be removed, requests to delete or hide personal information, contact details posted in public, or a child who says they are leaving because something happened. These outrank every other category. - **Account integrity** — someone posting from another person's account, impersonation, shared logins, or a user operating a set of alternate accounts. - **Economy exploitation** — coordinated coin or XP farming across alternate accounts, coercive or deceptive arrangements, or a repeatable abuse of the platform economy with concrete evidence. A child offering a voluntary loan, repayment, prize, or contest is not enough by itself. - **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: - **Check the thread before escalating.** If Mikey already replied in it, the matter is his and it is closed unless something new happened after his reply — re-reporting it wastes the one channel that is supposed to mean "look at this." Say so explicitly when a post looks alarming but he already handled it. - **Check `operatorViewed` too.** Every Subject, Comment, StandalonePost, and queue item reports whether Mikey has opened that content and when. Silence is not the same as not having seen it — he often reads without replying. Lead the escalation list with items where `viewed` is false, and mark the rest as already-seen rather than dropping them, since he may have looked before the thing you are escalating happened. `lumine admin subjects candidates --unviewed` and `lumine admin recommendations list --unviewed` filter a page down to what he has not opened (`--viewed` inverts it). The flags are supported by the recommendation, Subject, Featured, and comment-list commands only; they are rejected before any request on every other command. Two limits make this a strong negative signal and a weak positive one: a view is recorded only when the content **page** is opened, so reading a post inline in a feed records nothing, and a user's view of their **own** content is never recorded. So `viewed: true` reliably means he opened it; `viewed: false` means "no page open recorded", not "he never saw it". Never tell a child, in public, whether Mikey has or has not looked at their post. - **Escalate; do not moderate.** Zero and Ciel have no moderation verbs here by design. Do not delete, hide, argue with, or publicly accuse anyone, and do not warn a child that they are in trouble. Report it and let Mikey decide. Mikey's decision must remain attached after the originating run closes. These commands are private, run-independent bookkeeping: ```bash lumine admin escalation list --json lumine admin escalation list --status all --json lumine admin escalation set 123 --status acknowledged \ --note "Mikey is reviewing the bot response" --json lumine admin escalation set 123 --status resolved \ --note "No user fault; this audit concerned Zero's response" --json ``` `list` defaults to unresolved `open` items. `--status` also accepts `acknowledged`, `resolved`, or `all`. The number passed to `set` is the original `run.escalation` audit ID returned by the run report/list. Every disposition is an immutable private `escalation.status.set` audit event. A revision allocated while the original escalation is locked orders concurrent decisions, so the last applied decision is the canonical status and annotation even if request audit IDs were reserved in another order. `--status open` can deliberately reopen an item with an explanatory note. Status filters walk indexed escalation history rather than a fixed latest-event window. No active run or public bot identity is used. ## Common JSON types All `--json` success output is one uncolored JSON value: ```ts type Success = { ok: true; status: "success" | "already_done" | "no_op" | "maximum_reached"; changed?: boolean; // mutations only data: D; }; ``` Failures print one JSON value to stdout and exit nonzero. A failing `--all` scan may already have written bounded page progress to stderr; stdout remains protocol-clean: ```ts type Failure = { ok: false; status: | "unauthenticated" | "forbidden" | "not_found" | "validation_error" | "partial_failure" | "internal_error" | "error"; error: { code: string; message: string; details: unknown | null; }; }; ``` Shared records: ```ts // Present on Subject, Comment, StandalonePost, and every recommend-queue item. // This is the OPERATOR's own view state (Mikey), never the bot's, and reading it // records nothing. type OperatorViewed = { viewed: boolean; firstViewedAt: number | null; // Unix seconds lastViewedAt: number | null; }; type Author = { id: number | null; username: string | null }; type Attachment = { filePath: string | null; fileName: string | null; fileSize: number | null; thumbUrl: string | null; url: string | null; // canonical attachment URL when path and name exist }; type RecommendationState = { recommendedByActor: boolean; actorRecommendationId: number | null; anyoneCanReward: boolean | null; count: number; items: Array<{ id: number; actor: Author; anyoneCanReward: boolean; createdAt: number | null; }>; }; type RewardState = { totalTwinkles: number; actorTwinkles: number; actorAlreadyRewardedThree: boolean; caps: { maxRewardAmount: number; maxRewardAmountForOnePerson: number; } | null; items: Array<{ id: number; recipientUserId: number | null; rewarder: Author; type: string | null; amount: number; comment: string | null; claimed: boolean; createdAt: number | null; }>; }; type Subject = { id: number; url: string; // https://www.twin-kle.com/subjects/ author: Author; createdAt: number | null; // Unix seconds updatedAt: null; title: string | null; description: string | null; attachment: Attachment | null; hasSecretAnswer: boolean; hasSecretAttachment: boolean; secret: { hasSecret: boolean; revealed: boolean | null }; effortLevel: number; // 0 means unassigned effortRevision: number; featured: { member: boolean; order: number | null }; // one-based order createdByAuthor: boolean; recommendation: RecommendationState; reward: RewardState; root: { type: string | null; id: number | null }; ageRestriction: string | null; deleted: false; unavailable: false; }; type Comment = { id: number; url: string; // https://www.twin-kle.com/comments/ subjectUrl: string | null; author: Author; createdAt: number | null; updatedAt: null; content: string | null; contentHidden: boolean; attachment: Attachment | null; parentCommentId: number | null; replyToCommentId: number | null; isNotification: boolean; ageRestriction: string | null; deleted: false; unavailable: false; recommendation: RecommendationState; reward: RewardState; }; type StandalonePost = { contentType: "aiStory" | "dailyReflection"; contentId: number; id: number; url: string; author: Author; createdAt: number | null; updatedAt: null; title: string | null; question: string | null; grade?: "Pass" | "Fail" | "Masterpiece" | null; // Daily Reflection only masterpieceType?: "heart" | "mind" | "heart_and_mind" | null; content: string | null; explanation: string | null; imagePath: string | null; audioPath: string | null; deleted: false; unavailable: false; recommendation: RecommendationState; reward: RewardState; }; type Pagination = { nextCursor: string | null; hasMore: boolean; exhausted: boolean; snapshotMaxId: number; }; type Identity = { key: "zero" | "ciel"; userId: number; username: string; }; type DailyRun = { id: number; runKey: string; operatorUserId: number; publicActorUserId: number; identityMode: "auto" | "zero" | "ciel"; commentMode: "off" | "draft" | "post"; runScope: "full" | "featured" | "newspaper"; sessionKind: "delegated-admin"; scopes: string[]; status: "active" | "completed" | "failed" | "expired"; successfulMutationCount: number; startedAt: number; expiresAt: number; completedAt: number | null; failedAt: number | null; failureReason: string | null; identity: Identity; scheduledDay: string; // YYYY-MM-DD in Asia/Bangkok scheduledIdentity: Identity; }; ``` ## Identity and daily-run commands ```bash lumine admin identity list --json lumine admin identity status --json lumine admin identity use zero --json lumine admin identity use ciel --json lumine admin identity use auto --json lumine admin identity inspect Jay1216 \ --reason "Confirm the account family before a bucket change" --json ``` Schemas: ```ts type IdentityList = Success<{ identities: Identity[]; preferredIdentity: "auto" | "zero" | "ciel"; lastCompletedIdentity: "zero" | "ciel" | null; }>; type IdentityStatus = Success<{ preferredIdentity: "auto" | "zero" | "ciel"; lastCompletedIdentity: "zero" | "ciel" | null; scheduledDay: string; scheduledIdentity: Identity; scheduleTimeZone: "Asia/Bangkok"; activeRun: DailyRun | null; }>; type IdentityUse = IdentityStatus; type IdentityInspection = Success<{ inspection: { targetUserId: number; privateEvidenceIncluded: boolean; manualBucket: { id: number; label: string; memberCount: number; isBanned: boolean; } | null; oldestAccount: IdentityCandidate | null; oldestAccountBasis: "manual_bucket" | "verified_email" | "target_only"; oldestAccountComplete: boolean; candidateAltCount: number; accounts: IdentityCandidate[]; evidenceCoverage: { deviceLookbackDays: number; targetDeviceEvidenceRows: number; targetDeviceIdsConsidered: number; relatedDeviceEvidenceRows: number; candidateLimit: number; truncated: boolean; }; }; }>; type IdentityCandidate = { userId: number; username: string | null; joinedAt: number | null; isTarget: boolean; isOldestAccount: boolean; hasDateOfBirth: boolean; banned: boolean; deleted: boolean; relationBasis: Array< "target" | "manual_bucket" | "verified_email" | "exact_device" >; sharedDeviceCount: number; privateEvidence?: { dateOfBirth: string | null; verifiedEmails: string[]; }; }; ``` `identity use zero|ciel` changes the explicit persistent override for future starts; `identity use auto` returns future starts to the Bangkok calendar schedule. It never changes an active run, alters the reported scheduled identity, or advances rotation. ```bash lumine admin daily-run start --identity auto --comment-mode off --json lumine admin daily-run start --scope featured --identity auto --json lumine admin daily-run start --scope newspaper --identity auto --json lumine admin daily-run start --identity ciel --comment-mode draft \ --run-key daily:2026-08-06:review --json lumine admin daily-run status --json lumine admin daily-run escalation add --target subject:123 \ --note "Public contact details need owner review" --severity urgent --json lumine admin daily-run escalation add --target chatMessage:3768159 \ --note "Concrete safety issue in a bot-authored chat message" --json lumine admin daily-run report --json lumine admin daily-run report --run 123 --json lumine admin daily-run complete --json lumine admin daily-run fail --reason "operator stopped" --json lumine admin escalation list --status all --json lumine admin escalation set 123 --status resolved \ --note "Final owner decision" --json ``` Schemas: ```ts type DailyRunStart = Success<{ run: DailyRun; scheduledDay: string; scheduledIdentity: Identity; scheduleTimeZone: "Asia/Bangkok"; carryoverTodos: CarryoverTodos; }>; type DailyRunStatus = Success<{ run: DailyRun | null; lastRun: DailyRun | null; }>; type DailyRunComplete = Success<{ run: DailyRun; rotationAdvanced: false; // legacy field; calendar schedules never advance by run }>; type DailyRunFail = DailyRunComplete; // `escalation add` echoes the same open-item shape `escalation list` returns, // so the run.escalation audit ID that `escalation set ` needs is in // the add response; no list round-trip is required. `recordedAt` (the audit // row's timestamp) appears only in `list`. type DailyRunEscalationAdd = Success<{ escalation: { auditId: number; // run.escalation audit event ID = escalation identity runId: number; targetType: string | null; targetId: number | null; url: string | null; summary: string; severity: "attention" | "urgent"; status: "open"; decisionNote: null; decisionAuditId: null; decisionRevision: 0; decisionUpdatedAt: null; decisionByUserId: null; }; }>; ``` ### Build Workshop sponsor applications and integrity This is the approved Zero/Ciel Build Workshop sponsor role, not the ordinary AI Energy sponsor flow. Applications originate only from `lumine sponsor`. Website-management agents review them inside an active full daily run: ```bash lumine admin sponsor applications list --status pending --json lumine admin sponsor applications review 12 --decision approve \ --note "Approved for probationary duty" --json lumine admin sponsor status set 45 --status trusted \ --note "Cleared probationary handoffs" --json lumine admin sponsor integrity scan --json lumine admin sponsor integrity cases --status open --json lumine admin sponsor integrity get 34 --json lumine admin sponsor integrity review 34 --decision clear --json ``` Run `sponsor integrity scan` until its bounded snapshot reaches `awaiting_review` or `completed`. Every pending completed handoff receives the deterministic checks. Probationary work, hard-flagged evidence, and a stable random sample become review cases; clean trusted work outside the sample is cleared automatically. A case includes the approved structured relay, canonical artifact snapshot, branch-notice evidence, and requested/resolved provider, model, effort, service-tier, runtime, usage, and agent-tree records. It never includes raw Zero/Ciel chat. `clear` qualifies a contribution to another user for its flat 50 KP award; self-sponsored testing remains ineligible even when its integrity evidence is cleared. `disqualify` makes it ineligible. `hold` and `flag` require an evidence note and remain open. The scan itself never changes sponsor status or applies a sanction. Use the separate, audited `sponsor status set` command for an explicit human decision. Full `daily-run complete` is rejected until the scan has covered its full snapshot and no pending, held, or flagged case remains. During a full review, record only qualifying escalations as they are confirmed. `daily-run report` then composes the active run's canonical audit events, successful mutations, completed queue scans, recorded escalations, and the most useful brief deltas into one result. Generate it before `complete`, because run-scoped reads require the current active run. After completion, `daily-run report --run ` is the run-independent recovery path. It reconstructs immutable run/audit/coverage/escalation evidence and the closed-day calendar cost view at the run's completion boundary. It labels that basis `historical_reconstruction`: later canonical ledger corrections to those closed days are reflected, while the boundary day's then-open cost bucket is omitted. The former live brief, carry-over-todo snapshot, and pending sponsor- application count are returned as unavailable rather than being synthesized from today's state; sponsor scan/case status is explicitly labeled as current canonical state for that run's scan. Queue coverage is written automatically only after an `--all` traversal reaches canonical exhaustion; an interrupted scan remains in its local checkpoint and cannot be misreported as complete. **Every agent-authored final full-management report includes a `Featured rotation` section.** Base it on the dated starting board, a fresh `featured list`, and canonical history. Report the target of replacing **all previous-day pins**, the exact proposed/completed outgoing-to-incoming mapping, and each retained pin with its reason. Rank new candidates by likely genuine member engagement, not thoughtfulness. Include the all-Featured-comment coverage and encouragement counts described above. When genuine capacity exists, make and report strong additions under the standing approval above; do not defer those as proposals. Every proposed or completed new addition must include its posting date and canonical never-Featured evidence; omit it when either gate is unverified. If a complete refresh is constrained, state the shortfall, including inadequate eligible inventory, inaccessible context, specific keep instructions, or pending approval. Do not report `None` merely because yesterday's posts are still good or have received support. Removing or reordering pins remains a proposal until 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. ### Daily-run conveniences (CLI 0.2.95) ```bash lumine admin daily-run gather --output-dir [--date YYYY-MM-DD] --json lumine admin daily-run progress --dir [--file ] --json lumine admin featured candidates [--days 7] [--after ] --json lumine admin report serve --file /daily-management-report.md [--port ] [--open] --json ``` These compose the documented commands in this contract, running them as child processes, so every scope check, audit and pagination rule applies unchanged. - **`gather`** saves each read-only report into ``, including the canonical published Math Lab queue in `math-lab-queue.json`. It follows `bot-output` to exhaustion and renders `bot-chats.txt`, then lists any failed step in `gather.json`. Total/per-step `durationMs`, attempts and recovered reads make recurring slow or failing collection steps visible during the daily review. It also creates `review-state.json`: every source is fetched, not read. Children bypass update checks, require matching fresh stdout/file receipts, and retry an unconfirmed opted-in read at most once. Mutations never auto-retry. It needs the active run for run-scoped reads. - **`progress`** reads local review state and explicit operator acknowledgments, writes private `progress.json`, and keeps reading, canonical effort mutations, the run lease, and browser checks separate. Add all required duties for the actual run scope and its carryovers; collection alone is not a full review. A completed run lease cannot complete a pending duty. Reading acknowledgments bind to the current file bytes and are operator attestations, not proof of comprehension. - **`featured candidates`** returns Subjects posted after the Bangkok-midnight cutoff that are off the board and provably never Featured. Each one comes with its human/bot comment counts, explicit comment truncation/completeness, and whether Mikey has viewed it. Counts from truncated context are partial. An unavailable Subject context fails the collection. Eligibility only: ranking stays editorial. - **`report serve`** detaches a loopback server that answers only `/`, `marked.min.js` and the report Markdown. `--open` opens Chrome and reports whether the OS accepted the request. Render, navigation and original-source verification remain pending until actually checked. Startup failures stop only the child this command started. ### Durable recovery and explicit duty evidence (CLI 0.3.5) Default checkpoints, mutation intents, runtime-log evidence and Build reviews live under `work/lumine-admin` in the invocation directory, with private permissions. Explicit persistent output/checkpoint paths take priority. Older automatic checkpoints in OS temp storage are copied with their candidate spools to persistent storage before resuming; the existing scope/hash checks still apply. Generic mutations persist their exact operation/account/run/session key before sending. A missing receipt leaves that key pending; rerunning the exact command reuses it instead of issuing a fresh mutation. Changed bodies or authorities get different keys. A canonical receipt is archived privately before printing, and the pending pointer closes only after successful output. Existing Featured, batch-skip and runtime-log workflows retain their own recovery contracts. `duty-evidence.json` is local operator evidence, for example: ```json { "protocol": 1, "runId": 107, "runReport": { "file": "run-report.json", "bytes": 123, "sha256": "" }, "requiredDuties": ["effort-levels", "report-browser", "football-coach"], "reading": [{ "file": "bot-chats.txt", "bytes": 456, "sha256": "", "complete": true, "readAt": "2026-10-01T00:00:00Z" }], "duties": [{ "id": "effort-levels", "status": "completed", "evidence": [{ "file": "run-report.json", "bytes": 123, "sha256": "" }], "note": "All candidates considered; preserve higher-authority levels." }] } ``` Use actual byte counts/digests and only acknowledge work performed. Every evidence reference stays inside the run directory. Changed files invalidate reading acknowledgments. Effort totals use the canonical report's `subject.effort.set` audit counts, including failed attempts separately; unavailable receipts remain unknown. Pending browser duties need genuine version-bound interaction evidence. ### 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 `/Users/mikey/Developer/twinkle/work/daily-management-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. `lastRun` makes a lost-response retry of `complete` or `fail` possible after the active pointer has been cleared. Other run-scoped commands accept only the current unexpired `active` run. Completion first finalizes any mutation whose content change committed but whose audit bookkeeping was still pending, counting it toward the run's rotation signal. It then rejects only while a mutation from the last ten minutes is genuinely in flight (the 409 lists the pending mutations and a `retryAfterSeconds`); older in-flight rows are treated as orphans of a dead process and no longer block completion. `fail` remains available to abandon a run without advancing rotation, including a run whose six-hour authorization has expired; an expired run can never be completed. A TTL-expired run is reported with status `expired` even before the next start reaps it, so `daily-run status` never shows an unusable run as `active`. Starting with a run key that belongs to a finished or expired run fails with `CLI_ADMIN_RUN_KEY_ALREADY_USED`; supply a fresh `--run-key` (for example `daily:2026-08-07:2`) to start again the same day. Reusing the key of the live active run returns that run only when the requested `--comment-mode` and `--scope`, plus any explicit `--identity`, match it; otherwise the start fails with `CLI_ADMIN_RUN_SETTINGS_MISMATCH` instead of silently returning a run with different scopes. The same check applies when a start without the active run's key would fall back to that active run. The default full-run key is `daily:YYYY-MM-DD` in Asia/Bangkok. Scoped Featured runs receive a fresh `scoped:featured:...` key so completing one slice cannot consume the day's full-run key or prevent a later explicitly requested slice. They also use a dedicated API start endpoint, so an older API cannot ignore the scope and silently create a full run; it fails before creating any run instead. Supply `--run-key` for a separate explicit run. `--idempotency-key` may be supplied to any mutation when a caller needs the same retry identity across processes. The CLI generates a fresh key for every mutation invocation; if a mutation fails, its JSON error includes `details.retryIdempotencyKey` for a safe exact retry. ### Build review requests: one queue for every unlock (any time; added 2026-09-28) Everything a creator asks Mikey to unlock is one review request with a type: `rewards` (XP & Coin rewards, below), `project-limit` (more project room), `storage-limit` (more Lumine file storage, per creator) and `cardcraft` (an AI Card crafting recipe). Mikey sees them in one list (Management → **Build approvals**, or the CLI below), gets the same DM card for each, and decides them the same way. Each type keeps its own rules: reward approvals carry the earning rules and publish the frozen version; storage approvals take a size (500 MB / 1 GB / 2 GB tiers, any size up to the 2 GB cap, never lowering an existing approval); project room approvals raise Main to the fixed bounds; card crafting approvals make the recipe live in the published app without a new release. Only rewards and card crafting approvals can be revoked. The older per-type commands (`reward-review`, `cardcraft-review`, `storage approve|reject|list`) are aliases of these routes and keep working. ```bash lumine admin review list --json # waiting on a decision (default) lumine admin review list --status queue --type storage,project --json lumine admin review show storage:12 --json # :, or --type storage lumine admin review approve storage:12 --size 1GB --json lumine admin review reject project:4 --reason "Split the big file first" --json lumine admin review approve cardcraft:3 --json lumine admin review revoke cardcraft:3 --reason "Too strong for level 1 cards" --json lumine admin review approve rewards:70 --config rules.json --json lumine admin review propose rewards:70 --dir /private/tmp/reward-review-70 --config rules.json --json ``` ### Management approvals and the teacher audit (any time; also a full-daily-review duty; added 2026-10-04) Birthdate, teacher-signup (`mentor`) and meetup-achievement requests, each with its evidence: the account, the request, who invited them, accounts linked by verified email, exact device or a manual identity bucket (with each one's age and role), the internet addresses the account acted from (network evidence, below), activity, and flags. These are Mikey-only and need no daily run. ```bash lumine admin approvals list [--status pending|approved|rejected|all] [--type dob|mentor|meetup] lumine admin approvals show lumine admin approvals approve|reject [--reason ] lumine admin teachers audit [--limit 1-100] [--cursor ] [--all] lumine admin teachers revoke --reason lumine admin teachers review --decision legit|revoke --note [--fingerprint ] # revoke requires --fingerprint lumine admin teachers review --all-flagged --expect --note lumine admin identity network --reason [--include-private-evidence] ``` **Network evidence** (`users_actions` addresses, added 2026-10-04): the account's most recently used addresses (up to 8), and for each one who else acted from it. - An address more than 8 other accounts use is a **shared network** (an academy, a school, a café): it is only counted, never listed, because it links strangers. Teachers and students at the same academy share one. - An address 8 or fewer other accounts use is a **small network** (a home): every account on it is listed with its age, role and account type. The person's own linked accounts (email, device, bucket) are marked `their linked account` and never raise a flag; logged-out visits are not accounts. If the addresses cannot be read (time cap), the pack still answers, with `network_evidence_unavailable`. - Addresses are masked (`58.151.x.59`) with a stable `addressId` for comparing reports; `--include-private-evidence` on `identity network` shows the full address. `identity network` commits a server-side access audit row with your reason before reading anything, like `identity inspect`; neither leaves a local copy unless you pass `--output `. - Only each address's newest 5,000 actions and each person's newest 5,000 are read (index-bounded, replica, time-capped), so `older history not read` can appear. **Flags.** A linked account counts as a *minor* only with a recorded age under 18, and as a *member* when it holds no teacher/staff role (most accounts record no age, so "member" does not mean student): - `shares_device_with_minor_account` / `shares_device_with_member_account`, the same for `shares_email_…` and `same_identity_bucket_…`; - `shares_small_network_with_minor_account`, `shares_small_network_with_member_account`, `shares_small_network_with_banned_account`; - `linked_account_is_minor`, `own_birthdate_is_minor`, `new_account_with_linked_accounts`, `real_name_differs_from_profile`, `banned_account_in_family`. - Flags are pointers, not verdicts: a school device can link strangers. Judge each case, recommend, and act only on Mikey's decision. - `teachers audit` reads approved teachers a page at a time (newest approval first, up to 100 per page; `--cursor` continues, `--all` pages through every teacher). Each page lists, in this order: flagged and never reviewed (`NEW`), reviewed but materially changed since (`CHANGED`, each change listed), reviewed and unchanged (one line, no evidence), then teachers with no flags. `--all` merges the pages in that order. Counts: `audited`, `flagged`, `newlyFlagged`, `changedSinceReview`, `reviewedUnchanged`. Each entry carries its `fingerprint`. - `teachers review` records Mikey's review (added 2026-10-07) of the facts he was shown. The fingerprint covers the flag set and the linked accounts (who, linked how, and whether each has a recorded age under 14 or under 18). Activity, last-active time, addresses and shared-device counts are not part of it. **Accounts that only share a network with the teacher count only when they change a network flag** (`shares_small_network_with_…`): a new sibling on a home address that already raised the member flag does not reopen a review, by design, because network sharers churn. The latest review per teacher wins; a teacher reappears when those facts change, or when a teacher reviewed as `revoke` holds the status again. - `review ` reads and prints that teacher's current entry, then sends its fingerprint; `--fingerprint ` sends the one from the audit Mikey read instead. If the facts changed since, nothing is recorded (409: read it again). - `--decision legit` keeps the teacher. `--decision revoke` **requires `--fingerprint`** from the entry Mikey decided on, then runs the same clean removal as `teachers revoke` (the note is its reason) and records the review. - `--all-flagged --expect ` pages the whole audit, prints it, and reviews as legit, with one note, only the `--expect` teachers that it shows as new or changed. Give each as `id:` (8+ hex from the audit Mikey read) to pin the facts he judged. Anything else is listed and not reviewed: new or changed but not expected; expected but its fingerprint moved; expected but not new or changed now. The server also skips, and lists, any whose facts changed between the printed audit and the write, whose last review was a revoke, or whose evidence is incomplete. Sent in batches of 25. - The write receipts these leave on disk hold only the decision (teacher id, decision, fingerprint, time, note); the evidence is printed, never saved. - Incomplete evidence is never compared or recorded: unread network evidence, or a linked-account family truncated at the identity inspection's cap. Such a teacher keeps showing until the evidence reads in full. - Record a review only on Mikey's decision for those accounts. - `teachers revoke` removes a teacher status cleanly: - the mentor achievement, plus the teenager/adult achievements the teacher approval gave unless a separately approved birthdate supports them; - the teacher title and the public "unlocked" posts; - the moderation powers that came with the level, by recounting points. - Revoke marks the request rejected, keeps who, when and why, and refuses sage/founder holders. - The daily-run procedure is in `agent-guides/lumine-admin.md`. ### Teacher branches (Mikey only, any time; added 2026-10-08) Which Twinkle branch each approved teacher works at, confirmed by Mikey through the academy networks teachers use. The branch a teacher typed when they applied is only a hint: many typed nothing, two branches, "Substitute", or an alias. ```bash lumine admin teachers branches suggest lumine admin teachers branches networks lumine admin teachers branches confirm --branch [--branch ...] [--note ] lumine admin teachers branches unconfirm lumine admin teachers branches set --branch [--note ] lumine admin teachers branches clear lumine admin teachers branches apply lumine admin teachers branches list [--branch |none] [--json] ``` - `suggest` finds the **academy networks** live: an address (`users_actions`) that 15 or more accounts used in the last 365 days, among addresses approved teachers used at least 3 times. Each one shows: - a 10-character `networkId` and a masked address (`58.151.x.59`); raw addresses never leave the server; - its account and teacher counts, and when teachers used it (an academy that changed address shows as two networks with dates that meet); - what its teachers typed, the branch most of them typed (`suggested`; `tie` when two are level), and its top 5 teachers; - whether it is already `CONFIRMED`. The read uses the read replica only, never the primary, and is time-bounded (75 s). A busy replica, or a read that hits its cap, is reported as not read, with the reason; it is never an error. `Incomplete` means run it again. - `confirm` names the network's branch. The network id must come from a `suggest` of the last 7 days (the server remembers what suggest found, so a confirm does not rescan; otherwise run suggest again). Names are the official Bridge Builder branches or their aliases (`meetup_quest_branches`; "Twinkle U" = TwinkleU, 목동 = Mokdong). A branch that is not official yet is refused: make it official in `lumine admin meetup branches` first. Give **two or more `--branch`** (or `--branches A,B`) for a building branches share (Mikey 10-08: TwinkleU and Mokdong share one). Confirming again replaces the branches. `unconfirm` removes a network. - `apply` recomputes the branch of every approved teacher that Mikey has not set, from their last-365-day actions on confirmed networks only: - a single-branch network counts for its branch; - on a shared network the actions count for the teacher's typed branch when it is one of that network's branches; otherwise they count for the shared group; - the teacher gets the top branch when it is not tied, holds at least half the actions (with shared networks that include it), and no other branch has 10% or more; - and the branch has actions on at least **3 distinct days** (Korea time) and at least 3 actions. Fewer is **low evidence**, which may be a single meetup visit to another branch or a new teacher. Such a teacher is listed with the branch, actions and days, and gets no branch. The default is 3 days, pending Mikey's confirmation. `TEACHER_BRANCH_MIN_DAYS` on the API overrides it; 0 turns it off; - otherwise the teacher is **ambiguous** (two branches, a substitute, or mostly in a shared building with no matching typed branch) and is listed with the candidate branches. No actions on a confirmed network is **unknown**. Teachers who could not be read (replica busy, slow read, time budget) are left unchanged and counted as not read. Ambiguous, low-evidence and unknown teachers get no branch; an earlier network branch is removed. It reports: - counts: assigned / ambiguous / low evidence / unknown / set by owner / not read, with reasons; - every change, with share, actions and days; - the ambiguous and low-evidence lists; - teachers given a branch other than the one they typed. Run it after each confirm or unconfirm. - `set` is Mikey's own setting for one teacher and always wins: `apply` never changes it. `clear` removes any branch (the next `apply` may give a network branch). - `list` shows every approved teacher grouped by branch, with the source (`set by owner`, or `network NN% · N actions on N day(s)`), what they typed and when last active. `--branch none` lists those without one. - Only approved teachers ever show a branch. Revoking a teacher deletes their branch, and other features (`loadTeacherBranches`) never return a branch for an account that is no longer a teacher. - Little Star is official (Mikey 10-08). "Littlestar" and 리틀스타 resolve to it. - `teachers audit` shows each teacher's confirmed branch on its line. The branch is not part of the review fingerprint, so a branch change never marks a reviewed teacher changed. - Writes are audited server-side. The local receipts hold the network id, masked address and branches; an `apply` receipt keeps only the counts and the changes. - After it goes live: `suggest`, Mikey confirms the networks, then `apply`, then settle the ambiguous teachers with `set`. ### Build XP/Coin reward approvals (any time; also a full-daily-review duty) The creator's Lumine designs the rewards and writes them into the app. The app declares its economy in `rewards.json` at the project root (rule ids, titles, XP, Coins, tries, retry share, budgets); quiz rules get their questions and answer keys from a private question sheet the creator's Lumine uploads with `lumine rewards sheet ` (never a project file: published source is readable by every player). **Send for review** (website, or `lumine rewards review` from the workspace) 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. **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) lumine admin reward-review list --status approved --json lumine admin reward-review list --status all --cursor 40 --json lumine admin reward-review show 2 --json # summary + file sizes + proposed rules 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 (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 propose 2 --dir /private/tmp/reward-review-2 --config rules.json \ --title "Word Forge" --thumbnail cover.png --json # …also offering a new name and thumbnail 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 ``` A proposal can also offer the app a new name (`--title`, at most 100 characters) and a new thumbnail (`--thumbnail `, uploaded to your proposal workspace copy first; `--thumbnail workspace` offers the one already set on that copy, e.g. from the website). Both are frozen with the offer and applied together with the files and rules when the creator accepts. An offer may change only the name or thumbnail; the files can then stay as submitted. `show --dir` writes the exact reviewed snapshot (private files, including the app's own `rewards.json`) so the agent can read it like a pulled workspace. The result's `config` is the proposal: the declared economy with the sheet's questions merged in. It also carries `detectedRuleIds` (a heuristic scan of `start({ ruleId })` calls), `isLatest`/`isLive`, the published version, lifetime totals and what this review has already paid out. Review questions to settle with Mikey before approving: - Is the reward tied to real play or learning, or does it fire on trivial or losing moments (a timer, a game over, the first minute of play)? - Completion rules (`verifier: "completion"`) prove nothing but elapsed time: the app calls `start` when an activity begins and `claim` when it ends, and the server only checks `minSeconds`, once per learner per day, and the budgets. Read the code for where those calls sit, and keep the amounts and `userDailyXP` small enough that a player scripting the calls would not matter. Arcade Typing's stage clears are the reference: up to 10,000 XP a day across twelve stages. - Quiz rules: fixed questions reachable in seconds are farmable; dated sets or `progression: "until-earned"` sets (a set stays up until somebody earns 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-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 { "userDailyXP": 10000, "userDailyCoins": 0, "rules": [ { "id": "stage-1", "title": "Clear Stage 1", "xp": 300, "coins": 0, "verifier": "completion", "minSeconds": 20 }, { "id": "e1-daily", "title": "Elementary 1 · Daily bounty", "xp": 50000, "coins": 1000, "verifier": "numeric-quiz", "maxAttempts": null, "retry": { "xpPercent": 50, "coinsPercent": 0 }, "progression": "until-earned", "sets": [{ "key": "e1-01", "questions": [{ "prompt": "...", "answer": 4, "hint": "...", "guide": { "explanation": "..." } }] }] } ] } ``` Rule fields (all server-enforced, none inferred from app code): - `verifier`: `numeric-quiz` (server-checked numeric answers) or `completion` (a finished activity; `minSeconds` is the only proof). - `sets`: question sets. Dated: `[{ "from": "2026-09-14", "to": "2026-09-14", "questions": [...] }]` on site days (UTC) (inclusive, non-overlapping, up to 62). Until-earned (`"progression": "until-earned"`): ordered sets with optional `key`; the first set nobody earned before today is up, an unsolved set is never replaced, and a set earned today stays up for the rest of that day. - `retry`: `{ "xpPercent": 50, "coinsPercent": 0 }` — what a correct answer pays after a wrong one, as a share of the rule's amounts (rounded down). Absent: every correct answer pays the full amounts. - `maxAttempts`: wrong answers allowed per challenge; `null` = unlimited until the daily reset (UTC midnight, 9:00 AM Korea) (wrong answers are paced two seconds apart). Absent: 3. - Per question `hint` (public from the start, ≤ 300 chars) and `guide` (a JSON object ≤ 6,000 chars the app renders as the after-answer lesson). The server releases a guide only after the learner's first answer. - Top-level `userDailyClaims`: receipts one learner may earn per site day across all rules. `1` is "one bounty a day". Math Lab's economy (Mikey, equal pay 2026-10-04): twelve level rules, one per grade per day, all paying 70,000 XP + 5,000 Coins; `retry` 50 % XP / 0 % Coins; `maxAttempts` null; `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. 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 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. Mikey-owned apps automatically attempt approval and publication when the owner requests reward review. Before that write, run `lumine rewards review --preflight --json` and retain its complete receipt. It identifies the saved version, artifact ID, source hash, private sheet hash and effective reward configuration hash, and states the publication behavior. After Mikey approves that exact candidate, use `lumine rewards review --approval-file `. The API checks those values under the build lock before freezing content; a change returns `build_reward_approval_stale`. There is no silent fallback to an unbound request. Saving a new preflight is read-only and is not approval. These commands require the matching API and CLI release. `propose --dir --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". **Try this version (since 2026-09-26, API 3c08af5d / vite 2.2.86).** While an offer is `changes_offered`, the creator and the reviewer (and nobody else) get a **Try this version** button on the chat card, in the creator's reward settings and in the Management approvals panel. It plays the offered `proposalSnapshot` as a normal app preview through `GET /build/preview/build/:buildId/reward-proposal/:reviewId`, with a token of its own scope (`reward-proposal:preview`, bound to viewer, build, review and revision; re-checked on every file request). XP and Coins inside it are simulated against the offered rules and never pay. The app's own SDK data calls (privateDb, sharedDb…) still reach the build's real data as the viewer, like a draft preview, and the modal says so. A newer revision or an answered offer closes the preview (409). 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. ### Owner client trace (any time, read-only; added 2026-10-06) When Mikey reports a UI issue from his phone, read what his browser did before guessing. Only the owner's own signed-in browser records it (everyone else's is a no-op and the upload route refuses them); the server keeps 30 days. ```bash lumine admin owner-trace --since 30m # readable timeline, oldest first lumine admin owner-trace --since 2026-10-06T09:00 --type route,feed-open lumine admin owner-trace --path /comments/123 --json # raw rows lumine admin owner-trace --since 1h --perf # performance events only ``` Event types: `session` (version, viewport, platform, PWA or tab), `route` (PUSH/POP/REPLACE, previous path, Home feed navigation/intent ids and action), `feed-open` (content type and id, open/comment/reward/recommend, how it was triggered and the tapped element's tag, card position), `scroll-anchor` (the scroll-anchor diagnostics: save/restore/cancel with scroll numbers), `content-scroll` (scrollTop at mount, when the content is ready, and 1 s/3 s later), `error`/`rejection` (short message and source file), `visibility`, `pagehide`, `trace-dropped`. Times are the phone's clock in this machine's time zone. Ids and paths only, never message text or other members' content. Performance events (`--perf` shows only these): `nav-timing` (one per navigation: ms from the tap to the URL change, the deploy-probe gate release with the probe's outcome current/armed/timeout/failed/throttled/backoff/pending and how long the tap waited for it, the route commit and, on content pages, content-ready; `cut by next-nav` means another navigation started before this one committed), `slow-request` (API requests over 1 s: method, path pattern with query keys only, status, ms, scheduler queue time), `stall` (main-thread gaps over 200 ms while the page is visible, bursts within 1 s coalesced) and `page-load` (once per load: TTFB, DOMContentLoaded, load, first route ready, ms since navigation start). ### Who holds which management level (any time, read-only; added 2026-10-10) Answer "who can see this?" or "is level N a teacher?" from this command, not from a raw production query. A member's management level is the higher of their user type's level and what their achievement points earn. Points never pass level 2, so every admin (level 3+) is a holder of a listed user type. ```bash lumine admin roles # every type; holders listed for level 1+ types lumine admin roles --min-level 3 # only the admin types' holders lumine admin roles --min-level 0 --limit 200 --json ``` ### Twinkle.craft universes: seed, audit, revise (any time; added 2026-10-12) An app using `Twinkle.craft` (Infinity Craft, build 1499) has its own universe of items and pairs. Players' new pairs are answered by the AI on their own Energy; we seed and curate the rest with Claude Code agents, not API calls (Mikey 10-12): an initial seed, then expansion and a daily audit, Math Lab style. No daily run is needed. `seed` and `revise` are dry runs unless `--confirm` is given. ```bash lumine admin craft stats --build 1499 [--limit 50] # sizes, frontier, today's star, newest AI answers, kept flagged names lumine admin craft seed --build 1499 --file pairs.json # ALWAYS first: what would be added, skipped, rejected, warned lumine admin craft seed --build 1499 --file pairs.json --confirm # only after reading every warning lumine admin craft revise --build 1499 --item Obsidian --why "Lava that cools very fast turns into glassy rock." --confirm ``` - `pairs.json` is up to 500 pairs, in order: `[{ "a": "Water", "b": "Fire", "result": { "name": "Steam", "emoji": "♨️", "category": "science", "why": "Fire heats water until it turns into vapour." } }]` (or `{ "pairs": [...] }`). `a` and `b` are item names: starters (Water, Fire, Earth, Wind, Tree, Nature), items already in the universe, or results earlier in the same file. - Every result passes the same checks as AI answers: 1-3 English words of letters (32 characters), exactly one emoji, a category from nature, weather, earth, space, life, body, science, energy, materials, food, tools, places, ideas, and one plain-text why of at most 140 characters (no links or markup). No AI or JEV call runs, so the content is ours to get right: real, common English nouns or ideas, no people, characters or brands, child-safe, and a true why that teaches the link. - **Always dry-run a seed first and read every warning before `--confirm`.** A warning means a word of the name is on Word Master's censored list; the pair is still written on `--confirm`, so drop or rename any pair whose name could read rudely before confirming. - A pair that already has an answer is skipped, never overwritten. Each chunk of 100 is one audited transaction (`craft.seed`); a re-run is safe. Word levels (Word Master's basic..epic) are looked up as for player items. - Seeded items have no World First: the first player to make one claims it (name on the item, rankings, the discovery reward). Seeded pairs count for Today's Star like any answered pair and never count toward the admin's daily new-pair limit. - `stats` lists the newest AI-made pairs (`source: ai`, newest first, `--limit` 1-100, default 20) with each result's name, emoji, category, word level and why. Audit them daily; fix a wrong or weak explanation with `revise`. - `stats` also lists **kept flagged names**: AI items JEV kept although a word matched the censored list (name, matched word, JEV's score, when). Read each one as a child would; `retire` any that reads rudely. - `revise` changes an item's `--why` (the explanation on its card: the pair that first made it), `--emoji` or `--category`, through the same checks. The name never changes: players hold it. Audited as `craft.revise`. - Expansion: `stats` shows the frontier (items no pair uses yet, and untried pairs); seed pairs that use frontier items so Today's Star has fresh targets. Take-down and repair (added 2026-10-13): ```bash lumine admin craft retire --build 1499 --item "" --reason "Not suitable for children" # dry run lumine admin craft retire --build 1499 --item "" --reason "Not suitable for children" --confirm lumine admin craft unfizzle --build 1499 [--since 2026-10-13T00:00:00Z] [--pair Water+Fire] # dry run lumine admin craft unfizzle --build 1499 --since 2026-10-13T00:00:00Z --confirm ``` - `retire` takes a bad item down everywhere: it leaves collections, item cards, rankings, journeys and the daily target (today's star is re-picked); the pairs that make it fizzle and no AI answer or seed can make it again; its unpaid World First no longer pays (a paid one stays paid); its name leaves bounty story lines. Who, when and why are stored on the item and in the admin audit (`craft.retire`). Starters cannot be retired. There is no un-retire. - Word Master's censored list (`content_words_censored`) is a Wordle filter, not a moderation list, so a hit never decides anything on its own. A name with a listed word (whole words only, simple inflections both ways: -s, -es, -ed, -ing; hyphens count as spaces) is always judged by JEV as a whole, told which word to look at, and must clear a stricter bar. Crystal Ball, Sperm Whale, Pork Loin or Blue-Footed Booby pass when JEV finds them innocent; a rude reading is regenerated once, then the pair fizzles. Only JEV itself judges such a name: if JEV is down and its fallback model answers, the merge takes the outage path below (the answer is kept and re-checked once JEV is back). There is no allowlist. For seeds a hit is a **warning** in the report (printed as `warning …` lines, and in `warnings` with `--json`), never a rejection. - During a safety-check outage players get `craft_check_unavailable`. A pair's answer is paid for once and re-checked free for 24 h from when the model wrote it; after that a new try generates fresh. (If JEV later judges the kept answer low, the one normal regeneration is billed as usual.) Each server pauses new runs for a minute after an outage (per pair, or everywhere after three); the pause never stops the free re-check of a kept answer or a run that has already paid. - `unfizzle` repairs pairs that fizzled because the safety check itself failed (an outage before 2026-10-13; a check outage now fails the merge without storing anything). It resets only fizzles whose stored checks all errored, never a real low verdict or a censored word; the next player to try the pair asks again. `--since` and `--pair` narrow it; up to 5,000 fizzles are scanned per run. ### Reward question-bank seeding (every full daily review; added 2026-09-28) `generated-quiz` rules fill a question bank on the server: a question is written for one declared topic at one ladder step (GPT-6.1 Sol) and kept only when an independent second solve agrees. Learners write missing questions themselves on their own AI Energy; seeding writes the gentlest steps ahead of them so the first learner on a unit never waits or pays. ```bash lumine admin reward-bank coverage [--max-step 3] [--json] # read-only, no run lumine admin reward-bank seed [--max-step 3] [--json] # delegated full run lumine admin reward-bank report [--days 1] [--json] # read-only telemetry ``` `report` covers the last `--days` (1-31): generation rounds by source (learner or seed) with outcomes (`accepted`, `off_brief`: the checker judged the question outside the brief's language, level or LaTeX rule; `answer_mismatch`; `malformed`; `error`), cost and time, and recent rejection reasons; learners served/answered/first-try/solved/skipped per rule and step; payouts; the current ladder distribution; active/hidden questions; the hardest questions (3+ learners) and every reported question with reasons; and seeding coverage for steps 1-3 once the app is approved. - `seed` writes ONE question per call into the first missing slot, lowest step first across every topic of every generated-quiz rule, up to `--max-step` (default 3, at most 10). A slot is a (rule, topic, step) with no active live question. The call takes as long as two model calls (about 20–40 s; the CLI allows 4 minutes) and returns `seeded` (`questionId`, `ruleId`, `topicKey`, `step`) or `complete: true`, plus `coverage` (`filled` / `total`). - It needs the `reward:bank-seed` scope, which only full delegated runs carry. The question is written as the run identity (Zero or Ciel) and billed to that account's own AI Energy. It never pays anyone and opens no challenge. - It refuses unless the app's rewards are approved and published (`CLI_ADMIN_BUILD_REWARD_BANK_NOT_LIVE`), and refuses to store a question if the approval changed while it was being written (`CLI_ADMIN_BUILD_REWARD_BANK_REVIEW_CHANGED`: run it again). `CLI_ADMIN_BUILD_REWARD_BANK_UNVERIFIED` means the two solves disagreed twice; nothing was stored. - Which apps to seed, how many steps and how many per run are Mikey's decisions, recorded in the agent guide (Math Studio #2655: steps 1–3, at most 20 per run). ### Reward activity report (standing duty, every full daily review; added 2026-09-12) Completion rewards (Arcade Typing's stage clears) prove nothing but elapsed time, so the run reads the shape of the week's claims instead of trusting them: ```bash lumine admin reward-activity --json # 7 UTC days INCLUDING today’s partial day lumine admin reward-activity --date 2026-09-13 --json # exactly this UTC day lumine admin reward-activity --date 2026-09-13 --days 7 --json # 7 days ending on this date lumine admin reward-activity --days 14 --build 333 --json ``` Read-only, no run lease. For yesterday, always pass its exact UTC `--date`; `--days 1` alone means the current partial day. `from`, `to`, `timezone`, and `includesCurrentDay` make the window explicit. Rules come from each claim’s frozen review, not the current app policy; `missingReviewIds` means rule-based flags lack context. The result lists every app that paid (claims, earners, XP, Coins) and the flagged player-days, worst first: - `fast`: a completion claim within 5 s of the rule's `minSeconds` — a human who types the stage lands well above the minimum; a script lands on it; - `burst`: 3+ claims within 10 minutes; - `sweep`: 75 %+ of an app's completion rules earned within 30 minutes (3+ claims); - `cap` / `daily-max`: at the per-learner day cap; at it on 3+ days of the window; - `guessing`: a quiz challenge with 15+ wrong answers (unlimited-tries rules). Put the app totals and every flagged row in the daily report verbatim. A single `cap` day is a good player having a good day; `fast` + `sweep` + `burst` together on one player is the script signature. None of it is proof: 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 `_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 ` 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. ### Members' chat reports (any time; also a full-daily-review duty, added 2026-09-27) Any member can report another member's chat message from the message's "…" menu (reasons: bullying or harassment, sexual content, asking for personal info, spam or scam, something else; optional note). The API snapshots the message and a few messages around it, so a later edit or delete does not erase the evidence, and Zero DMs Mikey on the first report of each message. The reporter only sees "Thanks. Our team will look at this."; the reported member is never told. The full-run intake and report carry `chatReports` (pending = `open` + `reviewing`), like `rewardReviews`. These commands need no daily run: ```bash lumine admin chat-reports list --json # pending (default) lumine admin chat-reports list --status all --cursor 40 --json lumine admin chat-reports show 12 --json # snapshot + context lumine admin chat-reports set 12 --status resolved --note "What was decided or done" --json ``` Read every pending report's snapshot and context in each full run. A report about a child's safety or wellbeing (sexual content, requests for personal information or photos, threats, targeted bullying) belongs at the top of the escalation list for Mikey with the report id, both usernames and a one-line summary; set it to `reviewing` with a note saying so. Spam, obvious misclicks and ordinary disagreements can be `dismissed` with a note. Recording a status only annotates the report: never message, ban or otherwise act against either member without Mikey's explicit go-ahead. ### Child-safety holds, evidence export and incident runbook (Mikey only, added 2026-09-27) > Not legal advice. Have a Korean lawyer review this procedure. Mikey, 2026-09-27: "if someone did something wrong - especially if for example a teacher was being inappropriate to a kid - shouldnt we be able to help police investigate?" **Automatic holds.** A report for sexual content or asking for personal info, or any report between a minor and an adult where both ages are known (an admin-approved birthdate, otherwise the birthdate on the profile), places a safety hold on the whole conversation and on both accounts. A second such report in the same conversation joins the existing hold. Zero, Ciel and the site-wide General channel are never held (a General report holds the two accounts). Zero's alert DM to Mikey says when a hold was placed, and `chat-reports show ` lists `safetyHoldIds`. **What a hold does**, silently, until it is released: a member's delete or edit still works for everyone, but the message row stays and the text before an edit (or the row at deletion) is copied to the hold; topic edits, removed archived profile pictures and removed previous usernames are copied too. Permanent deletion of a held message or of a held member's post or comment is refused with a neutral "can't be permanently deleted right now". Twinkle has no account deletion, so accounts are never erased. Nothing about a hold is shown to members. These commands are for Mikey. A daily run may read `list-holds` and report it, but never places, releases or exports a hold or suspends anyone without Mikey's explicit instruction for that case: ```bash lumine admin chat-reports hold 12 --note "Why this case is held" --json lumine admin chat-reports hold --user 7,9 --channel 40 --note "Parent phoned" --json lumine admin chat-reports list-holds [--status active|released|all] --json lumine admin chat-reports suspend --user 7 --note "Adult under investigation" --json lumine admin chat-reports export 12 --out ~/twinkle-case-12 --json # or --hold lumine admin chat-reports release 3 --note "Police closed the case" --json ``` Every hold, release, export and suspension is recorded with who and when (`chat_safety_actions`), and released holds keep their copies. **Incident runbook** (for example, an adult or a teacher being inappropriate to a child): 1. **Suspend the adult's access**: `chat-reports suspend --user --note `. This is the website's full ban: it signs them out and blocks the site. Lift it later from the website's Management ban editor. 2. **Place or confirm the hold**: `chat-reports hold --note ` (or `--user`/`--channel` when there is no report yet, for example after a parent's call), then `list-holds` to check that it covers the conversation and both accounts. 3. **Export the evidence**: `chat-reports export --out `. The folder holds the whole conversation with UTC and KST times, deletions and held edits; both accounts (username, id, join date, verified email, birthdates, username history, linked Minecraft players, and the IP addresses the site stores for logouts, searches and page visits); the report(s); the actions taken; and `manifest.json` with each file's SHA-256. Write down the printed manifest hash, keep the folder private, and never edit it. Attachments are listed by storage key, not included. 4. **Contact the police**: 112 for an emergency or ongoing danger, or the cyber crime report system at https://ecrm.police.go.kr. Give them the export when they ask for it. 5. **Contact child protection**: report suspected child abuse to 112 (the national child-abuse report line), which connects to the local 아동보호전문기관 (child protection agency). 6. **Teachers and academy staff are mandatory reporters**: under Korea's Act on Special Cases Concerning the Punishment of Child Abuse Crimes, teachers and academy (hagwon) staff must report suspected child abuse. If the adult is a teacher, their employer may also need to be told; ask the lawyer. 7. **Do not** confront or warn the adult, delete anything, or share the evidence with anyone but the police or child-protection staff. 8. **Release the hold** only after the case is closed: `chat-reports release --note `. ## Private carry-over todos ### Zero and Ciel's personal follow-ups Each bot has a separate persistent list of commitments made to members. The API reply tools save a concrete task before saying it is on the bot's list; they link the real source comment/chat and keep the requesting member and bot server-owned. Retries of the same message return the same task. Members can ask that bot to read or cancel their own tasks. This does not approve any administrative action, deployment, reward, or publication. Full `daily-run start` returns `personalFollowups` for the assigned bot; `daily-run gather` saves its first page in `personal-followups.json`. Follow `nextCursor` to exhaustion. Other bots' tasks wait for their own turns, and scoped sessions do not surface or modify the list. ```bash lumine admin followup list --json lumine admin followup list --cursor 100 --json lumine admin followup update 17 --revision 2 --status completed --note "Played the requested path on published version 400; observed ...; replied in original comment 91 (reply 103)." --json ``` Read the original context, do the promised work, keep evidence, and report the real result to the member in the original context under the existing reply rules. Do not move a private request into a public post. Build replies still require exact-version review evidence. Record `blocked` with a concrete next step when access, the creator, or Mikey's decision is needed. A completed daily run never completes promises automatically. Update requires the current revision and the assigned bot's active full run; stale or sibling updates are refused. Daily reports include pending follow-ups and their latest progress. Apply `add-ai-daily-followups.sql` before deploying this API/CLI capability. ### Operator carryovers ```bash lumine admin todo list --json lumine admin todo list --status all --json lumine admin todo add --kind experiment --status in_progress \ --title "Validate Zero/Ciel cost optimization" \ --note "Replay baseline and optimized conversations. Complete only after response-quality parity; lower cost with a weaker reply fails." --json lumine admin todo update 12 --status blocked \ --note "Implementation is ready; waiting for a complete cost bucket and old-vs-new quality replay." --json lumine admin todo update 12 --status completed \ --note "Blind parity comparison passed every required dimension; measured cost and latency evidence attached in this note." --json ``` Todos are private operator work, not Zero/Ciel public actions. They persist independently of daily runs and are therefore available before a run starts and after it closes. Creating or updating one uses the run-independent transactional audit path: canonical todo state and its private `todo.create` / `todo.update` audit response commit together, and no public bot, public mutation count, or rotation signal is involved. Track implementation, release and verification separately when a carryover involves a fix. After `add-admin-todo-workflow.sql` and the matching API are deployed, save a local JSON file such as: ```json { "implementation": "ready", "release": "pending", "verification": "pending", "fixRef": "work/topic/release-review.md", "releaseRef": "", "evidence": "Focused regression passed; production is unchanged.", "nextAction": "Deployer releases the reviewed fix, then check the live result." } ``` Use `lumine admin todo update 12 --revision --workflow work/topic/workflow.json --status in_progress --note "Ready for the deployer." --json`. The revision comes from the canonical list/update response; stale updates are rejected. Implementation values are `needed`, `in_progress`, `ready`, `not_needed`; release is `pending`, `live`, `not_needed`; verification is `pending` or `passed`. Any unfinished phase needs a concrete `nextAction`; passed verification needs `evidence`. Completion requires implementation ready (or unnecessary), release live (or unnecessary), and verification passed. Keep physical-device checks and observation windows pending until they happen. Legacy todos have `workflow: null`, which means unknown, never verified. An update without `--workflow` preserves an existing workflow and cannot bypass its completion requirements. Every successful full `daily-run start` response automatically includes all unfinished items under `data.carryoverTodos`. The same run ID increments an item's surfacing telemetry at most once, even when start is retried. This is the canonical handoff: read it before discretionary new work, resume what can safely progress after the run's mandatory newspaper/brief/conduct/log-review/cost/ energy-budget duties, and record a concrete progress note before the run closes. The daily-run report includes the still-unfinished set again. Completing a daily run never silently completes its todos. A CLI carrying this contract rejects a start response that does not echo the canonical handoff, so a newer CLI against an API deployed before the todo migration cannot quietly treat unsupported telemetry as an empty list. A Featured-only start instead returns an explicitly suppressed, empty handoff and performs no todo reads, writes, capacity checks, or surfacing increments. Evidence-dependent investigations must have a durable collection plan. Do not carry “still no recycle-under-load evidence” forward without checking the collector and recording new observations. Full starts and reports return `runtimeEvidence` with a scoped read command; this handoff is suppressed for Featured/newspaper slices. During a full daily run with pending runtime investigations, use: ```sh lumine admin runtime evidence primary --days 7 --json # Only when the investigation also covers the configured target host: lumine admin runtime evidence target --days 7 --json ``` This is a read-only, run-independent command. It does not acquire/clear a log lease, trigger a recycle, or authorize an unrelated management review. Host routing is explicit and never silently substitutes primary for target. An older API without this endpoint is unsupported, not “no incidents.” The cluster primary samples existing worker health snapshots once per minute and records memory-guard/operator recycle lifecycle events. Records survive restarts in the health directory's `evidence/` subdirectory (seven UTC calendar days, at most 2 MiB/day; 256 KiB/day reserved for events). Work is recorded as counts by kind, not user IDs, request labels, messages or tokens. Evidence is passive: never force production load, a worker recycle or a restart merely to complete an experiment. New collector code requires activation of the new **primary generation**, not just a rolling worker reload; verify a fresh live sample before saying collection is running. For each affected todo, persist the checked host/runtime identity, previous and new evidence cutoff, sample count/gaps/freshness, qualifying event IDs and the next safe action. `unavailable`, `stale` or `incomplete` means investigate the collection gap. A healthy collector with no qualifying recycle means keep collecting, not stall or claim a failure. Save the relevant summary in the todo before the seven-day retention window passes. Missing/stale active-work or OOM observations remain unknown; they are never zero or idle by default. Set investigation-specific acceptance criteria before interpreting results. For memory/recycle investigations, distinguish a long-lived steady-memory baseline from a recycle observed under load. Require the requested/signalled/ recovered sequence, fresh pre-recycle work evidence, replacement identity, bounded recovery time, and no OOM-counter increase across the same primary generation. “Topology recovered” does **not** prove each interrupted user task completed: correlate those tasks' existing canonical outcomes before closing a user-work continuity investigation. Never close based only on deployed code, a current healthy snapshot, or an unobserved event. Daily runs collect evidence and update todos; fixes and releases follow the project's existing authority rules. `kind` is `task` or `experiment`. New items may start `open`, `in_progress`, or `blocked`; updates may also use `completed` or `cancelled`. A progress note is required for every update. For experiments, put the acceptance criteria in the initial details and use evidence—not implementation status—as the completion boundary. In particular, an AI-cost experiment is not complete until old-vs-new response-quality parity is demonstrated; a cheaper but weaker user response is a failed experiment. Up to 50 unfinished items may be carried so the automatic start payload remains complete and bounded. ```ts type AdminTodo = { id: number; kind: "task" | "experiment"; title: string; details: string; status: "open" | "in_progress" | "blocked" | "completed" | "cancelled"; revision: number; createdRunId: number | null; lastWorkedRunId: number | null; lastSurfacedRunId: number | null; surfaceCount: number; lastProgressNote: string | null; createdAt: number; updatedAt: number; lastSurfacedAt: number | null; completedAt: number | null; cancelledAt: number | null; }; type AdminTodoList = Success<{ todos: AdminTodo[]; statusFilter: "pending" | "all" | AdminTodo["status"]; truncated: boolean; }>; type AdminTodoMutation = Success<{ todo: AdminTodo }>; type CarryoverTodos = { included: boolean; items: AdminTodo[]; count: number; surfacedForRunId: number | null; newlySurfacedCount: number; }; ``` ## Canonical lists and inspection ```bash lumine admin recommendations list --kind recommend \ --content-types comment,dailyReflection --all --json lumine admin recommendations list --after 2026-08-14T00:00:00Z \ --all --checkpoint recommendations.json --json lumine admin recommendations list --include-legacy --all --json lumine admin recommendations list --unviewed --json lumine admin subjects candidates --after 2026-08-01T00:00:00Z \ --all --checkpoint subjects.json --json lumine admin subjects candidates --since-run --all --json lumine admin subjects candidates --include-legacy --all --json lumine admin subjects candidates --effort unassigned --json lumine admin subjects candidates --unviewed --json lumine admin builds candidates --all --limit 50 --json lumine admin builds review build:884 --output-dir ./build-review --json lumine admin builds review build:884 --output-dir ./build-review \ --interact ./build-review/steps.json --json ``` Schemas: ```ts type RecommendationQueueList = Success<{ items: Array<{ queueId: string; feedId: number; contentType: "comment" | "aiStory" | "dailyReflection"; contentId: number; url: string | null; subjectUrl: string | null; author: Author; createdAt: number | null; title?: string | null; question?: string | null; content: string | null; explanation?: string | null; attachment?: Attachment | null; imagePath?: string | null; audioPath?: string | null; subject?: { id: number; title: string | null; effortLevel: number; url: string; }; recommendation: RecommendationState; reward: RewardState; }>; pagination: Pagination & { scannedCount: number; contentTypes?: Array<"comment" | "aiStory" | "dailyReflection">; }; clientFilter?: { contentTypes: Array<"comment" | "aiStory" | "dailyReflection">; excludedItems: number; }; }>; type SubjectCandidates = Success<{ subjects: Subject[]; pagination: Pagination & { scannedCount: number }; }>; type BuildCandidates = Success<{ builds: Array<{ id: number; title: string | null; description: string | null; username: string | null; publishedAt: number | null; publishedArtifactVersionId: number | null; collaborationMode: "private" | "open_source"; url: string; review: { publishedArtifactVersionId: number | null; codePullAvailable: boolean; requiredBeforeComment: true; }; }>; pagination: { nextCursor: string | null; hasMore: boolean; exhausted: boolean; }; }>; ``` Subject cursors freeze a primary-key high-water mark plus the server snapshot timestamp and traverse descending IDs; bounded scans keep creation timestamps inside that confirmed interval. Bounded recommendation cursors freeze both the feed-ID high-water mark and the server timestamp, then traverse the indexed `(timeStamp, id)` order; this also catches a Daily Reflection whose old feed row moved forward when it was reshared. Explicit legacy scans retain the descending primary-key walk. A page can be empty while `hasMore` remains true; continue until `exhausted`. `--all` does that automatically, fsyncs each confirmed page to a private NDJSON candidate spool, and writes only bounded cursor, boundary, count, byte-length, and digest metadata to the private checkpoint. `--resume` continues only when the checkpoint belongs to the same API, run, and exact request and its confirmed spool prefix still matches those metadata; an unconfirmed fsynced tail is discarded before the next request. The final JSON collection is streamed from the spool and can be copied to a separate `--output` file, while `--checkpoint` remains resumable operational state. Subject `--after` is inclusive, and every opaque cursor is bound to its original filters. An automatic checkpoint filename includes a fingerprint of the exact request, so two scans with the same operation name and run ID but different subjects, server filters, client-side view filters, or result-transform inputs cannot overwrite one another. An exclusive adjacent lock rejects a second process using the same checkpoint while the first scan is active and recovers a lock only when its recorded process no longer exists. Resume still recognizes the pre-fingerprint default filename, validates its stored request fingerprint, and migrates it through the existing checkpoint path. Legacy Build-candidate checkpoints intentionally fail that validation because they did not bind the Site URL used to materialize candidate links; start those scans fresh so one result cannot mix origins. For `--all --json`, stdout remains exactly one JSON value. Scan-start, first- page, every-tenth-page, and exhaustion progress is written to **stderr** with only page/scanned/candidate counts and the private checkpoint path. A long traversal therefore no longer looks stalled, while piping stdout to `jq` or a file remains safe. `Ctrl+C` and `SIGTERM` abort the in-flight page request, leave the last server-confirmed page fsynced in the private checkpoint/spool, and release the adjacent process lock. The cancellation error names the checkpoint. Continue only by rerunning the exact same command with `--resume`; the next invocation verifies the request fingerprint and confirmed spool digest before requesting another page. An interrupted request is never counted as queue coverage. Recommendations default to `--since-run`: the server uses the previous completed full run's start time, even if that gap exceeds 30 days. On a first run, the fallback begins seven days before the current run's stored start, so it cannot drift between pages. Insight reports retain their separate 30-day limit. That deliberate start-to-start overlap gives the queue at-least-once coverage when content arrives after the prior snapshot but before that run completes. `--after` supplies an explicit inclusive timestamp. All-history traversal is deliberately available only through `--include-legacy`. The CLI requires the API to echo the canonical `after` boundary for bounded modes, so deploying a new CLI against an older API cannot silently fall back to a million-row historical scan. `recommendations list` is the Earn Recommend picker, not a "new comments" feed: it returns only comments on subjects with an assigned effort level, whose length exceeds that level's threshold (>100 / >250 / >450 / >700 characters for effort ≤2 / 3 / 4 / 5), with no skip row and no existing recommendation from any effective Level 5+ user (1000+ AP or Teacher authority), Zero, or Ciel. Community-recommended and short comments are deliberately absent, so an empty page or an empty window is normal and is not evidence of a broken walk; Featured-subject comments are reviewed through the Featured comment scan instead. A successful `post recommend` does not imply the target was queue-eligible. After upgrading the API and CLI to the stable run-start window, start a fresh `--since-run` scan with a new checkpoint path, without `--resume`. Older since-run checkpoints are rejected even when already exhausted: they may have captured the former 30-day reporting cap. They are left intact as evidence. Explicit `--after` and `--include-legacy` checkpoints retain their contracts. Subject candidates follow the same window contract. They default to the previous completed full run's start (with the seven-day first-run fallback), accept an explicit inclusive `--after`, and require `--include-legacy` for a lifetime traversal. `--since-run`, `--after`, and `--include-legacy` are mutually exclusive. The CLI also requires the API to echo the bounded Subject window before accepting a page. `builds candidates` uses the admin publication-window endpoint, ordered by `publishedAt` and Build ID, not workspace `updatedAt`. Like Subject discovery, it defaults to the previous completed full run's start (seven-day first-run fallback), accepts inclusive `--after`, and requires `--include-legacy` for all history. These flags are mutually exclusive. The first page freezes the time boundary and an artifact-version high-water mark; the cursor and local checkpoint retain both. An old public-browser checkpoint cannot be reused. The CLI fails closed if the API does not confirm this publication window. It is available through the `admin` namespace only while a delegated run is active; page until `pagination.exhausted`. Each item includes its canonical app URL, published artifact version, and whether its code is pullable. This list does not decide that an app deserves a comment. The management agent must open and genuinely try the published runtime, or pull and read an open-source project, before making that judgment. Direct API/persona automation is never a review substitute. Only current public Main releases are candidates. Workspace-only saves and unchanged reactivations do not become new releases. A Build republished during paging can leave the snapshot; its new release is reconsidered by the next overlapping start-to-start window. Always recheck the current artifact before reviewing; this is not a frozen copy of an app or an immutable release archive. `builds review` is the managed runtime path: it fetches the current published artifact identity, launches the app in an isolated temporary Chromium profile, captures a screenshot and bounded console evidence, then fetches the identity again. It writes `review.json` in a unique per-review subdirectory only when the browser completed, the screenshot exists, and the artifact did not change mid-review. Attach the returned `receiptPath` with `comment draft ... --review-receipt review.json`, and pass a separate private `--review-context context.json` containing only the concrete `understanding` learned during that review. The receipt binds the draft to the exact reviewed artifact without copying a version number by hand; the server owns the Build, version, method, and review-time fields around that understanding. Without `--interact` the review captures only the start screen after `--wait-ms`. `--interact ` adds a bounded, ordered interaction script that runs inside the app's runtime iframe after that start screenshot, so the receipt can show what happens when the app is actually used. The file is a JSON array (or `{ "steps": [...] }`) of at most **12** steps, each exactly one of: ```json [ { "click": "text=Start" }, { "wait": 1500 }, { "screenshot": "after-start" }, { "type": { "selector": "input[name=name]", "text": "Zero" } }, { "press": "Enter" }, { "press": "ArrowLeft" }, { "screenshot": "moved" } ] ``` - `click`: a CSS selector, or `text=` (case-insensitive; the smallest visible element whose text matches, then a bounded contains match). Dispatched as a trusted mouse click at the element's centre, so canvas games and buttons both receive it. - `type`: `{ selector, text }` — clicks the element, then inserts single-line text (at most 200 characters) as trusted input. - `press`: `Enter`, `Space`, `Escape`, `Tab`, `Backspace`, `ArrowUp/Down/Left/Right`, a letter, or a digit. The frame is focused first if nothing was clicked yet. - `wait`: 1–5000 ms. - `screenshot`: a unique label (1–40 letters/digits/`-`/`_`, not `runtime` or `review`); saved as `