@wistantkode/dotfiles 1.7.0 → 1.7.2

package/data/github.sh

@@ -0,0 +1,174 @@
+#!/bin/bash
+
+# ═══════════════════════════════════════════════════════════════════════
+#   GITHUB SYNC  ·  Integrity Gate  ·  @wistantkode/dotfiles
+# ════════════════════════════════════════───────────────────────════════
+
+# ── Color palette (Minimalist 256-color) ──────────────────────────────
+RESET='\033[0m';    BOLD='\033[1m';     DIM='\033[2m'
+WHITE='\033[38;5;255m';  GRAY='\033[38;5;244m';   DGRAY='\033[38;5;238m'
+RED='\033[38;5;203m';    GREEN='\033[38;5;114m';  YELLOW='\033[38;5;221m'
+BLUE='\033[38;5;75m';    CYAN='\033[38;5;117m'
+
+# ── Table dimensions ──────────────────────────────────────────────────
+HASH_W=8    # hash column display width
+MSG_W=52    # message column display width
+
+# ── Layout helpers ────────────────────────────────────────────────────
+_rep() { printf "%${1}s" | tr ' ' "${2}"; }
+_sep()  { echo -e "${DGRAY}$(_rep 66 '─')${RESET}"; }
+
+_logo() {
+    echo -e "\n  ${WHITE}██████╗ ██╗████████╗██╗  ██╗██╗   ██╗██████╗ "
+    echo -e "  ${WHITE}██╔════╝ ██║╚══██╔══╝██║  ██║██║   ██║██╔══██╗"
+    echo -e "  ${WHITE}██║  ███╗██║   ██║   ███████║██║   ██║██████╔╝"
+    echo -e "  ${WHITE}██║   ██║██║   ██║   ██╔══██║██║   ██║██╔══██╗"
+    echo -e "  ${WHITE}╚██████╔╝██║   ██║   ██║  ██║╚██████╔╝██████╔╝"
+    echo -e "  ${WHITE} ╚═════╝ ╚═╝   ╚═╝   ╚═╝  ╚═╝ ╚═════╝ ╚═════╝ ${RESET}"
+    echo -e "\n  ${GRAY}${BOLD}[ GITHUB AUTOMATION SYNC ]${RESET}\n"
+}
+
+_header() {
+    printf "  ${BOLD}${GRAY}%-${HASH_W}s   %-${MSG_W}s${RESET}\n" "HASH" "COMMIT MESSAGE"
+    _sep
+}
+
+_row() {
+    local hash msg
+    hash=$(printf "%-${HASH_W}s" "${1:0:$HASH_W}")
+    local raw="$2"
+    [ ${#raw} -gt $((MSG_W-1)) ] && raw="${raw:0:$((MSG_W-3))}..."
+    msg=$(printf "%-${MSG_W}s" "$raw")
+    printf "  ${BLUE}%s${RESET}   ${WHITE}%s${RESET}\n" "$hash" "$msg"
+}
+
+_progress() {
+    local label="$1"
+    printf "  ${GRAY}%-28s ${RESET}" "$label"
+    for ((i=1; i<=20; i++)); do
+        printf "${WHITE}·${RESET}"
+        sleep 0.015
+    done
+    printf " ${GREEN}✔${RESET}\n"
+}
+
+# ── Core utilities ────────────────────────────────────────────────────
+abort() {
+    echo ""
+    _sep
+    echo -e "  ${RED}${BOLD}✗  ABORTED${RESET}  ${GRAY}$1${RESET}"
+    _sep
+    echo ""
+    exit 1
+}
+
+ask() {
+    echo -ne "\n  ${WHITE}${BOLD}?${RESET}  $1 ${GRAY}(y/N)${RESET}  "
+    read -r _r
+    [[ "$_r" =~ ^([yY][eE][sS]|[yY])$ ]]
+}
+
+# ── Phase 0 · Silent data collection ─────────────────────────────────
+CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null) \
+    || { echo -e "\n  ${RED}✗${RESET}  Not a git repository."; exit 1; }
+
+REMOTE="origin/${CURRENT_BRANCH}"
+COMMITS_RAW=$(git log "${REMOTE}..HEAD" --oneline 2>/dev/null)
+COMMIT_COUNT=0
+[ -n "$COMMITS_RAW" ] && COMMIT_COUNT=$(echo "$COMMITS_RAW" | wc -l | tr -d ' ')
+
+LOCAL_ONLY_TAGS=$(
+    git log --tags --simplify-by-decoration --pretty="format:%D" 2>/dev/null \
+    | grep "tag: " \
+    | sed 's/.*tag: \([^,)]*\).*/\1/' \
+    | while read -r t; do
+        git ls-remote --tags origin 2>/dev/null | grep -q "refs/tags/$t" || echo "$t"
+    done | sort -u
+)
+TAG_COUNT=0
+[ -n "$LOCAL_ONLY_TAGS" ] && TAG_COUNT=$(echo "$LOCAL_ONLY_TAGS" | grep -c .)
+PUSH_TAGS=""
+[ "$TAG_COUNT" -gt 0 ] && PUSH_TAGS="--follow-tags"
+
+case "$CURRENT_BRANCH" in
+    main|master) BLABEL="${RED}${BOLD}⬡  PRODUCTION${RESET}" ;;
+    *)           BLABEL="${GRAY}◈  BRANCH${RESET}" ;;
+esac
+
+# ── Phase 1 · Working tree check ─────────────────────────────────────
+clear
+_logo
+_sep
+echo ""
+echo -e "  ${WHITE}${BOLD}◆  INTEGRITY GATE${RESET}  ${DGRAY}·  Software Engineer${RESET}"
+echo ""
+
+if ! git diff-index --quiet HEAD -- 2>/dev/null; then
+    echo ""
+    echo -e "  ${YELLOW}${BOLD}⚠  DIRTY WORKING TREE${RESET}"
+    echo ""
+    git status -s | sed 's/^/     /'
+    abort "Stage and commit all changes before syncing."
+fi
+
+# ── Phase 2 · Summary panel ───────────────────────────────────────────
+printf "  ${GRAY}%-12s${RESET}  ${WHITE}${BOLD}%s${RESET}  %b\n"    "Branch"   "$CURRENT_BRANCH" "$BLABEL"
+printf "  ${GRAY}%-12s${RESET}  ${WHITE}%s${RESET} commit(s) ahead\n" "Ahead"  "$COMMIT_COUNT"
+printf "  ${GRAY}%-12s${RESET}  ${WHITE}%s${RESET} to publish\n"      "Tags"   "$TAG_COUNT"
+echo ""
+_sep
+
+# Commits table
+if [ "$COMMIT_COUNT" -gt 0 ]; then
+    echo ""
+    _header
+    while IFS= read -r line; do
+        h=$(echo "$line" | awk '{print $1}')
+        m=$(echo "$line" | cut -d' ' -f2-)
+        _row "$h" "$m"
+    done <<< "$COMMITS_RAW"
+    _sep
+fi
+
+# Tags list
+if [ "$TAG_COUNT" -gt 0 ]; then
+    echo ""
+    echo -e "  ${GRAY}Unpublished tags:${RESET}"
+    while IFS= read -r tag; do
+        echo -e "    ${GREEN}✔${RESET}  ${WHITE}${BOLD}$tag${RESET}"
+    done <<< "$LOCAL_ONLY_TAGS"
+    _sep
+fi
+
+# ── Phase 3 · Final confirmation ──────────────────────────────────────
+echo ""
+SUMMARY="${WHITE}${BOLD}${COMMIT_COUNT}${RESET} commit(s)"
+[ "$TAG_COUNT" -gt 0 ] && SUMMARY+=" ${DGRAY}+${RESET} ${WHITE}${BOLD}${TAG_COUNT}${RESET} tag(s)"
+printf "  ${GRAY}%-12s${RESET}  %b\n" "Will push"  "$SUMMARY"
+printf "  ${GRAY}%-12s${RESET}  ${BLUE}%s${RESET}\n" "Target" "$REMOTE"
+echo ""
+
+ask "Confirm push to remote?" || abort "Gate: push cancelled."
+
+# ── Phase 4 · Projection ──────────────────────────────────────────────
+echo ""
+_sep
+echo ""
+_progress "Initializing sync"
+_progress "Verifying state"
+_progress "Final handoff"
+echo ""
+
+if git push --quiet $PUSH_TAGS; then
+    echo ""
+    _sep
+    echo ""
+    echo -e "  ${GREEN}${BOLD}✔  SUCCESS${RESET}  Infrastructure synchronized."
+    echo ""
+    _sep
+else
+    echo ""
+    abort "Git push failed. Check connectivity."
+fi
+
+echo ""

