Roadmap
What needs to happen for XTL 1.0 (spec) and xl3 1.0 (reference implementation).
The current version is 1.0.0-rc.1 (npm) targeting XTL 0.1 (draft). Breaking changes are still possible during 0.x. The 1.0 cut is gated on technical stability and the time-bound soak below. Ecosystem adoption is tracked separately and does not block the compatibility promise (ADR-0079).
Deep version planning lives in
docs/internal/blueprint-to-1.0.md— gap analysis, philosophy boundary (xl3 ≠ JXLS), per-version step plan. This document is the elevator pitch; the blueprint is the rationale.Single source of truth for 1.0 gates is the table below. When this file and the blueprint conflict, this table wins; the blueprint is updated to match.
What 1.0 means for xl3
The 1.0 target is one stable end-to-end promise:
application-owned JavaScript data → Excel template → generated
.xlsx.
An application may pass an already-parsed xl3-source-json/0.1 object to
convertJson; no source data file is required. xl3 applies the data to the
operator-authored workbook and returns OutputFile[], with each completed
workbook in OutputFile.data as a Uint8Array. The same API runs in Node
and browsers.
That narrow workflow still carries operator-readable trust: a spec that doesn't shift, a reference impl that doesn't surprise, and a surface small enough that an operator can review a template without reading code. It is not about feature completeness vs JXLS — xl3 intentionally ships a smaller surface (ADR-0043 + ADR-0048). Database/API/ORM access belongs to the host, and dynamic images, custom host-language commands, streaming, macros, and pivot/chart authoring do not block 1.0. The intended audience is Korean operations teams that manage many customer-specific invoice formats (거래명세서, 정산서, 발주서); the engine generalizes beyond this niche, but the niche is the wedge.
1.0 blocking gate table (single source of truth)
Each blocking gate has an owner, the artifact that closes it, the pass-fail criterion, a fallback if the gate is unreachable, and the target milestone. Per-version step plan below references these gates by ID.
| ID | Gate | Owner | Artifact | Pass criterion | Fallback | Status (audited 2026-08-30) | Planned |
|---|---|---|---|---|---|---|---|
| G1 | Conformance corpus ≥ 140 | maintainer | conformance/fixtures/ | ls conformance/fixtures/ | wc -l ≥ 140 | — | ✅ DONE — corpus is well past the ≥ 140 threshold; the live count is in conformance/DASHBOARD.md, which is generated | DONE (160 fixtures; ADR-0066 added 141-145 mid-0.7.x; ADRs 0067-0069 added 146-155 in 0.8.0; 156 (#49 native value preservation) + 157 (#51 grouped side cells) added post-0.8.1; 158 (#52 arithmetic associativity) in 0.9.0; 159-161 (ADR-0073/0074 subtotal errors) in 0.10.0; 162-169 (data-loss group, spec-derived) + 170 (numFmt across @repeat expansion, Stage 2) added 2026-07-28 for G24; number 098 is unused, so at that point the count was 169 against a highest index of 170; ADRs 0051-0065 reserved further numbers for 0.7.1) |
| G2 | Stage 2 OOXML canonicalization spec'd | maintainer | ADR-0006 + canonicalizer in src/ | covered by fixtures 024-027, 093 + ADR-0006 amendment | — |