This spec is the current branch-level contract for the trimmed v15 line.
v15.0 is the slimmed-down non-Rust reboot. Selective Rust may land later in v15.x when it clearly pays for itself; v16 is the Rust-forward release target.
The product surface is now centered on:
- a fixed packaged runtime
- explicit install/update owners
- managed
user_configs/configuration - workspace/session commands
- helperless fast popup/menu transient panes
- generated-state repair instead of backend/profile orchestration
It is no longer centered on:
yazelix_packs.toml- dynamic pack graphs
- the old runtime-local
devenvlayer - cached launch-profile reuse
- automatic config migrations
- a generic Yazelix-owned runtime updater
Several older specs still describe the pre-trim planning space where Yazelix owned more runtime/package-manager behavior. That history is useful, but it is not the current branch contract anymore.
This file exists so current docs and current specs can point at one authoritative post-trim description instead of reusing planning notes that were written before the deletions actually landed.
- define the current v15 user-facing runtime/config/update boundary
- define what still belongs to the normal product surface
- define what moved to maintainer-only or historical territory
- give other docs a safe current contract to point at
- The normal product runtime is the packaged
yazelixruntime. - That runtime ships a fixed toolset rather than a user-managed package graph, but interactive shells only export the curated user-facing tool surface instead of the full helper closure.
- Runtime tool versions come from the locked
nixpkgsinput. Maintainer update pins record the Nix helper version and the Nixpkgs-provided Nushell version, so upstream Nushell releases only become runtime bumps after they land in Nixpkgs or Yazelix deliberately changes that ownership model. - Ghostty is built into the Yazelix runtime on Linux and macOS as the first-party terminal path.
- WezTerm, Kitty, Alacritty, and Foot remain supported alternatives when the user provides those binaries on
PATH. - The runtime does not ship a runtime-local
devenv.
- The canonical user config surface is
~/.config/yazelix/user_configs/. - The main config is
user_configs/yazelix.toml. - Managed override directories such as Zellij, Yazi, Helix, and shell user hooks remain part of that user-owned config surface.
- The trimmed v15 branch does not have a
yazelix_packs.tomlsidecar and does not expose a first-class pack graph. - Legacy or removed config fields fail fast instead of degrading silently.
- v15 does not ship a config-migration engine. Users moving from very old config shapes should compare with the current template manually or use
yzx config resetas a blunt fresh-start path.
- Generated Zellij/Yazi configs, shell initializers, logs, and repair hashes live under
~/.local/share/yazelix. - Those files are derived artifacts, not canonical handwritten config.
- Generated-state repair is an internal runtime responsibility surfaced through startup preflight,
yzx doctor, and maintainer canaries rather than through a public refresh command. - Generated-state repair does not rebuild or reuse a cached backend launch profile.
- Users choose one explicit update owner per install.
yzx update upstreamfor default-profile installs of#yazelixyzx update home_managerfor Home Manager installs
- The flake no longer exposes
#install. - The product no longer promises a generic in-app runtime updater that owns every install mode.
maintainer_shell.nixdefines the repo development shell for maintainer workflows.- That maintainer shell is not the normal user runtime contract.
- Maintainer-only commands may still touch flake inputs, repo profiling flows, or release automation.
- Those maintainer semantics should not leak back into user-facing runtime docs.
- reintroducing dynamic pack management on the trimmed v15 branch
- treating cached launch-profile reuse as a current product guarantee
- restoring the old runtime-local
devenvlayer as part of the normal shipped runtime - restoring automatic config migrations as a normal v15 product surface
- pretending the compatibility installer is the canonical everyday product flow
- treating v15.0 as the Rust release
- A current v15 user can understand the product without learning about
yazelix_packs.toml, launch-profile reuse, runtime-localdevenv, or automatic config migrations. - Current docs explain generated-state repair through startup and
yzx doctorrather than through a public refresh command. - Current docs explain update ownership through explicit owner commands rather than a generic runtime updater.
- Current docs distinguish the normal packaged runtime from maintainer-only
nix developworkflows. - Current roadmap docs describe v15.0 as the trimmed non-Rust reboot and v16 as the Rust-forward release.
nu nushell/scripts/dev/validate_installed_runtime_contract.nunu nushell/scripts/dev/validate_flake_install.nu allnu nushell/scripts/dev/test_yzx_workspace_commands.nunu nushell/scripts/dev/test_yzx_generated_configs.nunu nushell/scripts/dev/test_yzx_maintainer.nunu nushell/scripts/dev/test_stale_config_diagnostics_e2e.nu
- Bead:
yazelix-qgj7.2.4.3 - Defended by:
nu nushell/scripts/dev/validate_installed_runtime_contract.nu - Defended by:
nu nushell/scripts/dev/validate_flake_install.nu all - Defended by:
nu nushell/scripts/dev/test_yzx_workspace_commands.nu - Defended by:
nu nushell/scripts/dev/test_yzx_generated_configs.nu - Defended by:
nu nushell/scripts/dev/test_yzx_maintainer.nu