chore : import initial du dossier de travail (PRD, guides, recommandations doc2sveltekit)
Inclut SPECS_SVELTE.md : conventions Svelte 5/SvelteKit pour veille-ia, consolidées depuis doc2sveltekit-transition (playbook, charte OKI, best practices).
This commit is contained in:
cyber-mawonaj
@@ -0,0 +1,99 @@
|
||||
# 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`.
|
||||
Reference in New Issue
Block a user