https://kaneo.nanceela.com — espace « Nanceela », un projet par app.
| Clé |
Projet |
| PC |
PhotoCoach iOS |
| PCW |
PhotoCoach Web |
| CLN |
Clyro |
| SH |
SafeHome |
| SHP |
SafeHome Pro |
| CD |
Check Devis |
| RC |
RideCoach |
| SG |
SaveGas / Alyvo |
| POOL |
Poolcare |
| CLR |
Cleara |
| GEN |
Général (infrastructure, outils) |
Colonnes, dans l'ordre : Backlog → À faire → Pour Claude → Cette nuit → En cours → En revue → À valider → Intervention nécessaire → Terminé.
- Pour Claude : pris en charge par le robot dans la demi-heure. Cette nuit : traité pendant la nuit.
- À valider : le travail est fait, Nicolas vérifie. Intervention nécessaire : le robot est bloqué.
- Terminé appartient à Nicolas. Exception : une carte « À valider » entièrement vérifiée (code, tests, staging) peut y être passée par Claude.
- Étiquettes Prêt / À affiner : un ticket « À affiner » doit être discuté avant d'être lancé.
- Kaneo ne permet pas de créer des colonnes par son MCP : un nouveau projet demande une petite manipulation en base pour avoir ces 9 colonnes.
Sur le Mac mini, un service (launchd) interroge Kaneo et lance Claude Code sur les tickets des colonnes Pour Claude et Cette nuit. Il travaille dans des clones dédiés sur le SSD (/Volumes/SSD/kaneo-runner/<app>), crée une branche et une PR, puis commente le ticket.
Deux autorisations expirent et doivent être renouvelées :
- Accès de Claude à Kaneo (MCP) : session de 30 jours, prochaine expiration vers le 6 décembre 2026.
- Connexion claude.ai du robot : expire le 30 novembre 2026.
- BMAD (méthode de découpage en epics et stories) est installé à l'essai dans 7 dépôts. Chaque demande qui produit du code ou un réglage durable devient une story et un ticket Kaneo ; une simple question non.
- L'affinage d'un ticket se fait dans la conversation, une carte à la fois, puis Kaneo est mis à jour.
- Chaque dépôt a un
memory-bank/ tenu à jour dans la même PR que le code.
- PR d'interface : 1 à 3 petites captures avant/après dans la PR.
- Fusion : Claude peut fusionner les PR du site une fois ses tests passés (et redéployer le staging). Côté serveur, seulement si ce n'est pas critique : paiements, crédits, suppression, authentification = accord de Nicolas.
- Builds et tests sur le SSD externe, un seul simulateur ou émulateur à la fois.
Toutes les docs de projet suivent le même plan : voir le Modèle de documentation projet.
Le wiki doit refléter ce qui est livré, sans qu'on ait à le demander :
- une étude aboutit (recommandation, mesures, décision) → la page de l'étude est mise à jour avec le résultat ;
- un ticket passe en « À valider » ou « Terminé » → la page du projet est mise à jour (état, ce qui a changé) ;
- une décision est prise → elle s'ajoute au tableau des décisions datées du projet ;
- une date apparaît → elle va dans Échéances.
Claude fait ces mises à jour pendant les séances (le robot de nuit ne peut pas écrire dans le wiki : ses tickets sont reportés quand ils sont validés). Chaque mise à jour cite le ticket (ex. SHP-1).
Jamais de secret dans le wiki, les memory-bank/ ou les tickets. On écrit seulement où il est rangé.