merge: chore/docs-agents-ci-2025-08-27 → main (v2025.08.2)

.gitea/workflows/ci.yml

@@ -300,8 +300,7 @@ jobs:
         env:
           OPENAI_API_KEY: ""
         run: |
-          mkdir -p tests/reports/agents
-          scripts/agents/run.sh . tests/reports/agents all
+          scripts/agents/run.sh
       - name: Upload agents reports
         uses: actions/upload-artifact@v3
         with:
@@ -325,8 +324,7 @@ jobs:
           chmod +x scripts/agents/*.sh || true
       - name: Run agents with AI
         run: |
-          mkdir -p tests/reports/agents
-          scripts/agents/run.sh . tests/reports/agents all
+          scripts/agents/run.sh
       - name: Upload agents reports
         uses: actions/upload-artifact@v3
         with:
@@ -406,7 +404,7 @@ jobs:
     if: startsWith(github.ref, 'refs/tags/')
     env:
       RELEASE_TOKEN: ${{ secrets.RELEASE_TOKEN }}
-      GITEA_BASE_URL: ${{ vars.GITEA_BASE_URL }}
+      BASE_URL: ${{ vars.BASE_URL }}
     steps:
       - name: Checkout code
         uses: actions/checkout@v3
@@ -415,18 +413,18 @@ jobs:
           set -e
           if [ -z "${RELEASE_TOKEN}" ]; then
             echo "RELEASE_TOKEN secret is missing" >&2; exit 1; fi
-          if [ -z "${GITEA_BASE_URL}" ]; then
-            GITEA_BASE_URL="https://git.4nkweb.com"; fi
+          if [ -z "${BASE_URL}" ]; then
+            BASE_URL="https://git.4nkweb.com"; fi
           TAG="${GITHUB_REF##*/}"
           REPO="${GITHUB_REPOSITORY}"
           OWNER="${REPO%%/*}"
           NAME="${REPO##*/}"
-          echo "Publishing release ${TAG} to ${GITEA_BASE_URL}/${OWNER}/${NAME}"
+          echo "Publishing release ${TAG} to ${BASE_URL}/${OWNER}/${NAME}"
           curl -sSf -X POST \
             -H "Authorization: token ${RELEASE_TOKEN}" \
             -H "Content-Type: application/json" \
             -d "{\"tag_name\":\"${TAG}\",\"name\":\"${TAG}\",\"draft\":false,\"prerelease\":false}" \
-            "${GITEA_BASE_URL}/api/v1/repos/${OWNER}/${NAME}/releases" >/dev/null
+            "${BASE_URL}/api/v1/repos/${OWNER}/${NAME}/releases" >/dev/null
           echo "Release created"
 
   # Job de tests de performance

CHANGELOG.md

