@stage5/lumine 0.2.53 → 0.2.55

package/package.json

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

package/sdk/LUMINE_ADMIN.md

@@ -636,6 +636,40 @@ type DailyRunComplete = Success<{
 type DailyRunFail = DailyRunComplete;
 ```
 
+### 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 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 that unique handoff for its flat 50 KP award;
+`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. `daily-run complete` is rejected until the scan has covered its full
+snapshot and no pending, held, or flagged case remains.
+
 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
@@ -847,12 +881,15 @@ feed-ID high-water mark and the server timestamp, then traverse the indexed
 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 and writes a private checkpoint after every
-server-confirmed page; `--resume` continues only when the checkpoint belongs to
-the same API, run, and exact request. The final result can be copied to
-`--output`, while `--checkpoint` is resumable operational state. Subject
-`--after` is inclusive, and every opaque cursor is bound to its original
-filters.
+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.
 
 For `--all --json`, stdout remains exactly one JSON value. Scan-start, first-
 page, every-tenth-page, and exhaustion progress is written to **stderr** with