Products › LamBoot › Docs › Roadmap

Roadmap

The three-tier roadmap in full.

This is the single forward-looking authority for LamBoot. Older roadmap docs retain historical value (Phase A/B/C completion records and prior decision threads) and are cross-referenced in section 6, but new sprint planning, milestone decisions, and "what's next" discussions consult this document first.

Status Authoritative as of 2026-05-26 morning
Supersedes Forward-looking sections of docs/archive/plans/ROADMAP-2026-04-05.md and docs/archive/plans/ROADMAP-V1.0-AND-BEYOND.md (2026-04-25), per cross-reference matrix in section 6
Incorporates Eight overnight research deliverables (2026-05-25), synthesized at docs/analysis/OVERNIGHT-RESEARCH-SYNTHESIS-2026-05-25.md
User ratification 2026-05-26 morning. Tier decisions per section 0
Re-evaluation cadence At each release boundary (v0.10 to v1.0 to v1.1 to v2.0)

0. TL;DR: three tiers, ratified

Tier Theme Items Window
Tier 1: IMMEDIATE Installer infrastructure and plugin coding (1.1) lamboot-installer-protocol v1, then (1.2) AUR lamboot package, then (1.3) archinstall plugin, then (1.4) Calamares upstream PR, then (1.5) openSUSE script-contract (parallel) About 3 to 4 calendar months once started
Tier 2: v1.0 RHEL-family unblock and Proxmox depth and health observability (2.1) xfs-view native backend, then (2.2) Proxmox 5-phase reframed sequence, then (2.3) health monitoring and metrics and real NVMe SMART About 6 to 8 months parallel with Tier 1
Tier 3: v1.1+ Trust baseline expansion and Phase-D modules (3.1) Path D Microsoft shim-review, then (3.2) WASMi as separate lamboot-wasm.efi module, then (3.3) TPM2_Quote attestation, then (3.4) ZFS community-contribution gate (rzfs adoption), then (3.5) native f2fs and bcachefs Post-v1.0, staged
Declined or struck n/a Multiboot 1+2 (declined), Phase-D network agent HTTP listener (struck) n/a

Sequencing principle

Tier 1 (installer integration) parallelizes with Tier 2 (XFS and Proxmox and health): different code surfaces, different contributor types, no shared chokepoints. Tier 3 is post-v1.0. The "immediate" priority on installer infrastructure reflects the user's strategic call that adoption gates capability: without distributors installing LamBoot at OS-install time, LamBoot stays a retrofit niche regardless of how good the bootloader gets.

1. Tier 1, IMMEDIATE: installer infrastructure and plugin coding

Strategic rationale: the overnight installer-integration analysis identified an unstated hard prerequisite (lamboot-install v0.10 protocol additions) that must ship before any installer plugin work is workable. With that protocol shipped, the rest unlocks fast: archinstall has a zero-upstream-patch plugin hook, Calamares is one upstream PR away from unlocking about 10 distros, and openSUSE has a documented script-contract path that parallelizes with both.

Underlying authorities:

  • docs/analysis/INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md (742 lines, 10 findings)
  • docs/analysis/OVERNIGHT-RESEARCH-SYNTHESIS-2026-05-25.md sections 1.2, 3.4

1.1 lamboot-installer-protocol v1: the hard prerequisite

Goal: ship lamboot-install v0.10.0 with a stable, versioned, machine-parseable protocol surface that downstream installers (archinstall, Calamares, openSUSE script-contract) can integrate against without ad-hoc invocation conventions.

Scope (per INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 7, lamboot-installer-protocol v1):

  • --json: machine-parseable output mode (replaces stdout-text scraping)
  • --root PATH: chroot wrapper for installer-time invocation (installer runs in a chroot of the target system; lamboot-install must respect that root)
  • --capabilities: JSON capability discovery (what filesystems supported, what signing modes available, what trust tokens emitted)
  • --no-prompt: non-interactive flag for unattended installs (current --yes is ambiguous about polkit dialogs)
  • --protocol-version: version handshake; installers can adapt to future protocol versions