package/{gitignore → data/gitignore}

@@ -106,6 +106,7 @@ next-env.d.ts
 !PULL_REQUEST_TEMPLATE.md
 !AGENTS.md
 !CLAUDE.md
+!CHANGELOG.md
 
 # additionnals
 .protocols/

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wistantkode/dotfiles",
-  "version": "1.7.0",
+  "version": "1.7.2",
   "description": "High-End Linux Infrastructure & AI-Driven Orchestration Protocols",
   "main": "index.js",
   "type": "module",

package/protocols/ASSIST.md

@@ -1,66 +0,0 @@
-# MASTER OPERATING PROTOCOL (ASSIST.md)
-
-1. **`RODIN.md`** : Engineering Philosophy (Socratic Audit, Anti-compliancy).
-2. **`ASSIST.md`** : Operational System (Technical role, methodology).
-3. **`_INDEX.md`** : Navigation map.
-
----
-
-## ROLE DEFINITION
-
-You are a **Technical Assistant & Engineering Partner**. You facilitate excellence and ensure architectural integrity.
-
-- **Communication First** : Tu réponds toujours aux questions posées **AVANT** de commencer à coder. La communication prime sur l'exécution.
-- **Integrity Guard** : Si une solution sous-optimale est proposée, challenge-la (`RODIN.md`).
-- **Architect** : Quand tu produis du code ou de la config, applique les standards professionnels sans prendre d'initiatives non validées sur le périmètre.
-- **Context-Aware** : Adapt your methodology to the project type (library, monorepo, CLI, web app).
-
----
-
-## OPERATIONAL MODES
-
-### Systems & Backend
-
-*Target: Any backend stack (NestJS, Express, FastAPI, Go, etc.), databases, CI/CD, infrastructure.*
-
-- **Action**: Document architecture and data flows. Enforce atomicity and zero-trust.
-- **Communication**: Educational. Always ask a verification question before any major mutation.
-
-### Frontend & UI
-
-*Target: Any frontend stack (React, Vue, Svelte, etc.) and design systems.*
-
-- **Action**: Enforce high visual quality and clean implementation patterns.
-- **Communication**: Concise, focused on rendering, accessibility, and UX coherence.
-
-### DevOps & Tooling
-
-*Target: Docker, GitHub Actions, shell scripts, environment configuration.*
-
-- **Action**: Validate security, idempotency, and reliability of automation scripts.
-- **Communication**: Step-by-step. Surface side effects before execution.
-
----
-
-## METHODOLOGY (THE CYCLE)
-
-1. **Ecosystem Audit** : Identify package manager, stack, and architecture.
-2. **Protocol Sync** : Read the corresponding protocol via `_INDEX.md`.
-3. **The Socratic Test** : Reformulate the request and challenge it if it lacks depth or clarity.
-4. **Surgical Execution** : Provide complete, typed, and optimized code.
-5. **Git Sealing** : Generate atomic commits according to `COMMIT.md`.
-
----
-
-## REFERENCE CONVENTIONS
-
-| Topic | Protocol |
-| :--- | :--- |
-| **Identity & Philosophy** | [RODIN.md](./RODIN.md) |
-| **Commits** | [COMMIT.md](./COMMIT.md) |
-| **Release** | [RELEASE.md](./RELEASE.md) |
-| **Security** | [SECURITY.md](./SECURITY.md) |
-| **Initialization** | [INIT.md](./INIT.md) |
-| **Refactoring** | [REFACTOR.md](./REFACTOR.md) |
-| **Testing** | [TEST.md](./TEST.md) |
-| **Dotfiles Architecture** | [DOTFILES.md](./DOTFILES.md) |

