chore: replace legacy repo state docs with project memory

.continue/rules/global-file-standard.md

@@ -1,14 +0,0 @@
----
-alwaysApply: true
----
-
-Apply consistent coding standards, preserve existing project conventions, and avoid introducing breaking changes in all files unless explicitly requested.
-
-Also read and consider the repository state file when it exists:
-- `STATE.md`
-
-When this file is present:
-- use it as evolving project context,
-- keep recommendations aligned with it,
-- update suggestions to remain consistent with documented architecture, constraints, and review notes,
-- update `STATE.md` as part of the same task whenever changes materially affect repository behavior, architecture, constraints, or review notes.

.memory/project.md

@@ -0,0 +1,30 @@
+# Project memory
+
+- Repo: `netupgrade`
+- Language: Bash
+- Entry point: `bin/netupgrade`
+- Purpose: interactive SSH-based maintenance/upgrade CLI
+
+## Rules
+- Keep it lightweight and shell-based
+- Preserve backward compatibility when possible
+- Treat config files as trusted shell input
+- Be careful with SSH quoting and remote command construction
+- Prefer small, reviewable changes
+- Keep docs aligned with runtime behavior
+- Avoid introducing `set -euo pipefail` without validating failure semantics
+
+## Current behavior
+- Loads configs from `~/.config/netupgrade/*.cfg`
+- Uses `NODES` entries: `host;display-name;action1;action2;...`
+- Runs selected actions sequentially over SSH
+- Defaults to `root@host`, or `SSH_USER@host`
+- Logs to `~/netupgrade.log`
+- Opens the log with `$EDITOR`, then `nano`, `vi`, or `less`
+
+## Sensitive areas
+- SSH quoting
+- `cmd:<...>` execution
+- `docker-stacks:<...>` handling
+- package-manager cleanup behavior
+- error propagation

STATE.md

