@stage5/lumine 0.2.68 → 0.2.69

package/sdk/BUILD_SDK_INDEX.md

@@ -1,8 +1,8 @@
 # Build SDK Index
 
-Version: 1.39.0
-Updated: 2026-09-03
-Generated: 2026-09-03T04:17:20.106Z
+Version: 1.41.0
+Updated: 2026-09-08
+Generated: 2026-09-08T05:12:06.333Z
 
 ## Notes
 - This SDK is injected into Build iframes via the Build preview/runtime.
@@ -30,9 +30,12 @@ Generated: 2026-09-03T04:17:20.106Z
 - Static media published through sharedDb is app-owned feed data. A public user-generated feed must provide a visible report flow and owner removal, and must not claim that Twinkle globally moderates those posts.
 - Use Twinkle.live for one-way app livestreams and Twinkle.chat for the accompanying thread. Free livestreams require a verified host, end after at most 15 minutes, and issue at most 10 private viewer grants. Twinkle keeps platform-owned live-status/end controls above active hosts, so app code cannot hide or replace the broadcaster's Stop path.
 - Media Energy is separate from AI Energy. Replace Media Energy UI only from canonical mediaEnergy/getUsage responses; never decrement, reserve, or synthesize it in app code.
+- Twinkle.rewards awards real XP and Coins only in the current approved published release. Drafts, local previews, private apps and superseded releases cannot earn. The server supplies a published-runtime grant; app code cannot choose a recipient or award amount.
+- Lumine agents prepare private numeric quiz rules and budgets with prepare_reward_rules (CLI: POST /build/:buildId/rewards/prepare with { config }). Creators are kids and teens: show a simple earning summary, approval status and Send for review; do not ask them to fill in technical forms. Every code or rule update that retains rewards needs a new approval before publishing. Removing the SDK automatically clears its gate and publishes without reward permission; adding it back requires a fresh approval. Other protected SDKs keep their own gates. Keep protected SDK calls explicit in project source. Existing approved live rewards continue while a draft waits; approvals never publish automatically.
+- v1 verifies numeric quiz answers on the server; client scores, privateDb state, timers and completion booleans are not reward evidence. Daily limits reset at midnight in Korea. Each rule can be earned once per viewer per day, with three answer attempts per challenge. Challenge expiry is 30 minutes. Budgets apply across release changes.
 
 ## Token Scopes
-files:read, media:read, media:write, live:read, live:write, user:read, users:read, dailyReflections:read, content:read, content:write, sharedDb:read, sharedDb:write, privateDb:read, privateDb:write, files:write, chat:read, chat:write, notifications:read, notifications:write, notifications:emit, reminders:read, reminders:write
+files:read, media:read, media:write, live:read, live:write, user:read, users:read, dailyReflections:read, content:read, content:write, sharedDb:read, sharedDb:write, privateDb:read, privateDb:write, files:write, chat:read, chat:write, notifications:read, notifications:write, notifications:emit, reminders:read, reminders:write, rewards:claim
 
 ## Namespaces
 
@@ -941,6 +944,13 @@ world.updatePresence({ x, y, z, facing });
   - Returns: { success: true, deleted: boolean }
   - Delete one key from the default private per-user JSON store.
   - Deletes one key for the current viewer.
+- async compareAndSet(key, expectedValue, value, { operationId, expectedUserId }) | scopes: privateDb:write
+  - Returns: { item: { id, key, value, updatedAt }, applied, duplicate, conflict }
+  - Atomically save only when the current JSON value matches expectedValue, with a permanent idempotency receipt.
+  - Pass null as expectedValue for an absent/null value. Both values are limited to 16 KB. Optional expectedUserId prevents a held operation from crossing an account change.
+  - operationId is required: 8–64 letters, digits, underscores or hyphens. Reuse it for retries of the same logical change.
+  - On conflict, rebase the intent onto the returned canonical item before comparing again. Do not retry-loop a 429.
+  - A duplicate operation returns the current canonical item without applying again. Ordinary set/remove remain unconditional; use a dedicated key for a compare-and-save workflow.
 
 ### Twinkle.reminders
 - async list({ includeDisabled, limit } = {}) | scopes: reminders:read
@@ -962,6 +972,45 @@ world.updatePresence({ x, y, z, facing });
   - Returns reminders that are due right now for the current signed-in viewer.
   - autoAcknowledge defaults to true and prevents the same reminder from retriggering immediately.
 
