4NK/cursor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial: desk + ncantu placeholder + per-project cursor configs

Browse Source 
**Motivations:**
- Centraliser les fichiers Cursor (rules, skills, agents, commands, hooks) par user et par projet

**Root causes:**
- N/A

**Correctifs:**
- N/A

**Evolutions:**
- desk: rules, skills-cursor, agents, commands, hooks, argv/hooks/mcp.json
- ncantu: README placeholder
- 4NK_node, algo, builazoo, ia_local, lecoffre_ng, lecoffre_ng_pprod, lecoffre_ng_test: .cursor contents

**Pages affectées:**
- cursor/desk/, cursor/ncantu/, cursor/<project>/
This commit is contained in:
Nicolas Cantu
2026-03-03 23:29:29 +01:00
commit 785868b53b
114 changed files with 6455 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

208
desk/commands/audit-security.md Normal file
View File

@@ -0,0 +1,208 @@
---
model: inherit
---
# audit-security
You are an expert security audit agent specialized in identifying vulnerabilities and security risks. Apply systematic reasoning following OWASP guidelines and security best practices.
## Security Audit Principles
Before reviewing any code for security, you must methodically analyze:
### 1) Attack Surface Analysis
1.1) Identify all entry points (APIs, forms, file uploads, webhooks)
1.2) Map data flows from input to storage to output
1.3) Identify trust boundaries
1.4) List all external dependencies and their versions
1.5) Identify privileged operations
### 2) OWASP Top 10 Review
2.1) **Injection** (SQL, NoSQL, Command, LDAP)
- Are all queries parameterized?
- Is user input ever concatenated into queries?
- Are ORM queries safe from injection?
- Is shell command execution avoided with user input?
2.2) **Broken Authentication**
- Are passwords hashed with strong algorithms (bcrypt, Argon2)?
- Is MFA available for sensitive operations?
- Are session tokens secure (HttpOnly, Secure, SameSite)?
- Is there account lockout after failed attempts?
2.3) **Sensitive Data Exposure**
- Is sensitive data encrypted at rest and in transit?
- Are API keys, secrets in environment variables (not code)?
- Is PII properly protected?
- Are error messages generic (no stack traces in production)?
2.4) **XML External Entities (XXE)**
- Is XML parsing configured to disable external entities?
- Are safer data formats (JSON) used when possible?
2.5) **Broken Access Control**
- Are all endpoints properly authorized?
- Is there IDOR (Insecure Direct Object Reference) protection?
- Are CORS policies properly configured?
- Is principle of least privilege followed?
2.6) **Security Misconfiguration**
- Are default credentials changed?
- Are unnecessary features disabled?
- Are security headers set (CSP, X-Frame-Options, etc.)?
- Is HTTPS enforced?
2.7) **Cross-Site Scripting (XSS)**
- Is all user input escaped before rendering?
- Is Content Security Policy in place?
- Are dangerous functions (innerHTML, eval) avoided?
- Is input validated on both client and server?
2.8) **Insecure Deserialization**
- Is untrusted data ever deserialized?
- Are safe alternatives used (JSON instead of pickle)?
2.9) **Using Components with Known Vulnerabilities**
- Are dependencies up to date?
- Is there a process for security updates?
- Are vulnerability scanners in CI/CD?
2.10) **Insufficient Logging & Monitoring**
- Are security events logged?
- Are logs protected from tampering?
- Is there alerting for suspicious activity?
### 3) Risk Assessment
For each vulnerability found:
3.1) Severity: Critical / High / Medium / Low
3.2) Likelihood: How easy is it to exploit?
3.3) Impact: What's the damage if exploited?
3.4) Priority: Severity × Likelihood
### 4) Remediation Recommendations
4.1) Provide specific fix recommendations
4.2) Include code examples when possible
4.3) Reference security standards (OWASP, CWE)
4.4) Suggest defense-in-depth approaches
4.5) Prioritize fixes by risk level
### 5) Security Headers Checklist
- [ ] Strict-Transport-Security (HSTS)
- [ ] Content-Security-Policy
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENY
- [ ] X-XSS-Protection: 1; mode=block
- [ ] Referrer-Policy
- [ ] Permissions-Policy
## Vulnerability Report Format
**[SEVERITY] Vulnerability Title**
- **Location**: File:Line or Endpoint
- **Description**: What is the vulnerability?
- **Impact**: What can an attacker do?
- **Reproduction**: Steps to exploit
- **Remediation**: How to fix it
- **References**: CWE, OWASP links
ou are an expert security audit agent specialized in identifying vulnerabilities and security risks. Apply systematic reasoning following OWASP guidelines and security best practices.
## Security Audit Principles
Before reviewing any code for security, you must methodically analyze:
### 1) Attack Surface Analysis
1.1) Identify all entry points (APIs, forms, file uploads, webhooks)
1.2) Map data flows from input to storage to output
1.3) Identify trust boundaries
1.4) List all external dependencies and their versions
1.5) Identify privileged operations
### 2) OWASP Top 10 Review
2.1) **Injection** (SQL, NoSQL, Command, LDAP)
- Are all queries parameterized?
- Is user input ever concatenated into queries?
- Are ORM queries safe from injection?
- Is shell command execution avoided with user input?
2.2) **Broken Authentication**
- Are passwords hashed with strong algorithms (bcrypt, Argon2)?
- Is MFA available for sensitive operations?
- Are session tokens secure (HttpOnly, Secure, SameSite)?
- Is there account lockout after failed attempts?
2.3) **Sensitive Data Exposure**
- Is sensitive data encrypted at rest and in transit?
- Are API keys, secrets in environment variables (not code)?
- Is PII properly protected?
- Are error messages generic (no stack traces in production)?
2.4) **XML External Entities (XXE)**
- Is XML parsing configured to disable external entities?
- Are safer data formats (JSON) used when possible?
2.5) **Broken Access Control**
- Are all endpoints properly authorized?
- Is there IDOR (Insecure Direct Object Reference) protection?
- Are CORS policies properly configured?
- Is principle of least privilege followed?
2.6) **Security Misconfiguration**
- Are default credentials changed?
- Are unnecessary features disabled?
- Are security headers set (CSP, X-Frame-Options, etc.)?
- Is HTTPS enforced?
2.7) **Cross-Site Scripting (XSS)**
- Is all user input escaped before rendering?
- Is Content Security Policy in place?
- Are dangerous functions (innerHTML, eval) avoided?
- Is input validated on both client and server?
2.8) **Insecure Deserialization**
- Is untrusted data ever deserialized?
- Are safe alternatives used (JSON instead of pickle)?
2.9) **Using Components with Known Vulnerabilities**
- Are dependencies up to date?
- Is there a process for security updates?
- Are vulnerability scanners in CI/CD?
2.10) **Insufficient Logging & Monitoring**
- Are security events logged?
- Are logs protected from tampering?
- Is there alerting for suspicious activity?
### 3) Risk Assessment
For each vulnerability found:
3.1) Severity: Critical / High / Medium / Low
3.2) Likelihood: How easy is it to exploit?
3.3) Impact: What's the damage if exploited?
3.4) Priority: Severity × Likelihood
### 4) Remediation Recommendations
4.1) Provide specific fix recommendations
4.2) Include code examples when possible
4.3) Reference security standards (OWASP, CWE)
4.4) Suggest defense-in-depth approaches
4.5) Prioritize fixes by risk level
### 5) Security Headers Checklist
- [ ] Strict-Transport-Security (HSTS)
- [ ] Content-Security-Policy
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENY
- [ ] X-XSS-Protection: 1; mode=block
- [ ] Referrer-Policy
- [ ] Permissions-Policy
## Vulnerability Report Format
**[SEVERITY] Vulnerability Title**
- **Location**: File:Line or Endpoint
- **Description**: What is the vulnerability?
- **Impact**: What can an attacker do?
- **Reproduction**: Steps to exploit
- **Remediation**: How to fix it
- **References**: CWE, OWASP links

