Roadmap to v14

This is a pre-v14 roadmap.

It lists the major work still missing before Yazelix should be called v14. It is not a post-v14 feature roadmap.

v14 should mean packaged, hardened, trustworthy Yazelix.

The goal is not just to tag a new major version because the repo has changed a lot. v14 should only happen once the packaging/distribution story feels canonical and the repo/runtime surface is meaningfully cleaner, safer, and easier to reason about.

What v13.x already established

v13.x was not throwaway work. It established the product direction that this roadmap is trying to finish and harden before v14.

Across v13 through v13.11, Yazelix already moved substantially toward:

• plugin-managed workspaces and deterministic editor/sidebar orchestration
• a cleaner runtime story around refresh, restart, and the installed runtime
• migration-aware upgrades with yzx config migrate, yzx doctor --fix, upgrade notes, and first-run upgrade summaries
• clearer managed config ownership through user_configs/ and yazelix_packs.toml
• stronger launch, popup, desktop, CI, and Home Manager reliability

So this roadmap is not about inventing a different direction. It is about making that direction feel complete, coherent, and package-worthy enough to justify the major bump.

Main pre-v14 themes

1. Finish the packaging/distribution story

The core requirement for v14 is that Yazelix feels like a packaged product rather than merely package-ready.

Relevant issues:

• Packaging: prepare and submit a nixpkgs package for Yazelix #402 Prepare and submit a nixpkgs package for Yazelix
• Add launch-profile freshness diagnostics to yzx doctor #539 Add launch-profile freshness diagnostics to yzx doctor

There is also still internal Home Manager and packaging-gate work in the backlog that needs to land before I would consider v14 earned.

2. Reduce surface area and repo complexity

A lot of the remaining work is about making the repo smaller, tighter, and less surprising before treating the packaged story as stable.

Relevant issues:

• Continue removing unnecessary environment variables #411 Continue removing unnecessary environment variables
• Repo cleanup pass for legacy and unused artifacts #433 Repo cleanup pass for legacy and unused artifacts
• Audit large files and identify worthwhile refactors #457 Audit large files and identify worthwhile refactors
• Audit rm usage for safety and destructive-command hygiene #479 Audit rm usage for safety and destructive-command hygiene

3. Centralize config semantics and migration behavior

Yazelix has already moved toward a clearer canonical config contract, but there is still cleanup left around ownership, migrations, and diagnostics.

Relevant issues:

• Continue centralizing Yazelix declarative config semantics onto the canonical contract #516 Continue centralizing Yazelix declarative config semantics onto the canonical contract
• Make Yazelix config migrations land atomically across managed surfaces #520 Make Yazelix config migrations land atomically across managed surfaces
• Add launch-profile freshness diagnostics to yzx doctor #539 Add launch-profile freshness diagnostics to yzx doctor

This matters for v14 because a packaged product needs config changes, updates, and stale-state recovery to feel deliberate rather than ad hoc.

Post-v14 lanes

I am also doing architecture work that should make a future lighter/Core-style edition and later backend experiments more realistic, but that is not what must land before v14.

Those are better understood as post-v14 lanes.

Relevant issues for that later direction:

• Define the Yazelix backend contract before evaluating alternative runtime backends #538 Define the Yazelix backend contract before evaluating alternative runtime backends
• Define the runtime dependency contract and launch preflight checker scope #532 Define the runtime dependency contract and launch preflight checker scope
• Implement a shared runtime contract checker and reuse it across launch and doctor #533 Implement a shared runtime contract checker and reuse it across launch and doctor
• Extract a backend adapter boundary around env, run, refresh, and launch bootstrap #534 Extract a backend adapter boundary around env, run, refresh, and launch bootstrap
• Audit and classify yzx command families by backend coupling #535 Audit the yzx command surface into backend-required versus backend-agnostic commands
• Define the Yazelix Core edition boundary and support story #536 Define the Yazelix Core edition boundary and support story

Practical summary

If I had to summarize the remaining road to v14 in one sentence, it would be:

finish the packaging story, harden the runtime and config model, and cut repo/runtime cruft until the product feels stable enough to deserve the major bump.