@stage5/lumine 0.2.54 → 0.2.56

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -229,7 +229,7 @@ claude "Read CLAUDE.md, then make the requested change."
229
229
  The login command uses a browser approval code and stores a scoped token and the
230
230
  selected project at `~/.twinkle/lumine-cli-auth.json`.
231
231
 
232
- ## Sponsoring Zero or Ciel Build Workshop duty
232
+ ## Sponsoring shared Zero and Ciel Build Workshop help
233
233
 
234
234
  Sponsorship is an approved contribution role, not an open switch and not a
235
235
  website-management role. Applications are submitted only through Lumine CLI;
@@ -243,20 +243,30 @@ lumine sponsor status
243
243
  ```
244
244
 
245
245
  After Mikey approves an application, configure conservative limits based on
246
- the subscription you are contributing, then start one foreground duty:
246
+ the subscription you are contributing, then start one shared foreground duty:
247
247
 
248
248
  ```bash
249
249
  lumine sponsor capacity --concurrency 1 --helpers 0 \
250
250
  --daily-limit 3 --weekly-limit 10
251
- lumine sponsor duty start zero --provider codex \
251
+ lumine sponsor duty start --provider codex \
252
252
  --model gpt-5.6-sol --effort max --service-tier priority
253
253
  ```
254
254
 
255
- While that foreground process has a fresh server lease, Zero or Ciel exposes a
256
- Build Workshop in chat and users may see the named sponsor and canonical queue.
255
+ Sponsor commands use the same browser-approval login as the rest of Lumine.
256
+ When no saved CLI login exists, the command opens Twinkle, waits for the person
257
+ using that browser to approve their own account, and then resumes. Any Twinkle
258
+ account may authenticate this way, but login never grants sponsor duty:
259
+ `sponsor duty start` still requires that exact account to have a canonical,
260
+ server-approved sponsor profile.
261
+
262
+ While that foreground process has a fresh server lease, both Zero and Ciel can
263
+ delegate user-approved Build work to the shared worker pool. The user chooses
264
+ the assistant for each request, and may see the named sponsor and canonical
265
+ shared queue.
257
266
  With no live duty, the website stays in its ordinary chat state and shows none
258
267
  of the Workshop UI. Press Ctrl-C to stop accepting work and drain already
259
- claimed jobs before duty ends; `pause`, `resume`, and `stop` are also available.
268
+ claimed jobs before duty ends; `pause`, `resume`, and `stop` are also available
269
+ without a Zero/Ciel argument.
260
270
 
261
271
  Zero or Ciel remains the user-facing teammate. The local coding agent receives
262
272
  only the initial relay and active-job Build follow-ups covered by the user’s
@@ -266,8 +276,9 @@ cannot merge into Main, publish, or use website-management APIs. Lumine records
266
276
  the requested and provider-reported model, effort, service tier, runtime/usage
267
277
  evidence, coordinator/helper tree, saved artifact, and branch notice. Every
268
278
  completed handoff enters the daily integrity flow; probationary, hard-flagged,
269
- and sampled work requires review. Each unique cleared handoff earns a flat 50
270
- Karma Points, while retries and helper agents do not multiply the award.
279
+ and sampled work requires review. Each unique cleared contribution to another
280
+ user earns a flat 50 Karma Points, while self-sponsored testing, retries, and
281
+ helper agents do not earn or multiply the award.
271
282
 
272
283
  ## Privileged website administration
273
284
 
@@ -383,10 +394,13 @@ includes `error.details.retryIdempotencyKey` so a partial attempt can be
383
394
  resumed with the exact generated key.
384
395
 
385
396
  Subject and queue listings use opaque, stable snapshot cursors. `--all`
386
- follows them automatically, saves a checkpoint after every canonical page,
387
- and records completed queue coverage in the run audit; `--resume` continues
388
- the exact same request. With `--all --json`, bounded progress goes to stderr so
389
- stdout remains one pipe-safe JSON value. Recommendation scans default to the previous completed
397
+ follows them automatically, fsyncs each confirmed page to a private NDJSON
398
+ candidate spool, saves only bounded cursor/boundary/count metadata in the
399
+ checkpoint, and records completed queue coverage in the run audit; `--resume`
400
+ verifies the confirmed spool prefix and continues the exact same request. The
401
+ final JSON contract still contains the complete collection, streamed from the
402
+ spool instead of accumulated in memory. With `--all --json`, bounded progress
403
+ goes to stderr so stdout remains one pipe-safe JSON value. Recommendation scans default to the previous completed
390
404
  run's start boundary for at-least-once coverage. Use `--after` for an explicit
391
405
  timestamp or `--include-legacy`
392
406
  for an intentional all-history scan. Subject `--after` is inclusive and