Acceptance criteria:

  • lamboot-install --protocol-version returns 1
  • lamboot-install --capabilities --json returns valid JSON conforming to the schema at docs/analysis/INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 7
  • --root PATH works against a chroot, with fixture test coverage
  • --no-prompt exits with documented codes when interactive input would have been required
  • All existing flags and behavior unchanged (additive only)

Estimated effort: 2 weeks. Single Lamco engineer (the same one who owns lamboot-install today).

Release gate: lamboot-tools v0.4.0 paired with lamboot-dev v0.10.0 coordinated bump.

1.2 AUR lamboot package

Goal: publish lamboot to the Arch User Repository so archinstall plugin users can pacman -S lamboot (or AUR-helper equivalent) after install.

Scope:

  • PKGBUILD that downloads lamboot-dev release tarball and lamboot-tools release tarball, builds nothing (we ship binary), installs to /usr/lib/lamboot/, /usr/lib/lamboot-tools/, /usr/local/sbin/lamboot-* (or /usr/bin/ per Arch convention)
  • AUR account glamberson (or lamco-office) takes maintainership
  • Track lamboot-dev tags via PKGBUILD pkgver automation

Dependencies: lamboot-dev v0.10.0 released and lamboot-tools v0.4.0 released

Estimated effort: 1 week (PKGBUILD authoring, AUR submission, install testing on a clean Arch VM).

1.3 archinstall plugin

Goal: archinstall plugin file that registers LamBoot as a bootloader option through the on_add_bootloader plugin hook, with zero upstream patches required to archinstall.

Scope (per INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 3.1):

  • Python plugin file shipped via the AUR lamboot package at /usr/share/archinstall-plugins/lamboot.py (or wherever AUR convention places it)
  • Implements the on_add_bootloader(installer) hook
  • Calls lamboot-install --root $TARGET --signed --no-prompt --json and parses the result into archinstall's installer state
  • Handles failure modes (chroot ESP detection, SB key acquisition)

Dependencies: 1.1, 1.2

