Refreshed and refactored AI rules.

.ai-rules.md

@@ -1,67 +0,0 @@
-# Règles du Projet : nixos-infra
-
-## Contexte Technique
-**Stack :** NixOS 25.11, agenix, bash, SSH, Proxmox VE, LXC, KVM, IPv4, IPv6
-**Environnement :** VSCodium (VSCode) sur Debian 13 + extension Continue poru l'IA, bash, SSH, Gitea, IPv4, IPv6
-**Package Manager :** Nix
-**Style :** Privilégier la modularité, dans la philosophie Unix. Utilisation de bash pour les tâches d'exploitation, avec un fallback sur python si bash devient impossible à maintenir.
-**Tests :** Test Driven Development dans la mesure du possible.
-**Matériels :** ordinateurs de bureau X86-64, un vieux Dell T62°, un vieux Dell T330, un Rpi 3B
-
-## Conventions de Code
-**Nommage :** camelCase pour les variables, PascalCase pour les composants et types. Majuscules et "_" pour les variables d'environnement shell.
-**Types :** N/A
-**Imports :** N/A
-**Formatage :**
-- Utiliser exclusivement `alejandra` ou `nixfmt-rfc-style`. Ne jamais laisser de trailing whitespaces.
-- Préférer `inherit` pour les variables de même nom.
-- Utiliser `with lib;` ou `with builtins;` avec parcimonie à l'intérieur des fonctions, mais préférer les chemins explicites pour la clarté.
-- Toujours déclarer les arguments en début de fichier : `{ config, pkgs, lib, ... }:`.
-**Modularité :** Chaque service doit être encapsulé dans un module avec une option `enable` (ex: `services.mon-service.enable = true;`).
-
-## Architecture & Dossiers
-**Architecture :**
-Le but est de permettre le déploiement et la maintenance de services d'infrastructure réseau et applicatifs
-(DNS, serveur de dépôts git, gestionnaire de mots de passe, file server, backup server, reverse proxy,
-workstations, etc.). Le dépôt git contient l'ensemble des fichiers permettant de configurer et installer
-n'importe quelle machine du parc (images d'OS, fichiers de configuration et scripts de déploiemente et maintenance).
-En cible, reconstruire l'ensemble du parc doit être possible depuis une workstation Linux (pas forcément NixOS) sur lequel ce dépôt aura été cloné.
-
-**Dossiers :**
-- `/nixos-infra/hosts/servers` : Configurations spécifiques de chaque serveur (.nix, lxc.config).
-- `/nixos-infra/hosts/workstations` : Configurations spécifiques de chaque station de travail (.nix, lxc.config).
-- `/nixos-infra/modules/machine-types` : Modules Nix standardisant les différents types d'hotes (hyperviseur, VM, LXC, stations, etc.).
-- `/nixos-infra/modules/services` : Modules Nix standardisant les différents services d'infrastructure réseau (DNS, etc.).
-- `/nixos-infra/modules/user-profiles` : Modules Nix standardisant les différents profils d'utilisateurs (admin, dev, burautique, etc.).
-- `/nixos-infra/overlays` : Overlays Nix (dernier recours).
-- `/nixos-infra/pkgs` : Paquets personnalisés non présents dans Nixpkgs.
-- `/nixos-infra/lib` : Fonctions utilitaires Nix.
-- `/nixos-infra/scripts` : Scripts d'exploitation et de helpers.
-
-Le point d'entrée pour chaque machine est hosts/<servers|workstations>/\<hostname>/configuration.nix.
-
-## Gestion des Secrets
-**Interdiction Formelle :** Ne JAMAIS écrire de mot de passe, clé d'API ou token en clair dans les fichiers `.nix`.
-**Outil :** Utiliser **agenix**.
-
-## Instructions NixOS
-1. Ne pas utiliser les flakes Nix.
-2. Toujours vérifier si une option (https://search.nixos.org/options), un paquetage (https://search.nixos.org/packages) ou une fonction (https://noogle.dev/) avant de l'inventer.
-3. Ne pas supposer que la workstation utilisée est elle-même sous NixOS. L'environnement de développement est sous Debian Trixie jusqu'à ce que le projet soit complètement auto-porteur. Néanmoins, le paquetage "nix-bin" est installé pour disposer des binaires de Nix.
-4. Utiliser nix-isntantiate pour vérifier la syntaxe et l'évaluation des fichiers Nix:
-```
-nix-instantiate --parse chemin/vers/fichier.nix # Vérifie la syntaxe
-nix-instantiate --eval -E 'import ./hosts/machine/configuration.nix {}' # Vérifie l'évaluation
-```
-
-## Instructions Spécifiques (Guidelines)
-1. Ne **jamais** exposer de mot de passe, de clef API ou tout secret en clair. Utiliser les mécanismes de gestion/protection de secrets appropriés au contexte.
-2. Privilégier les clefs SSH pour l'authentification aux systèmes.
-3. Limiter les longueurs des lignes à 78 caractères imprimables.
-4. Signaler les éventuelles incohérences de pratiques au sein du projet ou avec les bonnes pratiques.
-
-## Préférences de Réponses
-- Langue : Français. Le code, les commentaires et la documentation restent en Anglais.
-- Style : Technique, concis, orienté "Infrastructure as Code".
-- Toujours expliquer brièvement *pourquoi* une option NixOS spécifique a été choisie (référence aux options officielles).
-- Me signaler si et quand il aura été difficile ou impossible de respecter les instructions fournies dans .ai-rules.md .

.clinerules2/coding_nix

@@ -0,0 +1,32 @@
+## Nix
+
+## General Instructions
+1. Do not use Nix flakes.
+2. Always check if an option (https://search.nixos.org/options), a package (https://search.nixos.org/packages) or a function (https://noogle.dev/) exists before inventing one.
+3. Do not assume the development or administration workstations themselves run NixOS. The development environment is more likely Debian Trixie.
+4. Use `nix-instantiate` to verify syntax and evaluation of Nix files:
+```
+nix-instantiate --parse path/to/file.nix # Check syntax
+nix-instantiate --eval -E 'import ./hosts/machine/configuration.nix {}' # Check evaluation
+```
+
+## Code Conventions
+**Naming:** camelCase for variables, PascalCase for components and types. UPPER_CASE and "_" for shell environment variables.
+**Types:** N/A
+**Imports:** N/A
+**Formatting:**
+- Use exclusively `alejandra` or `nixfmt-rfc-style`. Never leave trailing whitespace.
+- Prefer `inherit` for same-name variables.
+- Use `with lib;` or `with builtins;` sparingly inside functions, but prefer explicit paths for clarity.
+- Always declare arguments at the beginning of the file: `{ config, pkgs, lib, ... }:`.
+**Modularity:** Each service must be encapsulated in a module with an `enable` option (e.g., `services.mon-service.enable = true;`).
+
+## Secret Management
+**Strict Prohibition:** NEVER write passwords, API keys, or tokens in plaintext in `.nix` files.
+**Tool:** Use **agenix**.
+
+## Specific Guidelines
+1. **Never** expose passwords, API keys, or any secrets in plaintext. Use appropriate secret management/protection mechanisms for the context.
+2. Prefer SSH keys for system authentication.
+3. Limit line lengths to 78 printable characters.
+4. Report any inconsistencies in practices within the project or with best practices.

.clinerules2/project_nixos-infra_directories

@@ -0,0 +1,14 @@
+# Project Rules: nixos-infra
+
+## Directories
+- `/nixos-infra/hosts/servers`: Server-specific configurations (.nix, lxc.config).
+- `/nixos-infra/hosts/workstations`: Workstation-specific configurations (.nix, lxc.config).
+- `/nixos-infra/modules/machine-types`: Nix modules standardizing different host types (hypervisor, VM, LXC, workstations, etc.).
+- `/nixos-infra/modules/services`: Nix modules standardizing different network infrastructure services (DNS, etc.).
+- `/nixos-infra/modules/user-profiles`: Nix modules standardizing different user profiles (admin, dev, office, etc.).
+- `/nixos-infra/overlays`: Nix overlays (last resort).
+- `/nixos-infra/pkgs`: Custom packages not present in Nixpkgs.
+- `/nixos-infra/lib`: Nix utility functions.
+- `/nixos-infra/scripts`: Operational and helper scripts.
+
+The entry point for each machine is `hosts/<servers|workstations>/<hostname>/configuration.nix`.

.clinerules2/project_nixos-infra_goals

@@ -0,0 +1,10 @@
+# Project Rules: nixos-infra
+
+## Goals
+
+The goal is to enable the deployment and maintenance of network infrastructure and application services
+(DNS, git repository server, password manager, file server, backup server, reverse proxy,
+workstations, etc.). The git repository contains all files needed to configure and install
+any machine in the fleet (OS images, configuration files, deployment and maintenance scripts).
+The target is to be able to rebuild the entire fleet from a Linux workstation (not necessarily NixOS)
+where this repository has been cloned.

.clinerules2/project_nixos-infra_response_preferences

@@ -0,0 +1,7 @@
+# Project Rules: nixos-infra
+
+## Response Preferences
+- Language: English
+- Style: Technical, concise, Infrastructure as Code oriented.
+- Always briefly explain *why* a specific NixOS option was chosen (reference to official options).
+- Notify me if and when it was difficult or impossible to follow the instructions provided in `.ai-rules.md`.

.clinerules2/project_nixos-infra_tech_context

@@ -0,0 +1,9 @@
+# Project Rules: nixos-infra
+
+## Technical Context
+**Stack:** NixOS 25.11, agenix, bash, SSH, Proxmox VE, LXC, KVM, IPv4, IPv6
+**Environment:** VSCodium (VSCode) on Debian 13 + Cline extension for AI, bash, SSH, Gitea, IPv4, IPv6
+**Package Manager:** Nix
+**Style:** Favor modularity, in the Unix philosophy. Use bash for operational tasks, with a fallback to Python if bash becomes unmaintainable.
+**Tests:** Test Driven Development whenever possible.
+**Hardware:** X86-64 desktop computers, an old Dell T620, an old Dell T330, a Rpi 3B

.clinerules2/role_product_manager

@@ -0,0 +1,35 @@
+# Role
+You are an exceptional product manager with 20 years of experience and an engineer proficient in all programming languages, skilled in assisting junior developers.
+
+# Goal
+Help users complete their product design and development tasks in an easily understandable way, proactively completing all tasks without waiting for repeated prompting.
+
+## Step 1: Project Initialization
+- When a user makes a request, first review the readme.md file and all code documents in the root directory to understand the project's goals, architecture, and implementation methods. If a readme file doesn't exist, create one. 
+- This file will serve as a manual for users to understand all provided functions and your project plan. 
+- Clearly describe the purpose, usage, parameter descriptions, and return value descriptions of all functions in the readme.md file to ensure user-friendly understanding and usage.
+
+## Step 2: Task Understanding and Execution
+### Understanding User Needs
+- Fully understand user needs from their perspective. Consider: "If I were the user, what would I need?"
+- As a product manager, identify any gaps in user needs. Discuss and refine requirements with users until satisfaction is achieved.
+- Prioritize the simplest solutions to meet user needs, avoiding overly complex or advanced approaches.
+
+### Code Development
+- Plan step-by-step, considering user needs and existing codebase.
+- Choose appropriate programming languages and frameworks to implement user requirements. 
+- Design code structure based on SOLID principles and use design patterns to address common problems.
+- Write comprehensive comments for all code modules and include necessary monitoring to track errors.
+- Opt for simple, controllable solutions over complex ones.
+
+### Problem Solving
+- Thoroughly read the entire code file library to understand all code functions and logic.
+- Analyze the root causes of user-reported code errors and propose solutions.
+- Engage in multiple interactions with users, summarizing previous interactions and adjusting solutions based on feedback until user satisfaction.
+- Initiate "System 2 Thinking Mode" for persistent bugs:
+  1. Systematically analyze potential root causes and list all hypotheses.
+  2. Design verification methods for each hypothesis.
+  3. Provide three distinct solutions, detailing pros and cons for user choice.
+
+## Step 3: Project Summary and Optimization
+- After completing the user's task, reflect on the task completion process, identify potential issues and improvements, and update the readme.md file accordingly.

nixos-infra/scripts/create-lxc-nixos.sh

@@ -18,7 +18,7 @@ Usage:
 
 Options:
   -h, --help                    Show this message.
-  -t, --template TEMPLATE        LXC template (e.g. local:vztmpl/nixos-unstable).
+  -t, --template TEMPLATE       LXC template (e.g. local:vztmpl/nixos-unstable).
   -r, --rootfs-size SIZE        Root filesystem size (e.g. 8G).
   -c, --cores CORES             Number of CPU cores.
   -m, --memory MEMORY           RAM in MiB.