package/protocols/COMMIT.md

@@ -1,90 +0,0 @@
-# CONVENTION DE COMMITS ATOMIQUES
-
-> [!IMPORTANT]
-> **Activation de l'Agent :**
-> Des que l'utilisateur entame une phase de commit, tu actives le **Rodin Audit**. Ta mission est de refuser tout commit "fourre-tout". Tu dois forcer la decomposition des changements en intentions logiques isolees.
-
----
-
-### Règle d'Or 1 : Zéro "git add ."
-
-Il est **STRICTEMENT INTERDIT** d'utiliser `git add .` ou `git commit -a`.
-Chaque modification doit être atomique. On ne mélange pas la logique métier (`core/`) et le style (`ui/`).
-
-### Règle d'Or 2 : Isolation des Commits (STRICTE)
-
-L'IA ne doit **JAMAIS** modifier ou inclure les fichiers de release (`package.json`, `CHANGELOG.md`, `pom.xml`, etc.) ni manipuler les `git tags` lors d'une phase de commit classique. Toute interaction avec le versioning est réservée **EXCLUSIVEMENT** au protocole `RELEASE.md`.
-
-### Règle d'Or 3 : Zéro Initiative de Versioning
-
-Si l'utilisateur demande un commit, fais uniquement le commit du code demandé. Ne propose pas de bump de version ou de mise à jour du changelog de ton propre chef. Ne prends aucune décision sur le périmètre de la tâche sans validation préalable.
-
----
-
-## METHODOLOGIE : LE CYCLE ATOMIQUE
-
-### PHASE 1 : L'AUDIT D'INTENTION (Silent)
-
-1. **Status Check** : Examine `git status` et `git diff`.
-2. **Identification des Motifs** : Pourquoi as-tu fait ces changements ?
-3. **Partitionnement** : Separe les changements techniques (refactor, deps) des changements fonctionnels (feat, fix).
-
-### PHASE 2 : L'INTERROGATION SOCRATIQUE
-
-Si l'utilisateur semble vouloir tout commiter d'un coup, pose la question :
-> *"Je vois des changements sur [Fichier A] et [Fichier B]. Sont-ils lies par une seule intention logique, ou devons-nous les separer en deux commits distincts pour preserver l'historique ?"*
-
-### PHASE 3 : GROUPEMENT & STAGING CIBLE
-
-1. **Selection** : Ajoute uniquement les fichiers lies au motif n°1.
-2. **Commande** : `git add [fichiers specifiques]`.
-3. **Verification** : Effectue un `git status` pour valider que seule l'intention n°1 est dans le buffer.
-
----
-
-## Format du Message
-
-Chaque commit doit suivre strictement ce format :
-
-```text
-<type>(scope): <sujet>
-
-[Corps explicite mais concis — réservé aux changements d'ampleur moyenne ou majeure]
-
-[Footer]
-```
-
-### 1. Types Autorises
-
-- `feat`: Nouvelle fonctionnalite (ajoute de la valeur utilisateur).
-- `fix`: Correction de bug (repare quelque chose de casse).
-- `ui`: Changement purement visuel (CSS, style, assets) sans impact logique.
-- `refactor`: Reecriture de code (ni fix ni feat, ex: nettoyage, simplification).
-- `perf`: Amelioration des performances.
-- `docs`: Documentation uniquement.
-- `test`: Ajout ou modification de tests.
-- `chore`: Maintenance, build, dependances (pas de code de prod).
-- `style`: Formatage, espaces manquants (pas de changement de logique).
-
-### 2. Scope (Portee)
-
-Le fichier ou module impacte. Exemples : `(auth)`, `(ui)`, `(deps)`, `(api)`, `(hooks)`.
-
-### 3. Sujet
-
-- Imperatif present ("add" et non "added").
-- Pas de majuscule au debut.
-- Pas de point a la fin.
-- Clair et concis.
-
-### Exemples de Bons Commits
-
-- feat(hooks): add use-media-query for responsive logic
-- fix(ui): resolve typescript error in 3d-card component
-- chore(deps): upgrade prisma to v7
-
-### Exemples a BANNIR
-
-- fix bugs (Trop vague)
-- wip (Interdit sur main/dev)
-- update files (Ne veut rien dire)

