Added spezcific cline rules to the framework repo.

.clinerules/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.

.clinerules/project_nixos-infra_framework_directories

@@ -0,0 +1,16 @@
+# Project Rules: nixos-infra
+
+## Directories
+
+### Public framework repo (nixos-infra-framework)
+- `/nixos-infra-framework/modules/machine-types`: Nix modules standardizing different host types (hypervisor, VM, LXC, workstations, etc.).
+- `/nixos-infra-framework/modules/services`: Nix modules standardizing different network infrastructure services (DNS, git-forge, password-manager, reverse-proxy, etc.).
+- `/nixos-infra-framework/modules/user-profiles`: Nix modules standardizing different user profiles (admin, dev, office, etc.).
+- `/nixos-infra-framework/overlays`: Nix overlays (last resort).
+- `/nixos-infra-framework/pkgs`: Custom packages not present in Nixpkgs.
+- `/nixos-infra-framework/lib`: Nix utility functions.
+- `/nixos-infra-framework/scripts`: Generic operational scripts (deploy, create-lxc, etc.).
+- `/nixos-infra-framework/environments/sample`: Example environment for onboarding.
+
+The entry point for each machine is `environments/<env>/hosts/<servers|workstations>/<hostname>/configuration.nix`.
+Modules are imported via `fetchGit` from the framework repo.

.clinerules/project_nixos-infra_framework_goals

@@ -0,0 +1,12 @@
+# 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.
+This git repository contains the technical framework. It must not contain data/configuratin from actual
+environments.

.clinerules/project_nixos-infra_framework_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`.

.clinerules/project_nixos-infra_framework_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

.clinerules/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.

.clinerules/savings_rtk

@@ -0,0 +1,32 @@
+# RTK - Rust Token Killer (Cline)
+
+**Usage**: Token-optimized CLI proxy for shell commands.
+
+## Rule
+
+Always prefix shell commands with `rtk` to minimize token consumption.
+
+Examples:
+
+```bash
+rtk git status
+rtk cargo test
+rtk ls src/
+rtk grep "pattern" src/
+rtk find "*.rs" .
+rtk docker ps
+rtk gh pr list
+```
+
+## Meta Commands
+
+```bash
+rtk gain              # Show token savings
+rtk gain --history    # Command history with savings
+rtk discover          # Find missed RTK opportunities
+rtk proxy <cmd>       # Run raw (no filtering, for debugging)
+```
+
+## Why
+
+RTK filters and compresses command output before it reaches the LLM context, saving 60-90% tokens on common operations. Always use `rtk <cmd>` instead of raw commands.