Estimated effort: 2 weeks (plugin code plus integration test against archinstall's test harness plus at least one end-to-end Arch install from a live ISO with the plugin enabled).

1.4 Calamares upstream PR

Goal: add LamBoot as a first-class bootloader option in upstream Calamares. One PR unlocks about 10 distros (Manjaro, EndeavourOS, CachyOS, KDE neon, Garuda, KaOS, Nitrux, Sparky, Siduction, and more).

Scope (per INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 3.2):

  • Upstream PR to calamares/calamares adding install_lamboot() in src/modules/bootloader/main.py (about 80 LOC estimated)
  • Schema extension in src/modules/bootloader/bootloader.schema.yaml to recognize bootloader: "lamboot" in distro bootloader.conf
  • Calls lamboot-install --root @@ROOT_MOUNT_POINT@@ --signed --no-prompt --json
  • Documentation patch
  • 1 reviewer per distro outreach: each adopting distro adds one line in their bootloader.conf

Dependencies: 1.1, 1.2 (so distros that adopt have a package channel to pull from). For non-Arch-family distros (Manjaro and others), each may need its own packaging; coordinate with distro liaisons.

Estimated effort: 4 to 6 weeks of work over about 3 calendar months (upstream PR review cycles).

1.5 openSUSE script-contract integration (parallel)

Goal: ship /usr/lib/bootloader/lamboot/ script-contract files so that update-bootloader on openSUSE/SLES treats LamBoot as a recognized bootloader at the update-bootloader layer. This integrates at the update-bootloader layer rather than YaST, whose closed Ruby subclass dispatch requires upstream patches.

Scope (per INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 3.5 plus prior memory finding from April):

  • Script contract files matching the existing /usr/lib/bootloader/grub2/, /usr/lib/bootloader/systemd-boot/, /usr/lib/bootloader/grub2-bls/ patterns
  • lamboot-install --root @@SYSROOT@@ --signed invocation in the install-kernel and remove-kernel hooks
  • Ships via OBS (openSUSE Build Service) as the package channel
  • Post-install integration (operator runs update-bootloader --loader lamboot to set LOADER_TYPE) at post-install time, since YaST is too closed for installer-time integration

Dependencies: 1.1 (the --root flag)

Estimated effort: 2 to 3 weeks parallel with 1.3 and 1.4.

Tier 1 sequencing

Week 1-2:  1.1 lamboot-installer-protocol v1 (lamboot-tools v0.4.0 / lamboot-dev v0.10.0 ship)
Week 3:    1.2 AUR lamboot package published
Week 4-5:  1.3 archinstall plugin + end-to-end Arch install test
Week 4-5:  1.5 openSUSE script-contract + OBS publish (parallel with 1.3)
Week 6+:   1.4 Calamares upstream PR (calendar runs ~3mo through review)

Total wall time: about 3 to 4 calendar months from start of 1.1 to Calamares PR merged.

Tier 1 ongoing work after initial ship

  • Distro-liaison pattern: one human contact per distro for ongoing compatibility (per INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 4)
  • Adoption telemetry: track which distros add LamBoot to their bootloader options
  • Re-evaluation cadence: after 6 months of field deployment via archinstall plus first 1 to 2 Calamares-using distros, evaluate whether to invest in Anaconda, d-i, or Subiquity (all marked DEFER for the reasons in section 3.3 of the installer doc)

2. Tier 2, v1.0: RHEL-family and Proxmox depth and health

Strategic rationale: v1.0 ships when LamBoot covers the enterprise distro families (RHEL via XFS) and Lamco's primary deployment platform (Proxmox) at production-grade depth, plus the observability story (health and metrics) is complete. The overnight research provides concrete architectures for all three.

2.1 xfs-view native backend: SPEC-XFS-VIEW.md execution

Goal: ship native Rust no_std XFS read backend mirroring the lambutter (btrfs) and ext4-view patterns, unblocking RHEL/CentOS Stream/Rocky/Alma/Oracle Linux as LamBoot-supported distros.

Authority: docs/specs/SPEC-XFS-VIEW.md (811 lines, full SDS) plus docs/analysis/XFS-VIEW-CRATE-LAYOUT-2026-05-25.md (240-line companion repo layout) plus docs/analysis/XFS-RUST-ECOSYSTEM-SURVEY-2026-05-25.md (706-line survey).

Strategy: fork-and-port from xfs-fuse v0.6.0 (BSD-2-Clause, Khaled Emara and Alan Somers). Separate xfs-view-dev repository mirroring lambutter-dev. Dual MIT OR Apache-2.0 plus BSD-2 NOTICE attribution. Secure Boot signing path stays open.

Day-one feature coverage (required for RHEL 8/9 reads, distro defaults):

  • XFS v4 (legacy) plus v5 plus CRC
  • NREXT64 large-extent-counts (RHEL 9 default, non-negotiable)
  • Sparse-inodes (RHEL 8+ default, non-negotiable)
  • ftype
  • Reflinks (read-pass-through only)

Scope boundaries (these return typed errors, since LamBoot reads at boot time):

  • Realtime device and external log are out of scope
  • Dirty log replay is out of scope
  • xattrs are out of scope (LamBoot does not need them at boot)
  • fscrypt is out of scope

Founder sign-off needed (per SPEC-XFS-VIEW.md section 12 resolved decisions):

  • [x] Crate name xfs-view (mirrors ext4-view naming): ratified
  • [x] Fork-and-port path (vs clean-room): ratified
  • [x] Separate xfs-view-dev repo (vs in-tree): ratified
  • [x] Day-one feature set (NREXT64 plus sparse-inodes both on): ratified

Milestone roadmap (per SPEC-XFS-VIEW.md section 11):

  • M1 scaffold (1 day): create xfs-view-dev repo with layout
  • M2 vendor xfs-fuse subset (2 days)
  • M3 superblock plus AG headers with zerocopy 0.8 (1 week)
  • M4 inode plus inobt walker (1 week)
  • M5 BMBT walker incl. NREXT64 (1 week)
  • M6 directory parsing, all 4 formats (1 week)
  • M7 symlink resolution (2 days)
  • M8 path resolver (3 days)
  • M9 examples plus LamBoot integration (1 week)
  • M10 cargo-fuzz harnesses x5 (1 week)
  • M11 host-fixture oracle tests with kernel-mount cross-checking (1 week)
  • M12 live-VM validation on Rocky 9 / RHEL 9 (3 days)
  • M13 docs plus announce (2 days)

Total: about 8 to 10 calendar weeks.

Strategic significance: unblocks the RHEL-family enterprise distros that monetize Lamco Layers 3 and 4 (per the cross-cutting analysis in OVERNIGHT-RESEARCH-SYNTHESIS-2026-05-25.md section 2.4).

2.2 Proxmox 5-phase reframed sequence

Authority: docs/analysis/PROXMOX-5-PHASE-DEEP-DIVE-2026-05-25.md (921 lines, 11 findings).

Key reframe: the 5 phases split along a power-vs-politics axis. Three phases (3-A, 4-A) are upstream-patch dependent and politically blocked by Proxmox's stated stance ("no console plugins; storage plugins are the only official extension type"). The remaining four (1.5, 2, 4-C, 5) are purely-engineering and ship without any Proxmox-staff engagement.

Recommended sequence:

Phase 1.5: hardening (1.5 weeks)

10 punch-list gaps from the v0.8.4 Phase 1 ship: 2 HIGH (opt/lamboot/config schema unpublished; multi-VM concurrency untested), 5 MEDIUM, 3 LOW. Full list in PROXMOX-5-PHASE-DEEP-DIVE-2026-05-25.md section 3.

Phase 2: fleet completion (5.5 weeks)

Two-layer Python architecture:

  • Per-PVE-node lamboot-fleet-shipper (about 200 LOC): reads each guest's boot-trust.log from the host's view of the guest efidisk0 (via VM stop plus ESP mount), POSTs to central aggregator
  • Central lamboot-fleet-agg (about 600 LOC, Python plus SQLite, 5 HTTPS endpoints): receives telemetry, stores, exposes query API for Phase 4 dashboard

Folds in the trust-log-shipping gap (1.5wk add-on at Milestone M5): closes the SECURITY-MODEL section 7 gap where the trust log lives on the guest ESP and never reaches the host. Compliance value of the trust log is currently limited because host-side audit is not possible.

Phase 5: auto-rollback (1.5 weeks)

Highest ROI in entire roadmap (value 5 / 1.5wk = 3.3, per analysis section 6). Buildable today on existing bls::decrement_boot_counter plumbing. Guest-side primary mechanism plus host-side safety net via guest agent.

Phase 4-C: Grafana provisioning (2 to 3 weeks)

Web UI dashboard as Grafana provisioning atop Phase 2 aggregator data. This is Grafana provisioning rather than a pve-manager patch (politically blocked). Operators run their own Grafana instance (typical Lamco-fleet-customer pattern) and point at the Phase 2 aggregator's HTTPS endpoints.

Phase 3-C: storage-plugin spike (1 week in 2027)

The one phase-3 option with non-zero political viability. Proxmox storage plugins are the one officially-supported extension type. Spike whether LamBoot can be packaged as a storage plugin (conceptually unusual, since LamBoot is not a storage backend, but the plugin mechanism is the one entry point for distribution). Defer to 2027; pursue only when paired with mature IronRDP collaboration with Dietmar Maurer.

Indefinitely deferred (per political wall):

  • Phase 3-A (native --lamboot knob upstream patches to QemuServer.pm)
  • Phase 4-A (pve-manager UI patches)

Net plan: 5.5 to 6 months bounded engineering across Q3-Q4 2026 ships Phases 1.5/2/4-C/5 with zero upstream Proxmox engagement required.

2.3 Health monitoring completion plus metrics plus real NVMe SMART

Authority: docs/analysis/PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md (567 lines, 12 findings).

Key reframe: the existing roadmap marked WASMi "High priority / Research complete" but the overnight analysis identified that the actually-requested WASM modules depend on infrastructure (NVMe SMART, structured health emit, metrics) that is not yet in place. Shipping WASMi first would force ABI churn within six months. Priority inversion: infrastructure ships v1.1 (formerly v1.0 per old section 4 ordering); WASMi ships v1.2 as a separate lamboot-wasm.efi module, moved to Tier 3.

v1.0 scope (this section):

2.3.1 Health monitoring completion

  • Rolling health.json file at /EFI/LamBoot/reports/health.json capturing the last N boot outcomes
  • Last Known Good (LKG) tracking: record the last entry that booted cleanly with mark-success
  • HMAC-chained trust log: closes SECURITY-MODEL section 7 (tamper detection on the trust log itself; today the log is plain JSON)

2.3.2 Expanded metrics

  • 12-metric set as JSON in boot.json: boot total time, ESP-walk time, BLS-scan time, per-driver load time, kernel size, initrd extraction time, native PE load time vs LoadImage time, TPM extension count, FAT vs lambutter vs ext4-view backend selection counts, trust-log entry count, crash counter value, mark-success-service runtime
  • The bootloader emits JSON metrics rather than Prometheus or OpenTelemetry (wrong shape; too heavy)
  • Format is JSON-in-boot.json; userspace push uploader (Phase 2 lamboot-fleet-shipper) handles transport

2.3.3 Real NVMe SMART

  • UEFI NVM Express Pass-Thru protocol (UEFI 2.5+)
  • Get Log Page admin command, log identifier 0x02 (SMART / Health Information)
  • Parse and emit into trust log or separate health report
  • Replaces the existing nvme-diag.efi stub (the diagnostic module is a stub today and this work implements it)

2.3.4 One-shot userspace push uploader

  • Replaces the proposed (struck) Phase D HTTP listener
  • Lives in lamboot-tools-dev, outside the bootloader
  • Reads health.json plus boot.json from the ESP at OS boot, POSTs to Phase 2 aggregator
  • Authenticates via PVE pveum / RBAC integration (per Proxmox section 7 security cross-cut)

Estimated effort: 4 to 6 weeks total for 2.3.1 plus 2.3.2 plus 2.3.3 plus 2.3.4 combined.

Tier 2 sequencing

Months 1-2.5: 2.1 xfs-view native backend (8-10 weeks)
Months 1-2:   2.3 health monitoring + metrics + NVMe SMART (parallel, 4-6 weeks)
Months 2-7.5: 2.2 Proxmox 5-phase reframed (Phases 1.5, 2, 5, 4-C, 5.5-6 months)
Month 7-8:    integration testing + v1.0 release prep

Tier 2 runs parallel with Tier 1 (different code surfaces, no chokepoints). v1.0 ships when all four streams converge, approximately 6 to 8 months after Tier 1 start.

3. Tier 3, v1.1+ and later

3.1 Path D: Microsoft shim-review submission

Goal: submit a LamBoot-specific shim binary to rhboot/shim-review for Microsoft UEFI CA signing. Once accepted, broadens trust baseline to Microsoft-signed level and removes the MOK enrollment requirement for most users.

Reference: ROADMAP-V1.0-AND-BEYOND.md section 2.1 (retained, content unchanged by overnight work). Prerequisites (reproducible build pipeline, SBAT discipline, public audit trail, documented security threat model, multiple committed maintainer contacts, key-rotation process) all stand.

Strategic positioning: first Rust bootloader accepted through shim-review. Industry first.

Window: post-v1.0; pursue when v1.0 has had about 3 to 6 months of field deployment to satisfy the "stability" criteria reviewers will look for.

3.2 WASMi as separate lamboot-wasm.efi module: module only, kept out of core

Per PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md section 2, WASMi ships as a separate module that stays out of core LamBoot:

  • Separate module, kept out of the core LamBoot link
  • Three-tier signing: release-signed / MOK-trusted / dist-trusted / none
  • Read-only host-call ABI v1: WASM modules read only, with no host writes, no file creation, no NVRAM writes, and no protocol installation
  • Fuel plus wall-clock plus memory plus report-size caps
  • Module loading at LamBoot menu time via existing lamboot-modules/ discovery path

Dependencies: 2.3 infrastructure (health, metrics, SMART) must ship first; otherwise the ABI for WASM modules would need rework when infrastructure lands.

Window: v1.2.

3.3 TPM2_Quote attestation

Goal: collect TPM quote (signed by AIK), package with evidence (boot-trust.log), send to remote verifier (IETF RATS pattern).

Reference: PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md section 4.

Long pole: AIK provisioning plus verifier infrastructure on the customer side. The bootloader code is bounded (about 500 LoC for the TPM2_Quote call plus report packaging) but the surrounding ecosystem (verifier, attestation server, certificate enrollment) is the heavy lift.

Window: v1.3 or v2.0. Pursue only on concrete customer demand (compliance-driven deployments).

3.4 ZFS: community-contribution gate (rzfs adoption path)

Authority: docs/analysis/ZFS-DEFERRAL-RATIONALE-2026-05-25.md (477 lines, formal decision record) plus docs/analysis/ZFS-RUST-ECOSYSTEM-SURVEY-2026-05-25.md (484 lines, ecosystem map).

Status: ratified deferral. zfs-view native backend remains a v1.1+ community-contribution gate. LamBoot does not invest core engineering in writing it.

Path open if pursued: fork rzfs (cybojanek, GPL-2.0 OR MIT, format-only, about 31.6kloc) plus write 8 to 15 kloc of orchestration layer on top, with LZ4 plus Zstd decompressors (lz4_flex no_std plus ruzstd alloc-no_std).

License path: 2006 Sun ZFS on-disk-format spec is Berkeley-licensed (BSD-2-equivalent). Clean-room MIT/Apache is legally fine. No CDDL imports permitted under any path.

Five revisit triggers (per ZFS-DEFERRAL-RATIONALE-2026-05-25.md section 6):

  • A. rzfs upstream grows an orchestration-layer API (open_by_path, read_file) AND ships LZ4 plus Zstd decompression
  • B. A commercial customer with hard ZFS-on-root requirement commits to LamBoot (funded scope)
  • C. Bpool / Ubuntu ZFS-root market share grows materially
  • D. A community contributor delivers a credible PR (review on merits, MIT/Apache only)
  • E. After v1.0 ships, an LLM-assisted clean-room project becomes feasible in Lamco scope budget

Roadmap section 3.2 amendment required: apply the copy-pasteable patch from ZFS-DEFERRAL-RATIONALE-2026-05-25.md section 5 to docs/archive/plans/ROADMAP-V1.0-AND-BEYOND.md (remove the incorrect Proxmox-needs-it claim).

3.5 Native f2fs / bcachefs

Per docs/archive/plans/ROADMAP-V1.0-AND-BEYOND.md section 3.1 / 3.3, unchanged. f2fs has documented ecosystem value (CachyOS f2fs /boot increasingly common; GRUB has known extra_attr breakage). bcachefs is a moving target (kernel removal-revert saga). Both stay as v1.1+ community-contribution candidates.

4. Declined or struck: closure entries

4.1 Multiboot 1 plus Multiboot 2: declined

Authority: docs/analysis/MULTIBOOT-EVALUATION-2026-05-25.md (480 lines, 9 findings).

Recommendation: Option A, do not adopt. Xen users are covered by existing xen.efi PE chainload (which LamBoot supports today, unchanged). A trust-model mismatch (ShimLock::Verify is PE-only) would put a permanent "degraded trust" asterisk on every MB2/ELF kernel, undermining LamBoot's central security claim. systemd-boot's deliberate non-support is the closest-peer precedent.

Revisit only if: a concrete commercial Xen customer commits to LamBoot AND xen.efi is insufficient for them. None as of 2026-05-25.

Side-finding (defused without code change): website-content.md says "No multi-boot exotica": that copy meant multi-OS / dual-boot, and refers to the Multiboot protocol rather than dual-boot. With Option A ratified, the line stands as-is. Flagged for future contributor awareness.

4.2 Phase D network agent HTTP listener: struck from roadmap

Authority: PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md section 6.

Rationale: bootloader-as-listener is the wrong shape (boot-time process; firewall complexity; security surface). Replaced by the one-shot userspace push uploader (Tier 2 section 2.3.4) living in lamboot-tools-dev that reads ESP-resident health.json and POSTs to the Phase 2 aggregator.

5. Coordinated repo / release cadence

Tier 1 release coordination:

  • lamboot-dev v0.10.0 paired with lamboot-tools v0.4.0 (1.1 protocol additions)
  • AUR lamboot package tracks lamboot-dev tags via PKGBUILD pkgver automation
  • archinstall plugin v1.0 paired with lamboot-tools v0.4.0 protocol guarantee
  • Calamares upstream PR plus openSUSE script-contract independent of LamBoot release cadence after 1.1 is in place

Tier 2 release coordination:

  • xfs-view crate v0.1.x paired with lamboot-dev v0.10.x via Cargo exact-pin (same pattern as lambutter v0.3.x paired with lamboot-dev fs_backend_btrfs)
  • lamboot-fleet-shipper / lamboot-fleet-agg ship in lamboot-tools cadence
  • Health/metrics/SMART ship in lamboot-dev cadence

v1.0 tag gate: Tier 1 plus Tier 2 both complete; field deployment via at least archinstall plus one Calamares-using distro; xfs-view validated on Rocky 9 plus RHEL 9 fixture VMs; Phase 1.5/2/5 of Proxmox shipping; health.json plus boot.json metrics flowing end-to-end through Phase 2 aggregator.

6. Cross-reference matrix: what each prior doc still owns

Document Status after this consolidation What it still owns
docs/archive/plans/ROADMAP-2026-04-05.md Superseded for forward planning Historical Phase A/B/C completion records; Session 1-4 testing narrative
docs/archive/plans/ROADMAP-V1.0-AND-BEYOND.md (2026-04-25) Superseded for forward planning; section 3.2 amendment patch pending Section 1 v0.9.x bugfix cadence triage process; section 2.1 Path D shim-review prerequisites detail; section 7 cross-repo coordination authority; section 8 ecosystem positioning reference
docs/archive/plans/INTEGRATED-PLAN-V0.8.3-TO-V1.0.md Historical v0.8.x to v0.9.0 development arc reference
docs/archive/plans/INNOVATION-ROADMAP-2026-03-29.md Historical Original WASMi research speculation (superseded by PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md)
docs/specs/SPEC-XFS-VIEW.md (NEW, 2026-05-25) Authoritative Full SDS for the v1.0 XFS native backend
docs/analysis/OVERNIGHT-RESEARCH-SYNTHESIS-2026-05-25.md Authoritative Cross-cutting synthesis of all 8 overnight deliverables; per-deliverable headline summaries
8 overnight deliverables in docs/analysis/*2026-05-25.md Authoritative Underlying research data for each Tier item

7. Decision authority

This roadmap is the forward map. Specific items are binding only when:

  1. Listed in a per-cycle release plan (current: forthcoming V0.10.0-RELEASE-PLAN.md)
  2. Pulled into an active session by user direction
  3. Captured in a per-sprint kickoff doc

Items here without those bindings are intentions and triage reference, not commitments.

Re-evaluation cadence: review and refresh this document at each release boundary (v0.10 to v1.0 to v1.1 to v2.0). Update memory and lamco-admin tracking ledger after each refresh.

8. Decision log

  • 2026-05-25 ~06:05: Overnight research session initiated (/research-begin). Three workstreams, 8 parallel agents, 2h10m wall time, 5,977 lines of analysis on disk, 71 DB findings persisted.
  • 2026-05-25 ~08:15: All 8 agents fruitful. Synthesis written. Four "roadmap is wrong" findings plus one "roadmap is right" finding (Multiboot omission) surfaced.
  • 2026-05-26 morning (user, this commit): Tier decisions ratified:
    • Tier 1 (immediate): installer infrastructure plus archinstall plus Calamares
    • Tier 2 (v1.0): xfs-view plus Proxmox 5-phase reframed plus health monitoring
    • Tier 3 (v1.1+): WASMi-as-module, TPM attestation, ZFS community gate, Path D shim-review, native f2fs/bcachefs
    • Declined: Multiboot (formal)
    • Struck: Phase D HTTP listener
  • 2026-05-26 morning (executed alongside this consolidation):
    • ZFS amendment patch applied to legacy docs/archive/plans/ROADMAP-V1.0-AND-BEYOND.md section 3.2 (Proxmox-needs-it claim removed; deferral rationale plus rzfs adoption pointer plus Sun-BSD spec reference plus no-CDDL-imports rule all inline).
    • Debian BTS bug number #1137582 retrieved from public BTS submitter query and threaded into all five reference locations (per-package lamco-admin/upstream-contributions/systemd/log.md, top-level lamco-admin/upstream-contributions/log.md, BLS-SORT-KEY-COHORT-SPLIT-2026-05-25.md section 5.1, lamboot-install/TROUBLESHOOTING.md section 3.0 Bug 22, and docs/analysis/bug-reports/DEBIAN-kernel-install-sort-key-inconsistency-2026-05-25.md header).

9. Quick-look reference: what to read for each Tier item

Tier item Read first Then if needed
1.1 protocol v1 INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 7 Existing lamboot-install source
1.2 AUR package INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 2 Arch PKGBUILD convention docs
1.3 archinstall plugin INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 3.1 archinstall on_add_bootloader hook source
1.4 Calamares PR INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 3.2 Calamares src/modules/bootloader/main.py
1.5 openSUSE script-contract INSTALLER-INTEGRATION-ROADMAP-2026-05-25.md section 3.5 plus prior April 27 memory finding openSUSE /usr/lib/bootloader/grub2/ reference
2.1 xfs-view docs/specs/SPEC-XFS-VIEW.md (full SDS) XFS-RUST-ECOSYSTEM-SURVEY-2026-05-25.md for context
2.2 Proxmox PROXMOX-5-PHASE-DEEP-DIVE-2026-05-25.md (921 lines) Existing PROXMOX-INTEGRATION-ROADMAP.md in lamboot-tools-dev
2.3 health/metrics/SMART PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md sections 2, 3, 5, 3.4 (push uploader) Existing lamboot-core/src/health.rs, tpm.rs, telemetry.rs
3.1 Path D shim-review docs/archive/plans/ROADMAP-V1.0-AND-BEYOND.md section 2.1 plus docs/archive/plans/PATH-C-PLAN-MICROSOFT-SHIM-REVIEW-2026-04-25.md rhboot/shim-review submission requirements
3.2 WASMi module PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md section 1 wasmi-labs/wasmi current docs
3.3 TPM attestation PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md section 4 TCG TPM 2.0 spec plus RFC 9334 (RATS)
3.4 ZFS gate ZFS-DEFERRAL-RATIONALE-2026-05-25.md ZFS-RUST-ECOSYSTEM-SURVEY-2026-05-25.md
4.1 Multiboot declined MULTIBOOT-EVALUATION-2026-05-25.md n/a, decision is closed
4.2 HTTP listener struck PHASE-D-WASMI-HEALTH-METRICS-2026-05-25.md section 6 n/a, replaced by push uploader

10. Change log

  • 2026-05-26 (morning): Initial consolidation written. Integrates the eight overnight deliverables (OVERNIGHT-RESEARCH-SYNTHESIS-2026-05-25.md and underlying analyses) with the user's preliminary tier decisions. Supersedes the forward-looking sections of docs/ROADMAP.md and docs/archive/plans/ROADMAP-V1.0-AND-BEYOND.md; cross-reference matrix preserves what each prior doc still authoritatively owns.
← All documentation