package/protocols/DOTFILES.md

@@ -1,29 +0,0 @@
-# DOTFILES ARCHITECTURE (DOTFILES.md)
-
-This repository contains a modular environment setup designed for high-end engineering.
-
-## COMMANDS & ALIASES
-
-- **`ia`** (Integrity Assist) : `cat protocols/ASSIST.md`
-- **`is`** (Integrity Status) : `cat protocols/_INDEX.md`
-
-### 2. Git Automation
-
-- **Smart Sync** : Interactive gatekeeper script (`github.sh`) to manage branches, tags, and remote projection.
-
----
-
-## DESIGN PRINCIPLES
-
-The interface is designed for focus and structural clarity.
-
-- **Prompt** : Starship. Minimalist indicator for the repository state.
-- **Multiplexeur** : Zellij. Layouts that prioritize documentation alongside code.
-- **Typography** : JetBrains Mono (optimized for code readability).
-
----
-
-## SHELL HOOKS
-
-Every directory change triggers a check for local protocols.
-See `aliases.zsh` for the `chpwd` function logic.

package/protocols/INIT.md

@@ -1,37 +0,0 @@
-# PROTOCOLE D'INITIALISATION (CLEAN START)
-
-> [!IMPORTANT]
-> **Agent Activation:**
-> Whenever a new project is initialized or cloned, activate the **Calibration Audit**. Your mission is to lock down the environment before any code mutation. A failed step must immediately suspend all operations.
-
----
-
-## PHASE 1 : IDENTITÉ & CONFIGURATION GIT
-
-1. **Vérification d'Identité** :
-   - `git config user.name` (Doit être configuré).
-   - `git config user.email` (Précision attendue).
-2. **Standard de Projet** :
-   - `git config core.ignorecase false` (Strict pour la cohérence inter-OS).
-
----
-
-## PHASE 2 : SETUP DE L'ENVIRONNEMENT (ECO-SYSTEM)
-
-Audit des fondations :
-
-- **Variables** : Presence de `.env.example` et validation du `.env` local.
-- **Runtimes** : Validation des versions (Node.js, Bun) via `.nvmrc` ou `package.json`.
-- **Managers** : Détection du gestionnaire privilégié (`pnpm` prio ou `bun`).
-
----
-
-## PHASE 3 : CALIBRAGE DES OUTILS (TOOLSET)
-
-1. **Tooling Check** : Confirm Linting & Formatting are configured (Prettier, ESLint, or project equivalent).
-2. **IDE Sync** : Verify recommended IDE configuration is present (e.g., `.vscode/extensions.json`).
-
----
-
-> [!CAUTION]
-> A poorly initialized environment is the primary cause of regression. Operate surgically.

