Feature catalogue

Status: Accepted

v1 is the seven product areas (A–G) — the contract the technical spec is written against, where every architecture and implementation decision must trace to a feature requirement here, not the other way round. The ecosystem adds four areas (H–K) plus F3, catalogued below the v1 areas and sequenced before 1.0.0 on the same train. Area L — Release & distribution spans both, and carries one release: L1 ships 1.0.0, which is the scoped work of getting there rather than a summary of it. The generated feature board lists every feature with how far it is built and the version it ships in; index.json is the same board for tools: the counts, the version train, and the board.json in each area’s directory that lists its features.

Every feature carries two answers that are easy to confuse and are kept apart. status is about the specification — draft until it is agreed, then accepted, and citable. maturity is about the implementation — planned, building, built, shipped (with the version that carried it), or withdrawn. It is derived rather than written: scripts/maturity.py reads every repository’s tracker and every version manifest, and the maturity workflow opens the pull request that rewrites it whenever the trackers move a feature (OPS-R78). withdrawn alone is set by hand. A feature is routinely accepted and planned for a year; conflating the two would lose whichever question is asked less often.

built and shipped are also worth keeping apart. A feature whose every requirement is met sits in built until the version carrying it is released — which is a different fact from being half-written, and building used to have to mean both. It is the state OPS-R54 can actually gate on: shipped means out in a released version, so demanding it before a release is a gate nothing could ever pass.

A requirement added to a built or shipped feature reopens it: it is building again until the implementation tracker ticks every requirement it defines, and status_lint.py refuses a catalogue that says otherwise (OPS-R73).

How to read a feature doc

Each follows the same shape:

Requirement IDs

Requirements live inside their feature — there is no separate requirements tree. An ID is <feature>-R<n>: A1-R3 is the third acceptance criterion of feature A1.

IDs are permanent. A requirement that’s removed is marked Withdrawn in place; its number is never reused. Tests and commits cite these IDs.

Audiences

Two, and they need naming because most features serve only one:

A household member has exactly one account — their Jellyfin login, which Seerr authenticates against. The multi-account problem is an operator problem only.

---

A — Getting started

The hardest part of the product, and where most users are lost today.

B — Running it

B7 (remote access for the household) is deferred — household features are LAN-only until it lands. It returns as I1 in 0.22.0, once a self-hosted overlay control plane (Headscale + self-hosted relay) makes it possible without the proprietary control plane that blocked it (Tailscale). See ADR-0010 for the related runtime decision and the roadmap.

C — Trust & correctness

Features that exist because P3 demands the tool prove things rather than assume them.

D — Content & household

E — Maintenance

F — Extensibility

G — Cross-cutting UX

These are not screens; they are properties every other feature must exhibit. G4 and G5 in particular are the connective tissue that makes the whole catalogue read as one product.

---

The ecosystem

Everything below ships before 1.0.0, on the same train as everything above it: authored to the same falsifiable-requirement bar, and gated by the same rule — no version ships a requirement it has not finished (OPS-R54). The through-line is the project’s wedge applied outward — not just wiring these services, but proving the wire works (a health check, a valid upstream credential, and a synthetic action read back), the thing no adjacent tool does.

Areas H, I and K are Accepted, as is F3. The runtime pillar (J) is Draft — proposed and open for comment: it reopens a non-goal (ADR-0010) and carries the most design risk, so it is not binding until reviewed.

H — Ecosystem glue

The tools the community bolts on, bundled and — the differentiator — verified.

I — Remote access & identity

Reaching the stack from outside the home, and the one-account gate it requires — both without a proprietary control plane.

J — Runtime & platform · Draft

Freeing the stack from a single container runtime, while keeping both proofs (VPN egress, hardlinks) passing on every engine (ADR-0010).

K — Observability

Open-source-native metrics and monitoring — a second opinion, delivery-confirmed.

Also in existing areas: F3–F11 (the plugin system), B9 (open notification back-ends, extends B5), and G9 (mobile handoff, extends G6).

L — Release & distribution

Turning the built product into something a stranger can install and run. Each major release is its own scoped work — the distribution itself, not the features that came before it.

N — Companion

The fourth surface, on a device that is not the one the stack runs on. One application for both audiences, deciding which by who signs in (ADR-0017).

Specified in full and locked by no version: the app follows what the main repositories have shipped rather than leading them, so nothing on the release train waits on it. It is pinned with the rest once it has caught up.

---

Traceability

Three links, all of which CI checks:

Journey  ──exercises──▶  Feature  ──contains──▶  Requirement  ◀──implements──  Code
                                                      ▲
                                                      └──cites──  Architecture doc

1. Every journey names the features it exercises.
2. Every feature owns numbered requirements.
3. Every architecture and per-repo doc cites the requirement IDs it satisfies.

A technical decision that cites no requirement is unjustified, and should be challenged in review. That’s the rule that keeps the technical spec written against the features rather than alongside them.