24
desk/commands/banch-align-update.md Normal file
View File

@@ -0,0 +1,24 @@
---
model: inherit
---
# banch-align-update
`<env>` la branche passée en paramètre.
On on veut aligner la branche actuelle sur `<env>` sans modifier `<env>` et que la branche locale actuelle pointe sur la meme branche locale et la brnche locale de `<env>` sur la branche distantede `<env>`.
Stash et aligne toi sur la branche `<env>`, avant liste les modifications qui seront stash (sans le rétablir) et attend une confirmation.
la locale branche actuelle doit etre: alignée sur les commits de `<env>`
sans changer de branche.
`<env>` : doit rester inchangée.
A la fin :
- la branche locale a été remise sur origin/`<meme nom>`, puis `<env>` a été mergée dans la branche locale.
- la branche locale pointe toujours sur la branche `<meme nom>` (ref refs/heads/`<meme nom>`).
- `<env>` pointe toujours sur la branche `<env>` (ref refs/heads/`<env>`).
- la branche locale test pointe sur la branche distante test
- la branche locale pprod pointe sur la branche distante pprod
- la branche locale prod pointe sur la branche distante prod

28
desk/commands/banch-align.md Normal file
View File

@@ -0,0 +1,28 @@
---
model: inherit
---
# banch-align
avec en paramètre `<env>`
sans mofidier la branche de `<env>`, sans quiter la branche de`<env>` aligne test et pprod et prod (sauf `<env>`) sur cette branche de `<env>` (meme code) et les branches locales test et pprod et prod doivent toujours pointer sur les branches distantes test et pprod et prod.
Pour le merge en cas de conflit : `<env>` est prioritaire.
Stash sans rétablir les modifications en cours sur une branche si elle cause ds conflits avec `<env>`.
A la fin :
origin/test, origin/pprod et origin/prod doivent avoir été mis à jour pour pointer sur le même commit que `<env>`.
Les branches locales test, pprod et prod ont été mises à jour pour suivre origin/test, origin/pprod et origin/prod.
L'utilisateur doit êre resté sur la branche `<env>`, qui n’aura pas été modifiée.
test, pprod, prod (locales et distantes) devront être au même commit.
Vérifie que les 30 derniers commits sont strictement équivalents.
- la branche locale pointe toujours sur la branche `<meme nom>` (ref refs/heads/`<meme nom>`).
- `<env>` pointe toujours sur la branche `<env>` (ref refs/heads/`<env>`).
- la branche locale test pointe sur la branche distante test
- la branche locale pprod pointe sur la branche distante pprod
- la branche locale prod pointe sur la branche distante prod

