@stage5/lumine 0.2.68 → 0.2.70

package/sdk/LUMINE_ADMIN.md

@@ -484,6 +484,27 @@ it never authorizes unrelated daily work or generic recommendation commands.
    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, 12-grade/36-question editorial
+process, verification, repeat-run recovery, release gates, and final reporting.
+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.
+
+The initial private draft must remain unpublished until Mikey authorizes its
+launch. After launch, routine content releases follow the standing duty but
+cannot bypass a reward-enabled app's exact-version approval gate. 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
 
 A full daily management run is not finished when the mutations are done. Curation surfaces things only
@@ -891,6 +912,27 @@ type DailyRunComplete = Success<{
   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 <auditId>` 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
@@ -1038,6 +1080,53 @@ 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
@@ -1101,6 +1190,8 @@ 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:
@@ -1215,8 +1306,10 @@ 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 run's start time (or the same bounded seven-day fallback used by the
-brief on a first run). That deliberate start-to-start overlap gives the queue
+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
@@ -1224,6 +1317,23 @@ All-history traversal is deliberately available only through
 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
@@ -1231,9 +1341,16 @@ 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` is a management-agent discovery view over the canonical
-public Build browser, ordered by the current published release. It is
-available through the `admin` namespace only while a delegated run is active;
+`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
@@ -1241,6 +1358,12 @@ 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
@@ -1253,6 +1376,53 @@ 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 <steps.json>` 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=<visible 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 `<label>.png` beside `runtime.png`.
+
+The whole script is capped at **60 s**; it stops at the first failed step
+(element not found/not visible, budget exhausted, frame unreachable). Console
+evidence stays bounded exactly as before. `review.json` gains
+`screenshots: [{ label, path, bytes }]` (script screenshots only; the start
+screen stays in `screenshot`) and
+`interaction: { path, stepsPlanned, stepsCompleted, status, failedStep, frame,
+elapsedMs, steps }` with a per-step record (coordinates for clicks, the saved
+path for screenshots, the error for a failed step). Both are `[]`/`null`
+without `--interact`. The review remains one receipt bound to one artifact: the
+published version is re-read after the script finishes, and a script that did
+not complete makes the receipt `failed` with
+`CLI_ADMIN_BUILD_REVIEW_INTERACTION_FAILED` (the completed steps and their
+screenshots are still listed) so a draft can never cite interactions that did
+not happen. `comment draft --review-receipt` accepts a receipt only when every
+listed screenshot still exists unchanged and the script completed.
+
 During every full daily management review, scan recent Build candidates back through the
 run's review window alongside Subjects and the recommendation queue. An app
 that is thin, broken, private, unchanged since a prior substantive bot
@@ -1551,6 +1721,16 @@ after the finalized coverage boundary. `null` means the subject predates provabl
 coverage—never convert that unknown into “never Featured.” Both the website
 editor and Lumine mutations write this append-only history in the same
 transaction as the canonical board replacement.
+Each API read accepts up to **100 subject IDs**, independently of the
+20-subject delegated addition policy. `--all` automatically batches larger
+lists (up to 20,000 IDs), exhausts every batch's event pages, and retains all
+per-subject summaries. Use the exact command with `--resume` after interruption;
+confirmed pages are not replayed. Single-batch `--cursor` remains available,
+but cannot be combined with `--all`. Multi-batch results explicitly use
+`pagination.snapshotScope: "per-batch"`; events are ordered by input batch,
+then descending event ID within that batch—not by one global snapshot.
+`data.scan.batches` records each batch's coverage, snapshot and private spool.
+Deploy the matching API before using the expanded read bound.
 For a retry whose board transaction committed but whose canonical detail reload
 failed, the audit-linked history event is the durable receipt: the API re-reads
 the current board and preserves the original changed-mutation accounting.
@@ -1637,7 +1817,8 @@ lumine admin featured comments scan --checkpoint featured-read.json --json
 # On interruption: repeat with --resume, in the same active run.
 # Read ALL pageFiles, including full root context and nested replies.
 lumine admin featured comments acknowledge \
-  --checkpoint featured-read.json --reviewed --json
+  --checkpoint featured-read.json --reviewed \
+  --decisions-template featured-decisions.json --json
 ```
 
 The scan snapshots every current Featured Subject (up to 100) and its maximum
@@ -1658,6 +1839,26 @@ missing Subject IDs and comment counts, and distinguishes complete from partial
 coverage. A download alone never counts as a read or grants recommendations.
 After a resumed scan fills a gap, read those pages and acknowledge again.
 
+Acknowledge returns `data.reviewedCoverage` (the coverage receipt; its `id` is
+the `coverageId` the recommend step needs — it is a different audit row from
+the review ID) and a ready-to-fill `data.decisionsTemplate`
+`{ reviewId, coverageId, selections: [] }`. With `--decisions-template <file>`
+the CLI also writes that template as a private mode-0600 file; only
+`acknowledge --reviewed` writes it (a scan rejects the flag). Start the
+decisions file from the template rather than assembling the identifiers by
+hand. `readFeaturedSelections` refuses a file whose `coverageId` equals its
+`reviewId` before any request is sent, and the API answers a wrong receipt
+with `CLI_ADMIN_FEATURED_COVERAGE_MISMATCH` naming the expected receipt, e.g.
+`coverageId 5719 is not the acknowledged coverage receipt for review 5719
+(expected 5749; 5719 is the review ID itself).` with
+`details: { reviewId, suppliedCoverageId, expectedCoverageId,
+suppliedReceiptAction, suppliedCoverageReviewId }`, or
+`CLI_ADMIN_FEATURED_COVERAGE_MISSING` when the review has no acknowledged
+coverage in this run. Other receipt failures (a page ID from another run,
+operator, or actor) keep the generic
+`Receipt #<id> is not a completed <action> receipt of this active run,
+operator and actor.` rejection.
+
 Compose a decisions JSON file from the genuinely reviewed comments, using the
 returned review ID, coverage receipt ID, and each selected comment's page ID:
 
@@ -2108,10 +2309,23 @@ type NewsSubmit = NewsStatus; // "success"; newspaper includes revisionNumber
 lumine admin bot-output --json
 lumine admin bot-output --days 3 --json
 lumine admin bot-output --cursor '<pagination.nextCursor>' --json
+lumine admin bot-output context 3797910 --reason "Review reported bot conduct in its conversation context" --json
+lumine admin bot-output context 3797910 --reason "Continue the same bot-conduct review" --cursor '<pagination.nextCursor>' --json
 ```
 
 **Every full daily review reads what Zero and Ciel themselves said since the
 last completed full review.**
+
+**Ordinary wrong answers and hallucinations are expected model limitations,
+not website incidents.** A factual error, mistaken puzzle answer, or imperfect
+reasoning alone does not warrant an escalation, engineering todo, or a code
+patch. Model quality improves through LLM upgrades; do not add hard-coded
+answer validators, secondary graders, forced research, correctness retry loops,
+or subject-specific rules to compensate. A normal conversational correction is
+enough when appropriate. This does not excuse actual harmful conduct or
+application failures, nor weaken security, permissions, billing, or canonical
+server-state checks: investigate those distinct problems on concrete evidence.
+
 The bots talk to children constantly — chat replies, Daily Reflection
 responses, autonomous comment-assistant comments — and a harmful message must
 never depend on a kid being brave enough to report it (real incident,
@@ -2120,7 +2334,9 @@ streak — "I'm telling you: Stop", guilt framing, ordering him to quit Daily
 Reflections — and it surfaced only because the kid showed Mikey).
 
 `bot-output` returns, windowed since the operator's last completed full run
-(`--days 1..30` overrides): `chatMessages` (every stored Zero/Ciel chat and
+(`--days 1..30` overrides; the bare form sends no `days` parameter at all, so
+the API applies that default window — an older CLI wrongly validated the empty
+default and failed with "--days must be an integer"): `chatMessages` (every stored Zero/Ciel chat and
 reflection reply, with full text and recipient metadata when its best-effort
 prompt audit exists) and `comments`
 (every public bot comment/reply). Individual utterances are returned in full;
@@ -2137,6 +2353,27 @@ right after the brief, and **read every row** — the tool deliberately does no
 filtering, scoring, or keyword matching, because the judgment is the reviewing
 agent's.
 
+Chat output now also includes `messageKind`, `attachment`, and the stored
+`generation` outcome (success, failure, cancelled, generating, or unresolved).
+This is stored-message evidence, not a live request-guard check: do not call
+an empty row an orphan solely from its text. Hidden attachment locations and
+arbitrary settings/request keys are never returned. `source: voice` identifies
+newly recorded voice transcripts, while typed input during a call says `typed`;
+older replies correctly say `not-recorded`
+because the historical schema did not distinguish typed text from voice.
+
+`bot-output context <messageId>` is a private, **run-independent** investigation.
+It requires a 1–500 character reason and records a minimized access receipt,
+not the private message text, in the audit. It returns the specified existing
+Zero/Ciel output plus preceding messages in that bot's own two-person
+conversation and exact topic/subchannel, oldest first within each page.
+Default 20, maximum 40 messages per page; continue manually with the cursor.
+The complete scope is bounded to 100 prior rows, 24 hours, and 10,000 message
+IDs before the anchor. `boundedLimitReached` means stop and report that bound,
+not that all channel history was reviewed. Deleted messages and hidden
+attachments remain hidden. Group-channel browsing, `--all`, and `--days` are
+not supported. Never start an entire daily run just to investigate one reply.
+
 ### API runtime-log review (same phase, every full daily review)
 
 The bot-conduct review also owns a bounded production API log review. Bot
@@ -2145,6 +2382,24 @@ the HTTP layer while stdout records a degraded fallback/retry loop or stderr
 records a side-effect failure. Reviewing only `bot-output` can therefore miss
 the other half of what happened.
 
+For passive RSS/recycle investigations, use the read-only command independently
+of a daily run or production-log review:
+
+```bash
+lumine admin runtime evidence primary --days 7 --output ./runtime-evidence.json --json
+# Use target explicitly only when investigating a configured second host.
+```
+
+It performs no restart, log clear, review lease acquisition, or fallback to a
+different host. `collecting`, `incomplete`, `stale`, and `unavailable` describe
+evidence coverage, not a verdict that the system is healthy. A 404 means the
+API route is not deployed; an old primary generation can also lack collector
+samples after workers update. Record that activation gap and arrange an
+authorized release—do not silently close the investigation or force a recycle.
+An observed topology recovery alone does not prove interrupted user work
+survived. Keep the evidence cutoff, gaps and actual outcomes in the relevant
+todo so the next run can continue.
+
 The current API-side files are:
 
 - `/home/ec2-user/server/logs/twinkle-api.err.log`
@@ -2157,6 +2412,27 @@ in scope so a later API-side worker is not silently omitted. Use the delegated,
 run-independent workflow; it holds one server lease across the review and
 writes private, digest-verified local artifacts:
 
+For the deploy-time two-API topology, `runtime-logs start primary` and
+`runtime-logs start target` explicitly select the host. Omitted host means
+primary; pre-migration NULL owners also mean primary. Use a separate private
+output/session directory for each completed review. Review-ID/session operations
+route back to the recorded owner; never treat a peer's files as that review's
+bytes. An unresolved start key cannot be replayed against a different host.
+The additive host-owner migration and compatible API must be live before this
+CLI capability is published.
+
+Review every participating host, including primary private-helper logs. A
+primary review does not cover the target. Finish the exclusive review before
+that host is held; a held/unavailable owner returns an explicit retryable failure,
+not another host's snapshots or an independent log service. Do not abandon its
+lease merely to bypass a deployment guard. After a planned hold, final shutdown
+deltas are reviewed via management SSH outside any active lease, recorded, and
+API stderr is cleared only with the existing guarded `npm run logs:clear-errors`
+plus post-clear re-read. This is the deployment runbook's final boundary, not
+permission to bypass an active Lumine lease. A stopped target whose final logs
+were reviewed does not need to be started for daily management; starting EC2
+requires separate authority. See `twinkle-api/DEPLOY_TIME_HANDOFF.md`.
+
 ```bash
 lumine admin runtime-logs start --output-dir ./runtime-log-review --json
 # Read every file under data.artifacts.latestSnapshot.snapshotPath.
@@ -2227,7 +2503,16 @@ checking, and in-place truncation occur on the same open descriptor. It then
 returns `post_clear_review_required` with another immutable snapshot. That
 snapshot also captures normal-output bytes that arrived after the prior
 acknowledged cutoff, so routine stdout traffic cannot make the review infinite.
-Read it and run the same `finish --reviewed` command again. A review clears
+Read it and run the same `finish --reviewed` command again. **Only
+`data.completionStatus: "completed"` means the review is done.** The top-level
+`status` mirrors it: `"needs_review"` for both non-terminal outcomes
+(`needs_review` and `post_clear_review_required`, including a recovered
+pending snapshot), `"success"` only when `completed`, and `"already_done"` for
+a replay of an already-finished review. `ok` stays `true` in every case; a
+`needs_review` result is a valid response that requires another read plus
+finish, not an error. The CLI derives the top-level status from
+`completionStatus`, so it is correct against an API that still answers the
+older `success` envelope. A review clears
 `twinkle-api.err.log` at most once. The lease closes when the reviewed error
 boundary is still stable, i.e. every byte now in the API error log arrived
 after that clear and was captured and acknowledged; errors that arrive before
@@ -2831,12 +3116,19 @@ farm-signal sections added that day; AI Card summon watch added 2026-08-24):
   is never called a dodge. Offers without redemptions are a reason to inspect
   sample size, event type, and offer age — not proof of a broken funnel by
   themselves.
-- `goneQuiet` — the inverse of `notableCandidates`: users whose `lastActive`
-  fell in the 14 days before the window (so they were around, then stopped),
-  ranked by how regular they were in the prior 30 days (daily tasks and
-  Wordle), capped at 15 with `daysQuiet`. Use it for product signal (what did
-  they stop doing?) and gentle outreach candidates; never guilt a child in
-  public about absence.
+- `goneQuiet` — the inverse of `notableCandidates`, and window-relative: a
+  user "went quiet" the moment 7 days of silence passed since their
+  `lastActive`, and the section lists only the users whose quiet moment fell
+  inside the brief's window (`lastActive` between `sinceTs - 7d` and
+  `now - 7d`). A one-day brief therefore reports one day of crossings and
+  contiguous daily runs list each user once; it never re-lists everyone seen
+  in the past fortnight. `totals.wentQuiet` is that cohort; `previouslyRegular`
+  is the subset with at least 7 distinct active days (completed daily tasks or
+  Wordle plays) in the 30 days ending on their own last active day, and
+  `users` is that subset ranked by `regularityScore` (`dailyTasks * 2 +
+  wordlePlays`, both measured over the same per-user span), capped at 15 with
+  `daysQuiet`. Use it for product signal (what did they stop doing?) and
+  gentle outreach candidates; never guilt a child in public about absence.
 - `newUserFunnel` — signups in the window with `activeOnDayOne` (any
   XP-ledger event within 24h of joining) and `returnedAfterDayOne`
   (`lastActive` beyond their first day), plus the newest few accounts.
@@ -3137,11 +3429,38 @@ cannot choose or override that identity. The authorization lasts ten minutes,
 is bound to that exact comment, permits only reading that target and editing
 it, and never runs daily duties, changes the Bangkok calendar assignment, or
 contributes to a daily-run mutation count. A correction cannot target a human
-comment, notification record, deleted comment, or Build thread. Build comments
-still require a fresh version-bound correction reply after genuinely reviewing
-the published app. Starting a newer correction supersedes an older active one.
+comment, notification record, or deleted comment. A Build comment must belong
+to a public, published canonical owner Build; editing it requires a fresh review
+of the exact published version and private review context. Starting a newer
+correction supersedes an older active one.
 Finish it explicitly after the canonical edit is confirmed.
 
+For a Build, inspect the current app and its full discussion first. Managed
+runtime review does not require a daily run and does not start one:
+
+```bash
+lumine admin builds review build:884 --output-dir ./build-review --json
+lumine admin correction start 456 --json
+lumine admin comment edit 456 --file corrected.md \
+  --review-receipt ./build-review/<returned-review-directory>/review.json \
+  --review-context context.json --json
+lumine admin correction complete <sessionId> --json
+```
+
+Use the exact receipt path returned by `builds review`, or pass manual
+`--reviewed-version <artifactId> --reviewed-via runtime|code` evidence instead.
+The private context file contains only `{"understanding":"What you actually reviewed"}`.
+The API locks the Build and comment, verifies the current version and ownership,
+and commits the text, mention updates, and a new immutable review record together.
+Only the edited comment's context link moves; older bot replies retain their
+historical review context. Changed/deleted comments, changed versions, and
+private/noncanonical Builds fail without a partial edit. A fresh review can be
+stored even if the public text is unchanged. The CLI requires the exact edited
+text plus `edit.buildReviewContextStored: true`, the reviewed version, and a
+canonical review record ID before claiming success. Older APIs that still block
+Build edits must be deployed first; do not silently substitute a duplicate reply
+when Mikey requested an edit.
+
 **Editing the bot's own comments.** `comment edit <commentId> --file
 <comment.md>` replaces the text of a comment the acting bot itself authored —
 for correcting a factual error, an unfulfillable claim, or outdated guidance
@@ -3153,7 +3472,8 @@ composed-comment rules (plain UTF-8, 10,000-character limit, truth about what
 the session actually did) and publishes through the website's canonical
 comment-edit pipeline — mentions are reprocessed (a newly added `@mikey`
 notifies him), and Earn-candidate projections resync. Submitting identical
-text returns `already_done`. It requires either the exact active correction
+text returns `already_done` for non-Build comments; a Build edit can still save
+a fresh review without changing its text. It requires either the exact active correction
 session above or the `comment:post` scope of a comment-mode `post` run, and is
 audited as `comment.edit` with the previous content in `beforeState` and
 `data.edit.previousContent`. Edit sparingly:
@@ -3399,9 +3719,12 @@ sponsor pays from their own battery. Mentions elsewhere in a Build, replies to
 unlinked or legacy bot comments, replies to humans, and the other bot remain
 ineligible. If the published version has changed, the responder is told the
 stored understanding belongs to the reviewed older version and must say it has
-not checked behavior that could have changed. The generic `comment edit`
-shortcut is also disabled there; review the current version and post a
-version-bound correction reply instead.
+not checked behavior that could have changed. Editing the acting bot's own
+Build comment is supported with the same fresh reviewed-version/method and
+private-context flags, including managed review receipts. It updates the
+existing comment, not a duplicate reply. See the narrow correction workflow
+above; a version-bound follow-up remains appropriate when the conversation
+calls for an additional reply instead of an edit.
 
 **Offer a Lumine prompt when the moment invites it (Mikey's direction,
 2026-08-10).** Zero and Ciel may include one concrete, copy-pasteable Lumine