@@ -26,6 +26,13 @@ et ce projet adhère au [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 - Déploiement: copie étendue (.cursor, AGENTS.md, LICENSE, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, TEMPLATE_VERSION, .markdownlint.json, .cursorignore, .gitignore, security/, scripts/)
 
 ### Changed
+## [2025.08.2] - 2025-08-27
+
+### Changed
+- Renommage variable CI/Docs `GITEA_BASE_URL` → `BASE_URL`
+- Exécution des agents simplifiée: `scripts/agents/run.sh` sans arguments par défaut
+- CI mise à jour pour utiliser l’exécution sans paramètres
+
 
 ## [2025.08.1] - 2025-08-27
 
@@ -40,7 +47,6 @@ et ce projet adhère au [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 - Normalisation MD005/MD007/MD051 dans la documentation
 - Ancrages ASCII dans `AGENTS.md`, correction des titres emphase (MD036)
 
-
 - Documentation projet réécrite à partir des modèles `docs/templates/**` (générique, non applicative)
 - `docs/INDEX.md` mis à jour (liens Déploiement et SSH)
 - Alignement documentaire sur 4NK_template (titres, liens Gitea, wording) dans docs/**

SECURITY.md

@@ -9,6 +9,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 **NE PAS** créer d'issue publique pour les vulnérabilités de sécurité.
 
 #### À la place
+
 1. Envoyez un email à [security@4nkweb.com](mailto:security@4nkweb.com)
 2. Incluez "SECURITY VULNERABILITY" dans l'objet
 3. Décrivez la vulnérabilité de manière détaillée
@@ -34,6 +35,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Pour les Contributeurs
 
 #### Code
+
 - Validez toutes les entrées utilisateur
 - Utilisez des requêtes préparées pour les bases de données
 - Évitez les injections de code
@@ -41,12 +43,14 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 - Utilisez HTTPS pour toutes les communications
 
 #### Configuration
+
 - Ne committez jamais de secrets
 - Utilisez des variables d'environnement pour les données sensibles
 - Vérifiez les permissions des fichiers
 - Maintenez les dépendances à jour
 
 #### Tests
+
 - Incluez des tests de sécurité
 - Testez les cas limites
 - Validez les entrées malveillantes
@@ -55,18 +59,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Pour les Utilisateurs
 
 #### Installation
+
 - Utilisez des sources officielles
 - Vérifiez les checksums
 - Maintenez le système à jour
 - Utilisez un pare-feu
 
 #### Configuration
+
 - Changez les mots de passe par défaut
 - Utilisez des clés SSH fortes
 - Limitez l'accès réseau
 - Surveillez les logs
 
 #### Opération
+
 - Surveillez les connexions
 - Sauvegardez régulièrement
 - Testez les sauvegardes
@@ -77,24 +84,28 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Composants Principaux
 
 #### Bitcoin Core
+
 - **RPC Interface** : Authentification requise
 - **ZMQ** : Communication locale uniquement
 - **P2P** : Validation des blocs
 - **Wallet** : Chiffrement des clés
 
 #### Blindbit
+
 - **API HTTP** : Validation des entrées
 - **Filtres** : Vérification des signatures
 - **Cache** : Protection contre les attaques DoS
 - **Logs** : Pas d'informations sensibles
 
 #### SDK Relay
+
 - **WebSocket** : Validation des messages
 - **Synchronisation** : Authentification des pairs
 - **Cache** : Protection contre les attaques
 - **Configuration** : Validation des paramètres
 
 #### Tor
+
 - **Proxy** : Configuration sécurisée
 - **Contrôle** : Accès restreint
 - **Logs** : Anonymisation
@@ -103,6 +114,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Tests de Sécurité
 
 #### Tests Automatisés
+
 ```bash
 # Tests de sécurité
 ./tests/run_security_tests.sh
@@ -115,6 +127,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ```
 
 #### Tests Manuels
+
 - Tests de pénétration
 - Audit de code
 - Tests de configuration
@@ -147,6 +160,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 📋 Checklist de Sécurité
 
 ### Avant le Déploiement
+
 - [ ] Audit de code de sécurité
 - [ ] Tests de vulnérabilités
 - [ ] Vérification des dépendances
@@ -154,6 +168,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 - [ ] Tests de charge
 
 ### Pendant l'Opération
+
 - [ ] Monitoring de sécurité
 - [ ] Surveillance des logs
 - [ ] Mise à jour des composants
@@ -161,6 +176,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 - [ ] Tests de récupération
 
 ### Après un Incident
+
 - [ ] Analyse post-mortem
 - [ ] Mise à jour des procédures
 - [ ] Formation de l'équipe
@@ -170,18 +186,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 🔧 Outils de Sécurité
 
 ### Monitoring
+
 - **Logs** : Centralisation et analyse
 - **Métriques** : Surveillance en temps réel
 - **Alertes** : Notification automatique
 - **Tableaux de bord** : Vue d'ensemble
 
 ### Tests
+
 - **SAST** : Analyse statique
 - **DAST** : Tests dynamiques
 - **IAST** : Tests interactifs
 - **Fuzzing** : Tests de robustesse
 
 ### Protection
+
 - **WAF** : Pare-feu applicatif
 - **IDS/IPS** : Détection d'intrusion
 - **Antivirus** : Protection des endpoints
@@ -190,18 +209,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 📚 Ressources
 
 ### Documentation
+
 - [Guide de Sécurité Bitcoin](https://bitcoin.org/en/security)
 - [OWASP Top 10](https://owasp.org/www-project-top-ten/)
 - [CWE/SANS Top 25](https://cwe.mitre.org/top25/)
 - [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)
 
 ### Outils
+
 - [Bandit](https://bandit.readthedocs.io/) - Analyse Python
 - [Clang Static Analyzer](https://clang-analyzer.llvm.org/) - Analyse C/C++
 - [SonarQube](https://www.sonarqube.org/) - Qualité du code
 - [OpenVAS](https://www.openvas.org/) - Scan de vulnérabilités
 
 ### Formation
+
 - Cours de sécurité applicative
 - Formation aux tests de pénétration
 - Certification en cybersécurité
@@ -210,18 +232,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 🤝 Collaboration
 
 ### Bug Bounty
+
 - Programme de récompenses pour les vulnérabilités
 - Critères d'éligibilité
 - Montants des récompenses
 - Processus de validation
 
 ### Responsible Disclosure
+
 - Timeline de divulgation
 - Coordination avec les chercheurs
 - Communication publique
 - Remerciements
 
 ### Communauté
+
 - Groupe de sécurité
 - Discussions techniques
 - Partage d'informations

TEMPLATE_VERSION

@@ -1,2 +1,2 @@
-v2025.08.1
+v2025.08.2
 

docs/project/AGENTS_RUNTIME.md

@@ -16,10 +16,12 @@ Ce guide décrit comment utiliser et intégrer les agents de conformité (qualit
 ## 3. Commandes
 
 - Bash (recommandé):
-  - `scripts/agents/run.sh [target_dir] [output_dir] [agent]`
+  - `scripts/agents/run.sh`
+  - Options (facultatives): `scripts/agents/run.sh [target_dir] [output_dir] [agent]`
     - Par défaut: `target_dir=.` `output_dir=tests/reports/agents` `agent=all`
 - PowerShell (fallback Windows):
-  - `scripts/agents/run.ps1 -TargetDir . -OutputDir tests/reports/agents -Agent <nom>`
+  - `scripts/agents/run.ps1`
+  - Options (facultatives): `-TargetDir . -OutputDir tests/reports/agents -Agent <nom>`
 
 ## 4. Agents disponibles
 

docs/project/CONFIGURATION.md

@@ -5,7 +5,7 @@
 - Secrets CI uniquement (pas de secrets en clair)
 - Variables agents : OPENAI_API_KEY, OPENAI_MODEL, OPENAI_API_BASE, OPENAI_TEMPERATURE
 - Secret release: RELEASE_TOKEN (publication des releases via l’API Gitea)
-- Variable optionnelle: GITEA_BASE_URL (ex: `https://git.4nkweb.com`)
+- Variable optionnelle: BASE_URL (ex: `https://git.4nkweb.com`)
 
 ## Conventions
 

docs/project/DEPLOYMENT.md

@@ -20,7 +20,7 @@
 - Script d’installation: `scripts/deploy/setup.sh`
   - Crée `~/.4nk_template/` (chmod 700) et `~/.4nk_template/.env` (chmod 600)
   - Copie depuis `scripts/env/.env.template` si présent, sinon génère un modèle
-  - À compléter: `OPENAI_API_KEY`, `OPENAI_MODEL`, `RELEASE_TOKEN`, `GITEA_BASE_URL` (si custom)
+  - À compléter: `OPENAI_API_KEY`, `OPENAI_MODEL`, `RELEASE_TOKEN`, `BASE_URL` (si custom)
   - Applique la structure 4NK_template au projet cible (sans écraser par défaut):
     - `.gitea/**`, `.cursor/**`, `.cursorignore`, `.gitignore`, `.markdownlint.json`
     - `AGENTS.md`, `LICENSE`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md`, `TEMPLATE_VERSION`

docs/project/GITEA_SETUP.md

@@ -1,29 +1,35 @@
 # Configuration Gitea — 4NK_template (projet)
 
 ## 1. Repository
+
 - Activer les Actions (workflows `.gitea/workflows/*.yml`)
 - Vérifier les templates d’issues/PR
 
 ## 2. Protections de branches
+
 - Reviews requises avant merge
 - Status checks requis (CI verte)
 - Mise à jour obligatoire de la branche avant merge
 
 ## 3. Secrets et variables
+
 - Secrets: `OPENAI_API_KEY` (optionnel), `RELEASE_TOKEN` (obligatoire pour publier les releases via API Gitea)
-- Variables: paramètres de CI non sensibles, ex: `OPENAI_MODEL`, `OPENAI_API_BASE`, `OPENAI_TEMPERATURE`, `GITEA_BASE_URL`
+- Variables: paramètres de CI non sensibles, ex: `OPENAI_MODEL`, `OPENAI_API_BASE`, `OPENAI_TEMPERATURE`, `BASE_URL`
 
 ### Ajouter `RELEASE_TOKEN`
+
 - Aller dans Repository Settings → Secrets → New Repository Secret
 - Nom: `RELEASE_TOKEN` ; Valeur: un token personnel avec portée API sur le dépôt
 - Le job `release-create` utilisera ce secret lors d’un push de tag `v*`
 
 ## 4. Workflows requis
+
 - `code-quality`, `unit-tests`, `documentation-tests`, `security-audit`
 - `deployment-checks`, `bash-required`, `markdownlint`, `release-guard`, `release-create`
 - (Optionnels) `agents-smoke`, `openia-agents`
 
 ## 5. Processus PR
+
 - Branche dédiée, PR petite et ciblée
 - CI verte, review approuvée
 - Doc et changelog à jour

docs/project/OPEN_SOURCE_GUIDE.md

@@ -1,15 +1,18 @@
 # Guide open source — 4NK_template (projet)
 
 ## Pré-requis
+
 - LICENSE, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md
 
 ## CI
+
 - tests, lint, security-audit, release-guard, bash-required
 
 ## Publication
+
 - Alignement version/changelog/tag, notes de release
 
 ## Communauté
+
 - Templates issues/PR, labels, milestones
 - Divulgation responsable des vulnérabilités
-

docs/project/QUALITY_STANDARDS.md

@@ -6,4 +6,3 @@
 - Tests verts (catégories pertinentes) et rapports conservés
 - Documentation à jour (INDEX, guides impactés)
 - Sécurité de base: secrets, permissions, audit CI
-

docs/project/RELEASE_PLAN.md

@@ -1,20 +1,23 @@
 # Plan de release — 4NK_template (projet)
 
 ## Objectifs
+
 - Version documentée, testée, sécurisée
 - Processus reproductible et traçable
 
 ## Préparation
+
 - CI verte: lint/tests/doc/security‑audit/release‑guard
 - Docs à jour (INDEX, guides impactés)
 - Version/Changelog/Tag alignés
 
 ## Lancement
+
 - Tagging: `vX.Y.Z` ou `vX.Y.Z-wip.N`
 - Notes de release (résumé, changements majeurs, impacts)
 
 ## Post‑lancement
+
 - Suivi issues/retours
 - Corrections critiques
 - Mise à jour de la roadmap
-

docs/project/ROADMAP.md

@@ -1,22 +1,25 @@
 # Roadmap — 4NK_template (projet)
 
 ## Vision
+
 Maintenir un template robuste (docs, CI, sécurité) pour accélérer les projets.
 
 ## Objectifs (12 mois)
+
 - Qualité: standards renforcés, automatisations CI supplémentaires
 - Documentation: squelettes enrichis, index cohérents
 - Sécurité: contrôles CI étendus, guides pratiques
 - Outillage: agents élargis, rapports synthétiques
 
 ## Jalons
+
 - T1: Mise à jour squelettes docs et agents
 - T2: Extensions CI (lint multi‑langages, déploiement dry‑run)
 - T3: Guides open source/qualité consolidés
 - T4: Synchronisation de template outillée
 
 ## Mesure du progrès
+
 - CI verte en continu
 - Adoption des squelettes par projets
 - Diminution des écarts de conformité
-

docs/project/SECURITY_AUDIT.md

@@ -1,24 +1,28 @@
 # Audit de sécurité — 4NK_template (projet)
 
 ## Menaces
+
 - Secrets, permissions, endpoints sensibles, dépendances, supply chain
 
 ## Contrôles
+
 - Scan secrets/permissions
 - Audit dépendances (outil selon la pile des projets)
 - Vérifs de configuration (auth/TLS/CORS/rate‑limit)
 - Journalisation sécurité, traçabilité
 
 ## CI
+
 - Job `security-audit` échoue si alerte critique
 - Rapports archivés en artefacts
 
 ## Politique des secrets
+
 - Exclusivement secrets CI/variables d’environnement
 - Rotation régulière, révocation sur incident
 - Aucun secret en clair dans le dépôt
 
 ## Remédiation
+
 - Prioriser, corriger, documenter dans `CHANGELOG.md`
 - Ajouter des tests de non‑régression sécurité si pertinent
-

docs/project/USAGE.md

@@ -3,54 +3,63 @@
 Ce document explique comment utiliser le template pour initier, documenter, contrôler et publier des projets dérivés, en respectant les standards qualité, sécurité et open source.
 
 ## 1. Pré‑requis
+
 - Git opérationnel et accès à votre forge (Gitea recommandé)
 - CI activée sur le repository
 - bash disponible pour les agents (recommandé). À défaut, fallback PowerShell local
 
 ## 2. Démarrer un projet dérivé
+
 1) Créer un repository à partir de 4NK_template
 2) Copier/adapter la documentation depuis `docs/templates/**` vers votre `docs/**`
 3) Tenir `docs/INDEX.md` et `CHANGELOG.md` à jour
 4) Activer les workflows CI et vérifier `release-guard`/`security-audit`
 
 ## 3. Documentation
+
 - Utiliser les squelettes de `docs/templates/**` comme base
 - Documenter uniquement votre domaine applicatif (le template reste générique)
 - À chaque changement de code/dépendance/CI, synchroniser la doc correspondante
 
 ## 4. Agents (contrôles)
+
 - Recommandé (bash): `scripts/agents/run.sh [target_dir] [output_dir] [agent]`
 - Windows fallback: `scripts/agents/run.ps1 -TargetDir . -OutputDir tests/reports/agents -Agent <nom>`
 - Rapports: `tests/reports/agents/*.md`
 - Agents utiles en premier passage: `documentation`, `quality-technique`, `open-source`, `securite`, `deploiement`
 
 ## 5. Qualité et CI
+
 - Jobs attendus: qualité, tests (catégories pertinentes), documentation, security‑audit, bash‑required, release‑guard
 - `bash-required` garantit la présence de bash et du runner des agents
 - `release-guard` bloque les publications si tests/doc/build/sécurité/version/changelog/tag ne sont pas cohérents
 
 ## 6. Sécurité
+
 - Secrets uniquement via la CI (variables d’environnement), jamais en clair dans le dépôt
 - Audit sécurité automatisé (job `security-audit`) et remédiations tracées dans `CHANGELOG.md`
 
 ## 7. Workflow quotidien
+
 - Éditer: code et documentation (toujours en parallèle)
 - Exécuter: tests locaux, agents (diagnostics)
 - Vérifier: sorties CI, rapports `tests/reports/`
 - Commiter: messages clairs, PR petites et ciblées
 
 ## 8. Publication
+
 - Choisir `latest` (tag `vX.Y.Z`) ou `wip` (ex: `vX.Y.Z-wip.N`)
 - Aligner: fichier de version, `CHANGELOG.md`, tag git
 - Déployer si pipeline défini; sinon documenter la procédure
 
 ## 9. Dépannage
+
 - Agents fallback PowerShell si bash indisponible localement
 - Consulter `tests/reports/agents/*.md` pour les écarts à corriger
 - Vérifier les logs de la CI et le job `release-guard`
 
 ## 10. Bonnes pratiques
+
 - Pas d’exemples applicatifs dans le template
 - Toujours mettre à jour la documentation et le changelog
 - Réduire la dérive: synchroniser régulièrement vos projets avec les squelettes et standards
-

docs/templates/README.md

@@ -1,14 +1,17 @@
 # README — Template de projet
 
 ## Présentation
+
 Décrivez brièvement l’objectif du projet, son périmètre et ses utilisateurs cibles.
 
 ## Démarrage rapide
+
 - Prérequis (langages/outils)
 - Étapes d’installation
 - Commandes de démarrage
 
 ## Documentation
+
 - Index: `docs/INDEX.md`
 - Architecture: `docs/ARCHITECTURE.md`
 - Configuration: `docs/CONFIGURATION.md`
@@ -17,8 +20,10 @@ Décrivez brièvement l’objectif du projet, son périmètre et ses utilisateur
 - Déploiement: `docs/DEPLOYMENT.md`
 
 ## Contribution
+
 - GUIDE: `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`
 - Processus de PR et revues
 
 ## Licence
+
 - Indiquez la licence choisie (MIT/Apache-2.0/GPL)

scripts/deploy/setup.sh

@@ -67,7 +67,7 @@ OPENAI_API_BASE=https://api.openai.com/v1
 OPENAI_TEMPERATURE=0.2
 
 # Gitea (release via API)
-GITEA_BASE_URL=https://git.4nkweb.com
+BASE_URL=https://git.4nkweb.com
 RELEASE_TOKEN=
 EOF
   fi

tests/README.md

@@ -3,6 +3,7 @@
 Ce répertoire décrit la stratégie et l’organisation des tests exigées par le template 4NK.
 
 ## Pyramide de tests
+
 - Unit: validation des unités logicielles
 - Integration: interactions multi-composants
 - Connectivity: réseau et endpoints
@@ -10,16 +11,20 @@ Ce répertoire décrit la stratégie et l’organisation des tests exigées par
 - Performance: charge et temps de réponse
 
 ## Exécution
+
 - Local: exécuter les suites pertinentes et déposer les résultats dans `tests/reports`
 - CI: orchestrée par `.gitea/workflows/ci.yml`
 
 ## Journaux et rapports
+
 - `tests/logs`: journaux d’exécution
 - `tests/reports`: rapports synthétiques
 
 ## Nettoyage
+
 Utiliser `tests/cleanup.sh` après exécution.
 
 ## Critères d’acceptation
+
 - Zéro échec avant commit
 - Documentation associée à jour dans `docs/TESTING.md`