# Guide d’adaptation du template 4NK

Ce document décrit comment adapter `4NK_template` à un projet concret.

## 1. Périmètre et langage
- Choisir les jobs CI pertinents (Rust/Node/Docker) et supprimer ceux non applicables.
- Conserver le job `security-audit` et le `release-guard`.

## 2. Sécurité
- Activer `scripts/security/audit.sh` (npm audit/cargo audit + scan secrets) et ajuster les seuils si nécessaire.
- Vérifier les permissions de fichiers sensibles et l’absence de secrets en clair.

## 3. Versionnage & release
- Définir le fichier de version (`VERSION` ou `TEMPLATE_VERSION`).
- Tenir `CHANGELOG.md` comme source de vérité et intégrer au `release-guard`.

## 4. Documentation
- Adapter `docs/INDEX.md`, `INSTALLATION.md`, `USAGE.md`, `ARCHITECTURE.md` au contexte projet.
- Maintenir `docs/SECURITY_AUDIT.md` conforme à la réalité du dépôt.

## 5. Règles Cursor
- Conserver `.cursor/rules/*` puis affiner selon le langage et la structure du projet.

## 6. CI/CD (Gitea)
- Adapter `.gitea/workflows/ci.yml` (jobs, versions, caches) sans retirer `security-audit` ni `release-guard`.
- Ajouter des jobs spécifiques (e2e, perf) si nécessaire.

## 7. Gouvernance et open source
- Vérifier `LICENSE`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `OPEN_SOURCE_CHECKLIST.md`.
- Utiliser `AGENTS.md` pour clarifier les responsabilités.

## 8. Synchronisation avec le template
- Documenter toute divergence locale dans `LOCAL_OVERRIDES.yml` si utilisé.
- Proposer les améliorations génériques en feedback (voir `docs/TEMPLATE_FEEDBACK.md`).