Linux installer dry-run, Kitty selection, and Arch packages diverge

[ztc0]

Problem

Three Linux installer paths currently disagree with the behavior advertised by the CLI and documentation:

1. --dry-run still executes installation work.
2. Kitty is accepted by the CLI and documented for Linux, but is hidden from the Linux TUI and is not installed by the Linux backend.
3. Arch shell dependencies include packages that are not available to pacman, aborting the installation.

Together, these make it difficult to preview or complete a supported Linux installation safely.

Reproduction

1. Dry-run executes real work

$ gentleman-dots --dry-run --non-interactive \
    --terminal=none --shell=fish --wm=none

installer/cmd/gentleman-installer/main.go sets GENTLEMAN_DRY_RUN=1, but the execution wrappers do not read it. The non-interactive installer continues through dependency installation, repository cloning, configuration writes, and shell changes.

--test is not a safe substitute: it redirects HOME, but package-manager, sudo, network, and current-working-directory operations still run.

2. Kitty is unavailable in the Linux TUI

1. Start the interactive installer on Linux.
2. Select Linux.
3. Open the terminal selection screen.

The available choices are Alacritty, WezTerm, Ghostty, and None. Kitty is only returned for macOS in installer/internal/tui/model.go.

However:

• --terminal=kitty is accepted by the CLI;
• the learning screen lists Kitty on every platform;
• the documentation lists Kitty as a Linux-capable choice;
• the backend has a Kitty configuration branch.

On Linux, that backend does not install a missing Kitty binary and can log Kitty already installed even when it is absent.

3. Arch sends unavailable packages to pacman

Selecting Fish, Zsh, or Nushell on a clean Arch installation can send carapace to pacman; Zsh also sends zsh-theme-powerlevel10k. Those package names are not available from the official Arch repositories used by pacman, so the whole transaction exits with status 1.

This part overlaps the existing reports #174 and #176, the consolidated analysis in #174, and open PR #186. It is included here because it is part of the same Linux installer path and needs regression coverage alongside the mode/TUI fixes. The implementation should avoid duplicating or conflicting with #186.

Expected behavior

• --dry-run performs no process, package-manager, network, filesystem, configuration, or shell mutations and prints the planned operations.
• Kitty appears as a Linux TUI option when the installer supports configuring it.
• On supported Linux distributions, a missing Kitty binary is installed through the platform package strategy, or the installer returns an accurate actionable precondition.
• Arch package transactions contain only packages resolvable by the selected package manager; optional external dependencies use an explicit supported fallback.
• Automated tests cover all three contracts.

Actual behavior

• --dry-run only sets an environment variable and then executes the normal installation path.
• Linux users cannot select Kitty in the TUI, despite CLI/backend/documentation support.
• Arch shell installation can abort before later selected components run.

Environment and evidence

• OS: Arch Linux x86_64
• Installer: official Linux amd64 v2.12.2
• Verified against current main installer structure
• Prior workaround required preinstalling the unavailable Arch dependencies before retrying the installer

Relevant source areas:

• installer/cmd/gentleman-installer/main.go
• installer/internal/system/exec.go
• installer/internal/tui/model.go
• installer/internal/tui/installer.go
• installer/internal/tui/non_interactive.go

Proposed validation

• A marker-file command remains unexecuted under dry-run.
• Filesystem helpers and direct installer writes leave no artifacts under dry-run.
• Linux terminal option tests include Kitty.
• Platform tests verify the correct Kitty installation command per supported Linux distribution.
• Arch shell package tests verify that unresolved AUR-only names are never passed directly to pacman.

[ztc0]

Could a maintainer review this scope and add status:approved if it is suitable for implementation? I will keep the Arch package work compatible with #186 and avoid duplicating its fallback changes.

[ztc0]

Proposed implementation plan

I mapped the interactive and non-interactive execution paths. The smallest safe fix is to make dry-run an explicit execution policy and stop mutations at the step boundary, rather than adding partial checks only around command execution.

1. Make dry-run mutation-free

• Add explicit DryRun state to the TUI model and pass the CLI flag into both interactive and non-interactive models.
• In executeStep, return before dispatching any mutating step when DryRun is enabled.
• In the interactive runner, skip before generating temporary scripts or calling tea.ExecProcess; interactive steps currently bypass executeStep.
• Process --dry-run before --test. When both are supplied, dry-run must not call setupTestMode, because that function creates directories and changes HOME.
• Keep read-only detection and print the planned step names, but skip package managers, sudo, network operations, cloning, backups, config copies/patches, downloads, cleanup, shell changes, and temp-script creation.

Regression tests should:

• run every installer step with DryRun: true against a temporary HOME/CWD and assert an unchanged filesystem snapshot;
• assert injected package/command runners receive zero calls;
• verify an interactive dry-run never returns an exec-process request or creates a temporary script;
• verify the full non-interactive dry-run succeeds without package managers, sudo, source configs, or network access;
• verify --test --dry-run leaves HOME and the test directory untouched.

2. Make Kitty consistent on Linux

• Include Kitty in the Linux terminal options in model.go.
• Preserve the macOS cask path.
• When Kitty is absent on Linux, install it using the repository's native-first platform strategy:
  • Arch: pacman -S --needed --noconfirm kitty
  • Fedora: dnf install -y kitty
  • Debian/generic supported Linux: apt-get install -y kitty when using the native package manager
  • existing configured package-manager fallback where supported
• Only report Kitty already installed when detection actually succeeds.
• Keep copying GentlemanKitty into the existing config destination after installation.
• Update the duplicated interactive terminal script so TUI and non-interactive behavior remain equivalent.

Regression tests should update the existing Linux-negative option tests and verify Arch/Fedora/Debian command selection, existing-Kitty behavior, fallback behavior, and config deployment.

3. Integrate the Arch dependency fix without duplicating #186

Issue #174 and PR #186 already own the general missing-package fallback. I do not plan to copy that implementation into a competing patch.

Preferred sequence:

1. Let maintainers decide/merge the package strategy in fix(installer): fall back to GitHub when packages are missing from native repos #186.
2. Rebase the Linux installer dry-run, Kitty selection, and Arch packages diverge #190 branch onto that result.
3. Add only the missing regression assertion that AUR-only/unresolvable names are never sent directly to pacman, plus any narrow Kitty mapping needed by Linux installer dry-run, Kitty selection, and Arch packages diverge #190.
4. Keep separate work-unit commits for dry-run, Kitty support, and the post-fix(installer): fall back to GitHub when packages are missing from native repos #186 Arch integration.

If maintainers prefer #190 to supersede #186, that should be stated before implementation because both changes touch installer.go and platform_packages_test.go and would otherwise create duplicate/conflicting fallback behavior.

The implementation/PR remains paused until this issue receives status:approved, as required by the repository PR workflow.