{
    "items": [
        {
            "id": "d17d2d74",
            "project": "PELLET",
            "action": "Créer 2 docs de référence dans Drive/PELLET : (1) \\\"PELLET — Mail Fred 26-06\\\" avec le texte du mail envoyé (objet: Pellet Frères — Actions à engager) ; (2) \\\"PELLET — Devis A & B juin 2026\\\" avec la structure des 2 devis. DEVIS A (sous 3.1) — Audit Phase 1 traces numériques Pellet Entreprise + corrections prioritaires : 1600€ HT / TVA 320€ / 1920€ TTC. DEVIS B (sous 3.1) — Quick wins com : ligne1 Lien avis Google Extrabat 250€ HT + ligne2 Harmonisation signatures mail 350€ HT = 600€ HT / TVA 120€ / 720€ TTC. Validité 30j, TVA 20%, à l'attention de Fred Pellet.",
            "status": "done",
            "createdAt": "2026-06-26T15:33:47Z",
            "doneAt": "2026-06-29T09:56:39Z"
        },
        {
            "id": "82eca7f5",
            "project": "QG",
            "action": "PROTÉGER L'ÉTAT QG CONTRE LA PERTE DE DONNÉES. Repo serveur MCP : D:\\xampp\\htdocs\\OD\\smrcvp.onlydev.fr (structure : public/index.php, src/Storage.php, src/Tools.php, src/McpServer.php, src/config.php). PRÉREQUIS : lire src/Storage.php ET src/Tools.php AVANT toute modif pour respecter les noms de méthodes existants (loadState/saveState ou autres) et la structure réelle. Ne PAS changer la signature publique des outils MCP (get_state/set_state/list_inbox/mark_done/push_instruction). === MODIF 1 — VERSIONING dans src/Storage.php : avant CHAQUE écriture de l'état (dans la méthode qui sauve state.json), copier l'ancien fichier state.json vers data/history/state_AAAA-MM-JJ_HHMMSS.json (créer le dossier data/history s'il n'existe pas, mkdir 0775 récursif). Ne jamais écraser sans archiver d'abord. Utiliser date('Y-m-d_His') pour l'horodatage. === MODIF 2 — MERGE NON-DESTRUCTIF dans src/Tools.php (logique set_state) : au lieu de remplacer l'état entier, charger l'état courant via get/load puis fusionner : priorite_semaine = nouvelle valeur SI fournie et non vide, SINON garder l'ancienne ; focus = nouveau SI array non vide, SINON garder l'ancien ; projets = fusion PAR NOM (indexer l'existant par champ 'nom', les projets entrants écrasent/ajoutent ceux du même nom, les autres projets sont CONSERVÉS) ; si projets entrant vide → garder tout l'existant. Un set_state vide ou partiel ne doit JAMAIS vider l'état. === MODIF 3 — TEST après implémentation : get_state (noter), set_state avec UN seul projet bidon, get_state → vérifier que les autres projets (PELLET, WINORWIN) sont TOUJOURS présents. Puis supprimer le projet test et restaurer l'état propre. === ATTENTION : ne pas casser le déploiement OVH (mscrpv.onlydev.fr) — ce sont les sources locales, à déployer après validation.",
            "status": "done",
            "createdAt": "2026-06-29T11:03:31Z",
            "doneAt": "2026-06-29T11:11:20Z"
        },
        {
            "id": "5205cafc",
            "project": "QG-INFRA",
            "action": "Mettre en place le tool drive_push sur le MCP OD (mscrpv.onlydev.fr). Auth = OAuth utilisateur compte perso sebastienonlydev@gmail.com, scope drive.file UNIQUEMENT (pas drive). Refresh token stocké hors webroot dans un .env perms 600, jamais versionné. IMPORTANT: publier l'app OAuth en mode 'In production' (Publishing status) sinon le refresh token expire à 7 jours. Le tool drive_push prend: name, content, folder_id (optionnel), file_id (optionnel pour update). RÈGLE DE RANGEMENT: tous les fichiers projet doivent être créés sous le dossier CLAUDESYNC (id Drive: 1rZ-Qfs2-JO2NgONCZD2dT7jbO5VzBs37), avec un sous-dossier par projet. Squelette PHP DriveClient + handler fourni par Sébastien.",
            "status": "done",
            "createdAt": "2026-06-29T11:38:43Z",
            "doneAt": "2026-06-29T12:29:22Z"
        },
        {
            "id": "6e8a6ede",
            "project": "Pellet",
            "action": "Ranger les docs Pellet au bon endroit sur Drive. Actuellement ils sont sous le parent 1YseY6uDsjDStXVhALDbSRzFay7EXGw8b (mauvais endroit). Les déplacer sous CLAUDESYNC (id: 1rZ-Qfs2-JO2NgONCZD2dT7jbO5VzBs37), dans un sous-dossier 'Pellet'. Fichiers concernés: 'PELLET — Devis A et B juin 2026' (id 1Tn_2mUVX6gbcP9YLgLwr6byWMvrxzXHV8H9qvYpw90g), 'PELLET — Mail Fred 26-06-2026' (id 12kWpILPvx4avwYCF7_od43JRQcHVypEJ69K60JPs-AA), 'PELLET — Phase 1 Audit Traces Pellet Entreprise' (id 17d9OBaiYLoJon2rKH1K6RrbPK7sysaIbDyeuUf1WKrc), 'PELLET — Actions concrètes post-RDV juin 2026' (id 1JL54tReiVDE76uRZVn4RAxQQ0bOgdWSSWipzt6KP_6c). NB: le déplacement de fichiers existants non créés par l'app nécessite le scope drive (pas drive.file) — soit faire ce rangement via un tool dédié à scope élargi ponctuel, soit déplacer manuellement. À arbitrer.",
            "status": "done",
            "createdAt": "2026-06-29T11:38:58Z",
            "doneAt": "2026-06-29T12:31:48Z"
        },
        {
            "id": "70b84dbc",
            "project": "QG-INFRA",
            "action": "Pour le chargement des credentials Google du tool drive_push : NE PAS utiliser vlucas/phpdotenv. Utiliser un parseur .env maison sans dépendance. Le .env est hors webroot, chmod 600, dans .gitignore. Format du .env (3 clés, pas d'espaces autour du =, pas de guillemets, pas d'espace en fin de ligne) : GOOGLE_CLIENT_ID=..., GOOGLE_CLIENT_SECRET=..., GOOGLE_REFRESH_TOKEN=... . Parseur à intégrer dans DriveClient::__construct() ou au bootstrap du MCP :\\n\\nforeach (file('/chemin/hors/webroot/.env', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES) as $line) {\\n    if ($line[0] === '#') continue;\\n    [$k, $v] = explode('=', $line, 2);\\n    putenv(trim($k) . '=' . trim($v));\\n}\\n\\nEnsuite getenv('GOOGLE_CLIENT_ID') etc. fonctionne dans DriveClient. Adapter le chemin réel du .env sur le serveur mscrpv.onlydev.fr.",
            "status": "done",
            "createdAt": "2026-06-29T11:46:45Z",
            "doneAt": "2026-06-29T12:29:22Z"
        },
        {
            "id": "cae8e2b1",
            "project": "QG-INFRA",
            "action": "Script get_refresh_token.php version localhost auto à fournir/utiliser pour générer le GOOGLE_REFRESH_TOKEN. Client OAuth = Desktop, app publiée In production, scope drive.file. Redirect URI http://localhost:8080 (à vérifier dans le client OAuth). Le script lance un mini-serveur stream_socket_server sur 127.0.0.1:8080 qui capture le code automatiquement (pas de oob, déprécié), puis échange code->refresh_token via https://oauth2.googleapis.com/token avec access_type=offline + prompt=consent. À lancer EN LOCAL par Sébastien, pas sur OVH. Code complet :\\n\\n<?php\\n$client_id='TON_CLIENT_ID';\\n$client_secret='TON_CLIENT_SECRET';\\n$redirect='http://localhost:8080';\\n$scope='https://www.googleapis.com/auth/drive.file';\\n$auth_url='https://accounts.google.com/o/oauth2/v2/auth?'.http_build_query(['client_id'=>$client_id,'redirect_uri'=>$redirect,'response_type'=>'code','scope'=>$scope,'access_type'=>'offline','prompt'=>'consent']);\\necho \\\"\\\\nOuvre:\\\\n$auth_url\\\\n\\\\n\\\";\\n$sock=stream_socket_server('tcp://127.0.0.1:8080',$errno,$errstr);\\nif(!$sock)die(\\\"Socket: $errstr ($errno)\\\\n\\\");\\n$code=null;\\nwhile($conn=stream_socket_accept($sock,60)){\\n  $req=fread($conn,4096);\\n  if(preg_match('/GET \\\\/\\\\?([^ ]*) /',$req,$m)){parse_str($m[1],$params);$code=$params['code']??null;}\\n  $msg=$code?\\\"Code recupere.\\\":\\\"Pas de code.\\\";\\n  fwrite($conn,\\\"HTTP/1.1 200 OK\\\\r\\\\nContent-Type: text/plain; charset=utf-8\\\\r\\\\n\\\\r\\\\n$msg\\\");\\n  fclose($conn);\\n  if($code)break;\\n}\\nfclose($sock);\\nif(!$code)die(\\\"Timeout\\\\n\\\");\\n$ch=curl_init('https://oauth2.googleapis.com/token');\\ncurl_setopt_array($ch,[CURLOPT_RETURNTRANSFER=>true,CURLOPT_POST=>true,CURLOPT_POSTFIELDS=>http_build_query(['code'=>$code,'client_id'=>$client_id,'client_secret'=>$client_secret,'redirect_uri'=>$redirect,'grant_type'=>'authorization_code'])]);\\n$res=json_decode(curl_exec($ch),true);\\ncurl_close($ch);\\nif(empty($res['refresh_token']))echo \\\"ABSENT: \\\".json_encode($res).\\\" -> revoquer sur myaccount.google.com/permissions puis relancer\\\\n\\\";\\nelse echo \\\"\\\\nREFRESH_TOKEN:\\\\n\\\".$res['refresh_token'].\\\"\\\\n\\\";\\n\\nNB si REFRESH TOKEN ABSENT: Google ne renvoie le refresh_token qu'à la 1re autorisation. Révoquer l'app sur myaccount.google.com/permissions puis relancer. Le token obtenu va dans .env OVH (GOOGLE_REFRESH_TOKEN=), chmod 600, hors webroot, jamais en chat.",
            "status": "done",
            "createdAt": "2026-06-29T11:57:58Z",
            "doneAt": "2026-06-29T12:29:22Z"
        },
        {
            "id": "017deabc",
            "project": "QG-INFRA",
            "action": "DEBUG get_refresh_token.php : retourne 'REFRESH TOKEN ABSENT : null'. L'app n'apparaît PAS dans myaccount.google.com/permissions (donc pas de consentement résiduel à révoquer). Le 'null' est suspect = réponse Google vide ou échec curl, pas juste un refresh_token manquant dans une réponse valide. À diagnostiquer dans cet ordre :\\n\\n1) Vérifier que l'URL d'auth générée contient BIEN les deux params access_type=offline ET prompt=consent (cause n°1). Les afficher/logger pour confirmer.\\n\\n2) Capturer la réponse brute Google avant json_decode pour voir l'erreur réelle :\\n   $raw = curl_exec($ch);\\n   var_dump($raw);\\n   echo curl_error($ch);\\n   Chercher: invalid_grant (code expiré, le code OAuth ne vit que quelques min), redirect_uri_mismatch, ou réponse vide.\\n\\n3) Si réponse vide / erreur curl SSL : rappel — Sébastien a déjà eu ce souci sur Windows (cert CA) résolu via cacert.pem + curl.cainfo dans php.ini pour le script Trello. Vérifier que curl a accès au bundle CA, sinon CURLOPT_CAINFO pointant sur cacert.pem. NE PAS désactiver CURLOPT_SSL_VERIFYPEER.\\n\\n4) Si invalid_grant sur code expiré : relancer le flux et aller plus vite entre autorisation navigateur et capture.\\n\\nRapporter la réponse brute Google (en masquant client_id/secret) pour identifier la cause exacte.",
            "status": "done",
            "createdAt": "2026-06-29T12:07:17Z",
            "doneAt": "2026-06-29T12:35:19Z"
        },
        {
            "id": "02ad5022",
            "project": "QG-INFRA",
            "action": "Intégrer la DOCTRINE QG (règles transverses héritées par TOUS les projets) dans le CLAUDE.md du QG (D:/PROJET/QG). MÉTHODE : d'abord LIRE le CLAUDE.md existant, puis FUSIONNER intelligemment (compléter sans dupliquer, signaler tout conflit à Sébastien plutôt qu'écraser aveuglément). Ne pas créer de doublons de règles déjà présentes.\\n\\n=== DOCTRINE QG À INTÉGRER ===\\n\\n[MISE À JOUR DU MCP / STATE QG]\\n- Déclenchement : UNIQUEMENT sur demande explicite de Sébastien ('j'ai fini', 'màj le QG'). Jamais de màj spontanée en cours de travail.\\n- Toujours get_state AVANT set_state (set_state remplace TOUT le state, ne jamais écraser à l'aveugle).\\n- Mettre à jour uniquement le projet concerné, garder les autres intacts.\\n- 5 champs disciplinés par projet : statut (en_cours/done/bloqué/en_attente), en_cours (factuel + daté), a_faire (la prochaine action concrète, pas un fourre-tout), risque (seulement si réel et actif).\\n- Màj priorite_semaine et focus si les priorités changent.\\n- Tout point concernant Claude.ai/Sébastien -> le rendre visible dans en_cours ou via une instruction.\\n\\n[COMPTE-RENDU DE SESSION / DRIVE]\\n- À chaque fin de session explicite, déposer un .md daté dans CLAUDESYNC/<projet>/ via drive_push.\\n- Nom : CR_<projet>_AAAA-MM-JJ.md\\n- Contenu : ce qui a été fait, décisions prises, points en suspens, prochaine action.\\n- Le state = photo de l'instant ; le CR = historique pérenne. Les DEUX, pas l'un ou l'autre.\\n\\n[FICHIERS / DRIVE]\\n- Tout livrable va dans CLAUDESYNC/<projet>/ via drive_push, jamais ailleurs.\\n- Scope drive.file uniquement.\\n\\n[SÉCURITÉ - NON NÉGOCIABLE]\\n- Aucun secret en clair où que ce soit : ni code, ni state, ni doc Drive, ni chat, ni CR.\\n- Tokens/clés -> uniquement .env hors webroot, chmod 600, dans .gitignore.\\n- Un secret qui apparaît quelque part par erreur -> le révoquer immédiatement, pas juste le masquer.\\n\\n[CONFIDENTIALITÉ CLIENTS]\\n- Jamais de noms d'end-clients réels dans le state, les CR ou les docs partagés. Anonymiser (Association A, Site X, EHPAD A...). Règle issue d'APCIAL, généralisée à tous les projets.\\n\\n=== FIN DOCTRINE ===\\n\\nAprès intégration : confirmer dans le state (en_cours du projet QG-MCP ou note) que la doctrine est en place, et signaler tout conflit rencontré avec l'existant.",
            "status": "done",
            "createdAt": "2026-06-29T12:43:01Z",
            "doneAt": "2026-06-29T12:57:12Z"
        },
        {
            "id": "a31c0222",
            "project": "QG-INFRA",
            "action": "Exposer drive_push comme VRAI tool MCP dans le manifeste JSON-RPC du serveur OD (mscrpv.onlydev.fr), à côté de get_state/set_state/push_instruction/list_inbox/mark_done. Objectif : tout projet branché sur le MCP OD le voit automatiquement, sans rien écrire dans son CLAUDE.md.\\n\\nSchéma d'entrée : project (string, requis), name (string, requis), content (string, requis), file_id (string, optionnel pour update).\\n\\nSÉCURITÉ STRUCTURELLE OBLIGATOIRE (à coder en dur côté serveur, pas en convention) : le fichier DOIT toujours atterrir dans CLAUDESYNC/<project>/. Le serveur force le parent = sous-dossier <project> sous CLAUDESYNC (id CLAUDESYNC: 1rZ-Qfs2-JO2NgONCZD2dT7jbO5VzBs37), crée le sous-dossier <project> s'il n'existe pas. INTERDIRE tout écriture hors de cette arborescence : pas de folder_id arbitraire accepté en paramètre, pas de chemin remontant. Même si l'appelant tente de pointer ailleurs, le serveur ignore et range sous CLAUDESYNC/<project>/. C'est une garantie côté serveur, non contournable par l'appelant.\\n\\nGarder scope drive.file. Une fois exposé, confirmer dans le state (QG-MCP) que drive_push est dans le manifeste + que la contrainte CLAUDESYNC/<project>/ est forcée serveur.",
            "status": "done",
            "createdAt": "2026-06-29T12:49:54Z",
            "doneAt": "2026-06-29T12:59:33Z"
        },
        {
            "id": "20535904",
            "project": "QG-INFRA",
            "action": "CORRECTION de l'instruction 02ad5022 (qui visait à tort le CLAUDE.md du projet QG). La DOCTRINE QG doit aller dans le CLAUDE.md GLOBAL ~/.claude/CLAUDE.md (sous Windows : C:\\Users\\developpeur\\.claude\\CLAUDE.md), PAS dans le CLAUDE.md d'un projet. Raison : le CLAUDE.md global est lu par Claude Code quel que soit le projet ouvert, donc tout nouveau projet hérite automatiquement des règles transverses sans rien configurer.\\n\\nMÉTHODE : lire le ~/.claude/CLAUDE.md global existant d'abord, fusionner sans dupliquer, signaler tout conflit. S'il n'existe pas, le créer.\\n\\nDOCTRINE À INTÉGRER (règles transverses, tous projets) :\\n\\n[MISE À JOUR MCP / STATE QG]\\n- Déclenchement : UNIQUEMENT sur demande explicite de Sébastien ('j'ai fini', 'màj le QG'). Jamais spontané.\\n- Toujours get_state AVANT set_state (set_state remplace TOUT, ne jamais écraser à l'aveugle).\\n- Màj uniquement le projet concerné, garder les autres intacts.\\n- 5 champs : statut (en_cours/done/bloqué/en_attente), en_cours (factuel+daté), a_faire (prochaine action concrète), risque (si réel et actif).\\n- Màj priorite_semaine/focus si priorités changent.\\n- Tout point concernant Claude.ai/Sébastien -> visible dans en_cours ou via instruction.\\n\\n[COMPTE-RENDU SESSION / DRIVE]\\n- À chaque fin de session explicite : déposer un .md daté dans CLAUDESYNC/<projet>/ via drive_push. Nom : CR_<projet>_AAAA-MM-JJ.md. Contenu : fait / décisions / en suspens / prochaine action. State = photo instant ; CR = historique pérenne. Les deux.\\n\\n[FICHIERS / DRIVE]\\n- Tout livrable dans CLAUDESYNC/<projet>/ via drive_push, jamais ailleurs. Scope drive.file. (Rappel : la contrainte CLAUDESYNC/<projet>/ est forcée côté serveur, cf instruction a31c0222.)\\n\\n[SÉCURITÉ - NON NÉGOCIABLE]\\n- Aucun secret en clair nulle part (code, state, doc Drive, chat, CR). Tokens/clés -> uniquement .env hors webroot, chmod 600, .gitignore. Secret apparu par erreur -> révoquer immédiatement.\\n- NB : le dossier QG est sous htdocs XAMPP (webroot) -> aucun secret ne doit y résider ; Sébastien prévoit de le déplacer hors webroot.\\n\\n[CONFIDENTIALITÉ CLIENTS]\\n- Jamais de noms d'end-clients réels dans state/CR/docs partagés. Anonymiser (Association A, Site X, EHPAD A...). Règle APCIAL généralisée à tous les projets.\\n\\nUne fois fait : confirmer dans le state (QG-MCP) que la doctrine est dans le CLAUDE.md global + signaler conflits éventuels.",
            "status": "done",
            "createdAt": "2026-06-29T13:00:02Z",
            "doneAt": "2026-06-29T13:00:47Z"
        },
        {
            "id": "40784f6a",
            "project": "digital",
            "action": "LOT 0 — Sécurisation table `encours` (référentiel taux de commissionnement). AVANT toute FK vers cette table. (1) Convertir `encours` de MyISAM vers InnoDB. (2) Convertir charset latin1 → utf8mb4. (3) Changer `Id` de tinyint(4) [plafond 127, déjà à 101 lignes] vers SMALLINT UNSIGNED AUTO_INCREMENT. Raison : MyISAM ignore silencieusement les contraintes FK et tinyint sature dans ~26 ajouts. Faire un dump de sauvegarde avant migration. VÉRIFIER au passage la ligne Id=61 libellé '40/12/8' : le JSON ne contient que tauxAnnee1:40,tauxAnnee2:12 — le '8' est perdu, confirmer avec Sébastien si coquille ou 3e année à modéliser.",
            "status": "done",
            "createdAt": "2026-06-30T14:03:03Z",
            "doneAt": "2026-07-02T09:09:42Z"
        },
        {
            "id": "5a004b3c",
            "project": "digital",
            "action": "LOT 1 — Migration BD table dossiers. Ajouter : `date_effet` DATE | `fd_societe` DECIMAL(10,2) NULL (frais dossier prélevés par notre société) | `fd_compagnie` DECIMAL(10,2) NULL (frais dossier compagnie) — LES DEUX peuvent coexister sur un même dossier, l'admin peut modifier les deux | `commissionnement_id` INT FK → encours.Id (déroulant, PAS de saisie libre — réutilise le référentiel encours qui gère TxUnique et TxDouble) | `compagnie_id` INT FK → table compagnies | `type_produit_id` INT FK → types_produits | `statut_paiement` ENUM('paye','impaye') | `commentaire_mandataire` TEXT NULL. Renommer le statut 'Conclure' → 'a_traiter' (statut d'entrée du process). Créer table `types_produits (id, libelle, couleur_hex)` avec seed : emprunteur=rouge, PNO=bleu, auto=violet (extensible). Créer table `notifications (id, mandataire_id, dossier_id, type, lu BOOLEAN, created_at)`.",
            "status": "done",
            "createdAt": "2026-06-30T14:03:13Z",
            "doneAt": "2026-07-02T09:09:44Z"
        },
        {
            "id": "57a1eeea",
            "project": "digital",
            "action": "LOT 2 — Vues + dashboard compteurs. Deux vues : mandataire (read-mostly) et admin (éditable). 7 tuiles compteurs : À traiter / En cours / Validés / À corriger / Invalidés / Commission en attente (€) / Commission payée (€). ATTENTION SCOPING : côté mandataire les compteurs sont SES dossiers (WHERE mandataire_id = ?), côté admin c'est le total tous mandataires (global) + tuile Total dossiers. NE PAS reproduire la maquette qui affiche les mêmes chiffres 12/8/25 sur les deux vues (cas de test à un seul mandataire). Colonnes liste : Produit (pastille couleur), Client, Compagnie, Date d'effet, Statut, Frais de dossier (afficher fd_societe ET/OU fd_compagnie), Commissionnement (libellé encours), Paiement (badge Payé/Impayé), Actions. Légende couleurs produits en bas.",
            "status": "done",
            "createdAt": "2026-06-30T14:03:20Z",
            "doneAt": "2026-07-02T09:09:45Z"
        },
        {
            "id": "a7ec8128",
            "project": "digital",
            "action": "LOT 3 — Déroulants + édition admin. (1) Déroulant Compagnie (sélection de la compagnie choisie pour le client — côté mandataire à la saisie + modifiable admin). (2) Déroulant Commissionnement alimenté par table encours (afficher libellé Nom ex '40/10', '25%' ; stocker commissionnement_id). (3) Déroulant Type produit (avec rendu pastille couleur). (4) Frais de dossier : DEUX champs montants éditables (fd_societe €, fd_compagnie €), admin peut modifier les deux. (5) Édition admin des documents déposés par les mandataires : Ajouter / Remplacer / Supprimer un document. Toute action destructive sur document doit être LOGUÉE dans l'Historique + protégée CSRF (cohérent avec l'audit sécu en cours sur ce projet). Clarifier 'Remplacer' = écrasement ou versioning.",
            "status": "done",
            "createdAt": "2026-06-30T14:03:30Z",
            "doneAt": "2026-07-02T09:09:46Z"
        },
        {
            "id": "77645b84",
            "project": "digital",
            "action": "LOT 4 — Recherche clients. Améliorer le moteur de recherche pour rechercher un client par Nom, Prénom OU e-mail (barre unique 'Rechercher par nom, prénom ou e-mail'). Présent sur les deux vues (mandataire scopé à ses dossiers, admin global). Combinable avec les filtres existants : Tous les produits / Tous les statuts / Date d'effet / (admin : Tous les mandataires) + bouton Réinitialiser.",
            "status": "done",
            "createdAt": "2026-06-30T14:03:34Z",
            "doneAt": "2026-07-02T09:09:48Z"
        },
        {
            "id": "86c37625",
            "project": "digital",
            "action": "LOT 5 — Workflow correction + notifications. Quand l'admin clique 'Demande de correction' sur un dossier : (1) envoyer une ALERTE E-MAIL automatique au mandataire concerné + (2) créer une notification IN-APP (table notifications, badge sur la cloche). Harmoniser le libellé : statut dossier 'À corriger' = action 'Demande de correction' (même concept). Prévoir flag dossier 'correction_vue' (pastille rouge sur le dossier tant que le mandataire n'a pas vu la demande). La cloche header affiche le compteur de notifs non lues. Boutons admin sur dossier sélectionné : Demande de correction / Invalider / Valider le dossier / Enregistrer.",
            "status": "done",
            "createdAt": "2026-06-30T14:03:40Z",
            "doneAt": "2026-07-02T09:09:51Z"
        },
        {
            "id": "33e5feb7",
            "project": "QG",
            "action": "Déployer un nouvel endpoint d'upload Drive sécurisé sur OVH (mscrpv.onlydev.fr), pour remplacer le passage du contenu fichier via le paramètre `content` de drive_push (trop lent : régénération token par token de plusieurs dizaines de Ko par fichier). Objectif : les machines de dev envoient le fichier en binaire via multipart/form-data ; seul OVH détient le refresh token Google et parle à l'API Drive.\n\nÉTAPES :\n\n1. Créer `drive_upload.php` à la racine web d'OVH. Spécification complète de l'endpoint :\n   - POST uniquement (sinon 405).\n   - Auth par secret partagé : header `X-Auth-Token` comparé en `hash_equals` à `DRIVE_PUSH_SECRET` chargé depuis le `.env` HORS webroot (au-dessus de la racine). Ne pas distinguer secret absent/faux (toujours 401).\n   - Rate limit basique 1 req/s/IP (stockage fichier dans sys_get_temp_dir, clé = sha256 de l'IP) → 429 si dépassé.\n   - Champ `file` en multipart/form-data (binaire). Vérifier is_uploaded_file + UPLOAD_ERR_OK. Taille max 25 Mo → 413.\n   - Validation nom de fichier : basename() pour neutraliser les chemins, refus si contient `/`, `\\`, `..`, ou \\0 ; regex autorisée `^[A-Za-z0-9._-]+$`.\n   - Whitelist d'extensions (REFUS par défaut) : php, html, htm, css, js, json, md, txt, sql, csv, xml, yml, yaml → sinon 415.\n   - Paramètre POST `project` (sous-dossier CLAUDESYNC) validé par regex `^[A-Za-z0-9_-]{1,64}$`. Paramètre `file_id` optionnel (regex `^[A-Za-z0-9_-]{10,200}$`) pour mise à jour d'un fichier existant.\n   - Appel à `DriveClient::push($content, $name, $project, $fileId)` — IMPORTANT : vérifier la signature RÉELLE de DriveClient::push() dans le code existant et adapter l'appel en conséquence (la signature supposée s'aligne sur drive_push : content, name, project, file_id). Ranger dans CLAUDESYNC/<project>/ comme drive_push.\n   - Log IP/projet/fichier/horodatage + statut (OK avec drive_id, ou ERROR avec message) dans un fichier de log HORS webroot (ex: ../logs/drive_upload.log). Créer le dossier logs/ si absent.\n   - Réponse JSON : {ok:true, file, project, drive_id} en succès ; {ok:false, error} sinon.\n\n2. Générer un secret robuste : `openssl rand -hex 32`. L'ajouter au `.env` d'OVH sous `DRIVE_PUSH_SECRET=...` (à côté du refresh token Google existant). Ne JAMAIS le committer ni le mettre dans le webroot.\n\n3. Vérifier que le `.env` et le dossier logs/ sont bien hors webroot et non servis par le serveur web (tester qu'une requête HTTP vers /.env et /logs/ renvoie 403/404).\n\n4. Tester l'endpoint depuis une machine de dev avec un petit fichier :\n   curl -sS -X POST https://mscrpv.onlydev.fr/drive_upload.php -H \"X-Auth-Token: $DRIVE_PUSH_SECRET\" -F \"file=@chemin/test.php\" -F \"project=TEST\"\n   Vérifier : 200 + drive_id retourné, fichier présent dans CLAUDESYNC/TEST/ sur le Drive, ligne de log écrite.\n\n5. Tester les cas d'erreur : mauvais secret → 401, extension interdite (ex .exe) → 415, nom avec ../ → 400, méthode GET → 405.\n\n6. Une fois validé : transmettre à Sébastien le secret généré (canal sûr) pour qu'il le place dans la variable d'env DRIVE_PUSH_SECRET de chacune de ses 2 machines de dev. Documenter la commande curl d'usage standard.\n\nNOTE SÉCU : l'archi choisie est centralisée OVH (le credential Google reste à un seul endroit) car Sébastien a 2 machines de dev — éviter de dupliquer le refresh token. Optionnel si IP de dev fixes : ajouter une whitelist d'IP en tête de script (ceinture + bretelles).",
            "status": "done",
            "createdAt": "2026-06-30T14:39:49Z",
            "doneAt": "2026-07-01T07:28:30Z"
        },
        {
            "id": "dd11c4cb",
            "project": "digital",
            "action": "SPEC D'ARBITRAGE DISPO : lire CLAUDESYNC/digital/ARBITRAGE_compta_v1.md (id Drive 1SCASu0sjKnDc8CbCYJCNcY7HblvEdEUA) AVANT de toucher compta.php/compta_admin.php. Ce doc réconcilie code déployé + maquette + 6 LOTs. Décisions actées : (1) on ENRICHIT l'existant, socle périodes/prélèvement conservé ; (2) statuts 3→5 états ; (3) NE PAS recréer les frais (fraisDossier/fraisDossierComp existent déjà) ; (4) encours = 3 taux, ajouter tauxAnnee3, ligne Id=61 MAJ avec 8 ; (5) Remplacer doc = écrasement simple. ORDRE IMPÉRATIF : commencer par la PHASE SÉCU (bloquante, avant tout LOT) sur compta_admin.php + config.php : sortir DB_USER/DB_PASS/COMPTA_ADMIN_PASS hors webroot ; remplacer la comparaison mdp admin en clair par password_hash/password_verify ; display_errors OFF en prod + log hors webroot ; CSRF sur les GET destructifs (del_file, supprimer) ; uploads/ hors webroot + download authentifié. Ne PAS enchaîner sur LOT 0 tant que SÉCU pas validée. 3 points restent à trancher avec Sébastien avant LOT2/3/5 (table compagnies ? passerelle e-mail ? base de calcul commission en attente/payée ?) — voir section 6 du doc.",
            "status": "done",
            "createdAt": "2026-07-01T08:48:31Z",
            "doneAt": "2026-07-02T09:09:52Z"
        },
        {
            "id": "7baef7a6",
            "project": "digital",
            "action": "MAJ SPEC v1.1 (ARBITRAGE_compta_v1.md mis à jour, même id) — compléments à intégrer : (1) COMMISSION HORS PÉRIMÈTRE CALCUL : commissionnement réel payé sur bordereau, système à part, développé plus tard. AUCUN moteur de calcul. Les 2 tuiles Commission (en attente/payée) sont AFFICHÉES MAIS GRISÉES/DÉSACTIVÉES (état 'à venir', pas de 0 € trompeur). Dashboard = 5 tuiles actives (À traiter/En cours/Validés/À corriger/Invalidés) + 2 grisées. (2) commissionnement_id sur l'affaire = attribut documentaire (barème rétroc apporteur 40/12/8 depuis encours), SAISISSABLE DES DEUX CÔTÉS (mandataire à la saisie + admin en édition), dernière saisie fait foi, valeur unique affichée identiquement. Pas de montant dérivé. (3) TABLE compagnies N'EXISTE PAS → la créer (id, nom, actif) + seeder à partir des compagnies réellement utilisées (récupérer depuis tarificateur/affaires existantes). Rappel ordre inchangé : SÉCU d'abord (bloquant), puis LOT 0, LOT 1, LOT 2... Reste à confirmer avec Sébastien : passerelle e-mail (mail/SMTP/tiers) — bloque uniquement le LOT 5.",
            "status": "done",
            "createdAt": "2026-07-01T08:57:07Z",
            "doneAt": "2026-07-02T09:09:53Z"
        },
        {
            "id": "8d50eeec",
            "project": "digital",
            "action": "RÉSOLU — passerelle e-mail LOT 5 : PHP + SMTP, identifiants chargés DEPUIS L'ENV (jamais en dur). Variables à AJOUTER au .env (hors webroot, le même que celui créé en phase SÉCU pour les credentials BD/admin) : SMTP_HOST, SMTP_PORT, SMTP_SECURE (tls/ssl), SMTP_USER, SMTP_PASS, SMTP_FROM_EMAIL, SMTP_FROM_NAME. SMTP_PASS = secret, même traitement que DB_PASS (hors webroot, jamais commité, jamais loggé). Recommandation brique d'envoi : PHPMailer (auth SMTP + TLS + gestion erreurs propre) plutôt que mail() natif ; réutiliser un mailer ASDGL existant s'il y en a un. OPTIMISATION : prévoir les variables SMTP dès la phase SÉCU (créer le .env avec BD + admin + SMTP en une fois) plutôt qu'en deux passes. Le LOT 5 est désormais entièrement spécifié : plus aucun point ouvert sur ce module.",
            "status": "done",
            "createdAt": "2026-07-01T08:59:30Z",
            "doneAt": "2026-07-02T09:09:55Z"
        },
        {
            "id": "7d730779",
            "project": "digital",
            "action": "MAJ SPEC v1.2 — AJOUT SYSTÈME DE PAIEMENT (section 7 du doc, cœur métier). Résumé : (1) 3 flux distincts : frais société (payé au prélèvement, pas de bordereau), frais compagnie (payé sur bordereau, réf à saisir), commission (bordereau, manuelle, hors calcul, type réservé). (2) 2 statuts de paiement SÉPARÉS (société / compagnie), JAMAIS un badge unique. (3) Badges DÉRIVÉS automatiquement : un badge passe 'payé' dès qu'un versement du type existe (option A) — jamais coché à la main. (4) 2 granularités : paiement par LOT (admin filtre un mandataire → dossiers VALIDÉS uniquement → total → clic 'Payer frais société' OU 'Payer frais compagnie', 2 actions/totaux séparés → horodaté) ET paiement à l'UNITÉ (affaire par affaire). (5) 2 TABLES à créer dans LOT 1 : paiements_lots (id, mandataire_id, type_flux ENUM(frais_societe,frais_compagnie), montant_total, date_paiement DATETIME, admin_id) + paiements (id, affaire_id FK, type_flux ENUM(frais_societe,frais_compagnie,commission), montant, date_paiement, ref_bordereau VARCHAR NULL niveau affaire uniquement, batch_id INT NULL FK→paiements_lots, created_at). Logique : lot = 1 ligne paiements_lots + N lignes paiements avec batch_id ; unité = 1 ligne paiements batch_id NULL. Badge = EXISTS(paiement du type pour l'affaire). RÈGLES : paiement lot = statut valide uniquement ; ref_bordereau niveau affaire seulement ; commission dans ENUM dès maintenant (place réservée, pas de calcul). IMPACT PLAN : tables paiements dans LOT 1, écran paiement admin dans LOT 3. Le champ statut_paiement n'est PLUS un champ sur l'affaire (remplacé par badges dérivés).",
            "status": "done",
            "createdAt": "2026-07-01T09:12:34Z",
            "doneAt": "2026-07-02T09:09:55Z"
        },
        {
            "id": "52f47653",
            "project": "digital",
            "action": "═══ ONBOARDING COMPLET MODULE COMPTA — LIRE AVANT TOUTE ACTION ═══ Trois documents sont désormais dans CLAUDESYNC/digital/, à lire DANS CET ORDRE : (1) CONTEXTE_a_lire_en_premier.md (id 14GtM_ILqYO5dGUZd7dJWG8Vj7Da1JGCr) — c'est quoi ce module, le socle métier existant à conserver, les 3 règles d'or, ton rôle vs Claude.ai ; (2) MAQUETTE_description.md (id 1emaCyXpguqhdGOYyWs4cfK3UzRp_2MFA) — description fidèle et annotée de l'interface cible (vue mandataire + vue admin), puisque l'image ne transite pas par le MCP ; (3) ARBITRAGE_compta_v1.md (id 1SCASu0sjKnDc8CbCYJCNcY7HblvEdEUA) — document de référence : les 5 collisions tranchées, le modèle de données complet, le système de paiement §7, le plan ordonné. RÈGLE : en cas de conflit entre maquette et arbitrage, l'ARBITRAGE FAIT FOI. RAPPEL DES DÉCISIONS CLÉS : enrichir l'existant (pas réécrire) · périodes calendaires conservées · statuts workflow 3→5 · frais NE PAS recréer (existent) · encours = barème 40/12/8 + tauxAnnee3 · commission hors calcul (tuiles grisées) · commissionnement saisissable 2 côtés sans calcul · table compagnies à créer+seed · système paiement 2 niveaux (lot dossiers validés + unité) avec 2 tables paiements/paiements_lots et badges dérivés · Remplacer doc = écrasement simple · email SMTP via .env/PHPMailer. ═══ PREMIER CHANTIER = PHASE SÉCU (BLOQUANTE) ═══ sur compta_admin.php + config.php : sortir DB_USER/DB_PASS/COMPTA_ADMIN_PASS + variables SMTP hors webroot dans un .env ; hash mdp admin (password_hash/verify) ; display_errors OFF + log hors webroot ; CSRF sur GET destructifs (del_file, supprimer) ; uploads/ hors webroot + DL authentifié. NE PAS enchaîner sur LOT 0 sans validation de Sébastien (point de contrôle après SÉCU car credentials prod). Si tu vois un écart entre spec et réalité du code/base, SIGNALE-le (push_instruction) plutôt que trancher seul sur un point métier. Instructions détaillées précédentes toujours valables : dd11c4cb, 7baef7a6, 8d50eeec, 7d730779.",
            "status": "done",
            "createdAt": "2026-07-01T09:14:49Z",
            "doneAt": "2026-07-02T09:09:57Z"
        },
        {
            "id": "3f9da9d3",
            "project": "QG-MCP",
            "action": "INFRA MCP — CRÉER LE TOOL 'drive_read' (pendant LECTURE de drive_push). CONTEXTE : le pont Drive est actuellement push-only (drive_push écrit du texte, drive_upload.php pousse du binaire), mais Claude Code ne peut RIEN LIRE depuis le Drive. Résultat : les instructions qui pointent vers des fichiers CLAUDESYNC/*.md sont inexploitables côté Claude Code. Il faut un canal de lecture. DÉCISION : ajouter un tool MCP 'drive_read' au serveur mscrpv.onlydev.fr, symétrique de drive_push. SPEC : entrée = soit un file_id Drive, soit un chemin relatif type 'digital/CONTEXTE_a_lire_en_premier.md' (résolu sous le dossier racine CLAUDESYNC, id 1rZ-Qfs2-JO2NgONCZD2dT7jbO5VzBs37) ; sortie = le contenu texte du fichier. Réutiliser la logique d'accès Drive déjà présente dans drive_push (même compte de service / OAuth) et l'auth/rate-limit de drive_upload.php. Gérer : fichier introuvable (erreur claire), fichier binaire (renvoyer base64 ou message explicite), taille max raisonnable. TESTS attendus : lire un des 3 .md d'onboarding et vérifier le contenu. APRÈS déploiement + reload du serveur MCP : mettre à jour l'état QG-MCP. DÉPENDANCE : ce tool est un PRÉREQUIS pour que Claude Code lise l'onboarding du module compta (instruction 52f47653) — le faire AVANT d'attaquer la phase SÉCU digital.",
            "status": "done",
            "createdAt": "2026-07-01T09:27:51Z",
            "doneAt": "2026-07-02T07:31:32Z"
        },
        {
            "id": "1a08c0ff",
            "project": "digital",
            "action": "PRÉREQUIS LECTURE — avant d'exécuter l'onboarding compta (instruction 52f47653 qui référence 3 docs dans CLAUDESYNC/digital/), il faut pouvoir LIRE le Drive. Le pont est actuellement push-only. Un tool 'drive_read' est demandé côté QG-MCP (instruction 3f9da9d3). SÉQUENCE CORRECTE : 1) créer + déployer + recharger drive_read (projet QG-MCP, instr 3f9da9d3) ; 2) via drive_read, lire dans l'ordre : digital/CONTEXTE_a_lire_en_premier.md, digital/MAQUETTE_description.md, digital/ARBITRAGE_compta_v1.md ; 3) seulement ensuite, attaquer la phase SÉCU du module compta. Si drive_read n'est pas encore dispo quand tu lis ceci, commence par lui. Note pour Sébastien : tant que drive_read n'existe pas, Claude.ai peut aussi recopier le contenu des docs directement en inbox en solution de repli.",
            "status": "done",
            "createdAt": "2026-07-01T09:28:01Z",
            "doneAt": "2026-07-02T07:31:33Z"
        },
        {
            "id": "778a0773",
            "project": "MCP",
            "action": "Installer MarkItDown sur l'infra MCP/QG pour convertir les PDF en Markdown avant traitement, afin de réduire la consommation de tokens. Install: `pip install markitdown[all]` (ou `[pdf]` pour PDF seul). Usage Python: `from markitdown import MarkItDown; MarkItDown().convert(path).text_content`. Intégrer dans le flux drive_upload.php -> conversion -> push du .md allégé plutôt que de faire transiter le PDF brut. Note: pas d'OCR natif sur les PDF scannés/images (coupler un moteur OCR si besoin).",
            "status": "done",
            "createdAt": "2026-07-01T21:50:55Z",
            "doneAt": "2026-07-02T07:46:56Z"
        },
        {
            "id": "e8c094e3",
            "project": "MCP",
            "action": "COMPLÈTE l'instruction 778a0773 (install MarkItDown) — wrapper qualité fourni, à utiliser À LA PLACE d'un appel MarkItDown direct. Fichier : CLAUDESYNC/MCP/markitdown_convert.py (id Drive 1uKh1CtYCLs2n3OlRy8_Uf8c5gvIUF6S_). (1) Récupérer le script et l'installer HORS webroot (PAS dans D:\\xampp\\htdocs — dossier de travail dédié, ex D:\\onlydev\\tools\\markitdown\\, sorties .md avec données clients également hors htdocs). (2) Prérequis : Python 3.10+, pip install \"markitdown[all]\". (3) Contrat d'interface : stdout = rapport JSON ; exit 0 = OK, 1 = conversion DÉGRADÉE (.md écrit mais warnings — logguer et NE PAS pousser silencieusement vers le flux LLM), 2 = échec (rien d'exploitable, ex PDF scanné sans couche texte), 3 = erreur usage/dépendance. Option --quiet pour JSON compact parsable côté PHP. (4) Intégration flux : appel via proc_open depuis le pipeline PHP (drive_upload.php → convert → push .md), tester le code retour AVANT tout push ; si exit != 0, logguer le rapport JSON dans un fichier de log hors webroot. (5) Tester avec 2-3 PDF réels du projet digital (dont un avec tableaux) et remonter le rapport JSON via push_instruction si tables_malformed > 0 ou statut dégradé récurrent — on ajustera les seuils ou on basculera sur pymupdf4llm pour les PDF à tableaux.",
            "status": "done",
            "createdAt": "2026-07-02T07:40:10Z",
            "doneAt": "2026-07-02T07:46:58Z"
        },
        {
            "id": "107337c2",
            "project": "APCIAL",
            "action": "DIAGNOSTIC SYNC (accès GitLab obtenu 07/07 — fenêtre ferme le 16/07, Seb absent 17/07-08/08).\n\n1. CLONER les 2 repos GitLab (front PWA React/Vite/Tailwind/shadcn + back PHP) en local.\n\n2. REPÉRER la couche sync : front = queue offline (IndexedDB/Dexie probable, service worker, service de sync) ; back = endpoint(s) appelés par la sync. Cartographier le flux complet (déclencheurs, payload, réponses, gestion d'erreur).\n\n3. DIAGNOSTIQUER les 3 bugs identifiés le 02/07 — chercher la cause racine commune (couche sync codée pour le cas heureux) :\n- BUG1 (rouge) : 2 modifs concurrentes du même projet → conflit bloque l'app, seule sortie = suppression = perte de travail. Aucune résolution de conflit implémentée.\n- BUG2 (orange) : passage online → la vue serveur REMPLACE le local, l'audit offline non synchronisé disparaît visuellement (donnée pas perdue, revient offline). Attendu : serveur UNION local-en-attente.\n- BUG3 (orange) : réseau dégradé → sync éternelle, spinner infini, pas de timeout/retry/backoff.\n\n4. LIVRABLE = diagnostic écrit + spéc du comportement attendu (PAS de patch direct dans leur code — la correction revient à l'équipe malgache) :\n- reco conflit : last-write-wins niveau champ + horodatage serveur, jamais de blocage sans issue, UI de choix garder-ma-version / garder-serveur ;\n- reco affichage : merge serveur + modifs locales en attente, avec indicateur \"en attente de sync\" ;\n- reco réseau : timeout + retry avec backoff exponentiel + état d'échec explicite reprenant automatiquement.\nPointer les fichiers/fonctions concernés (chemins précis) pour que l'équipe corrige vite.\n\n5. POUSSER le diagnostic sur Drive via drive_push (projet APCIAL) + mettre à jour le state QG.\n\nRappel confidentialité APCIAL : anonymiser tout nom réel de client/organisation/site dans le livrable.",
            "status": "done",
            "createdAt": "2026-07-07T13:18:02Z",
            "doneAt": "2026-07-09T09:22:02Z"
        },
        {
            "id": "02318851",
            "project": "WINORWIN",
            "action": "Uploader le PDF WOW_TABLEAU_ARBITRAGE_IDEES_v1.1.pdf vers CLAUDESYNC/WINORWIN/ via drive_upload.php (curl multipart, token X-Auth-Token depuis $env:DRIVE_PUSH_SECRET). Le PDF a été généré dans Claude.ai le 10/07 — Sébastien le déposera sur le disque (dossier de travail à lui demander si introuvable). Si le fichier n'est pas sur disque : le régénérer depuis la source markdown déjà sur Drive, CLAUDESYNC/WINORWIN/WOW_TABLEAU_ARBITRAGE_IDEES_v1.1.md (file_id 1RKoOupHEiVRgSMAID2HbfJxFgDfsBWbq) — mise en page A4 paysage, tableaux par quadrant (V1 Site / V2 Site / V2 App exigences / V2 App modules / Post-MVP / Technique-négo) + récapitulatif. NB : ne rien stocker de sensible sous D:\\xampp\\htdocs\\7hWk (webroot).",
            "status": "done",
            "createdAt": "2026-07-10T20:55:43Z",
            "doneAt": "2026-07-17T09:46:47Z"
        },
        {
            "id": "cba51d56",
            "project": "APCIAL",
            "action": "CR de la réunion 08/07 PRODUIT par Claude.ai le 13/07 → CR_REUNION_APCIAL_2026-07-08.md sur Drive APCIAL (file_id 104C8jE27rnQG5XzrW-UqImi9IZFveV3S, même dossier que la transcription). Mettre à jour l'état APCIAL : retirer \"CR à produire par Claude.ai\" du a_faire ; ajouter décisions clés au en_cours : (1) nouvelle entité Espace extérieur rattachable à bâtiment OU site, (2) blocs enveloppe multiples par bâtiment (toiture/façade/menuiserie/occultation/isolation 1..n : nom+type+surface+année+commentaire+état, état=déclencheur PPI), (3) PDL renommé Point d'énergie rattachable site/bâtiment/espace avec héritage + historisation consos (saisie annuelle/mensuelle/trimestrielle), (4) notation portée exclusivement par la fiche Check-Diag (retirée des espaces), rattachable site/bâtiment/espaces, non automatisée, (5) aménagements intérieurs sur Espace, (6) notifications ACTÉ (mails regroupés + in-app), PPI prix manuel + barème administrable ACTÉ, RGPD en attente retour Simon, (7) Phase 1 confirmée inventaire+GED+CheckDiag+Score sérénité (score = indicateur interne). Calendrier : points structurels CDC renvoyés + brief équipes avant 16/07 ; structure 18/07→09/08 ; référentiels APCIAL fin juillet ; RÉUNION VALIDATION FONCTIONNEMENT mercredi 26/08 9h30 ; livraison Phase 1 octobre ; 2 audits réels dès début septembre (6 puis ~15 établissements). NOUVEAU point IP : cession de droits réaffirmée en réunion → document officiel de cession à rédiger (à cadrer AVANT signature : périmètre cédé, maintien maintenance récurrente, licence sur briques génériques réutilisables).",
            "status": "done",
            "createdAt": "2026-07-13T13:06:11Z",
            "doneAt": "2026-07-17T13:22:14Z"
        },
        {
            "id": "e296048e",
            "project": "APCIAL",
            "action": "IP APCIAL — cadrage document de cession (décision Seb 13/07). Contexte : cession PI promise oralement en réunion 08/07 (\"je vous cède les droits, on fera un document officiel\"). Le document est à rédiger par Seb, validation avocat, signature pas avant fin août. Contenu impératif en 3 points : (1) OBJET : cession du logiciel APCIAL uniquement ; les briques génériques OnlyDev (moteur sync/offline, socle PWA, patterns transverses) restent propriété OnlyDev, LICENCIÉES à APCIAL — indispensable pour réutilisation sur WOW et autres projets. (2) USAGE : cession pleine pour les besoins propres et missions d'APCIAL ; toute mise à disposition payante à des tiers (SaaS, revente, marque blanche) = accord séparé le moment venu. (3) CONTREPARTIE dans le même acte : maintenance récurrente contractualisée + droit de préférence sur les évolutions. Rappel légal : L131-3 CPI exige énumération des droits cédés, modes d'exploitation, durée, territoire — une cession vague est fragile. Créer une tâche de rédaction du draft pour la rentrée (avant réunion du 26/08 si possible).",
            "status": "open",
            "createdAt": "2026-07-13T13:36:09Z"
        },
        {
            "id": "40bdaee0",
            "project": "APCIAL",
            "action": "CONCEPTION v3.6 PRODUITE par Claude.ai le 13/07. Source markdown sur Drive : CLAUDESYNC/APCIAL/APCIAL_Conception_fonctionnelle_v3_6.md (file_id 1Ejl9FBfEjhmu9QWOjN-b_GXoYyGz_RrC). Le PDF v3.6 (32 pages) a été généré dans Claude.ai — Sébastien le déposera sur disque : l'uploader vers CLAUDESYNC/APCIAL/ via drive_upload.php (curl multipart, X-Auth-Token depuis $env:DRIVE_PUSH_SECRET). Si introuvable sur disque : le régénérer depuis le .md source (pandoc + xelatex, police DejaVu Sans 9pt, marges 1.8cm, TOC 2 niveaux, header/footer 'Document confidentiel', encadrés citation en bleu). Contenu v3.6 vs v3.5 : blocs enveloppe multiples 7 catégories (§4.4, état Bon/Moyen/Mauvais/À remplacer = déclencheur), entité Espace extérieur (§4.6, rattachable Bâtiment ou Site), notes retirées de l'Espace + aménagements intérieurs en blocs (§4.5), PDL→Point d'énergie avec héritage + consos historisées saisie annuelle/trim/mensuelle (§4.7), fiche Check-Diag à périmètre libre + mécanique héritage/aide à la saisie/complétion à la volée, unicité bâtiment×mission supprimée (§4.15), Score sérénité manuel /5 couleur (§5.3), déclencheurs Garde-corps et Toiture terrasse déduits des blocs (§5.1), §6.5 nouveau référentiel types de blocs, §7.1 +12 décisions 08/07, §7.2 = P1/P4/P5/P6 + P7 (liste éléments déclencheurs) + P8 (décret tertiaire), P2/P3 tranchés sortis. Renumérotation : ex-4.6 PDL→4.7, décalage jusqu'à 4.20. Mettre à jour l'état APCIAL : CDC v3.6 produit, à envoyer à Simon/Alain/Patrice pour relecture AVANT le 16/07 (avec demande de vérif des listes §6.5 inventées : Occultations et Garde-corps). NB : ne rien stocker de sensible sous D:\\xampp\\htdocs\\7hWk (webroot).",
            "status": "done",
            "createdAt": "2026-07-13T14:09:55Z",
            "doneAt": "2026-07-17T13:22:16Z"
        },
        {
            "id": "2beb1ba9",
            "project": "APCIAL",
            "action": "COMPLÉMENT à l'instruction 40bdaee0 : le PDF final v3.6 est la version STYLÉE charte v3.5 — fichier APCIAL_Conception_fonctionnelle_v3_6_styled.pdf (19 pages : page de garde OnlyDev/APCIAL, encadrés verts DÉCISION ACTÉE / orange À TRANCHER / bleus NOTE DE CONCEPTION, titres #1F497D, tableaux en-tête bleu, header OnlyDev·v3.6·13/07/2026, footer Page X — Document confidentiel). Sébastien le dépose sur disque → uploader CELUI-CI vers CLAUDESYNC/APCIAL/ via drive_upload.php, renommé APCIAL_Conception_fonctionnelle_v3_6.pdf. Ignorer la consigne pandoc/xelatex de 40bdaee0 ; si régénération nécessaire : md source (file_id 1Ejl9FBfEjhmu9QWOjN-b_GXoYyGz_RrC) → HTML avec classes decision/trancher/note sur les blockquotes → wkhtmltopdf (header/footer via options CLI).",
            "status": "done",
            "createdAt": "2026-07-13T14:24:49Z",
            "doneAt": "2026-07-17T13:22:17Z"
        },
        {
            "id": "6e1aec6b",
            "project": "APCIAL",
            "action": "ANNULE l'étape upload des instructions 40bdaee0 et 2beb1ba9 : Sébastien dépose lui-même le PDF final directement dans le dossier Drive CLAUDESYNC/APCIAL sous le nom APCIAL_Conception_fonctionnelle_v3_6v2.pdf. À faire à la prochaine session : (1) vérifier sa présence sur Drive ; (2) le référencer comme PDF officiel v3.6 dans l'état APCIAL (source md = APCIAL_Conception_fonctionnelle_v3_6.md, file_id 1Ejl9FBfEjhmu9QWOjN-b_GXoYyGz_RrC) ; (3) marquer done les volets upload de 40bdaee0 et 2beb1ba9 — le reste de 40bdaee0 (mise à jour état + envoi client avant 16/07 + vérif listes §6.5) reste valable.",
            "status": "done",
            "createdAt": "2026-07-13T14:35:38Z",
            "doneAt": "2026-07-17T14:52:36Z"
        },
        {
            "id": "4a1e41b8",
            "project": "ASDGL",
            "action": "Tarificateur : intégrer un contrat APRIL multiproduit (nouveau contrat à ajouter dans le moteur de comparaison assurance emprunteur).",
            "status": "open",
            "createdAt": "2026-07-15T21:06:26Z"
        },
        {
            "id": "f6ea7c05",
            "project": "digital",
            "action": "BLOC 1 — Corrections module compta (notes réunion 17/07) : 1. Bug UX : clic \"Conclure\" → la page scrolle en bas, corriger. 2. Valider taille max fichier (lié au chantier Plesk 25M/100M déjà prévu). 3. Compléter la liste des compagnies (compa_compagnies). 4. Présélectionner le menu produit. 5. Ne pas imposer le % de commissionnement (champ libre — À CLARIFIER : saisi par admin ou mandataire ?). 6. Erreur \"action non autorisée\" / jeton : vérifier durée de validité du token + poids des requêtes (probable lien post_max_size). 7. Frais de dossiers compagnie et Ass : redonner la main en édition côté admin. 8. Renommer \"Frais société\" → \"Frais Ascourtage\". 9. Bordereaux : stocker tous les bordereaux liés à un paiement. 10. Côté mandataire : masquer les frais (calcul des montants côté admin). 11. Supprimer le paiement des frais compagnies. 12. Ajouter \"Recueil de besoin AS du Grand Lyon\". 13. Côté mandataire : afficher \"frais de dossiers vendus\". 14. Date du premier prélèvement — note incomplète (\"à côté de\"), À CLARIFIER avec Seb avant implémentation. NOTE ÉTAT : test_upload.php a été SUPPRIMÉ du serveur par Seb le 17/07 → mettre à jour le state QG (retirer ce point des finitions/risques du projet digital).",
            "status": "done",
            "createdAt": "2026-07-17T14:34:50Z",
            "doneAt": "2026-08-21T15:42:38Z"
        },
        {
            "id": "b7c4d8a5",
            "project": "digital",
            "action": "BLOC 2 — Nouveau workflow prélèvements bancaires (à SPÉCIFIER avant dev, pas d'implémentation directe) : fichier récap des prélèvements calqué sur la compta. Séquence métier : sélection des dossiers → ouverture du recueil pour récupérer le RIB → mise en place du prélèvement à la banque → attente confirmation prélèvement OK → virement au mandataire. Inclut : gestion des rétrocessions, outil côté compagnie d'analyse des rétrocessions, génération du tableau récap à envoyer à Laurène. Livrable attendu : spéc fonctionnelle courte (écrans, états d'un prélèvement, données nécessaires) à valider par Seb au retour (après le 08/08) avant tout dev.",
            "status": "open",
            "createdAt": "2026-07-17T14:34:59Z"
        },
        {
            "id": "5ab83b7a",
            "project": "digital",
            "action": "BLOC 3 — MNCAP : chantier À CHIFFRER AVANT TOUT DEV (décision Seb : devis, pas absorption dans le forfait — risque IP L131-3 sur ASDGL toujours non résolu). Périmètre évoqué en réunion : tarificateur dédié MNCAP, module d'adhésion, gestion QS (questionnaire santé), gestion avancement des dossiers, suivi de la résiliation. Voir aussi comment articuler avec l'intégration APRIL multiproduit déjà en inbox ASDGL (\"truc APRIL mixer\"). Livrable attendu : estimation macro par lot (jours/lot) pour permettre à Seb de produire un devis au retour. NE RIEN CODER.",
            "status": "done",
            "createdAt": "2026-07-17T14:35:06Z",
            "doneAt": "2026-08-11T08:16:56Z"
        },
        {
            "id": "98aef963",
            "project": "digital",
            "action": "RENOMMAGE QG — décision Seb 17/07 : ASDGL est le CLIENT parent, pas un projet. Convention adoptée : préfixe ASDGL- pour chaque projet de ce client. À faire dans le state (via set_state, après get_state pour ne rien perdre) : renommer le projet \"digital\" → \"ASDGL-digital\". Les futurs projets ASDGL suivront la même convention (ex. ASDGL-simulateur, ASDGL-MNCAP). Les instructions inbox f6ea7c05 (bloc 1 corrections compta) et b7c4d8a5 (bloc 2 spéc workflow prélèvements) restent valables et concernent ASDGL-digital. L'instruction 5ab83b7a (MNCAP) est OBSOLÈTE → la marquer done sans la traiter : remplacée par une instruction dédiée sur le projet ASDGL-MNCAP.",
            "status": "done",
            "createdAt": "2026-07-17T14:36:03Z",
            "doneAt": "2026-08-11T10:13:17Z"
        },
        {
            "id": "64f8a130",
            "project": "ASDGL-MNCAP",
            "action": "NOUVEAU PROJET ASDGL-MNCAP (client ASDGL, distinct du module compta ASDGL-digital) — chantier À CHIFFRER AVANT TOUT DEV (décision Seb : devis, pas absorption dans le forfait — risque IP L131-3 sur ASDGL toujours non résolu). Périmètre évoqué en réunion du 17/07 : tarificateur dédié MNCAP, module d'adhésion, gestion QS (questionnaire santé), gestion avancement des dossiers, suivi de la résiliation. Articuler avec l'intégration APRIL multiproduit déjà en inbox ASDGL (\"truc APRIL mixer\"). Livrable attendu : estimation macro par lot (jours/lot) pour permettre à Seb de produire un devis au retour (après le 08/08). NE RIEN CODER. Ajouter ce projet au state QG avec statut \"nouveau\".",
            "status": "done",
            "createdAt": "2026-07-17T14:36:09Z",
            "doneAt": "2026-08-21T09:15:03Z"
        },
        {
            "id": "f12700e4",
            "project": "digital",
            "action": "COMPLÉMENT BLOC 1 (corrections module compta, suite notes Seb 19/07) — point 15 : les champs de l'EMPRUNTEUR 2 ne sont pas modifiables dans la nouvelle version ; seul l'emprunteur 1 est géré. Corriger pour que les champs emp2 soient éditables au même titre que emp1 (vérifier saisie, édition admin, et persistance en base — contrôler que les colonnes/champs emp2 sont bien câblés dans comptabilite.php et comptabilite_admin.php et pas seulement affichés). À traiter avec le BLOC 1 (instruction f6ea7c05).",
            "status": "done",
            "createdAt": "2026-07-19T21:46:24Z",
            "doneAt": "2026-08-21T15:42:42Z"
        },
        {
            "id": "8ce42269",
            "project": "QG",
            "action": "Implémenter la boucle de distillation QG v1. Spec complète : CLAUDESYNC/QG/SPEC_boucle_distillation_v1.md (lire via drive_read avant tout). Livrables : (1) repo Git doctrine hors webroot avec structure regles/skills/etat/candidates + seed 5 règles listées dans la spec, (2) outils MCP post_mortem + push_candidate + list_episodes + list_candidates dans Tools.php/Storage.php sur mscrpv.onlydev.fr, (3) hook : post_mortem appelé au mark_done. Localisation : serveur OD + nouveau repo local. Bloqueur : validation Sébastien avant déploiement serveur (revue au retour, ~10/08). Timebox : 1 journée — si dépassé, stop et documenter le point de blocage.",
            "status": "done",
            "createdAt": "2026-07-21T18:13:20Z",
            "doneAt": "2026-08-11T10:55:57Z"
        },
        {
            "id": "7bbb3c51",
            "project": "QG",
            "action": "CADRAGE — Module Échéances. Lire CLAUDESYNC/QG/SPEC_QG_echeances_v0.1.md (id 1KqMs92VqZ0CXECx6zmtwaB7VfSBIHB30). Périmètre : stockage etat/echeances.json + 4 outils MCP (echeance_add / list / report / close) + extension get_state avec bloc echeances_a_risque. Contraintes : serveur MCP = couche stockage muette, aucune logique LLM ; aucun secret sous D:\\xampp\\htdocs\\7hWk ; timebox 1 jour, fallback Hermes. SÉQUENCEMENT : à traiter APRÈS la boucle de distillation doctrine, pas en parallèle. NE RIEN METTRE EN PROD avant validation Sébastien (retour ~08/08). Livrable attendu : branche + note de retour listant les écarts avec la spec et les points de §9 que l'implémentation a rendus caducs ou plus aigus.",
            "status": "open",
            "createdAt": "2026-07-30T17:40:17Z"
        },
        {
            "id": "6ae824d6",
            "project": "WINORWIN",
            "action": "NOTE STRATÉGIQUE — NE RIEN EXÉCUTER, capture pour arbitrage Seb. Question ouverte : sur WinOrWin, le CA doit-il être généré via OnlyDev (structure 100% Seb) ou via WOWDEV (structure conjointe 50/50 avec François) dans l'hypothèse où Seb est associé ? Points à instruire au moment de l'arbitrage : (1) les conditions préalables WOWDEV ne sont PAS remplies à ce jour — lettre d'accord non signée, IP non assignée, contribution antérieure de Seb non reconnue en compte courant ; router du CA vers WOWDEV avant signature = diluer 50% d'un revenu dans une structure sans cadre protecteur. (2) Distinguer les natures de revenu : prestation de dev (candidate WOWDEV), conseil/CPO-CTO (aujourd'hui facturé via 3.1, cf. mission 700€ HT), licence/briques réutilisables OnlyDev (doit rester OnlyDev quoi qu'il arrive). (3) Vérifier l'articulation avec le périmètre SF DEV. Livrable attendu quand le sujet sera ouvert : matrice type de revenu × structure de facturation, à trancher AVANT la signature de la lettre d'accord WOWDEV. Rattacher à la réunion d'arbitrage architecture V2 semaine du 10/08.",
            "status": "done",
            "createdAt": "2026-08-06T07:19:35Z",
            "doneAt": "2026-09-15T10:19:25Z"
        },
        {
            "id": "9dfcd2ad",
            "project": "WINORWIN",
            "action": "NOTE STRATÉGIQUE (complète et précise 6ae824d6) — NE RIEN EXÉCUTER, capture pour arbitrage Seb. IDÉE PRODUIT : créer une application tierce qui se connecte à WinOrWin via API, vendue aux membres WinOrWin (base membres = marché captif). Structure de facturation selon issue : WOWDEV si Seb associé, OnlyDev sinon. Points à instruire avant tout dev : (1) DÉPENDANCE TECHNIQUE — le produit dépend d'une API WinOrWin qui n'existe pas encore ; la Core-API Node.js est au cadrage V2, donc la fenêtre pour y inscrire une API partenaire (endpoints, auth, versioning, SLA) est MAINTENANT, pendant que Seb a la main sur l'architecture. À porter explicitement à la réunion d'arbitrage V2 semaine du 10/08. (2) DÉPENDANCE CONTRACTUELLE — accès API + droit de commercialiser auprès des membres doivent être sécurisés par écrit AVEC L'ENTITÉ WinOrWin (pas avec François personnellement) : clause de non-révocation, durée, exclusivité ou non, conditions tarifaires. Sans ça, WinOrWin peut couper l'accès une fois le produit construit. (3) CONFLIT D'INTÉRÊTS À NOMMER — Seb spécifie en tant que CPO/CTO de fait l'API dont son propre produit dépendra ; à déclarer explicitement à François pour éviter la contestation ultérieure. (4) PROPRIÉTÉ — l'application est un produit OnlyDev (IP Seb) même si le dev transite par WOWDEV ; WOWDEV est un véhicule de production, pas un propriétaire de produit. Ne pas laisser le statut d'associé emporter mécaniquement 50% de l'IP produit. (5) Articuler avec le périmètre SF DEV (même thèse : base membres WinOrWin comme marché captif) — décider si ce produit EST le premier SFDEV-<nom> ou s'il reste hors périmètre conjoint. Livrable attendu à la réouverture du sujet : note de cadrage produit (quel service vendu aux membres, quel prix, quelle dépendance API minimale) + matrice type de revenu × structure.",
            "status": "done",
            "createdAt": "2026-08-06T07:23:57Z",
            "doneAt": "2026-08-11T08:16:58Z"
        },
        {
            "id": "19816f30",
            "project": "WINORWIN",
            "action": "NOTE PRODUIT (complète 9dfcd2ad) — NE RIEN EXÉCUTER, capture d'idée. Extension : la première app (celle de Seb) sert d'amorce d'écosystème. Effet visé en cascade : (1) elle prouve que l'API WinOrWin est utilisable et qu'il y a une demande côté membres ; (2) d'autres membres WOW veulent connecter leur app existante ou en faire créer une ; (3) WOWDEV vend les accès à l'API (et potentiellement le dev des apps tierces). Passage d'un modèle réseau à un modèle plateforme : le revenu vient de l'accès et non du temps passé. À creuser plus tard : qui possède la gateway API (c'est là que la valeur se capture), modèle tarifaire des accès (par membre / par app / par volume), et si le dev des apps tierces est un canal WOWDEV ou OnlyDev. Aucune décision prise, aucun cadrage lancé.",
            "status": "done",
            "createdAt": "2026-08-06T07:27:33Z",
            "doneAt": "2026-08-11T08:17:01Z"
        },
        {
            "id": "7089d42f",
            "project": "WINORWIN",
            "action": "CLÔTURE DE PISTE — NE RIEN EXÉCUTER. Conclusion de la session du 06/08/2026 sur l'idée d'app connectée à l'API WinOrWin (notes 6ae824d6, 9dfcd2ad, 19816f30) : PISTE ABANDONNÉE comme amorce de CA pour WOWDEV. Motifs : (1) l'API n'existe pas et dépend de la livraison V2, non arbitrée avant le 10/08 — premier euro repoussé de plusieurs mois ; (2) ticket unitaire faible (abonnement membre), volume plafonné par la taille de la base membres ; (3) dev à financer avant tout client payant, dans une structure dont la lettre d'accord n'est pas signée. Go/no-go théorique si le sujet est rouvert : nombre de membres WinOrWin × taux de conversion plausible (ordre de grandeur : ~4000 membres nécessaires à 30€/mois et 5% de conversion pour sortir 6k€/mois) — Seb détient ce chiffre. PISTE À CHIFFRER À LA PLACE : canal prestation de dev auprès des membres WinOrWin (dirigeants de PME = marché captif), ticket 4-5 chiffres, ne dépend d'aucune brique technique, facturable dès accord de prospection signé avec l'entité WinOrWin. Correspond à la thèse SF DEV déjà posée. Grille de qualification produite en séance : CLAUDESYNC/QG/GRILLE_qualification_idees_v1.md (id 19RRK96UhgB1U4sw17gW7M9_TnVO-2kWJ) — coefficients à calibrer sur 3-4 idées passées avant usage.",
            "status": "done",
            "createdAt": "2026-08-06T07:45:39Z",
            "doneAt": "2026-09-02T11:29:36Z"
        },
        {
            "id": "64caac90",
            "project": "QG",
            "action": "AMENDEMENT SPEC — à intégrer AVANT implémentation de la boucle de distillation (instruction 8ce42269). Source : DOCTRINE_notes_v1.md, CLAUDESYNC/ONLYDEV/ (Drive id 1K4cApf3-0G_y-kPxV-UCSAYjb8JNQx-v), révisée le 07/08/2026.\n\nObjet : le tri des notes ne doit JAMAIS supprimer. Toute note non requalifiée est ARCHIVÉE.\n\nÀ ajouter à SPEC_boucle_distillation_v1.md :\n1. Destination d'archive : CLAUDESYNC/ARCHIVE/<ANNEE>/ — un fichier par note ou un fichier mensuel agrégé (à trancher à l'implémentation).\n2. Métadonnées obligatoires sur chaque note archivée : date de capture, date d'archivage, périmètre pressenti (si existant), motif d'archivage parmi {requalifiee_ailleurs, sans_suite, doublon}. Le motif est obligatoire — sans lui l'archive redevient un dépotoir déplacé.\n3. Règle d'ancienneté : note en vrac depuis > 3 mois sans requalification = archivée d'office (motif sans_suite).\n4. L'archive doit être consultable et réactivable : prévoir un outil de lecture/recherche dans l'archive, et un chemin de remontée d'une note archivée vers un périmètre actif (pas de réécriture from scratch).\n5. Aucune suppression définitive, à aucune étape de la boucle.\n\nSéquencement inchangé : boucle de distillation (8ce42269) PUIS module échéances (7bbb3c51). Rien ne se déploie sur mscrpv.onlydev.fr avant revue Sébastien.",
            "status": "done",
            "createdAt": "2026-08-07T14:15:05Z",
            "doneAt": "2026-08-11T10:55:58Z"
        },
        {
            "id": "71b22723",
            "project": "ONLYDEV",
            "action": "DIAGNOSTIC + ACTION SEB — NE RIEN EXÉCUTER CÔTÉ CODE. Session du 07/08/2026.\n\nCONSTAT : sur les 5-6 projets en cours, Sébastien ne connaît la marge réelle d'AUCUN. Zéro sur cinq. Conséquence : tous les arbitrages stratégiques (délégation Clovis, équipe malgache, canal prestation WinOrWin, association WOWDEV) sont pris en aveugle, sans savoir quel projet enrichit et lequel appauvrit.\n\nCADRE DE RÉFÉRENCE (3 piliers, ordre séquentiel obligatoire) :\n1. Avoir des clients / relancer / capturer — état : correct mais captation passive (relationnel, pas systémique).\n2. Gagner vraiment de l'argent sur chaque chantier — état : NON TENU. C'est le trou. Absorption de scope, conception non facturée, IP tarificateur non contractualisée.\n3. Sortir de l'exécution / boîte qui tourne seule — état : en cours (Clovis, Madagascar, QG) MAIS prématuré. Déléguer sans connaître sa marge = industrialiser la perte.\n\nACTION À FAIRE PAR SEB (pas par Claude Code) : tableur simple, 2 colonnes par projet — MONTANT FACTURÉ / TEMPS RÉEL PASSÉ (Seb + sous-traitance valorisée). 5 lignes. Format volontairement crade, PAS un module QG, PAS de schéma de données, PAS de connecteur. Objectif = obtenir le chiffre, pas construire l'outil. Automatisation seulement APRÈS que le chiffre ait été produit une fois à la main.\n\nÉCHÉANCE : avant le tri hebdo du mardi 11/08 (9h00). À reprendre en revue à cette date.\n\nRISQUE IDENTIFIÉ : tendance documentée de Seb à transformer une tâche comptable ennuyeuse en chantier technique intéressant. Si ce point réapparaît sous forme de spec ou de module, c'est un signal d'évitement.",
            "status": "done",
            "createdAt": "2026-08-07T14:39:17Z",
            "doneAt": "2026-08-10T16:09:43Z"
        },
        {
            "id": "421239db",
            "project": "QG",
            "action": "IDÉE À TRIER (capture brute, non instruite) — Concevoir une formation \"IA + élocution / prise de parole\". À clarifier au tri hebdo du 11/08 : (1) est-ce UNE formation (utiliser l'IA pour s'entraîner à parler en public / travailler son élocution) ou DEUX sujets distincts empilés ? (2) rattachement : OnlyDev en propre ou canal SF DEV avec François ? (3) cible et prix avant tout contenu. NE PAS commencer à produire du contenu ni du support technique tant que le calcul de marge réelle sur les 5-6 projets actifs n'est pas fait.",
            "status": "done",
            "createdAt": "2026-08-08T21:04:54Z",
            "doneAt": "2026-08-08T21:36:38Z"
        },
        {
            "id": "322feb55",
            "project": "QG",
            "action": "CORRECTION de l'idée 421239db — Il s'agit de DEUX formations distinctes, pas une : (A) formation IA, (B) formation élocution / prise de parole / pitch. À trancher au tri du 11/08 : même audience cible ou deux marchés différents ? Question de légitimité à instruire sur (B). Reste conditionné au calcul de marge préalable.",
            "status": "done",
            "createdAt": "2026-08-08T21:05:56Z",
            "doneAt": "2026-08-08T21:36:41Z"
        },
        {
            "id": "a3f926cf",
            "project": "QG",
            "action": "CORRECTION des idées 421239db et 322feb55 — Il ne s'agit PAS de créer des formations à vendre. Sébastien veut SE FORMER lui-même, sur deux sujets : (A) IA, (B) élocution / prise de parole / pitch. À trancher au tri du 11/08 : priorité entre les deux, budget, financement possible via fonds de formation (à vérifier selon statut EURL/TNS). Ignorer toute analyse produit/marché des instructions précédentes.",
            "status": "done",
            "createdAt": "2026-08-08T21:06:48Z",
            "doneAt": "2026-08-09T16:11:16Z"
        },
        {
            "id": "945f1983",
            "project": "QG",
            "action": "IDÉE À TRIER (capture brute) — Tester Seedance et Higgsfield (génération vidéo IA). À qualifier au tri du 11/08 : usage visé (curiosité perso / livrable client type PELLET-communication / offre à packager) et budget temps. Time-boxer si retenu. Reste conditionné au calcul de marge préalable.",
            "status": "done",
            "createdAt": "2026-08-08T21:14:19Z",
            "doneAt": "2026-08-09T16:11:19Z"
        },
        {
            "id": "4ddb032e",
            "project": "QG",
            "action": "OBJECTIF SEMAINE (déclaré par Sébastien, 08/08) — 1) Cadrer WinOrWin (arbitrage tech ISA semaine du 10/08, gouvernance WOWDEV, licence) et ASDGL (périmètre, IP tarificateur, chiffrage MNCAP). 2) Ensuite seulement : lancer une stratégie de développement + communication pour OnlyDev. Seedance/Higgsfield qualifiés = outils de création de contenu pour la comm OnlyDev, donc séquencés en phase 2, pas maintenant. Rappel : le calcul de marge réelle (facturé / temps passé sur 5-6 projets) est l'INPUT du cadrage, pas une tâche concurrente.",
            "status": "done",
            "createdAt": "2026-08-08T21:15:51Z",
            "doneAt": "2026-08-08T21:36:44Z"
        },
        {
            "id": "290dd57b",
            "project": "WINORWIN",
            "action": "WINORWIN — Fait nouveau (08/08) : une réunion avec ISA est confirmée pour lancer les modifications du document d'arbitrage concernant la V1. Timing et ordre du jour à caler avec François (non fixés). Points de vigilance : (1) la V1 porte l'antériorité de Sébastien — produire un inventaire écrit de l'existant V1 et de qui a construit quoi AVANT la réunion, sert de preuve de contribution antérieure et alimente la lettre d'accord ; (2) déterminer qui rédige le document d'arbitrage modifié (Sébastien ou Barthélémy) — si c'est Sébastien, c'est un livrable de valeur à ne pas produire avant envoi de la lettre d'accord ; (3) la lettre d'accord ne dépend pas du calendrier de François, elle peut partir indépendamment.",
            "status": "done",
            "createdAt": "2026-08-08T21:18:27Z",
            "doneAt": "2026-08-08T21:36:46Z"
        },
        {
            "id": "a0f6f7f7",
            "project": "WINORWIN",
            "action": "WINORWIN — Décision actée avec François (08/08) : périmètre V1 / V2 délimité. La V1 est confiée à ISA sur le mois d'août, pour libérer de la bande passante et préparer proprement le lancement V2. Points à sécuriser avant transfert : (1) périmètre V1 délégué écrit, tickets fermés, interdiction de refactor architectural sans validation Sébastien ; (2) qui valide et recette les livraisons V1 en août — et Sébastien est-il censé rester disponible pour débloquer ISA ; (3) l'onboarding V1 est un transfert de connaissance non rémunéré : la lettre d'accord doit être partie avant ; (4) l'inventaire V1 (preuve d'antériorité) doit être produit à cette occasion, il sert deux fois.",
            "status": "done",
            "createdAt": "2026-08-08T21:20:24Z",
            "doneAt": "2026-08-08T21:36:49Z"
        },
        {
            "id": "7f3a39e3",
            "project": "WINORWIN",
            "action": "WINORWIN — CORRECTION de l'instruction a0f6f7f7 : la V1 n'est PAS du code de Sébastien. V1 = noyau Revolucy + modifications réalisées par ISA depuis janvier. Aucun transfert de connaissance ni risque IP sur la délégation V1 à ISA en août — ISA finit un chantier qu'elle mène déjà. Ignorer les garde-fous \"onboarding\" et \"transfert d'actif\" de a0f6f7f7. QUESTION OUVERTE qui remonte en priorité : où se situe exactement la contribution de Sébastien sur WinOrWin si ce n'est pas le code ? (conception, architecture fonctionnelle, CDC, arbitrage, pilotage produit). La nature de sa contribution détermine la forme de sa rémunération — un rôle de conception se paie en retainer ou en equity, pas en licence logicielle. À trancher avant rédaction de la lettre d'accord.",
            "status": "done",
            "createdAt": "2026-08-08T21:21:44Z",
            "doneAt": "2026-08-08T21:36:52Z"
        },
        {
            "id": "9621ca00",
            "project": "WINORWIN",
            "action": "WINORWIN / WOWDEV — Modèle clarifié (08/08) : WOWDEV = structure commune Sébastien 50 / François 50. WOWDEV porte la conception (Sébastien) et sous-traite le dev à ISA. WinOrWin paie une LICENCE À WOWDEV (WinOrWin est client, WOWDEV est éditeur). Points structurels à trancher AVANT création de WOWDEV : (1) CONFLIT D'INTÉRÊT — François est des deux côtés de la table (dirigeant du payeur WinOrWin + 50% du bénéficiaire WOWDEV), Sébastien d'un seul côté ; chaque euro de licence coûte 0,50 à François et rapporte 0,50 à Sébastien, donc François est structurellement motivé à minimiser la licence qu'il fixe lui-même. Montant + indexation + durée à graver par écrit avant tout apport de conception. (2) Que apporte François en contrepartie de ses 50% ? La base clients appartient à WinOrWin en tant qu'entité, pas à lui personnellement. (3) WinOrWin a-t-elle d'autres associés — si oui, licence à une structure détenue à 50% par son dirigeant = convention réglementée à sécuriser. (4) Risque de dépassement ISA porté par WOWDEV donc à 50% par Sébastien, alors qu'il en assume seul le pilotage.",
            "status": "done",
            "createdAt": "2026-08-08T21:25:00Z",
            "doneAt": "2026-08-08T21:36:56Z"
        },
        {
            "id": "8469cb25",
            "project": "WINORWIN",
            "action": "WINORWIN / WOWDEV — Précision (08/08) : WinOrWin appartient à 100% à François. Corrige l'instruction 9621ca00 : pas d'autres associés donc pas de sujet convention réglementée, et l'apport de François à WOWDEV (base clients captive) est réel et lui appartient effectivement — 50/50 défendable sur ce point. MAIS le conflit d'intérêt sur le prix s'aggrave : chaque euro de licence coûte 1€ à François et ne lui en rend que 0,50 — incitation maximale à minimiser la licence qu'il fixe seul. DEUX CLAUSES NON NÉGOCIABLES à porter dans la lettre d'accord : (1) licence NON EXCLUSIVE — WOWDEV doit pouvoir vendre à d'autres clients, sinon la part de Sébastien n'a aucune valeur hors François ; (2) IP du code V2 détenue par WOWDEV, pas par WinOrWin. QUESTION STRUCTURANTE : WOWDEV a-t-il vocation à servir d'autres clients que WinOrWin ? Si non, la structure est une fiction et Sébastien devrait être payé en direct (retainer) plutôt qu'en 50% d'un fournisseur captif.",
            "status": "done",
            "createdAt": "2026-08-08T21:26:39Z",
            "doneAt": "2026-08-08T21:36:59Z"
        },
        {
            "id": "f5a1ffe5",
            "project": "WINORWIN",
            "action": "WINORWIN / WOWDEV — Vocation précisée (08/08) : WOWDEV = deux jambes. (1) développer le SaaS V2, (2) ensuite vendre des prestations aux MEMBRES WinOrWin en s'appuyant sur le réseau. Conséquences à trancher avant création : (A) L'ACTIF CLÉ N'EST PAS LE CODE, C'EST L'ACCÈS AU RÉSEAU — et il est 100% contrôlé par François, révocable à tout moment. La lettre d'accord doit contenir un droit d'accès contractuel de WOWDEV à la base membres à des fins commerciales : modalités, durée minimale, et clause de changement de contrôle (François ~58 ans, si WinOrWin est vendue l'accès doit survivre). (B) Engagement commercial de François à quantifier — s'il ouvre juste son carnet sans objectif chiffré, il n'apporte pas 50%. (C) CAPACITÉ DE LIVRAISON : Sébastien est déjà le goulot sur la conception SaaS ; s'il porte aussi la delivery des prestations membres, le montage le remet à vendre du temps, contraire à son objectif. (D) DOUBLON À CLARIFIER : SF DEV visait déjà la base membres WinOrWin avec François comme canal. SF DEV et WOWDEV ciblent le même actif avec le même partenaire — fusionner, arbitrer ou abandonner l'un des deux AVANT d'immatriculer quoi que ce soit.",
            "status": "done",
            "createdAt": "2026-08-08T21:28:34Z",
            "doneAt": "2026-08-08T21:37:02Z"
        },
        {
            "id": "4415063c",
            "project": "ONLYDEV",
            "action": "CADRAGE COMM / ACQUISITION ONLYDEV — NE RIEN EXÉCUTER, capture pour tri du 11/08. Note Seb 09/08/2026. Deux volets à traiter séparément, séquencés, pas en parallèle.\n\nVOLET 1 — RÉASSURANCE (à cadrer maintenant, scope FERMÉ, one-shot).\nObjectif : qu'un prospect qui cherche OnlyDev trouve quelque chose de crédible. Sert directement la bascule vers le mode produit+licence (vendre une brique suppose de pouvoir montrer qu'elle existe et tourne ailleurs) et les rendez-vous en cours (WOW, ASDGL, APCIAL).\nPérimètre exact, à ne pas élargir : (a) site OnlyDev propre — positionnement, offres, preuve ; (b) profil LinkedIn cohérent avec le site ; (c) 3-4 cas clients anonymisés au format problème / solution / résultat.\nContrainte confidentialité : anonymisation systématique, et RÈGLE STRICTE sur APCIAL — ne jamais mentionner les noms réels des clients finaux (Association A, Site X…).\nContrainte IP : ne présenter comme actif OnlyDev que ce qui l'est réellement — le tarificateur ASDGL n'a toujours pas d'acte de cession, ne pas l'exposer en vitrine avant l'audit PI avocat.\nLivrable attendu au tri : décision go/no-go + estimation en jours, PAS de production.\n\nVOLET 2 — ACQUISITION PAR LE CONTENU (REPORTÉ, mais NE PAS PERDRE).\nObjectif : présence régulière sur les réseaux générant des leads entrants. Nature : récurrent, 6-12 mois avant premier effet, première chose qui saute quand un client urgent arrive.\nDÉCISION SEB 09/08 : reporté, pas abandonné. À rouvrir explicitement — ne pas laisser mourir en fond de file.\nCondition de réouverture : le tableau de marge (instruction 71b22723) doit avoir été produit. Motif : générer plus de leads sur des prestations dont la marge est inconnue amplifie le problème au lieu de le résoudre — pilier 1 du cadre de référence est correct, c'est le pilier 2 qui est le trou.\nÀ instruire à la réouverture : quel canal unique (pas trois), quelle cadence tenable, quel angle (architecte/concepteur produit, pas prestataire de dev), et quel volume d'heures/mois plafonné.\n\nRATTACHEMENT : à reprendre au tri hebdo du mardi 11/08 avec le volet 1 seulement. Le volet 2 est à re-présenter au tri suivant la production du tableau de marge, sans attendre que Seb y repense.",
            "status": "done",
            "createdAt": "2026-08-09T16:13:25Z",
            "doneAt": "2026-09-15T10:18:29Z"
        },
        {
            "id": "8b7eba84",
            "project": "ONLYDEV",
            "action": "FACTURATION — Établir et envoyer la facture de renouvellement d'hébergement pour le client PLUNE (orthographe à confirmer avec Seb, saisie mobile).\n\nÀ compléter avant émission : montant HT, période couverte (dates début/fin), périodicité (annuelle ?), et vérifier si un renouvellement fournisseur (OVH ou autre) est à passer en amont ou déjà réglé.\n\nNote capture 09/08/2026, à traiter au tri du 11/08.\n\nPOINT À SOULEVER AU TRI (ne pas exécuter sans validation Seb) : passer en revue TOUS les hébergements en cours chez les clients OnlyDev en une seule fois plutôt qu'au fil de l'eau — lister client / montant / date d'échéance / coût fournisseur réel. Motif : c'est la seule ligne de revenu récurrent identifiée chez OnlyDev, elle est facturée à la demande donc probablement sous-facturée ou oubliée sur certains clients, et la marge réelle n'est pas connue. Alimente directement le tableau de marge (instruction 71b22723).",
            "status": "done",
            "createdAt": "2026-08-10T09:01:09Z",
            "doneAt": "2026-08-11T08:16:54Z"
        },
        {
            "id": "cabbc7af",
            "project": "QG",
            "action": "MCP — accepter les binaires dans drive_push.\n\nCONTEXTE : drive_push n'accepte que du texte. Tout binaire (.xlsx, .pdf, .pptx, .docx) doit passer par drive_upload.php côté Claude Code, ce qui casse le flux quand on travaille depuis Claude.ai. Session du 10/08/2026 : ~15 itérations sur MARGE_REELLE_2026.xlsx, chacune avec un aller-retour manuel télécharger → déposer sur le Drive.\n\nATTENDU : soit un paramètre optionnel content_b64 + mime_type sur drive_push, soit un outil drive_push_binary distinct. Comportement conservé : sous-dossier projet créé automatiquement sous CLAUDESYNC/<project>/, file_id optionnel pour mise à jour d'un fichier existant. Détection ou rejet propre si content_b64 mal formé.\n\nCONTRAINTES : périmètre Drive existant, pas de nouveau pilier. Timebox 1 jour. Aucun secret ni token dans D:\\xampp\\htdocs\\7hWk (sous webroot XAMPP). Rien en prod avant validation Sébastien.\n\nNON-OBJECTIF : ne pas toucher à mark_done, get_state, set_state, list_inbox, push_instruction.\n\nJUSTIFICATION FILTRE QG : critère \"heures économisées\" démontré (15 allers-retours manuels sur une seule session). Le Drive fait déjà partie du périmètre gelé état + inbox + Drive — c'est une amélioration d'un pilier existant, pas une extension.",
            "status": "done",
            "createdAt": "2026-08-11T08:13:27Z",
            "doneAt": "2026-08-11T10:26:48Z"
        },
        {
            "id": "cfe9356d",
            "project": "QG",
            "action": "QG — LISIBILITÉ DE L'INBOX ET DES PRIORITÉS. À traiter à la sortie de la réunion WOW du 11/08 (Sébastien s'occupe du state en parallèle).\n\nCONSTAT SÉBASTIEN 11/08 : les priorités du jour et le tri hebdo sont peu exploitables. L'inbox restitue des blocs de texte longs, sans hiérarchie. Pour arbitrer, il faut avoir tout le contexte de toutes les tâches en tête — donc aucune vision globale possible. Le problème est le PILOTAGE, pas le confort d'affichage.\n\nDIAGNOSTIC À VALIDER : le défaut n'est pas dans le MCP mais dans le FORMAT D'ÉCRITURE des instructions. Elles sont rédigées comme des dumps de contexte : ni titre, ni prochaine action isolée, ni échéance, ni blocage, ni indication de ce qui est fermable. Une instruction de 40 lignes ne se relit pas au tri.\n\nVOLET 1 — DOCTRINE DE FORMAT (zéro code, à faire en premier).\nRédiger DOCTRINE_instructions_v1.md dans CLAUDESYNC/QG/. Template imposé à toute instruction future, en 6 champs courts :\n- TITRE : une ligne, verbe d'action + objet\n- POURQUOI : 2 lignes maximum\n- PROCHAINE ACTION : une seule, concrète, exécutable\n- ÉCHÉANCE : date ou \"aucune\"\n- BLOQUÉ PAR : instruction, personne, ou décision attendue\n- FERMABLE QUAND : critère explicite de clôture\nLe contexte long va dans un fichier Drive lié, pas dans l'instruction. L'instruction porte le pointeur.\n\nVOLET 2 — RESTITUTION (après validation du volet 1).\nVue de tri : list_inbox trop verbeux pour un arbitrage. Étudier un mode compact (titre + projet + échéance + bloqué par) et un regroupement par projet. Décider si c'est un paramètre de list_inbox ou une simple convention de rendu côté Claude.ai. NE RIEN CODER avant arbitrage Sébastien sur le volet 1.\n\nCONTRAINTES : périmètre gelé état + inbox + Drive, pas de nouveau pilier. Timebox 1 jour pour le volet 1. Rien en prod avant validation.\n\nSÉQUENCEMENT QG : cinq chantiers en file (8ce42269 distillation, 64caac90 amendement archive, 7bbb3c51 échéances, cabbc7af binaires drive_push, celui-ci). Aucun déployé. Celui-ci est un prérequis de lisibilité pour les autres — le proposer en tête de file à l'arbitrage.",
            "status": "done",
            "createdAt": "2026-08-11T08:21:28Z",
            "doneAt": "2026-08-11T10:23:22Z"
        },
        {
            "id": "73bb09b2",
            "project": "QG",
            "action": "TITRE : Modifier le MCP — âge des instructions + vue de tri compacte + champ échéance\n\nPOURQUOI : Le pilotage est illisible (constat Seb 11/08, cf. cfe9356d). Décision de session : exploiter createdAt (âge visible, tri par ancienneté, seuil de décision forcée) et poser les fondations du modèle chantier. Synthèse complète : CLAUDESYNC/QG/SYNTHESE_session_2026-08-11.md (id 1dE6BHX_ndybobFMx7uAUN-R1XPe3IMcR) — LIRE via drive_read avant tout.\n\nPROCHAINE ACTION : Lire la synthèse, puis implémenter dans Tools.php/Storage.php sur mscrpv.onlydev.fr, dans cet ordre :\n1. list_inbox : ajouter un paramètre optionnel format=compact retournant une ligne par instruction : id / projet / titre (première ligne de action, tronquée à 80 car.) / âge en jours (calculé depuis createdAt) / échéance si présente. Paramètre sort=age pour tri par ancienneté décroissante. Comportement actuel inchangé par défaut.\n2. push_instruction : accepter un champ optionnel echeance (date ISO, nullable). Stocké, restitué dans list_inbox (les deux formats).\n3. list_inbox format=compact : marquer visuellement (préfixe [!]) toute instruction dont l'âge dépasse le seuil. Seuil dans un fichier de config, valeur initiale 21 jours — PAS en dur dans le code, Seb doit pouvoir l'ajuster.\n\nÉCHÉANCE : aucune (backlog ordonné, à engager au prochain tri).\n\nBLOQUÉ PAR : validation Sébastien du seuil 21 jours (proposé, non confirmé) — implémenter avec 21 par défaut, il est configurable. Rien en prod avant validation Seb (règle permanente).\n\nFERMABLE QUAND : les 3 points livrés + testés depuis Claude.ai (un list_inbox compact réel affiché avec âges corrects) + note de retour listant les écarts.\n\nCONTRAINTES : périmètre gelé état+inbox+Drive — ceci est une amélioration de piliers existants, pas une extension. Aucun secret sous D:\\xampp\\htdocs\\7hWk. Timebox 1 jour, si dépassé stop et documenter. NE PAS implémenter ici le module échéances complet (7bbb3c51 : echeances.json, 4 outils, echeances_a_risque) ni la distillation (8ce42269) — cette instruction est le socle minimal, le resequencement de la file QG reste à arbitrer par Seb (cf. synthèse §resequencement).\n\nNOTE FORMAT : cette instruction applique le template 6 champs de cfe9356d volet 1 — elle sert de premier exemple du format cible.",
            "status": "done",
            "createdAt": "2026-08-11T10:08:49Z",
            "doneAt": "2026-08-11T10:21:40Z"
        },
        {
            "id": "2df15307",
            "project": "APCIAL",
            "action": "Débloquer Clovis (formulaires + API livrés) : 1) créer ses accès serveur OnlyDev pour déployer une version de démo/staging ; 2) créer le repo Git APCIAL et lui donner accès. Bloquant pour la mise en ligne — à faire avant fin de semaine.",
            "status": "done",
            "createdAt": "2026-08-12T09:05:02Z",
            "echeance": "2026-08-14",
            "doneAt": "2026-08-21T09:14:57Z"
        },
        {
            "id": "f0e42834",
            "project": "WINORWIN",
            "action": "Nettoyer les colonnes In Review et In Progress du board Trello W (tickets obsolètes ou terminés à archiver/déplacer) — idéalement avant de filer les 17 tickets V1 arbitrés à l'équipe, pour que le board reflète la charge réelle.",
            "status": "done",
            "createdAt": "2026-08-12T09:05:08Z",
            "echeance": "2026-08-13",
            "doneAt": "2026-08-28T15:16:59Z"
        },
        {
            "id": "2ca10742",
            "project": "MCP",
            "action": "Évaluer Hermes Agent (Nous Research, open source, MIT) comme runtime d'agent complémentaire au MCP QG — pas un remplacement : Hermes peut consommer le serveur MCP existant. Points à examiner : cron intégré vs échéances module, mémoire persistante vs doctrine CLAUDESYNC, self-hosting (VPS/local). NE PAS DÉMARRER avant signature lettre d'accord WOWDEV + licence WinOrWin.",
            "status": "open",
            "createdAt": "2026-08-12T22:18:28Z"
        },
        {
            "id": "fce2fdcd",
            "project": "ASDGL",
            "action": "Lire DEBRIEF_oussama_2026-08-14.md (CLAUDESYNC/ONLYDEV/). Action : prise de contact ASDGL pour poser le RDV de régularisation IP tarificateur. Règle anti-pattern : date posée AVANT toute préparation (prep plafonnée à 1 page / 1 heure, après confirmation de la date). Levier : MNCAP verrouillé sur \"estimation avant dev, en attente contrat IP\". Échéance contact : semaine du 17/08. Échéance RDV : avant fin septembre 2026. Bloqueur : aucun. Done-when : date de RDV confirmée par ASDGL.",
            "status": "done",
            "createdAt": "2026-08-14T15:11:51Z",
            "echeance": "2026-08-21",
            "doneAt": "2026-08-21T08:15:48Z"
        },
        {
            "id": "34961372",
            "project": "ONLYDEV",
            "action": "Évolution QG vers pattern \"graph engineering\" (réf : DEBRIEF_oussama_2026-08-14.md §A3, ONLYDEV). Objectif : monter d'un niveau d'abstraction — boucles agents avec vérificateurs, pas plus d'agents. Étape 1 (pilote) : choisir UN chantier réel (ticket V1 WinOrWin ou module ASDGL), définir le vérificateur AVANT de lancer (tests auto, schéma, diff gate — critère objectif vérifiable sans relecture ligne à ligne), puis laisser Claude Code boucler générer→vérifier→corriger jusqu'au vert. Étape 2 (après pilote réussi) : évaluer typage de l'état QG (nœuds/arêtes vs texte libre) pour mémoire inter-sessions exploitable par agents. Garde-fous : le MCP OD existant = couche de persistance, à conserver ; pas de refonte big-bang ; pas de swarm avant d'avoir des vérificateurs qui tiennent. Done-when étape 1 : un chantier livré en boucle autonome avec vérificateur documenté dans CLAUDESYNC/ONLYDEV/.",
            "status": "open",
            "createdAt": "2026-08-14T15:12:01Z"
        },
        {
            "id": "ece23230",
            "project": "ONLYDEV",
            "action": "Veille / à tester : GitHub Spec Kit (github/spec-kit) — toolkit open source de Spec-Driven Development compatible Claude Code. CLI `specify` (install via `uv tool install specify-cli`, repo GitHub uniquement, pas PyPI) + slash commands /speckit.specify → plan → tasks → implement, avec analyse de cohérence inter-artefacts. Piste de test : un lot réel borné (ex. ticket V1 WinOrWin) plutôt qu'un projet jouet. Prise de note simple — pas prioritaire, pas de deadline.",
            "status": "open",
            "createdAt": "2026-08-14T20:24:15Z"
        },
        {
            "id": "27f356dc",
            "project": "digital",
            "action": "Intégrer le nouveau contrat KEREIS « SMART EMPRUNTEUR » au tarificateur (nouveau connecteur emprunteur). Deadline : vendredi 21/08. Tracer le dev par commit daté + libellé explicite (preuve d'antériorité OnlyDev pour le dossier IP — définition large tarificateur = moteur + connecteurs + orchestration).",
            "status": "done",
            "createdAt": "2026-08-19T17:00:58Z",
            "echeance": "2026-08-21",
            "doneAt": "2026-08-21T08:15:43Z"
        },
        {
            "id": "60f3f162",
            "project": "QG-MCP",
            "action": "DEV — VUE_QG v0 (timebox 1 jour, dans le plafond dev propre 2j/sem). Objectif : page web READ-ONLY rendant le state + l'inbox du MCP OD visuellement — Seb ouvre et voit, sans passer par Claude. Périmètre : (1) une carte par projet du state : nom, statut (couleur), prochaine action (a_faire résumé), risque principal, échéances détectées dans le texte (rouge si dépassée/J-3) ; ordre = focus. (2) priorite_semaine en bandeau haut. (3) inbox en badge compteur + liste dépliable (id, projet, titre, âge, [!] si >21j, échéance). (4) Responsive mobile + desktop. Contraintes : READ-ONLY strict (aucune écriture, v0 sans action) ; consomme get_state + list_inbox du MCP existant (ou lecture directe du même stockage serveur) ; hébergement sur mscrpv.onlydev.fr derrière auth simple (pas public) ; AUCUN secret sous D:\\xampp\\htdocs\\7hWk ; pas de framework lourd — PHP/HTML/CSS vanilla suffit ; zéro dépendance nouvelle côté serveur. Done-when : state + inbox lisibles en 10 secondes sur mobile et desktop, échéances à risque visibles sans scroll. NE PAS étendre le périmètre (pas d'édition, pas de graphiques, pas de module finances en v0). Livrable : URL + note d'écarts éventuels avec cette spec.",
            "status": "open",
            "createdAt": "2026-08-21T09:22:14Z",
            "echeance": "2026-08-28"
        },
        {
            "id": "7b8f87b4",
            "project": "WINORWIN",
            "action": "CAPTURE POUR TRI — NE RIEN EXÉCUTER, NE RIEN CODER. Idée produit Seb 21/08 : offre « QG piloté par IA pour dirigeant de PME » à destination des membres WinOrWin. Deux formes possibles évoquées : (A) SaaS dashboard (type outil de pilotage abonnement) — PRÉ-ANALYSE DÉFAVORABLE : même équation que la piste app API WoW clôturée le 06/08 (ticket faible × base membres plafonnée ≈ 4000 membres nécessaires pour 6k/mois) + concurrence frontale Monday/Notion à prix égal (R1 : alternative client excellente et pas chère) ; (B) offre packagée SERVICE : setup QG + rituel de pilotage + IA branchée, ticket 4 chiffres, aucune brique à construire d'avance — l'installation de Seb EST la démo. Forme B cohérente avec la thèse prestations aux membres (ex-SF DEV, fusionnée WOWDEV). À passer à la GRILLE_qualification_idees_v1.md (CLAUDESYNC/QG/, id 19RRK96UhgB1U4sw17gW7M9_TnVO-2kWJ) au tri du 25/08. CONTRAINTES NON NÉGOCIABLES : rien de démontrable avant lettre d'intention WOWDEV signée ; si go après qualification → périmètre structure signée, pas de canal informel François ; VUE_QG v0 (instruction 60f3f162) est un outil interne Seb, PAS le pilote du produit — ne pas confondre les deux chantiers.",
            "status": "done",
            "createdAt": "2026-08-21T09:22:25Z",
            "echeance": "2026-08-25",
            "doneAt": "2026-09-15T10:18:35Z"
        },
        {
            "id": "e77a4311",
            "project": "QG-MCP",
            "action": "FIX set_state (~30 min) : l'endpoint fait un upsert par nom et ne supprime jamais un projet absent du payload — bug confirmé 21/08 (TEST_BIDON et SF DEV « supprimés » deux fois, toujours présents). Corriger en vrai remplacement (delete des projets absents du payload) OU ajouter une action delete_project. Puis purger TEST_BIDON (statut obsolete_a_purger) et SF DEV (statut fusionne_a_purger) — leur contenu utile est déjà repris dans WINORWIN, rien à sauvegarder. Test de recette obligatoire : pousser un state sans un projet → get_state ne le renvoie plus. À coller à la session VUE_QG v0 (instruction 60f3f162, même échéance).",
            "status": "open",
            "createdAt": "2026-08-21T14:56:26Z",
            "echeance": "2026-08-28"
        },
        {
            "id": "3817545c",
            "project": "ASDGL",
            "action": "Planifier la bascule vers le nouveau serveur : produire le plan de bascule (périmètre, prérequis, séquencement, fenêtre de bascule, tests, rollback). Plan à faire semaine du 31/08 au 04/09.",
            "status": "open",
            "createdAt": "2026-08-28T09:14:28Z",
            "echeance": "2026-09-04"
        },
        {
            "id": "3b51cb19",
            "project": "WINORWIN",
            "action": "[WINORWIN] CR réunion du 2026-08-12 publié — distillat à faire par le QG. Fichier : CLAUDESYNC/WINORWIN/CR_2026-08-12_reunion-isa.md",
            "status": "done",
            "createdAt": "2026-08-28T14:57:07Z",
            "doneAt": "2026-08-28T15:17:03Z"
        },
        {
            "id": "bc13304a",
            "project": "WINORWIN",
            "action": "Suivi post-réunion ISA 12/08 (CR : CLAUDESYNC/WINORWIN/CR_2026-08-12_reunion-isa.md) — 3 points dormants à statuer : ① tickets bloqués \"installation APK\" (discussion François prévue le 12/08 après-midi — résolue ?) ② ticket Airtable de Lilian (posé le 24/06, aucune nouvelle de lui ; il aurait fait les posts de renouvellement à la dernière minute — clarifier le statut de la ressource, pas seulement du ticket) ③ validation finale Pennylane, annoncée comme \"le gros morceau\" — obtenir périmètre et échéance.",
            "status": "open",
            "createdAt": "2026-08-28T15:16:54Z"
        },
        {
            "id": "044a002a",
            "project": "APCIAL",
            "action": "[APCIAL] CR réunion du 2026-08-12 publié — distillat à faire par le QG. Fichier : CLAUDESYNC/APCIAL/CR_2026-08-12_clovis.md",
            "status": "done",
            "createdAt": "2026-08-31T08:31:09Z",
            "doneAt": "2026-08-31T09:38:52Z"
        },
        {
            "id": "188b1607",
            "project": "APCIAL",
            "action": "[APCIAL] CR réunion du 2026-08-26 publié — distillat à faire par le QG. Fichier : CLAUDESYNC/APCIAL/CR_2026-08-26_reunion-usage.md",
            "status": "done",
            "createdAt": "2026-08-31T08:31:11Z",
            "doneAt": "2026-08-31T09:38:59Z"
        },
        {
            "id": "2a070450",
            "project": "ASDGL",
            "action": "[ASDGL] CR réunion du 2026-09-02 publié — distillat à faire par le QG. Fichier : CLAUDESYNC/ASDGL/CR_2026-09-02_note-vocale.md",
            "status": "done",
            "createdAt": "2026-09-02T10:57:44Z",
            "doneAt": "2026-09-02T11:18:54Z"
        },
        {
            "id": "8fbb9b18",
            "project": "3P1-AZUR-CONFORT",
            "action": "RELANCE CLIENT devis multilingue (2 langues WPML + bug panier anglais) — NE PAS RELANCER AVANT LE LUNDI 07/09 (décision Seb 02/09). Le 07/09 : message de relance court au client (devis en attente de signature depuis 8+ semaines), proposer un créneau d'échange. Rappel périmètre à la signature seulement : licence WPML (coût inclus ou refacturé ?) + implémentation + vérifier si le bug panier est dans le périmètre.",
            "status": "open",
            "createdAt": "2026-09-02T11:31:28Z",
            "echeance": "2026-09-07"
        }
    ]
}