lidarslam_ros2 v0.9 roadmap — product foundation

Status: direction approved 2026-07-27; Phase 0 complete; Phase 1 in progress (CLI and manifest lifecycle landed; resume semantics pending). This roadmap turns the existing benchmark-heavy map-authoring stack into a product-level OSS project. It does not replace the evidence-driven capability roadmaps; it defines the stable product surface they must integrate with.

0. Product decision

The product is an offline rosbag2-to-map authoring workflow, not a general collection of SLAM experiments:

A third party can start from the public documentation, run one official command, obtain a verified Autoware-compatible point-cloud map bundle, and diagnose a failure without reading the implementation.

The authoritative scope and compatibility promises are in docs/product-contract.md.

Research tracks remain valuable, but they are not allowed to expand the beginner surface, silently change defaults, or block product hardening.

1. Measurable v1.0 readiness targets

Dimension	Readiness gate
First success	A clean-machine user can complete the Docker demo from README alone; a source user can build and start the fixed quickstart from Getting Started
Official surface	No more than three beginner-facing entrypoints; every other path is labelled advanced, benchmark or research
Diagnosability	Unsupported input, missing topics, missing calibration prerequisites and invalid output return an actionable error or diagnosis artifact
Reproducibility	Fixed demo inputs and parameters are pinned; offline determinism and map verification gates remain green
Distribution	Versioned GHCR image and source install work on supported platforms; the rosdistro/RKO-LIO packaging decision is resolved and documented
Reliability	Corrupt bag, missing TF, time disorder, output collision, disk pressure and interrupted-run behaviors have automated coverage
Compatibility	Product flags, output schema and deprecation policy are documented and tested
OSS operations	Security, support, conduct, governance, citation, issue templates and release ownership are public
External adoption	At least three independent users complete first-map validation from public docs, with findings recorded before v1.0

Targets are evidence requirements, not marketing estimates. A readiness item is incomplete until the command, artifact or external report proving it is available.

2. Phase 0 — Product Foundation

Deliverables:

publish the product contract and explicit non-goals;
identify exactly three official entrypoints;
add security, support, conduct, governance and citation policies;
add structured bug, feature and sensor-support issue forms;
reconcile README, docs navigation, release links and VERSION;
encode the above as documentation regression tests.

Gate:

mkdocs build --strict succeeds;
documentation and metadata tests succeed;
all policy links resolve locally;
historical release pages remain available but are not described as current;
no runtime algorithm or default changes in this phase.

3. Phase 1 — Golden-path UX

Build one stable command surface over the existing runners:

./scripts/lidarslam doctor <bag>
./scripts/lidarslam run <bag> --profile <profile>
./scripts/lidarslam inspect <output>

The implementation may initially be a Python console package delegating to the proven scripts. The public contract is the command behavior, exit codes and artifacts—not the internal wrapper language.

The repo-local spelling is deliberate during Phase 1: the ROS package already installs a C++ node named lidarslam. Phase 2 must provide an installed CLI and compatibility shim together rather than silently replacing that node.

Deliverables:

versioned preflight/diagnosis JSON schemas;
deterministic execution plan with explicit selected profile and parameters;
run_manifest.json containing input identity, Git/package versions, commands, timing, completion state and output checksums;
atomic output creation, collision protection and resumable stages;
actionable error taxonomy and stable non-zero exit codes;
user-facing success summary with map, diagnosis and viewer paths.

Gate:

unit tests cover planning, schema, errors and resume state;
fixed demo and own-bag dry-run exercise the same product core;
clean Docker and source-workspace usability trials are recorded.

4. Phase 2 — Distribution and compatibility

Deliverables:

resolve the flagship packaging mismatch: either release the maintained rko_lio fork for Humble/Jazzy or make the binary product path and product claim explicitly use a frontend available from the same distribution;
release ndt_omp_ros2 before packages that declare it;
publish versioned GHCR tags in addition to moving convenience tags;
generate an SBOM and provenance for release images and bundles;
document amd64 as a tested target and assign an explicit support tier to arm64/Jetson;
test install/upgrade paths, not only source builds.

Gate:

one documented install command reaches the same golden-path behavior on each supported ROS distribution;
package contents include every runtime resource and exclude research media or generated artifacts not needed at runtime;
installation evidence is attached to the release candidate.

5. Phase 3 — Operational reliability

Deliverables:

failure-injection fixtures for corrupt metadata, missing TF, timestamp reversal, disk exhaustion, termination and partial output;
one-hour and eight-hour soak profiles with peak RSS, wall time, output size and dropped-input counters;
nightly fixed real-bag E2E with pinned input identity;
output schema compatibility tests and migration tooling;
release rollback and last-known-good image instructions.

Gate:

every failure either completes successfully or exits with a documented, recoverable state;
resource budgets are measured on named hardware;
no open release-blocking defect remains.

6. Phase 4 — v1.0 validation

Deliverables:

publish v0.9 as a stable release candidate, not only a prerelease;
run the external first-map validation with at least three independent users;
resolve or document every reported onboarding failure;
publish a v1.0 migration guide, support matrix and compatibility policy;
complete the full real-data release gate and security/release checklist.

Gate:

all readiness rows in §1 have direct evidence;
GitHub release, documentation, image tags and package metadata agree;
the maintainer signs off the release according to GOVERNANCE.md.

7. Parallel capability track

Degeneracy handling, map refinement, multi-session mapping, dynamic removal, colouring and optional loop detectors continue under separate evidence roadmaps. They follow four rules:

default-off until an adoption gate passes;
no new beginner entrypoint;
real-data positive and negative checks;
promotion updates the product contract only when support responsibility is accepted.

8. Execution order

Phase 0 Product Foundation.
Phase 1 manifest/doctor core before adding more wrapper features.
Phase 2 packaging decision early enough to expose dependency blockers.
Phase 3 reliability gates on the final command surface.
Phase 4 external validation and v1.0 release.

Do not mark this roadmap complete because individual code paths exist. Each phase closes only when its stated gate has authoritative evidence.