# System Design: Archinstall Stack Analysis

This document evaluates the existing `archinstall` codebase architecture in the context of the new `mddosinstall` MVP goals (a stripped-down, secure, barebones Hyprland + quickshell installer). 

## 1. Requirements & Constraints
*   **Functional:** The system must install Arch Linux, specifically configuring zram, systemd-boot (quiet+plymouth), NetworkManager, greetd, and a Hyprland profile.
*   **Non-functional:** The codebase must be maintainable, minimizing technical debt by aggressively pruning unused profiles, applications, and legacy TUI menus.
*   **Constraints:** The system is an offline/live-environment installer script, built entirely in Python using curses/TUI for user interaction.

## 2. High-Level Architectural Flow
1.  **Entry Point (`main.py`):** Parses arguments, initializes logging, and invokes the TUI.
2.  **TUI/UI Layer (`archinstall/tui/` and `archinstall/lib/menu/`):** Manages the curses-based menus where the user configures the system.
3.  **Data Models (`archinstall/lib/models/`):** Holds the state of the user's choices (Disk, Network, Profile, etc.).
4.  **Hardware/System Abstraction (`archinstall/lib/`):** Executes shell commands via `archinstall.lib.command.SysCommand` to interact with Pacstrap, systemd, and disk utilities.
5.  **Execution (`archinstall/lib/installer.py`):** Consumes the configuration models to mount disks, pacstrap base packages, chroot in, configure the bootloader, and export the logs/handoff data.

## 3. Deep Dive: Component Stack Analysis

Below is an analysis of each major module/directory in the `archinstall` stack, its original intent, and the architectural decision (Keep, Modify, or Delete) for the MVP.

### 3.1. Core Engine & Entry Points
| Component | Original Intent | Decision | Notes |
| :--- | :--- | :--- | :--- |
| `archinstall/main.py` | Primary entry point, argument parsing, main execution loop. | **Modify** | Simplify the CLI arguments if necessary, wire it to the new 7-step hierarchical global menu. |
| `archinstall/lib/installer.py` | The main `Installer` class that handles the `pacstrap` and `chroot` logic. | **Modify** | Needs modifications for Phase 5 (Post-Install Handoff) to ensure `mddos_config.json` and logs are safely copied to `/etc/mddos/`. |
| `archinstall/lib/command.py` | Wrapper for executing and logging shell commands (`SysCommand`). | **Keep** | Essential for our `cmd_history.txt` and `install.log` requirements. |
| `archinstall/lib/hardware.py` | Hardware detection (CPU microcode, Graphics cards). | **Keep** | Required for the automatic ucode injection and the NVIDIA driver warning fallback. |

### 3.2. User Interface (TUI & Menus)
| Component | Original Intent | Decision | Notes |
| :--- | :--- | :--- | :--- |
| `archinstall/tui/` | The curses framework building blocks (checkboxes, inputs, lists). | **Keep** | Core UI library. We will heavily reuse the checkbox list components. |
| `archinstall/lib/menu/global_menu.py` | The main menu the user sees. | **Modify** | Complete rewrite required (Phase 1) to implement the 7-step hierarchy (Locales, Disk, System, Auth, Profile, Advanced, Install). |
| `archinstall/lib/general/system_menu.py` | Handles kernel, audio, etc. | **Modify** | Strip old options, implement `systemd-boot` defaults, zram swap, and pacman checkboxes. |

### 3.3. Profiles & Applications (The "Bloat")
| Component | Original Intent | Decision | Notes |
| :--- | :--- | :--- | :--- |
| `archinstall/default_profiles/desktops/` | JSON configs for GNOME, KDE, XFCE, Sway, etc. | **Delete** | Nuke everything except a customized `hyprland.json` to enforce the Secure Barebones MVP. |
| `archinstall/default_profiles/servers/` | JSON configs for web servers, database servers. | **Delete** | Not relevant to a Hyprland desktop installer. |
| `archinstall/lib/profile/` | Logic for parsing and installing desktop profiles. | **Modify** | Hardcode the Hyprland lock and display the "More desktop environments will be given support later" tooltip. |
| `archinstall/applications/` | Helper scripts to install generic apps (like tailscale, docker, etc.). | **Delete** | The PRD explicitly defers "Additional packages" to the post-install wizard. This folder can be purged. |

### 3.4. System Configuration Modules
| Component | Original Intent | Decision | Notes |
| :--- | :--- | :--- | :--- |
| `archinstall/lib/disk/` | Disk partitioning, BTRFS, LUKS, formatting logic. | **Keep** | The PRD states disk configuration will be kept the same. Excellent, battle-tested code. |
| `archinstall/lib/bootloader/` | GRUB, systemd-boot, Limine logic. | **Modify** | Enforce `systemd-boot (quiet + plymouth)` as the default. Strip GRUB if deemed unnecessary for modern UEFI systems (optional, but recommended for simplicity). |
| `archinstall/lib/network/` | NetworkManager, iwd, systemd-networkd configurators. | **Keep / Modify** | Keep NetworkManager logic, ensure it defaults to NM instead of systemd-networkd as per PRD. |
| `archinstall/lib/authentication/` | Users, passwords, sudo, polkit setups. | **Modify** | Implement the `Lock root account` logic and dynamic UI disabling (Phase 3). |

### 3.5. Auxiliaries
| Component | Original Intent | Decision | Notes |
| :--- | :--- | :--- | :--- |
| `archinstall/locales/` | Language translations. | **Keep** | Internationalization is good, even if the default is English. |
| `archinstall/scripts/` | Standalone example scripts or test harnesses. | **Delete** | Mostly clutter for an opinionated fork. |

## 4. Scale and Reliability
*   **Scale:** Does not apply to a local installer script.
*   **Reliability:** By strictly limiting the Desktop Environments (Hyprland only) and Display Managers (greetd only), we drastically reduce the state-space of potential failures. The system is inherently more reliable than upstream `archinstall`.

## 5. Trade-off Analysis
*   **Trade-off 1 (Flexibility vs. Maintenance):** Deleting 90% of the `default_profiles/` and `applications/` severely limits user choice during the install phase. However, it guarantees a predictable baseline system for the post-install wizard, reducing developer maintenance burden by orders of magnitude.
*   **Trade-off 2 (Root Account Locking):** Defaulting to locking the root account prevents users from relying on legacy root logins. The trade-off is they *must* ensure their primary user has correct sudo/polkit permissions, which `archinstall` currently handles reasonably well but must be thoroughly tested.

## 6. Output & Revisit Strategy
*   As the system grows, we will need to revisit `archinstall/lib/profile/` to re-introduce other environments (Sway, KDE) once the base architecture proves stable.
*   The immediate next step is to begin systematically deleting the `Delete` components to clean the workspace, followed by refactoring the `global_menu.py`.