package/protocols/PR.md

@@ -1,50 +0,0 @@
-# UNIVERSAL PULL REQUEST PROTOCOL (AI-SYNC)
-
-> [!IMPORTANT]
-> **Activation de l'Agent :**
-> Lors de la preparation d'une PR, tu deviens le **Gatekeeper Architectural**. Tu dois vérifier que le code local est parfaitement synchronise avec le distant et que les protocoles amont (`COMMIT.md`, `SECURITY.md`) ont ete respectes scrupuleusement.
-
----
-
-## Etape 1 : Validation Atomique & Synchronisation (CRITICAL)
-
-Des que l'utilisateur demande une PR, l'IA **DOIT** executer cette sequence dans l'ordre :
-
-0. **Audit des Commits** :
-   - Vérifier que les modifications (git diff/status) ont bien ete decoupees selon le protocole `protocols/COMMIT.md` (aucun `git add .` global).
-1. **Verification Distante** :
-   - `git fetch origin`
-   - `git log HEAD..origin/dev` : Alerte si des commits distants manquent.
-2. **Analyse Differentielle** :
-   - `git log origin/dev..HEAD --oneline`
-   - `git diff --stat origin/dev..HEAD`
-3. **Audit des Protocols** :
-   - Vérifier que la securite respecte `protocols/SECURITY.md`.
-
----
-
-## Etape 2 : Generation Automatique du Rapport
-
-Une fois la synchronisation validee, l'IA doit generer de facon autonome un fichier d'audit listant les travaux :
-
-- **Location** : Le fichier doit etre cree sous `zothers/PR[Numero].md` (incrementer le numero par rapport a l'existant).
-- **Langue** : STRICTEMENT EN ANGLAIS. Meme si la conversation se deroule en francais, le fichier PR doit etre redige en anglais professionnel.
-
----
-
-## Etape 3 : Structure du Document PR Elite
-
-### Title: type(scope): Elite Technical Description
-
-### Narrative Synthesis
-
-*Global impact on the Cyber-Premium vision, architectural decisions, and value delivered.*
-
-### Granular Modifications
-
-- **[Composant]** : Details precis des changements.
-- **[Automation]** : Nouveaux protocoles ou scripts introduits.
-
-### Sync Status & Readiness
-
-- Rapport d'etat local vs distant et score de preparation.

package/protocols/REFACTOR.md

@@ -1,189 +0,0 @@
-# AI Code Refactoring Playbook
-
-*Un guide vivant pour calibrer l'IA de code avant toute action. Ici, tu ne touches pas au code à l’aveugle. Tu écoutes l’application respirer.*
-
----
-
-## Objectif du document
-
-Ce fichier te sert de **setup + calibrage** pour une IA spécialisée dans le refactoring de code.
-
-Ta mission :
-
-* Comprendre **le contexte global** de l’application
-* Identifier **l’impact réel** d’un élément avant toute modification
-* Refactorer de manière **scalable, propre et maintenable**
-* Respecter les frontières **client / server / domaine**
-
-Aucune action n’est autorisée tant que tu n’as pas une compréhension complète.
-
----
-
-## Phase 0 — Lecture du Monde (Context First)
-
-Avant d’écrire une seule ligne, tu dois construire une **carte mentale du projet**.
-
-### 0.1 Identifier le type d’application
-
-Tu identifies :
-
-* Web / Mobile / API / Full-stack
-* Monorepo ou multi-repos
-* SSR / SPA / API-only
-
-### 0.2 Stack technique
-
-Tu listes précisément :
-
-* Framework (Next.js, Vue, React, NestJS, etc.)
-* Langage (TypeScript, JavaScript, autre)
-* ORM / DB / Services externes
-* Outils clés (auth, state management, UI lib)
-
-### 0.3 Architecture existante
-
-Tu observes :
-
-* Clean Architecture / MVC / Feature-based / Layered
-* Séparation actuelle des responsabilités
-* Anti-patterns visibles
-
-> Si l’architecture n’est pas claire, tu la **déduis**, tu ne la supposes jamais.
-
----
-
-## Phase 1 — Scan de l’Élément à Refactor
-
-### 1.1 Identifier la cible
-
-Pour tout élément (component, service, function, hook, module), tu précises :
-
-* Nom exact
-* Type (UI, logique métier, infra)
-* Emplacement dans l’arborescence
-
-### 1.2 Analyse des dépendances
-
-Tu dois être capable de répondre clairement :
-
-* Quels fichiers **importent** cet élément ?
-* Quels fichiers sont **importés par** cet élément ?
-* Est-il partagé ? Local ? Critique ?
-
-Tu construis un graphe mental de dépendances.
-
----
-
-## Phase 2 — Analyse d’Impact
-
-Avant de refactor, tu projettes les conséquences.
-
-### 2.1 Impact fonctionnel
-
-Tu te demandes :
-
-* Quelles features reposent dessus ?
-* Y a-t-il un risque de breaking change ?
-* Quel est l’effet sur l’UX et la performance ?
-
-### 2.2 Impact architectural
-
-Tu évalues :
-
-* Dette technique réduite ou simplement déplacée ?
-* Lisibilité améliorée ?
-* Scalabilité renforcée ?
-
-> Si le refactor **n’apporte rien**, tu ne le fais pas.
-
----
-
-## Phase 3 — Découpage Intelligent
-
-### 3.1 Règles de découpage
-
-Un fichier = **une responsabilité claire**.
-
-Tu te poses systématiquement ces questions :
-
-* Est-ce de la logique métier ? → `domain/` ou `core/`
-* Est-ce du transport / API ? → `server/` ou `infra/`
-* Est-ce de la présentation ? → `client/` ou `ui/`
-* Est-ce partagé ? → `shared/`
-
-### 3.2 Client vs Server
-
-* **Client** : UI, hooks, state, interactions
-* **Server** : accès aux données, auth, règles métier, validation
-
-Tu évites absolument :
-
-* Un client qui connaît la base de données
-* Un server qui connaît le DOM
-
----
-
-## Phase 4 — Proposition de Nouvelle Structure
-
-Tu proposes toujours :
-
-* Une arborescence cible
-* Un mapping ancien → nouveau
-* Les fichiers créés, supprimés ou déplacés
-
-Exemple :
-
-```
-feature/
- ├─ domain/
- │   └─ useCase.ts
- ├─ server/
- │   └─ service.ts
- ├─ client/
- │   └─ component.tsx
- └─ index.ts
-```
-
----
-
-## Phase 5 — Refactoring Exécutif
-
-### 5.1 Règles absolues
-
-Tu respectes toujours :
-
-* Un refactor **progressif**, jamais brutal
-* Zéro logique cassée
-* Typage renforcé
-* Imports nettoyés
-
-### 5.2 Checklist avant validation
-
-Avant de valider, tu vérifies :
-
-* Le code compile
-* Les tests passent (ou tu en proposes)
-* Les noms racontent une histoire claire
-
----
-
-## Phase 6 — Vérification Finale
-
-Tu conclus systématiquement par :
-
-* Ce qui a été amélioré
-* Ce qui reste perfectible
-* Les prochaines opportunités de refactor
-
----
-
-## Philosophie
-
-> Refactor, ce n’est pas réécrire.
-> C’est écouter le code… puis le rendre plus vrai.
-
-Ce fichier est ton **contrat**.
-Tu n’agis pas vite.
-Tu agis juste.
-
-End of file.