5a4897921e
Some checks failed
CI / php-lint (push) Successful in 19s
CI / secret-scan (pull_request) Successful in 8s
CI / secret-scan (push) Successful in 10s
CI / static-tests (push) Successful in 30s
CI / php-lint (pull_request) Successful in 19s
CI / auto-merge (push) Has been skipped
CI / static-tests (pull_request) Successful in 30s
CI / auto-merge (pull_request) Failing after 4s
Ferme le finding HIGH de la revue Produits (#17) : le PIN d'action sensible etait verifie sans limitation de tentatives. Conception via panel multi-agents (3 lentilles + synthese + passe adversariale, holds=true) puis revue de l'implementation (holds=true). Dimension du throttle = UTILISATEUR AGISSANT (identite de session, RG-T02), pas l'email cible (contournable par rotation) ni l'IP (collateral sur poste partage). Table dediee pin_throttle (entite 22) STRICTEMENT SEPAREE des compteurs de login (user.failed_login_attempts / login_throttle) : un echec de PIN n'incremente aucun compteur de connexion (pas d'escalade DoS vers le login). - db/migrations/0002_pin_throttle.sql : table cle sur actor_user_id (UNIQUE, FK -> user ON DELETE CASCADE), separee du login. Appliquee a la base dev. - ThrottlePolicy : dimension 'pin' (bornes propres PIN_THROTTLE_*, 30s..300s, plus permissives que le login : controle de dissuasion, residuel Faible). - PinThrottle (nouveau) : isLocked / recordFailure (upsert atomique + backoff, une transaction, miroir d'AuthService) / reset (UPDATE simple). N'ecrit jamais user/login_throttle/audit_log. - PinVerifier::payTimingDecoy : parite de timing du chemin verrouille. - ProductController update/destroy : gate AVANT verification (leurre + 422 generique, pas de pin.failed sous verrou actif = borne anti-flood de l'audit) ; recordFailure sur PIN faux ; reset sur succes, cle sur l'acteur de SESSION. - Docs Merise 21 -> 22 entites : RG-T22 (mlt), entite 22 pin_throttle (mcd/mld/dictionary), couverture MCT 22/22 (mct). - .env.example + docker-compose : PIN_THROTTLE_THRESHOLD/BASE/MAX/WINDOW. - Journal RNCP : docs/journal/2026-06-15--p3-throttle-pin-rg-t22.md. Tests : 188 verts (525 assertions), PHPStan L6 propre.
4.2 KiB
4.2 KiB
Journal du projet Wakdo
Ce dossier contient les retrospectives de chaque session de travail et de chaque feature livree. Il est destine :
- A moi pour la revision de l'oral de certification RNCP
- Au jury qui souhaite tracer la demarche projet et la reflexion technique
Chaque fichier suit le meme template (voir ci-dessous) pour faciliter la relecture.
Organisation
docs/journal/
README.md # ce fichier (index + template)
YYYY-MM-DD--nom-de-la-session.md # un fichier par session significative ou feature mergee
Nommage : YYYY-MM-DD--slug-court.md (ex : 2026-04-23--cadrage-projet.md).
Les fichiers sont ordonnes chronologiquement par leur nom.
Index des sessions
| Date | Fichier | Sujet | Branche / PR |
|---|---|---|---|
| 2026-04-23 | cadrage-projet | Analyse brief RNCP, decisions d'architecture, bootstrap Git | main (commit initial) |
| 2026-04-24 | infra-docker | Stack Docker complete (compose + 4 services), referentiel RNCP integre, cross-check mappings Cr 4.f | feat/infra-docker |
| 2026-04-30 | smoke-test-infra | Smoke test bout-en-bout sur serveur reel : fusion .env, switch FQDN sur stark.a3n.fr, subnet explicite RFC 1918, fix init cron + healthz | feat/infra-docker |
| 2026-06-04 | conception-prodlike-revision | Revue d'alignement P1 + decisions prod-like du modele de donnees (drop commande_event, nommage EN, TVA par produit apres fact-check BOFiP, perso menus/ingredients, allergenes, ~16 entites) | feat/p1-conception |
| 2026-06-15 | p3-throttle-pin-rg-t22 | P3 securite : throttle du PIN d'action sensible (RG-T22) — design multi-agents + verification adversariale, dimension "utilisateur agissant", entite 22 pin_throttle |
feat/p3-pin-throttle -> dev |
Mis a jour a chaque nouvelle entree.
Template d'une entree
Copier ce bloc pour chaque nouvelle session ou feature :
# [Titre clair de la session ou feature]
**Date** : YYYY-MM-DD
**Branche** : `feat/xxx` ou `main`
**PR** : #n (ou "commit direct" si applicable)
**Duree estimee** : Xh
---
## Ce qui a ete fait
Description factuelle : quels fichiers, quelle feature, quel resultat concret.
Rester descriptif, pas interpretatif. Le "pourquoi" vient apres.
---
## Pourquoi — decisions et alternatives
Pour chaque choix technique significatif :
- **Decision** : [ce qui a ete retenu]
- **Alternatives considerees** : [les autres pistes]
- **Raison du choix** : [contraintes, tradeoffs, criteres]
C'est la section la plus importante pour l'oral. Le jury testera souvent : *"Pourquoi X plutot que Y ?"*
---
## Comment — points techniques cles
2 a 4 decisions d'implementation qui meritent une explication detaillee.
Extraits de code courts si pertinent, liens vers les fichiers concernes.
---
## Criteres RNCP couverts
Mapping explicite avec le referentiel (RNCP 37805) :
- **Bloc X - Critere Y.z** : [comment ce livrable y repond, avec reference au fichier]
- ...
---
## Questions anticipees du jury
Les questions que le jury pourrait poser sur cette session, avec les reponses preparees :
- **Q** : "..."
**R** : [reponse concise, tenue]
- **Q** : "..."
**R** : ...
---
## Points d'amelioration conscients
Ce qui a ete laisse volontairement imparfait, avec la raison. Montrer la maturite technique : savoir ce qui n'est pas optimal et pourquoi on a choisi de ne pas l'optimiser maintenant.
- [Point] : [pourquoi c'est laisse en l'etat + quand ca sera traite]
---
## Liens vers artefacts
- Commit(s) : `abc1234`, `def5678`
- Fichiers principaux : `path/to/file.php`, ...
- Documentation associee : `docs/xxx.md`
Regles de redaction
- Factuel d'abord : decrire ce qui a ete fait avant d'expliquer pourquoi.
- Pas d'emoji (mantra IA-23).
- Sources citees pour toute affirmation technique absolue (voir
.claude/rules/fact-check.md). - Liens vers les fichiers avec chemins relatifs depuis la racine (ex :
src/Core/Router.php:42). - Honnetete technique : si une decision a ete prise sans comprendre parfaitement, le dire. Le jury valorise la lucidite plus que la perfection.