feat(aidd-context): add Kilo-native generation targets

.github/workflows/cli-ci.yml

@@ -350,6 +350,7 @@ jobs:
       - name: Install Kilo Code CLI
         run: npm install -g @kilocode/cli@7.7.5
       - run: cd cli && pnpm test:e2e:kilo
+      - run: cd cli && pnpm test:e2e:kilo:native
 
   cli-build:
     name: cli / Build & Bundle Budget

aidd_docs/tasks/2026_10/2026_10_10_kilo-native-generation-914/challenge.md

@@ -0,0 +1,31 @@
+My confidence level of correctness now: 90%
+
+Rapport historique de planification, avant l’autorisation et l’implémentation de phase 1 ; aucune preuve d’implémentation ne se déduit de ce score.
+
+# Correctness (100%)
+
+- Capacité installée `aidd-refine:02-challenge` effectivement appliquée dans le caller Codex après production et lecture du plan, des six phases et de la matrice. Référence convenue : seize critères officiels #914, demande utilisateur actualisée, architecture et CONTRIBUTING. Ce pourcentage évalue la justesse du plan révisé, jamais une implémentation inexistante.
+- Alignement : les seize lignes reprennent les critères officiels sans regroupement qui en cache un. Aucun code fonctionnel modifié ; plan et phases pending, développement soumis à validation explicite.
+- Responsabilité correcte : aidd-context produit les artefacts ; CLI conserve profils et bridge. `02-project-init` obsolète se projette sur mémoire, sans ajout inutile à bootstrap. Aucun développement flat #868 ni hook runtime générique.
+- Canonique Claude : templates conservés ; exceptions Kilo ciblées dans rendu/validation, notamment filename agent, choix portable skill et guidance hook. Relance Claude hooks couverte car le code actuel peut dupliquer les entrées.
+- Configuration : sélection explicite en ambiguïté, réutilisation owner unique, édit minimal JSONC, conservation des duplications utilisateur. Les doublons sur disque sont un oracle distinct du tableau d’instructions fusionné par Kilo.
+- Challenge résolu : le preflight mémoire s’applique avant Upsert, pas seulement avant le sous-processus Fill. Sinon une erreur tardive pouvait laisser un nouveau contexte. Les tests capturent le projet entier à l’entrée de l’action sync, y compris une cible invalide en dernier.
+- Challenge résolu : plusieurs rename atomiques ne prouvent pas l’absence d’écriture partielle. Phase règles inclut staging global, contrôles de changement et restauration sur les pannes testées. Ne pas revendiquer une garantie crash-machine universelle.
+- Challenge résolu : la CI Kilo existante est Ubuntu-only sur 7.7.5. Phase 6 prévoit de vérifier les plateformes supportées et les contraintes du runner avant une adaptation ciblée du job existant, avec sorties réellement générées/hashées et inférence locale contrôlée. Aucun compte Codex ou modèle gratuit externe supposé disponible en CI.
+- Challenge résolu : le harness actuel appelle claude -p authentifié. Le plan prévoit des parcours Codex réels dès chaque phase, puis une extension ciblée du runner ; les sorties Claude sont vérifiables sans abonnement, mais cette preuve n’est pas une exécution de générateur dans Claude authentifié.
+- #979 revalidée Draft/open, next ; l’alignement du writer est un gate explicite de phase 2. Pas de mécanisme concurrent conçu en parallèle, pas de modification Git anticipée. Les changements Codex/OpenCode de cette base sont isolés des régressions introduites par Kilo.
+- Accès gratuit Kilo observé avec coût final 0 ; absence de credentials enregistrés déclarée. Les tests runtime restent futurs ; la sonde de connectivité ne valide ni découverte ni utilisation d’un artefact #914.
+- Trust : fier du plan livré : oui ; confiance dans les décisions conséquentes du plan conditionnel : oui ; réponse au résultat attendu de cette session : oui. Les gates d’implémentation et accès externes ne sont pas dissimulés comme des preuves obtenues.
+
+- Aucun deal breaker pour la remise du plan révisé. L’absence actuelle du writer #979 dans HEAD bloque le démarrage de la phase 2 tant que la base n’est pas alignée ou le plan explicitement amendé ; elle ne bloque pas les phases indépendantes ni l’approbation de ce plan.
+- Runtime Claude authentifié indisponible, OpenCode absent du PATH, Kilo multi-OS non exécuté : validations futures déclarées non acquises. Aucun critère #914 ne requiert spécifiquement un modèle Claude, mais la demande de CONTRIBUTING n’est pas satisfaite par le seul offline. Ne pas annoncer une validation finale complète sans publier cette limite.
+
+# Deal breakers
+
+# Suggestions (enhancements only)
+
+- Si le writer #979 évolue avant intégration, tenir un petit reçu de revalidation head/base/tests dans les preuves de phase 2 ; ne pas copier ses données historiques en les présentant comme nouvelles.
+- Pour limiter le coût des évaluations LLM, réserver les répétitions aux chemins à risque : sélection ambiguë, refus tardif, portable et relances. Garder le corpus déterministe pour les invariants byte-level, et les parcours runtime réels pour découverte/usage.
+- Garder une PR future cohérente couvrant #914 plutôt que supposer un découpage Git aujourd’hui. L’ordre des phases est une organisation du travail, pas une autorisation de commit ou de PR.
+
+- Précisions après validation utilisateur : le score historique de 90 % porte uniquement sur le plan. Les ajustements sont ciblés : preuves progressives et statut réel par tâche, phase 1 seule autorisée, gate #979 explicite, JSONC sans moteur générique et extension CI conditionnée au support/runner vérifiés. Aucun critère officiel supprimé ; aucun score de qualité d’implémentation déduit du challenge.