28
desk/commands/deploy.md Normal file
View File

@@ -0,0 +1,28 @@
---
model: inherit
---
# Déployer (test, pprod, prod)
Lance le déploiement via `deploy/scripts_v2/deploy.sh`.
## Usage
Spécifier l'environnement : `test`, `pprod` ou `prod`.
Exemple : `/deploy test` ou « Déploie sur test ».
## Processus
1. Vérifier que les modifications sont commitées (règle projet)
2. Exécuter `./deploy/scripts_v2/deploy.sh <env>`
3. En cas d'erreur : ne pas contourner ; analyser la cause, corriger puis retenter
## Options
- `--skipSetupHost` : ignorer setup-host (idempotent)
- `--checkLint` : activer lint/typecheck/build avant déploiement
## Référence
- `deploy/scripts_v2/deploy.sh`
- `docs/DEPLOYMENT.md`

52
desk/commands/docupdate.md Normal file
View File

@@ -0,0 +1,52 @@
---
model: inherit
---
# docupdate
## docs/features extract
Dans l'ordre et pour tous les documents de docs/features :
1) Extrait toutes les données pertinente des documents de docs/features et intègre les dans la documentation existante dans docs/
2) Supprimer tous les fichiers dans docs/features
## docs/fixKnowledge extract
Dans l'ordre et pour tous les documents de docs/fixKnowledge :
1) Extrait toutes les données pertinente des documents de docs/fixKnowledge et intègre les dans la documentation existante dans docs/
2) Supprimer tous les fichiers dans docs/fixKnowledge
## docs/ cleanup
Dans l'ordre et pour tous les documents de docs :
Documents à ne pas suppirmer lors des étapes suivantes :
* docs/API_IA.md
* docs/API.md
* docs/ARCHITECTURE.md
* docs/CLIENT_FOLDERS.md
* docs/CONFIGURATION_DOCUMENTS_SCHEMA.md
* docs/CONFIGURATION.md
* docs/DATAROOM_FOLDERS.md
* docs/DEPANNAGE.md
* docs/FONCTIONNALITES_ATTENDUES.md
* docs/QUALITE.md
* docs/RULES.md
* docs/SETUP.md
* docs/UX_UI_SPECIFICATIONS.md
* docs/WORKFLOWS.md
* docs/sources/*
* docs/fixKnowledge/*
* docs/features/*
1) Réuni et optimise la documentation en maximum 20 documents markdown
2) Supprimer les informations fausses ou obsoletes
Ventille les infos de features dans la doc existante et ne créé pas de fichier FEATURES.md
Ventille les infos de fixknowledge dans la doc existante et ne créé pas de fichier FIXKNOWLEDGE.md

10
desk/commands/fix-lint.md Normal file
View File

@@ -0,0 +1,10 @@
---
model: inherit
---
# Corriger les erreurs de lint
Exécute le plan `~/.cursor/plans/workflow-fix-lint.plan.md`.
Lis le fichier plan. NE JAMAIS modifier les fichiers dans ~/.cursor/. Corriger UNIQUEMENT le code du projet (lecoffre-back-main, lecoffre-front-main, lecoffre-ressources-dev).
**Concurrence** : Ne pas lancer si un déploiement est en cours. Si un déploiement est demandé pendant l'exécution, s'arrêter proprement. Voir docs/WORKFLOWS_AND_COMPONENTS.md §10.2.1.

221
desk/commands/lintit.md Normal file
View File

@@ -0,0 +1,221 @@
---
model: inherit
---
# lintit
Vérifie toutes ces règles et liste les actions à mener.
## qualité du code
### Analyse préalable obligatoire et arbre des fichiers
Avant toute implémentation, une phase d’analyse est obligatoire et doit produire une représentation de l’arbre des fichiers pertinents.
Cette représentation sert à identifier :
* la documentations le plus souvent dans docs/
* le code à rutiliser et les héritages
* les modules déjà disponibles
* les points d’extension existants
* les abstractions en place
* les conventions d’architecture
* les zones attendues de factorisation
Aucun code nouveau ne doit être écrit tant que cette cartographie minimale n’a pas été produite et exploitée pour éviter toute duplication.
### Non-duplication et réutilisation systématique
Toute logique nouvelle déclenche une vérification explicite de réutilisation possible dans le code existant.
Sont considérés comme duplication à éviter :
* copier-coller de blocs
* variations mineures d’une même fonction
* traitements parallèles de cas similaires
* conversions de types répétées
* mappings répétés
* gestion d’erreurs répétée
* validations répétées
* constructions d’objets redondantes
Si un comportement est récurrent, il doit être refactoré dans une abstraction partagée : fonction utilitaire ciblée, service, composant, stratégie, adaptateur ou classe de base, selon l’architecture.
Toute extraction doit préserver la lisibilité et la cohésion, sans créer d’utilitaires génériques sans responsabilité claire. Une réutilisation ne doit ni introduire de dépendance circulaire ni dégrader la modularité.
### Généricité et isolation des exceptions sans duplication
Le comportement par défaut doit être modélisé de façon générique. Les cas particuliers doivent être isolés dans des unités dédiées, sans répliquer le flux principal.
Les exceptions métier ou techniques doivent être représentées par :
* des types d’erreurs explicites
* des branches clairement identifiées
* des stratégies remplaçables ou des adaptateurs selon le besoin
Les variations doivent être injectées par inversion de dépendance plutôt que codées sous forme de conditions dispersées.
La règle est de minimiser le nombre d’endroits où un cas particulier est connu, idéalement un seul point de spécialisation.
### Design patterns et héritage
Les patterns doivent être employés uniquement lorsqu’ils clarifient le découpage et réduisent effectivement la duplication.
Les patterns attendus selon le contexte incluent notamment :
* Factory et Abstract Factory pour instancier selon le contexte sans cascade de conditions
* Strategy pour encapsuler des variations comportementales
* Template Method pour définir un squelette d’algorithme stable avec points d’extension
* Adapter pour interfacer une dépendance externe sans contaminer le domaine
* Decorator pour enrichir un comportement sans abus d’héritage
* Command pour formaliser des actions et leurs paramètres
* Repository ou Gateway pour l’accès aux données ou services externes
L’héritage est autorisé lorsqu’il représente une relation stable de type est-un, avec un contrat clair, et qu’il évite une duplication réelle.
Il est interdit d’utiliser l’héritage pour partager des détails d’implémentation instables ou pour créer une hiérarchie artificielle.
La composition est privilégiée lorsque les variations sont nombreuses ou lorsque des comportements combinables sont requis.
Toute hiérarchie doit rester courte, compréhensible, testable, et ne pas masquer les dépendances.
### Gestion des erreurs, traçabilité et journalisation
Tout cas d’erreur doit être journalisé.
Sont inclus :
* erreurs de validation
* erreurs d’entrée-sortie
* erreurs réseau
* erreurs de parsing
* états impossibles
* erreurs de dépendances externes
* timeouts
* conflits
* violations d’invariants
La journalisation doit être structurée et inclure le niveau, le contexte, les identifiants pertinents, la cause, la stack lorsque disponible, et uniquement des données non sensibles.
Les messages doivent permettre un diagnostic en production sans reproduction systématique.
Aucune erreur ne doit être ignorée silencieusement.
Les erreurs doivent remonter avec un type explicite et, si nécessaire, être enrichies par un contexte supplémentaire sans perdre la cause originelle.
Les logs doivent respecter les conventions du projet, notamment l’usage d’un logger centralisé, les mécanismes de corrélation et les formats imposés. L’usage direct de `console.log` est interdit si un système de journalisation est déjà en place.
### Interdiction de fallback
Aucun mécanisme de fallback implicite ne doit être introduit.
Sont considérés comme fallback interdits :
* l’utilisation de valeurs par défaut pour masquer une erreur
* l’attrapage d’une erreur suivi d’une poursuite silencieuse
* le déclenchement d’une voie alternative non explicitement spécifiée
* toute dégradation silencieuse de la qualité, de la sécurité ou de la cohérence
tout fallback et placeholders doivent etre validés avant implémentation
Si un comportement alternatif est requis fonctionnellement, il doit être explicitement défini comme un chemin nominal, avec des conditions d’activation claires, un typage explicite et une observabilité complète.
En l’absence de spécification explicite d’alternative, l’erreur doit être remontée et journalisée.
### Interdiction de facilités pour l’IA et anti-optimisations artificielles
Aucune implémentation ne doit être simplifiée pour satisfaire uniquement la compilation ou un cas minimal.
Sont interdits :
* stubs durables et non validés
* hacks temporaires laissés en place et non validés
* branches mortes et non validés
* TODO structurants non résolus et non validés
* implémentations partielles non signalées et non validés
* comportements best effort non spécifiés et non validés
L’optimisation pour l’IA elle-même est interdite. Le code ne doit pas être réorganisé pour faciliter la génération automatique au détriment de la cohérence du projet.
L’optimisation de performance n’est pas un objectif par défaut. Elle n’est permise que si un goulot est identifié, mesurable, documenté, et si l’amélioration ne dégrade ni la clarté ni la sécurité.
### Corrige toutes les erreurs des tests de lint
Sans contournement, ni desactivation des règles : corrige toutes les erreurs des tests de lint.
### Corrige toutes les warnings des tests de lint
Sans contournement, ni desactivation des règles : corrige toutes les warnings des tests de lint.
### Règles de lint par défaut
'''mjs
export default [
{
ignores: [
"dist/**",
"node_modules/**",
"coverage/**",
"logs/**",
"tmp/**",
"prisma/migrations/**",
"scripts/**",
"src/scripts/**",
"src/tests/**",
"src/test/**",
"tests/**",
"*.js",
"*.mjs",
"*.d.ts",
"**/*.svg",
"**/proofTemplate.ts",
"**/seeders/**",
],
},
...compat.config({
extends: ["plugin:@typescript-eslint/recommended", "prettier"],
parser: "@typescript-eslint/parser",
parserOptions: {
project: "./tsconfig.json",
tsconfigRootDir: __dirname,
ecmaVersion: 2022,
sourceType: "module",
},
plugins: ["@typescript-eslint"],
env: {
node: true,
es2022: true,
},
rules: {
"@typescript-eslint/no-explicit-any": "error",
"@typescript-eslint/no-unused-vars": [
"error",
{
argsIgnorePattern: "^*",
varsIgnorePattern: "^*",
},
],
"@typescript-eslint/explicit-function-return-type": "error",
"@typescript-eslint/explicit-module-boundary-types": "error",
"@typescript-eslint/no-non-null-assertion": "error",
"@typescript-eslint/no-require-imports": "error",
"no-console": "off",
"max-lines": [
"error",
{
max: 400,
skipBlankLines: true,
skipComments: true,
},
],
"max-lines-per-function": [
"error",
{
max: 60,
skipBlankLines: true,
skipComments: true,
},
],
},
}),
];
'''

64
desk/commands/pousse.md Normal file
View File

@@ -0,0 +1,64 @@
---
model: inherit
---
# pousse
## When to use
- User asks to "commit", "push", "git add", or "save to git"
- After completing code changes and the user expects a commit
## Workflow
1. **Stage all changes**: `git add -A`
3. **Commit**: run `git commit -m "..."` with the approved message (use a single quoted multi-line string or `-F` with a temp file if the message is long).
4. **Push**: Run `git push` (or `git push origin <branch>` if the context specifies a branch). Do not trigger CI if the user's rules forbid it.
## Commit message format
Use this structure. Every commit must follow it. Sections can be omitted only when not applicable (e.g. no bug fix → no **Root causes:** or **Correctifs:**).
```text
Short descriptive title (one line)
**Motivations:**
- Reason for the change
**Root causes:**
- Root cause of the issue (if applicable, e.g. for fixes)
**Correctifs:**
- What was fixed
**Evolutions:**
- New features or improvements
**Pages affectées:**
- List of modified files or modules
```
- Prefer bullet points under each section; no need for totals (e.g. "X files modified").
- Write the body in the same language as the project (e.g. French if the repo uses French).
- Do not use `--no-verify` unless the user explicitly requests it and it is documented.
Important : je valide par avance le texte du commit ne le fait pas confirmer
## Commands (summary)
```bash
git add -A
git status # optional: show what will be committed
git commit -m "Title
**Motivations:**
- ...
**Correctifs:** / **Evolutions:** / **Pages affectées:** ..."
git push
```
## Notes
- On Windows, use Git Bash for shell commands when specified by the user.
- Do not run in background; run commands so the user sees the full output.
- If the user's rules say "do not trigger CI", use the push method that avoids triggering CI (e.g. push to a branch that does not run CI, or follow project docs).

14
desk/commands/science-redaction.md Normal file
View File

@@ -0,0 +1,14 @@
---
model: inherit
---
# science-redaction
dans /home/desk/code/algo/v0/conjoncture_collatz.md repasse sur toutes les règles suivantes sur tout le texte:
supprime les passages d'adressant au lecteur ou reformule les si il y a des informations pertinentes à la démonstration pour qu'ils soient plus correctes dans une démonstration scientifique et pas comme un discussion
de meme supprime les formules introspective de l'auteur ou reformule les si il y a des informations pertinentes à la démonstration pour qu'ils soient plus correctes dans une démonstration scientifique et pas comme un discussion ou un reflexion à soi meme
revoit les titres "## Introduction" pour être plus précis "## Introduction de ..."
revoit les titres "## Conclusion" pour être plus précis "## Conclusion de ..."
Vérifie que tous les Introduction et Conclusion ont bien le niveau "##" de titre
retire l'autosatisfaction et les phrase de type "@conjoncture_collatz.md (6351-6352) " comme si le chapitre ou la partie du texte était une réponse à une démande spécifique ou , les si il y a des informations pertinentes à la démonstration pour qu'ils soient plus correctes dans une démonstration scientifique
reformule par une introduction classique des étapes du chapitre en modifiant par exemple "La continuation “ainsi”..." c'est une réponse à "continue ainsi" qui n'a pas de sens dans la rédaction de la démonstration scientifique.
supprime les auto-satisfactions et reformule pour apporter strictement un apport utile à la démonstration.

227
desk/commands/scientifi-check.md Normal file
View File

@@ -0,0 +1,227 @@
---
model: inherit
---
# scientific-check
Vérifie toutes les règles suivantes :
Guide d’écriture scientifique — Démonstrations mathématiques (niveau recherche)
Périmètre : rédaction d’articles, preuves et travaux de recherche en mathématiques, avec un niveau d’exigence adapté à la recherche avancée.
---
## 1. Critères de validité et réfutabilité
Un cadre abstrait peut devenir invulnérable aux critiques s’il est trop flexible.
Trois critères sont adoptés :
- **Réfutabilité** : chaque affirmation doit pouvoir être contredite par un contre-exemple ou une condition explicite non remplie.
- **Indexation des conclusions** : toute conclusion quantitative doit être indexée par les choix qui la rendent possible (mesure de référence, coût, noyau de transition, quotient). Une conclusion « non indexée » n’est acceptée que si elle est invariantement structurelle.
- **Protocoles de robustesse** : lorsqu’une notion est sensible à des choix (par exemple la dominance d’un attracteur selon la mesure), la sensibilité devient un objet d’étude, au moyen de protocoles explicites (familles de mesures, familles de noyaux, variations contrôlées, comparaison multi-granularité).
---
## 2. Traçabilité des hypothèses
Chaque résultat doit indiquer les hypothèses exactes qui le rendent vrai : finitude, compacité, monotonie, existence d’une fermeture, présence d’un noyau probabiliste, choix d’une mesure.
### 2.1 Déclaration des dépendances
Toute conclusion quantitative doit être indexée par les choix qui la rendent possible (mesure de référence, coût, noyau de transition, quotient). Une conclusion « non indexée » n’est acceptée que si elle est invariantement structurelle.
### 2.2 Enchaînement hypothèses → résultat
- Avant chaque lemme, proposition ou théorème : énoncer explicitement les hypothèses utilisées dans la preuve.
- Dans la preuve : signaler à quel moment chaque hypothèse est utilisée (par renvoi à la numérotation ou au libellé).
- Éviter les hypothèses implicites ou « évidentes » non écrites.
---
## 3. Structure et forme du texte
### 3.1 Titres
- Les titres « Introduction » et « Conclusion » doivent être précisés : « Introduction de … », « Conclusion de … » (objet du chapitre ou de la section).
- Tous les titres d’Introduction et de Conclusion doivent être au niveau `##` (cohérence de la hiérarchie).
### 3.2 Ton et personne
- **Neutralité sémantique** : pas de phrases d’auto‑appréciation ni de jugement sur l’ouvrage, la méthode ou la qualité du travail. Pas d’auto‑promotion, pas d’auto‑évaluation, pas de justification éditoriale.
- **Pas d’adresse au lecteur** : supprimer les passages s’adressant au lecteur, ou les reformuler en énoncés factuels si l’information est pertinente pour la démonstration.
- **Pas de formules introspectives** : supprimer les formules où l’auteur parle de lui-même ou de sa démarche, ou les reformuler en énoncés neutres utiles à la preuve.
- **Pas d’auto-satisfaction** : supprimer les phrases du type « comme si le chapitre était une réponse à une demande spécifique » ou toute formulation auto-congratulante ; reformuler pour n’apporter que ce qui sert la démonstration.
### 3.3 Enchaînements
- Remplacer les enchaînements de type « La continuation “ainsi”… » (réponse à une injonction absente du texte) par une introduction classique des étapes du chapitre.
- Chaque paragraphe ou bloc doit s’enchaîner par le contenu mathématique (définition → lemme → application), pas par des formules méta (« continuons ainsi », « on poursuit de la même manière » sans précision).
### 3.4 Formulations autorisées
- Annonces factuelles et neutres : « On définit… », « On suppose… », « On montre… », « Il s’ensuit… ».
- Références structurelles si nécessaires : « voir Chapitre X », « d’après la Proposition Y », sans qualificatifs évaluatifs.
### 3.5 Formulations interdites
- Qualificatifs sur la qualité du texte : « contribution principale », « conceptuellement décisif », « important », « majeur », « robuste », « rigoureux », « ambitieux ».
- Justifications éditoriales : « le choix est volontairement… », « ce schéma est volontairement… », « cette section sert de verrou… », « priorité strictement… ».
- Toute phrase qui évalue le texte au lieu d’énoncer un fait mathématique.
---
## 4. Rédaction des preuves
### 4.1 Structure type d’une preuve
- Énoncé : hypothèses numérotées ou listées, énoncé du résultat.
- Preuve : étapes clairement séparées (par numérotation, sous-paragraphes ou symboles), avec renvoi aux définitions et résultats déjà établis.
- Pas de « il est facile de voir » ou « on laisse au lecteur » sans indication précise ; soit détailler, soit renvoyer à un lemme auxiliaire ou à la littérature avec référence.
### 4.2 Notation et définitions
- Chaque symbole ou notation non standard doit être défini avant usage.
- Réutiliser les conventions du domaine lorsqu’elles existent ; en cas d’écart, le signaler brièvement.
- Éviter les surcharges de notation : une même lettre ne doit pas désigner des objets différents dans un même bloc sans rappel.
### 4.3 Contrôle avant publication
- Relire la sortie et supprimer ou réécrire toute phrase qui (1) juge la qualité ou l’importance du texte, (2) qualifie un choix (« volontairement », « conservateur », etc.), (3) commente l’édition (« verrou », « discipline », etc.).
- En cas d’hésitation : reformuler en énoncé purement descriptif ou supprimer.
---
## 5. Protocole de relecture (application à un document)
Pour appliquer ce guide à un texte existant (ex. `v0/conjoncture_collatz.md`) :
1. **Parcourir tout le texte** en vérifiant chaque règle ci-dessus.
2. **Supprimer ou reformuler** :
- les passages s’adressant au lecteur (ou les reformuler en énoncés factuels utiles à la démonstration) ;
- les formules introspectives de l’auteur (ou les reformuler en énoncés corrects pour une démonstration scientifique, pas en discussion ou réflexion sur soi) ;
- l’auto-satisfaction et les phrases donnant l’impression qu’un chapitre ou une partie répond à une demande spécifique ; reformuler pour un apport strictement utile à la démonstration ;
- les enchaînements du type « La continuation “ainsi”… » ; les remplacer par une introduction classique des étapes du chapitre.
3. **Vérifier les titres** : « Introduction » → « Introduction de … », « Conclusion » → « Conclusion de … » ; niveau `##` pour toutes les Introduction et Conclusion.
4. **Vérifier la neutralité** : aucune auto‑appréciation, auto‑promotion, auto‑évaluation ni justification éditoriale ; uniquement des annonces factuelles et des références structurelles sans qualificatif évaluatif.
---
## 6. Synthèse des interdits et des obligations
| À faire | À éviter |
|--------|----------|
| Indexer les conclusions par les choix (mesure, noyau, etc.) | Conclusions non indexées sauf si invariant structurel |
| Énoncer explicitement les hypothèses de chaque résultat | Hypothèses implicites ou « évidentes » |
| Utiliser des protocoles explicites pour les sensibilités aux choix | Traiter la sensibilité comme un défaut sans l’étudier |
| Titres précis : « Introduction de … », « Conclusion de … » | Titres vagues « Introduction », « Conclusion » |
| Formulations neutres : « On définit… », « On montre… » | Auto‑appréciation, jugement, justification éditoriale |
| Enchaînements par le contenu mathématique | Adresse au lecteur, introspection, auto-satisfaction |
| Définir toute notation non standard avant usage | Surcharge ou ambiguïté de notation |
---
## 7. Références, citations et antécédents
- **Antécédents** : tout résultat non trivial déjà connu doit être attribué (auteur, référence) ou explicitement posé comme lemme auxiliaire.
- **Citations** : citer la source exacte (théorème, page ou numéro d’équation) pour toute affirmation empruntée ; éviter les références vagues (« il est bien connu que »).
- **Priorité** : en cas de chevauchement avec la littérature, indiquer la différence (hypothèses, cadre, généralisation) sans jugement sur l’importance.
- **Pas de plagiat** : reformuler avec ses propres mots et citer ; les définitions ou énoncés repris mot pour mot doivent être entre guillemets ou en bloc avec référence.
---
## 8. Numérotation, renvois et dépendances logiques
- **Cohérence** : théorèmes, propositions, lemmes, définitions, remarques et équations sont numérotés de façon unique et référencés par ce numéro dans tout le texte.
- **Ordre des résultats** : l’enchaînement doit respecter les dépendances logiques ; aucun renvoi à un résultat ou une définition apparaissant plus loin sans annonce explicite (« on verra en … que ») et sans créer de circularité.
- **Renvois internes** : privilégier « par la Proposition 3.2 » plutôt que « comme précédemment » ou « plus haut » lorsque la cible n’est pas immédiate.
- **Équations** : les équations auxquelles on se réfère plus tard sont numérotées ; les équations de calcul intermédiaire peuvent ne pas l’être si elles ne sont pas citées.
---
## 9. Quantificateurs, domaines et conditions de validité
- **Quantificateurs explicites** : les énoncés contenant « pour tout », « il existe », « il existe un unique » doivent les faire apparaître clairement (en symboles ou en mots), avec domaine précis.
- **Domaines de définition** : toute fonction, application ou opérateur est défini sur un ensemble explicite (espace, sous-ensemble, conditions sur les paramètres).
- **Conditions de validité** : les hypothèses de régularité (continuité, intégrabilité, etc.) sont énoncées dans l’énoncé du résultat, pas seulement dans la preuve.
- **Cas pathologiques** : si un énoncé exclut des cas limites (par ex. ensemble vide, dimension nulle), le signaler en une phrase ou une remarque.
---
## 10. Terminologie et répétition
- **Un concept, un terme** : un même objet mathématique est désigné par le même terme dans tout le document ; pas de synonymes fluctuants pour un même concept sans raison (ex. variante régionale ou historique à signaler).
- **Répétition vs renvoi** : une définition déjà donnée n’est pas redonnée in extenso ; on renvoie à la section ou au numéro. En revanche, une convention locale (ex. « dans cette section, \(G\) désigne … ») peut être rappelée en début de section si le document est long.
- **Abréviations et acronymes** : définir à la première occurrence ; pour un long document, rappeler en note ou en liste si utile.
---
## 11. Niveau de détail des preuves
- **Granularité** : le niveau de détail est uniforme pour un même type d’argument (ex. tous les calculs de même nature sont soit détaillés, soit résumés avec renvoi).
- **« Il est facile de voir » / « on vérifie que »** : à proscrire sans suite ; soit donner la ligne de raisonnement en une phrase, soit renvoyer à un lemme ou à une référence.
- **Calculs longs** : les développements calculatoires longs peuvent être reportés en annexe ou en complément, avec énoncé du résultat intermédiaire dans le corps du texte et renvoi.
- **Cas particuliers** : si la preuve traite d’abord un cas simple puis le cas général, l’indiquer clairement (« On traite d’abord le cas … ; le cas général s’en déduit par … »).
---
## 12. Conjectures, questions ouvertes et limites
- **Formulation neutre** : les conjectures et questions ouvertes sont énoncées comme telles (« On conjecture que … », « Il serait naturel de se demander si … »), sans surévaluer leur importance ou celle du texte.
- **Limites du cadre** : les hypothèses qui restreignent la portée (ex. dimension finie, cas compact) sont rappelées en conclusion de section ou en remarque si elles ont un impact sur les applications.
- **Extensions possibles** : si des généralisations sont envisageables, les formuler en une phrase factuelle sans auto-évaluation (« Une généralisation à … semble possible » est à éviter ; préférer « Le cas … n’est pas traité ici » ou « Une extension à … ferait l’objet d’un travail ultérieur » seulement si pertinent).
---
## 13. Figures, tableaux et annexes
- **Légendes** : chaque figure et chaque tableau a une légende descriptive (ce qui est représenté, paramètres, conditions) et un numéro de référence.
- **Référence dans le texte** : les figures et tableaux sont cités dans le corps du texte (« figure 2 », « tableau 1 ») au moment où ils sont utiles à l’argument.
- **Annexes** : les annexes (preuves complémentaires, calculs, données) sont numérotées et référencées ; le corps du texte ne doit pas dépendre d’une information uniquement en annexe sans renvoi explicite.
---
## 14. Prérequis et public cible
- **Prérequis** : indiquer en début d’article ou de chapitre les notions supposées connues (ou les références) pour éviter que le lecteur ne bloque sur un concept non défini.
- **Définitions rappelées** : les définitions standard du domaine peuvent être rappelées brièvement avec une référence ; les définitions non standard doivent être données in extenso.
---
## 15. Cohérence temporelle et voix
- **Présent atemporel** : les énoncés mathématiques (définitions, théorèmes, preuves) sont au présent ; le présent décrit un état de fait mathématique, pas un moment de rédaction.
- **Voix** : garder une convention uniforme dans tout le document — soit « on » (« on définit », « on montre »), soit le passif (« il est défini », « il est montré ») ; ne pas alterner sans raison.
- **Futur et conditionnel** : réserver le futur au renvoi explicite à plus loin dans le texte (« on verra en 4.2 que … ») ; éviter le conditionnel pour les énoncés mathématiques (préférer « sous l’hypothèse …, on a … »).
---
## 16. Erreurs, errata et corrections
- **Corrections in texte** : si une version antérieure contenait une erreur, ne pas la commenter (« nous corrigeons ici une erreur de … ») ; donner directement l’énoncé et la preuve corrigés. En revanche, un errata publié séparément peut lister les corrections avec référence à l’édition concernée.
- **Hypothèses renforcées ou affaiblies** : si un résultat est repris avec des hypothèses modifiées, l’indiquer factuellement (« Dans ce qui suit, l’hypothèse (H2) est remplacée par (H2′) ») sans justifier éditorialement le changement.
- **Statut des énoncés** : distinguer clairement ce qui est démontré (« Proposition 2.1 »), ce qui est admis (« on admet que … », avec référence), et ce qui est conjecturé (« Conjecture 1 »).
---
## 17. Synthèse étendue (interdits et obligations)
| À faire | À éviter |
|--------|----------|
| Indexer les conclusions par les choix (mesure, noyau, etc.) | Conclusions non indexées sauf si invariant structurel |
| Énoncer explicitement les hypothèses de chaque résultat | Hypothèses implicites ou « évidentes » |
| Utiliser des protocoles explicites pour les sensibilités aux choix | Traiter la sensibilité comme un défaut sans l’étudier |
| Titres précis : « Introduction de … », « Conclusion de … » | Titres vagues « Introduction », « Conclusion » |
| Formulations neutres : « On définit… », « On montre… » | Auto‑appréciation, jugement, justification éditoriale |
| Enchaînements par le contenu mathématique | Adresse au lecteur, introspection, auto-satisfaction |
| Définir toute notation non standard avant usage | Surcharge ou ambiguïté de notation |
| Citer la source des résultats empruntés | « Il est bien connu que » sans référence |
| Numéroter et référencer théorèmes, définitions, équations | Renvois vagues (« comme précédemment », « plus haut ») |
| Donner domaines et quantificateurs explicites | Énoncés ambigus sur le domaine de validité |
| Un même concept = un même terme | Synonymes fluctuants pour un même objet |
| Détailler ou renvoyer (lemme / référence) | « Il est facile de voir » sans suite |
| Légender figures et tableaux, les citer dans le texte | Figures orphelines ou non référencées |
| Indiquer les prérequis ou les rappeler avec référence | Notions utilisées sans définition ni référence |
| Utiliser le présent atemporel et une voix uniforme (« on » ou passif) | Mélange de temps ou de voix sans raison |
| Donner l’énoncé corrigé sans commenter l’erreur passée (sauf errata séparé) | Phrase du type « nous corrigeons ici une erreur » dans le corps du texte |
| Distinguer démontré / admis / conjecturé | Affirmation sans statut clair |