Roadmap

Status: Accepted

The version table below is generated from the version manifests by scripts/gen_roadmap_table.py — edit a manifest, not the table. just generated rewrites it and refuses a hand edit. Everything else on this page is written by hand.

Sequenced to keep a working, demonstrable artifact at every milestone. The ordering principle: build the thing being wrapped before the wrapper. lemonfiber should target a stack that is already known-good, so that debugging is never “is it lemonfiber or is it the stack?”

---

The version train

Releases ship as a serial train of semver versions, each scoped by a manifest in 70-operations/versions/ — the single source of truth for a version’s goals and status; the table below renders that truth. Minors are themed feature slices; patches (x.y.Z) are hotfixes; a major carries the capability that justifies the number. No version ships a stub — a release refuses while a requirement it locks is not yet built (OPS-R54).

Patch releases (hotfixes)

A patch (x.y.Z) fixes an already-released version from its tag, bypassing the goal gate — a cited fix plus maintainer authorisation (OPS-R37). Patches appear in the changelog but never enter the goal-locked train.

---

M0 — Specification ✅

This repo. Decisions recorded, contracts defined, standards set.

Exit criteria: all sections Accepted; stack.toml schema defined precisely enough to implement against.

---

M0.5 — Governance in force

Before any implementation repo exists, the rules that bind it must. Standing this up after code has already landed means retrofitting citations onto history, which nobody does.

Exit criteria: a PR citing a non-existent identifier is closed with guidance; a PR citing a valid one passes; an override is recorded and opens a tracking issue.

Why before M1: the very first commit to lemonfiber-media-stack should cite a requirement. If governance arrives later, the initial history is exempt by accident, and “we’ll backfill” never happens.

---

M1 — lemonfiber-media-stack works standalone (with brand alongside)

No Rust involved. The stack must be usable with bare docker compose. The brand repo — tokens, marks, and its contrast CI — can be finished in parallel here, since the web UI that consumes it doesn’t arrive until M7 and nothing gates on it earlier.

Exit criteria: every form starts cleanly via raw docker compose --profile …; hardlink import verified end-to-end; VPN killswitch verified by hand.

Why first: proves the profile model empirically. If partial stacks don’t actually boot, that invalidates ADR-0002 and everything downstream.

---

M2 — lemonfiber core: manifest, compose driver, CLI

Headless. No TUI yet — every capability reachable as a plain subcommand, which keeps it scriptable and testable.

Exit criteria: lemonfiber up tv matches hand-written docker compose exactly; golden tests cover every form on every platform.

Form composition is in 1.0, not deferred. lemonfiber up full proxy is a set union over profiles — trivial to implement — and it is what makes proxy viable as a form rather than a special-cased flag.

---

M3 — Setup wizard + doctor

The milestone that delivers the actual product thesis.

Exit criteria: a fresh machine reaches a running tv form in under 15 minutes with no service web UI opened. Leak test provably catches a misconfigured VPN.

---

M4 — Seed & backup

Turns config from precious into reproducible (P6). Spans two versions: 0.3.0 (backup & restore — a configured stack captured to an archive) and 0.4.0 (auto-wiring & seed — the graph rebuilt from nothing).

Exit criteria: rm -rf config && lemonfiber up tv && lemonfiber seed restores a working stack in under 2 minutes. Seed is idempotent — running twice changes nothing.

---

M5 — Trust checks

The P3 trust pillar made real (0.5.0–0.7.0): the foundations everything is expressed in terms of, then the diagnostics that prove the stack is safe to run, beyond the setup-time checks M3 established.

Exit criteria: each trust check catches its failure on a deliberately broken stack and states a remedy.

---

M6 — Live TUI

The second surface (0.8.0, closing at 1.0.0), ratatui over the same core the CLI drives — the read-only dashboard and the interactive surfaces over it. It is what 1.0.0 delivers, and the reason that release is a major rather than another minor.

Exit criteria: dashboard sustains 1 Hz refresh at <2% CPU idle; input stays responsive while pulling images.

---

M7 — Web surface & UX

A third surface (0.9.0–0.10.0): a web view over the same core, plus the cross-cutting UX that spans every surface. The view is served by lemonfiber as a JSON API and drawn by a static app kept in its own repo (ADR-0011).

Exit criteria: the web surface renders the same live state the TUI shows and can complete setup, over the core with no surface-specific logic.

Setup is completable from the web surface (G1-R14), so it writes. The C6 goals guarding a writable loopback API are locked by 0.9.0.

---

