# Aman Target Persona and Distribution Strategy

## Primary Persona: Desktop Professional

This is the canonical Aman user.

- Uses Linux desktop daily on X11, across mainstream distros.
- Wants fast dictation and rewriting without learning Python tooling.
- Prefers GUI setup and tray usage over CLI.
- Expects a simple end-user install plus a normal background service lifecycle.

Design implications:

- End-user install path must not require `uv`.
- Runtime defaults should work with minimal input.
- Supported daily use should be a `systemd --user` service.
- Foreground `aman run` should remain available for setup, support, and
  debugging.
- Diagnostics should be part of the user workflow, not only developer tooling.
- Documentation should distinguish current release channels from the long-term
  GA contract.

## Secondary Persona: Power User

- Comfortable with CLI, package internals, and model customization.
- Uses advanced config, external APIs, or custom models.
- Can run diagnostics and debug logs when needed.

Design implications:

- Keep Make and Python workflows available.
- Keep explicit expert-mode knobs in settings and config.
- Keep docs for development separate from standard install docs.

## Current Release Channels

The current release channels are:

1. Current end-user channel: Debian package (`.deb`) for Ubuntu/Debian users.
2. Secondary: Arch package inputs (`PKGBUILD` + source tarball).
3. Developer: wheel and sdist from `python -m build`.

The portable X11 installer is the GA target channel, not the current shipped
channel.

## GA Target Support Contract

For X11 GA, Aman supports:

- X11 desktop sessions only.
- Runtime dependencies installed from the distro package manager.
- `systemd --user` as the supported daily-use path.
- `aman run` as the foreground setup, support, and debugging path.
- Representative validation across Debian/Ubuntu, Arch, Fedora, and openSUSE.
- The recovery sequence `aman doctor` -> `aman self-check` ->
  `journalctl --user -u aman` -> `aman run --verbose`.

"Any distro" means mainstream distros that satisfy these assumptions. It does
not mean native-package parity or exhaustive certification for every Linux
variant.

## Out of Scope for X11 GA

- Wayland production support.
- Flatpak/snap-first distribution.
- Cross-platform desktop installers outside Linux.
- Native-package parity across every distro.

## Release and Support Policy

- App versioning follows SemVer (`0.y.z` until API/UX stabilizes).
- Config schema versioning is independent (`config_version` in config).
- Docs must always separate:
  - Current release channels
  - GA target support contract
  - Developer setup paths
- The public support contract must always identify:
  - Supported environment assumptions
  - Daily-use service mode versus manual foreground mode
  - Canonical recovery sequence
  - Representative validation families
- GA means the support contract, validation evidence, and release surface are
  consistent. It does not require a native package for every distro.