veille-ia-gen/prompt_kimi_cli_veille_ia.md

# PROMPT POUR KIMI CLI — Projet « veille-ia »
*(à coller tel quel dans Kimi CLI, depuis le dossier de travail contenant `plan_prd_veille_ia.md` ; ajouter `SPECS_SVELTE.md` à côté quand tes recommandations Svelte sont prêtes)*

---

```
RÔLE
Tu es un développeur full-stack senior spécialisé SvelteKit et packaging YunoHost.
Tu construis une application web appelée « veille-ia » : un observatoire personnel
de veille sur les modèles IA génératifs (sorties, licences, classements), avec
moteur de recommandation par profils de projets. Application monoprivée,
self-hosted, destinée à être packagée pour YunoHost et installée sur un serveur
personnel. Tout doit fonctionner sans aucune API payante.

DOCUMENTS DE RÉFÉRENCE (à lire INTÉGRALEMENT avant de coder)
1. ./plan_prd_veille_ia.md  — PRD complet : architecture, schémas YAML, flows
   Node-RED, règles métier. C'est la spécification fonctionnelle, suis-la.
2. ./SPECS_SVELTE.md — recommandations Svelte du porteur. Si le fichier existe,
   il PRÉVAUT sur tout choix technique frontend. S'il est absent, applique :
   SvelteKit + TypeScript strict + adapter-node, Svelte 5 (runes), aucun
   framework CSS lourd (Tailwind autorisé), composants accessibles (clavier,
   contrastes), aucune dépendance non maintenue.
3. Documentation officielle packaging YunoHost : https://doc.yunohost.org/packaging_apps
   — VÉRIFIE le format actuel du manifest.toml (packaging v2) et des helpers
   avant d'écrire le moindre script. Ne devine jamais une syntaxe de helper.

RÈGLES STRICTES
- Zéro hallucination : tout champ de donnée non vérifiable doit être `null`
  et l'UI affiche un badge « ⚠️ à vérifier ». Aucune licence, aucun prix,
  aucun benchmark ne peut être écrit en dur sans champ `sources[]` associé.
- Zéro dépendance propriétaire ou source-available (pas de n8n, pas de licence
  non-OSI dans l'arbre de dépendances direct). Licence du projet : AGPL-3.0.
- Persistance : fichiers YAML dans le data_dir + commits git automatiques
  (simple-git). Pas de base de données dans cette version.
- Tout appel LLM passe par un endpoint Ollama configurable (variable d'env
  OLLAMA_URL, défaut http://127.0.0.1:11434). L'app doit démarrer et fonctionner
  même si Ollama est injoignable (dégradation gracieuse, pas de crash).
- Sécurité : endpoint POST /api/alerts protégé par token (variable d'env
  ALERTS_TOKEN générée à l'install). Aucune route mutative sans vérification.
- Commits git atomiques et explicites, en français. README.md à jour à chaque
  phase.

LIVRABLES, DANS CET ORDRE (arrête-toi à la fin de chaque phase pour mon validation)

PHASE 0 — Socle + packaging
1. Scaffold SvelteKit (TypeScript strict, adapter-node) dans ./app/
2. Layout + navigation SSO-aware : l'app lit le header SSO YunoHost
   (YNH_USER) via les hooks serveur ; sans header valide, page d'accueil
   publique minimale uniquement.
3. Package YunoHost ./veille-ia_ynh/ : manifest.toml (packaging v2),
   scripts install / remove / upgrade / backup / restore / change_url,
   ressources ports + nodejs + system_user + install_dir + data_dir,
   service systemd, config nginx. Respecte la doc officielle vérifiée.
4. Script de dev local : l'app doit aussi tourner hors YunoHost
   (variables d'env documentées).

PHASE 1 — Cœur métier
5. data/registre_modeles.yaml + data/profils_projets.yaml créés au premier
   démarrage, pré-remplis EXACTEMENT avec les schémas et les 5 profils du PRD
   (vn_renpy_adulte, prestation_images, clips_vendus, jeu_steam_itch,
   diffusion_libre). Les données d'exemple de modèles viennent du PRD §4.1.
6. CRUD registre + profils (pages + routes serveur), validation Zod des
   schémas YAML, commit git à chaque écriture.
7. Moteur de recommandation POST /api/recommander + page UI :
   filtrage dur (requiert/exclut) puis scoring pondéré (préférences,
   rang arena, fraîchier derniere_verif, pénalités statut et champs null).
   Chaque recommandation affiche sa justification et ses warnings
   (attribution requise, seuil de revenus, licence à vérifier,
   déclarations plateformes).
8. Exporteur markdown : génération des documents guide/classements depuis
   le registre via templates éditables.

PHASE 2 — Alertes (ne commence qu'après ma validation de la phase 1)
9. POST /api/alerts (token) + schéma d'alerte du PRD + inbox UI filtrable
   par profil impacté + actions « créer/MAJ fiche » et « traité ».
10. Flows Node-RED exportés en JSON importable dans ./nodered-flows/
    (rss-ingest, license-watch, classifier, notify) conformes au PRD §5,
    avec le prompt classifieur du PRD §6 embarqué tel quel.

QUALITÉ
- `npm run check` (svelte-check) et `npm run lint` propres à chaque commit.
- Tests : vitest sur le moteur de recommandation (cas nominaux + cas limites :
  licence null, seuil dépassé, modèle statut "mort").
- À la fin de chaque phase, imprime : ce qui est fait, ce qui reste,
  les commandes de test, et ATTENDS ma validation avant de continuer.
- Si une information te manque (version de helper YunoHost, comportement
  d'API), cherche la doc officielle ; si introuvable, pose-moi la question
  au lieu de supposer.
```

---

## Notes d'usage (pour toi, pas pour Kimi CLI)

1. **Ordre de préparation** : écris d'abord ton `SPECS_SVELTE.md` (conventions, runes vs stores, Tailwind ou non, structure de dossiers, accessibilité, i18n) et dépose-le à côté du PRD — le prompt lui donne la priorité.
2. **Validation par phases** : le prompt impose un arrêt entre phases. Ne laisse pas Kimi CLI enchaîner 0→2 d'un coup : le packaging YunoHost (phase 0) est le point le plus à risque, vérifie `package_check` toi-même.
3. **Ollama** : si `ollama_ynh` n'est pas maintenu au moment de l'install, fais tourner Ollama sur ta machine locale et expose-le au serveur via VPN/wireguard — l'app y survivra (dégradation gracieuse prévue).
4. **Après installation** : configure dans changedetection_ynh les URLs de ToS/licences à surveiller (liste dans ton guide licences §9) avec notification webhook vers Node-RED.
5. **Évolution future** : quand le registre sera stable, on pourra y brancher mon digest hebdomadaire (cron) — je te fournis les diffs, l'app les ingère via `/api/alerts`.