avi/Lumen
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Checkpoint: current Lumen state
Some checks failed
ci / check (push) Has been cancelled
Details

Browse source
This commit is contained in:
Lumen Stage1 2026-09-23 18:58:21 -05:00
commit fcc18ddcc8
96 changed files with 8074 additions and 214 deletions
Download patch file Download diff file Expand all files Collapse all files

4
ARCHITECTURE-DECISIONS.md
View file

@ -163,6 +163,7 @@ listed validation spike).
eviction detection via boot verification (no eviction event exists on the
platform).
- **Validation addendum (SPIKE-01 P1–P8, SPIKE-02 F-1…F-3 — normative):** P1 one short txn per staged file (bytes+progress together); P2 activation single txn on `lumen-system`; P3 wrapped IDB + QuotaExceededError keeps active; P4 free-space pre-check 2× package via `storage.estimate()`; P5 single record ≤6 MB; P6 `persist()` requested but never relied upon; P7 boot light verification as eviction detection; P8 no dataset state in SW. SPIKE-02 adds: F-1 bytes+progress atomic, F-2 verification record in activation txn, F-3 `readbackPending` flag, F-4 rollback depth 1 accepted.
- **Persistence correction (2026-08-31):** P1 requires the staging journal to be in each target slot database, alongside `files` and `assets`. `lumen-system` contains active/readback metadata only; it is not a source of per-file staging progress. This preserves one-database atomicity for file/asset + progress without a cross-database transaction.
- **Risks:** iOS IDB edge bugs (mitigation: wrapper isolation, spikes, re-prep
recovery); silent eviction (mitigation: RECOVERY state); residual device risk is YELLOW until D1–D4 matrix passes (ARCHITECTURE-VALIDATION.md §4).
- **Reversibility:** Storage layout is internal to the data layer; migrating to
@ -224,13 +225,14 @@ listed validation spike).
- **Status:** Accepted (YELLOW — device-conditional) — state machine proven 16/16 by SPIKE-02; production readiness conditional on IDB atomicity under real kills on iOS (SPIKE-01 §5, SPIKE-02 §6) — see ARCHITECTURE-VALIDATION.md §2, §4, §7
- **Validation addendum (SPIKE-02 F-1…F-4 — normative):** F-1 bytes+progress in same per-file txn; F-2 verification record (what/when/version) in activation txn; F-3 `readbackPending` flag set in activation and cleared after readback; F-4 rollback depth = 1 (new staging wipes inactive slot — accepted trade-off, 3-slot rejected for footprint). Ordering proof: single-DB atomicity suffices because inactive slot is fully written+validated before pointer moves; quarantine + monotonic versions prevent replay of bad packages.
- **Persistence correction (2026-08-31):** The F-1 progress record is the authoritative `staging` journal inside the target slot database. It is committed in the same short transaction as its corresponding file or asset. The system database retains only the active pointer, verification/readback metadata, and boot metadata; no cross-database transaction is used for staging.
- **Context:** Invariants 5–8; DISCOVERY AD-6; iOS SW-kill reality (PW-6).
- **Problem:** Apply dataset updates such that the observable state is always
"old valid dataset" or "new valid dataset", surviving interruption at any
stage; provide rollback.
- **Decision:** **A/B dual-slot model.** Two dataset slots (IDB databases).
Updates stage exclusively into the *inactive* slot with per-file download,
SHA-256 verification, and persisted progress (resumable). After full
SHA-256 verification, and slot-local persisted progress (resumable). After full
verification, activation is a **single transaction** on the `lumen-system`
DB flipping the active pointer + recording version/verification metadata.
Post-activation readback spot-check; failure triggers automatic rollback to