+### Twinkle.arena
+- async board({ ruleset, cursor, revision, limit } = {}) | scopes: sharedDb:read
+  - Returns: { ruleset, revision, total, fighters, me, targets, dailyUsed, cursor, hasMore }
+  - Load a ranked page plus your fighter and all challengeable opponents independently of the page.
+  - limit defaults to 50 and is at most 100. Pass returned cursor and revision together for more rows.
+  - A 409 means the ladder changed between pages: restart from the first page. Records are canonical and do not require replaying history.
+- async publish({ ruleset, expectedUserId }) | scopes: sharedDb:write
+  - Returns: { fighter }
+  - Publish or update your own fighter from your confirmed saved career.
+  - The server derives identity, stats, gameplan and appearance from the viewer’s saved career. Supplied fighter snapshots or user IDs are not accepted.
+  - Existing rank and records are preserved; a new fighter joins at the bottom.
+- async challenge({ ruleset, opponentUserId, operationId, expectedUserId }) | scopes: sharedDb:write
+  - Returns: { bout, duplicate }
+  - Issue and adjudicate one ranked match, atomically saving its result, quota usage and ranking.
+  - operationId must contain 8–64 letters, digits, underscores or hyphens. Preserve it across ambiguous failures and reloads.
+  - The server issues the seed and uses its pinned ruleset and saved fighters. Never submit a winner, seed, or fighter snapshot.
+  - The bout contains id, ruleset, seed, a, b, outcome, winner, reason, round, tookSpot, at and by. a/b contain userId, name and snap.
+  - Three challenges per UTC day, against fighters one to three ranks above you. Duplicate requests never consume another challenge.
+  - Subscribed defender owners receive a ruleset-bound result notification from the canonical transaction. HTTP 400/409 eligibility errors with writeStatus=not_applied are definitive rejections; retain the same operationId after an ambiguous network failure.
+- async bouts({ ruleset, cursor, limit } = {}) | scopes: sharedDb:read
+  - Returns: { bouts, cursor, hasMore }
+  - Read immutable ranked bout history, newest first, with cursor pagination.
+  - limit defaults to 50 and is at most 100. There is no three-page history cutoff.
+- async getBout({ ruleset, id, legacyEntryId }) | scopes: sharedDb:read
+  - Returns: { bout }
+  - Read one immutable bout in this build and ruleset.
+  - Supply id, or legacyEntryId for an imported legacy notification. Replay new bouts only with their exact ruleset; the stored outcome is authoritative. Legacy records explicitly identify their unversioned simulation.
+
+### Twinkle.rewards
+- await Twinkle.rewards.getStatus() | scopes: rewards:claim
+  - Returns: { mode: "live", dayKey, rules, history, balances: { xp, coins } } | { mode: "preview", rules: [], history: [], message }
+  - Read canonical earning rules (without answer keys), today’s receipts and balances. Drafts return preview mode. Unapproved or revoked published releases return an error.
+- await Twinkle.rewards.start({ ruleId }) | scopes: rewards:claim
+  - Returns: { mode: "live", challengeId, questions: [{ prompt }], reward: { xp, coins }, attemptsRemaining, expiresAt }
+  - Creates or resumes a server-issued challenge for the signed-in viewer. Render its questions and collect numeric answers in the same order. One daily challenge per rule/review; repeat starts cannot reset attempts.
+- await Twinkle.rewards.claim({ challengeId, answers: [number] }) | scopes: rewards:claim
+  - Returns: { awarded: false, attemptsRemaining } | { awarded: true, duplicate, receipt, balances: { xp, coins } }
+  - Twinkle verifies every answer, approval, current published artifact and budget before atomically recording XP and Coins. Retry the same challengeId after a lost response; a confirmed claim returns its original receipt without another award. Never update balance UI optimistically.
+
 ## Examples
 
 ### Daily reflection feed
@@ -1294,3 +1343,16 @@ await Twinkle.reminders.create({
   targetPath: '/focus'
 });
 ```
+
+### Claim an approved learning reward
+Keywords: xp, coins, rewards, quiz, approval
+
+```js
+const status = await Twinkle.rewards.getStatus();
+if (status.mode === 'live') {
+  const challenge = await Twinkle.rewards.start({ ruleId: 'daily-question' });
+  // Render challenge.questions and collect numbers in the same order.
+  // const result = await Twinkle.rewards.claim({ challengeId: challenge.challengeId, answers });
+  // Display only result.balances and result.receipt after awarded === true.
+}
+```

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
@@ -1038,6 +1059,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
@@ -1215,8 +1283,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 +1294,12 @@ 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.
 
+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 +1307,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 +1324,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
@@ -1551,6 +1640,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.
@@ -2108,10 +2207,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,
@@ -2137,6 +2249,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 +2278,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 +2308,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.
@@ -3137,11 +3309,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 +3352,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 +3599,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