@@ -1,84 +0,0 @@
-# Repository state
-
-## Project summary
-- Name: `netupgrade`
-- Language: Bash
-- Entry point: `bin/netupgrade`
-- Purpose: interactive CLI to run maintenance and upgrade actions on multiple remote hosts over SSH
-- Config model: Bash configuration files sourced from `~/.config/netupgrade/*.cfg`
-
-## Repository structure
-- `bin/netupgrade`: main executable script containing CLI parsing, node selection, remote execution, and logging
-- `config/netupgrade/*.cfg`: sample configuration files defining host groups and action sequences
-- `README.md`: installation and usage documentation
-- `TODO.md`: prioritized next actions and follow-up work
-
-## Current behavior
-- Loads a Bash configuration file
-- Expects a `NODES` array with entries formatted as `host;display-name;action1;action2;...`
-- Displays an interactive multi-select checklist using `whiptail`
-- Executes selected actions sequentially over SSH
-- Uses `root@host` by default, or `SSH_USER@host` when configured
-- Writes execution logs to `~/netupgrade.log`
-- Opens the log with `$EDITOR`, then `nano`, `vi`, or `less`; if none is available, prints the log path and continues with the existing optional cleanup prompt
-
-## Supported actions
-- `apt`
-- `yum`
-- `dnf`
-- `pkg`
-- `pacman`
-- `apk`
-- `reboot`
-- `cmd:<remote command>`
-- `docker-stacks:<directory>`
-
-## Architecture and constraints
-- The project is intentionally lightweight and shell-based
-- The main execution flow still lives mostly in a single Bash script
-- Configuration is code-driven rather than declarative, because config files are sourced as shell files
-- Config files are trusted inputs and imply arbitrary code execution
-- Remote operations are sequential, not parallel
-- Logging is file-based and tightly coupled to command execution
-- Backward compatibility for existing config files should be preserved where possible
-- Changes to SSH command construction require extra care because quoting regressions are easy to introduce
-
-## Notable implementation details
-- SSH execution is centralized through a `runSSH` helper
-- `SSH_USER` is configurable and defaults to `root`
-- `NODES` parsing was hardened to preserve spaces in action values such as `cmd:...`
-- `cmd:<...>` is executed through a remote shell to support shell operators, but remains intentionally powerful and unsafe
-- `reboot` now uses a direct SSH `reboot` invocation to keep the remote reboot path simple and predictable
-- `docker-stacks` runs through a remote shell script sent over SSH stdin to improve path handling and quoting
-- Startup dependency checks cover required local commands, including `mv` for log-summary rewriting
-
-## Sensitive areas for future changes
-- SSH command construction and shell quoting behavior
-- `cmd:<...>` execution semantics
-- `docker-stacks:<...>` path handling and remote shell behavior
-- Package-manager cleanup commands and confirmation flags
-- Error propagation consistency across action types
-- Documentation and runtime behavior alignment
-- Sample configuration accuracy to avoid operator mistakes
-
-## Recent meaningful changes
-- README and CLI help were aligned with current behavior, including the meaning of `-f`
-- Startup dependency checks were added and updated
-- Log viewer fallback was made more flexible
-- `NODES` parsing was hardened to preserve spaces in action values
-- SSH execution was centralized and made configurable through `SSH_USER`
-- Remote command construction was improved for `pacman` and `docker-stacks`; `reboot` was simplified to a direct SSH command
-- Log summary generation was rewritten to avoid `sed -i` interpolation and now replaces the log atomically
-- `apk` and `apt` cleanup behavior was corrected to better match real package-manager semantics
-- The sample configuration in `config/netupgrade/hypervisor-01.cfg` now keeps the alternate `docker-01` reboot example commented out rather than active by default
-- A new `dnf` action was added alongside the existing `yum` action to support newer RPM-based systems without breaking existing configurations
-
-## Change guidance
-- `STATE.md` should stay focused on current state, architecture, and constraints
-- `TODO.md` should hold prioritized follow-up work and next implementation steps
-- Prefer small, reviewable hardening changes over broad rewrites
-- Keep the tool simple and admin-friendly
-- Treat documentation consistency as part of functional correctness
-- Be cautious with remote command construction, because quoting changes can easily introduce regressions
-- Avoid introducing a global `set -euo pipefail` baseline in one step without first documenting and validating the intended failure semantics
-- Focus future testing first on parsing, command construction, and result reporting

TODO.md

@@ -1,33 +0,0 @@
-# TODO
-
-## Priorité haute
-
-### 1. Sécuriser les zones sensibles de construction de commandes SSH
-- Revoir les zones de quoting encore fragiles
-- Prioriser `cmd:<...>` et `docker-stacks:<...>`
-- Réduire le risque de régressions lors des prochains durcissements
-
-## Priorité moyenne
-
-### 1. Ajouter un minimum de validation et de qualité shell
-- Ajouter de la guidance ShellCheck dans le projet
-- Envisager `shfmt` si cela reste léger
-- Ajouter des vérifications simples autour des fichiers de configuration sourcés
-- Rester incrémental, sans imposer brutalement un strict mode global
-
-### 2. Réduire progressivement la complexité du script principal
-- Extraire des helpers quand cela réduit la duplication sans casser le comportement
-- Simplifier les branches liées aux package managers
-- Garder des changements petits et relisibles
-
-## Priorité basse
-
-### 1. Réfléchir à une configuration plus sûre si le projet grossit
-- Le sourcing Bash reste acceptable tant que le modèle est assumé
-- Si le projet s'étend, envisager à terme un format déclaratif plus sûr
-
-## Rappels de conduite
-- Préserver la compatibilité des fichiers de configuration existants autant que possible
-- Préférer de petits commits logiques
-- Traiter la cohérence documentation/comportement comme un sujet fonctionnel
-- Être particulièrement prudent sur toute modification du quoting ou des commandes distantes