M8 — Household & content

Content and household features (0.11.0–0.12.0): managing what the stack holds and who in the household reaches it.

Exit criteria: a household member’s request flows end to end, and content management acts without reverting an operator’s manual choices.

---

M9 — Lifecycle & maintenance

Living with a running stack (0.13.0–0.15.0): reconfiguration, migration, uninstall, credentials, remote control, autostart & boot persistence, hosting lemonfiber’s own long-running commands, stack and self updates, backup, rollback, the journal, customisation and the service catalogue.

Exit criteria: every lifecycle operation is reversible or explicitly confirmed, and an unattended stack recovers across a reboot.

---

M10 — Release engineering

Ships with 1.0.0: the install paths a non-contributor follows, and the gate that ships no stubs (OPS-R54).

Exit criteria: a non-contributor installs and runs on all three platforms following only the README.

---

The rest of the way to 1.0.0 (M11–M16)

These were once sequenced behind a second epoch opening at 2.0.0. There is no second epoch: 1.0.0 means everything specced is built and the interfaces stop moving, so everything below is on the way to it rather than after it. They ship as minors on the one train, authored to the same bar as everything before them.

The plugin system comes first of them, because it changes the stack manifest and introduces the capability vocabulary — every feature after it is then built on the shape that ships rather than retrofitted onto it, and the schema has several minors of use behind it before 1.0.0 freezes it.

---

M14 — The platform

0.16.0–0.18.0. Other people’s stacks, and the surface that makes them possible. F3–F8 and F10 are Accepted; recipes (F8) are locked by 0.18.0.

Recipes come last of the three, deliberately. A manifest describes a container whose reach lemonfiber fixes, so the worst one can do is fail to parse. A recipe runs with lemonfiber’s own authority on behalf of a manifest a stranger wrote, and it is the riskiest mechanism in this design — so it arrives in 0.18.0, after two versions of operating the simplest plugin there is.

The capability work is split across 0.16.0 and 0.17.0, and the difference is visible to an operator rather than internal. 0.16.0 ships the vocabulary and the converted wiring: a plugin can claim a capability, be refused for claiming one it cannot demonstrate, and take over one another plugin was filling. 0.17.0 ships the bundled declarations, which is what makes a plugin able to stand in for a bundled service. The model has to exist before a service can be described in it, and describing them all is the larger half of the work.

The wiring conversion sits with the vocabulary rather than with the declarations because five of F4’s requirements are what it makes buildable — reporting an ask nothing fills, journalling a substitution, refusing one that would leave a capability unfilled — and none of them has a subject while every consumer still names a service.

Exit criteria for 0.16.0: a plugin authored outside this project installs, proves itself, and adds a service to a running stack with no change to lemonfiber — and removing it puts the stack back.

Exit criteria for 0.17.0: a plugin replaces a bundled service, and nothing that consumed that service’s capability had to be changed for it to work. The first-run flows that some substitutions need wait for F8, which 0.18.0 locks.

---

M16 — The household’s library

0.19.0. What a member can find, ask for and play, on their own account and under their own limits (ADR-0027).

Exit criteria: a member finds a title they may watch, sees its artwork and what it is, and plays it at home on their own account; a title outside their limits is never offered, located or streamed.

---

M11 — Ecosystem glue

0.20.0–0.21.0. The integrations a mature stack grows into, each one verified rather than merely wired.

Exit criteria: each integration proves its effect on a live stack, not its presence in a configuration file.

---

M12 — Safely reachable

0.22.0. Reaching the stack from outside the house without opening it to the world.

Exit criteria: a household member reaches the library from outside with no port exposed to the internet, signing in once.

---

M13 — See everything

0.23.0. The stack’s own telemetry, for the operator who wants graphs rather than a dashboard.

Exit criteria: a deliberate outage appears in the metrics and raises the notification the trust checks already know how to send.

---

M15 — Runs anywhere

0.24.0. The container engine becomes one implementation behind an abstraction rather than an assumption, which lifts the single-engine non-goal (ADR-0010).

Exit criteria: the same stack starts, passes doctor and serves media under Docker, under Podman, and with no container runtime present.

Beyond 1.0.0

Not scheduled. Recorded so they’re not rediscovered as novel.

Several former post-1.0 candidates are scheduled features on the way to 1.0.0: autobrr/cross-seed (H1, H2), Janitorr/Maintainerr (H6), transcoding (H7, open-source Unmanic), and the plugin system (F3), and remote access for the household (I1).

Explicitly rejected

See vision § non-goals.