corentin_wakdo/docs/journal
Corentin JOGUET 7a2528a280
Some checks failed
CI / secret-scan (push) Successful in 22s
CI / php-lint (push) Has been cancelled
CI / static-tests (push) Has been cancelled
CI / js-tests (push) Has been cancelled
docs(journal): retro de session 2026-06-18 (#59)
2026-06-18 14:51:32 +02:00
..
2026-04-23--cadrage-projet.md docs: add RNCP 37805 referentiel and fix Cr 4.f mappings 2026-04-24 15:27:06 +00:00
2026-04-24--infra-docker.md feat(docker): complete stack with compose and 4 services 2026-04-24 15:59:19 +00:00
2026-04-30--smoke-test-infra.md docs: journal entry for session 4 smoke test infra 2026-04-30 11:52:45 +00:00
2026-06-04--conception-prodlike-revision.md docs: journal entry for 2026-06-04 prod-like conception decisions 2026-06-04 10:19:25 +00:00
2026-06-15--p3-throttle-pin-rg-t22.md feat(admin): throttle du PIN d action sensible par acteur (RG-T22) (#18) 2026-06-16 00:06:33 +02:00
2026-06-16--audit-reel-livrables-p2-p3.md docs(journal): audit reel des livrables P2/P3 (2026-06-16) (#22) 2026-06-16 14:19:48 +02:00
2026-06-17--makefile-to-compose-migrate.md chore: remplace le Makefile par un service compose wakdo-migrate (migrate + seed idempotents) (#40) 2026-06-17 15:07:05 +02:00
2026-06-17--session-infra-doc-e2e.md docs(journal): retro de session 2026-06-17 (infra, doc, E2E) (#47) 2026-06-17 17:15:33 +02:00
2026-06-18--front-login-ui-admin-p4-commande.md docs(journal): retro de session 2026-06-18 (#59) 2026-06-18 14:51:32 +02:00
README.md docs(journal): audit reel des livrables P2/P3 (2026-06-16) (#22) 2026-06-16 14:19:48 +02:00

Journal du projet Wakdo

Ce dossier contient les retrospectives de chaque session de travail et de chaque feature livree. Il est destine :

  1. A moi pour la revision de l'oral de certification RNCP
  2. 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
2026-06-16 audit-reel-livrables-p2-p3 Verification sur pieces des livrables du 2026-06-15 (sweep 10 dimensions + adversarial) : socle SbD confirme, miss confirmes par gravite (php.ini non deploye, CI sans tests DB, XSS kiosk, liens morts...) et remediations docs/journal-audit-2026-06-16 -> dev (PR #19/#20/#21)

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

  1. Factuel d'abord : decrire ce qui a ete fait avant d'expliquer pourquoi.
  2. Pas d'emoji (mantra IA-23).
  3. Sources citees pour toute affirmation technique absolue (voir .claude/rules/fact-check.md).
  4. Liens vers les fichiers avec chemins relatifs depuis la racine (ex : src/Core/Router.php:42).
  5. Honnetete technique : si une decision a ete prise sans comprendre parfaitement, le dire. Le jury valorise la lucidite plus que la perfection.