devflow-cli 4.0.2__tar.gz → 6.1.0__tar.gz

devflow_cli-6.1.0/.github/workflows/release.yml

@@ -0,0 +1,88 @@
+name: Release
+
+on:
+  push:
+    tags: ["v*"]
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup uv
+        uses: astral-sh/setup-uv@v4
+        with:
+          version: "latest"
+
+      - name: Setup Python
+        run: uv python install 3.12
+
+      - name: Check tag, version and main commit
+        env:
+          RELEASE_TAG: ${{ github.ref_name }}
+          RELEASE_SHA: ${{ github.sha }}
+        run: |
+          main_sha="$(git ls-remote origin refs/heads/main | cut -f1)"
+          uv run --no-project --python 3.12 python scripts/check_release.py \
+            --tag "$RELEASE_TAG" --head-sha "$RELEASE_SHA" --main-sha "$main_sha"
+
+  test:
+    needs: validate
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    strategy:
+      matrix:
+        python-version: ["3.11", "3.12"]
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup uv
+        uses: astral-sh/setup-uv@v4
+        with:
+          version: "latest"
+
+      - name: Setup Python ${{ matrix.python-version }}
+        run: uv python install ${{ matrix.python-version }}
+
+      - name: Create venv and install dependencies
+        run: |
+          uv venv --python ${{ matrix.python-version }}
+          uv pip install -e ".[dev]"
+
+      - name: Run tests
+        run: uv run pytest tests/ -v --ignore=tests/test_wheel_adaptive_acceptance.py
+
+      - name: Run installed-wheel adaptive acceptance
+        run: uv run pytest tests/test_wheel_adaptive_acceptance.py -v
+
+      - name: Check generated documentation
+        run: uv run devflow docs-sync --check
+
+      - name: Run bash tests
+        run: ./tests/run-tests.sh
+
+  publish:
+    needs: test
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write
+      contents: read
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup uv
+        uses: astral-sh/setup-uv@v4
+        with:
+          version: "latest"
+
+      - name: Build package
+        run: uv build
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1

{devflow_cli-4.0.2 → devflow_cli-6.1.0}/.gitignore

@@ -13,3 +13,4 @@ venv/
 .coverage
 .devflow/
 .state.lock
+.idea/

{devflow_cli-4.0.2 → devflow_cli-6.1.0}/CHANGELOG.md

@@ -5,6 +5,114 @@ Tous les changements notables de ce projet sont documentés dans ce fichier.
 Le format est basé sur [Keep a Changelog](https://keepachangelog.com/fr/1.1.0/),
 et ce projet adhère au [Semantic Versioning](https://semver.org/lang/fr/).
 
+## [6.1.0] - 2026-09-24
+
+Mesure de consommation des agents : voir [notes de version](docs/releases/6.1.0.md).
+
+### Added
+
+- Télémétrie locale de consommation : chaque tentative `adaptive run` ajoute
+  une ligne à `~/.devflow/telemetry.jsonl` (tokens, tours, modèle, coût
+  équivalent API Claude, deltas de quota Codex), sans prompt ni contenu.
+  Désactivable avec `DEVFLOW_TELEMETRY=0`.
+- `devflow usage` résume ces tentatives par activité, profil, agent, modèle ou
+  projet, avec `--since`, `--project` et `--json`.
+- `agent-execution.json` porte le `runId` de la tentative correspondante.
+
+## [6.0.0] - 2026-09-24
+
+Retours d'usage k-review traités : voir [v6-decisions.md](docs/v6-decisions.md).
+
+### Added
+
+- Le parcours adaptatif peut enchaîner les activités jusqu'à un jalon demandé.
+- En profil `critical`, `research` et `contracts` peuvent être omises si `risk-assessment` le recommande, avec décision nominative, motif audité et confirmation obligatoire lors de la revue. Les gates de sécurité, vérification et rollback restent obligatoires.
+
+### Fixed
+
+- Les résultats d'activité rejetés peuvent être réconciliés après contrôle de la trace et des fichiers.
+- Les preuves de revue expirent après une modification pertinente, et la fraîcheur des preuves de tests ne dépend plus des seuls changements documentaires.
+- Les diagnostics du runner et de la vérification rendent explicites les causes des refus et des indisponibilités.
+- `adaptive reconcile --result` n'est accepté que si la trace de l'agent ne contient aucune réponse exploitable pour le contrat courant.
+- `devflow upgrade` met à jour les commandes `devflow*.md` installées, jusqu'ici jamais rafraîchies ; une commande modifiée localement ou sans empreinte d'installation n'est remplacée qu'après confirmation, avec une copie `.bak`.
+- `adaptive approve-command` affiche la commande exacte, son répertoire et le motif du plan, puis demande confirmation ; `--yes` approuve sans terminal.
+- Une tentative refusée dont les fichiers ont changé ne bloque plus définitivement l'activité : `run` renvoie `stale-attempt` et `adaptive discard-attempt` l'abandonne avec archive et journal d'audit.
+
+### Changed
+
+- **Rupture de compatibilité.** `adaptive complete` refuse `prepare`, les activités documentaires et `implement`, qui ne progressent plus que par `adaptive run` ou `adaptive reconcile` afin que leur résultat et leurs mutations soient validés.
+- **Rupture de compatibilité.** Sur une feature adaptative, `devflow verify` exécute la vérification adaptative et fait progresser l'état ; `--allow-command` y est refusé au profit de `adaptive approve-command`.
+- La publication vérifie la correspondance du tag, des versions distribuées et de la pointe de `main`, puis rejoue la matrice Python, la documentation générée et les tests shell avant PyPI.
+
+## [5.0.0] - 2026-09-13
+
+### Added
+
+- Le besoin est un fichier obligatoire, `need.md`, dans le dossier de la feature (F-004). `adaptive start` refuse de démarrer sans lui, le runner le revérifie avant chaque activité, `adaptive contract` refuse de produire un contrat portable sans lui, et chaque contrat le cite en première entrée avec une contrainte le déclarant prioritaire sur le résumé de l'assessment, jusqu'ici seule description du besoin transmise à l'agent.
+- Les preuves collectées par `verify` enregistrent l'empreinte de HEAD et des fichiers modifiés, hors dossier de la feature (F-013). Une preuve dont le code a changé depuis est affichée `passed (stale)` par `adaptive status`, et `review`, `rollback-check` et `done` refusent de se terminer sur elle. `devflow adaptive verify ISSUE_ID --refresh` rejoue la collecte d'un `verify` déjà complété sans changer d'activité. Un état git inobservable ne rend aucune preuve périmée.
+- `devflow adaptive review ISSUE_ID --by NOM --report FICHIER` enregistre une revue humaine pendant `review` ou `rollback-check` (F-012). Le résultat est construit au schéma de la revue agent et soumis à la même validation ; la preuve porte la source `human` et le nom du relecteur. Les preuves de jugement acceptent désormais `agent`, `reconciled` ou `human` ; les preuves mesurées restent réservées à `devflow`.
+- `devflow adaptive reconcile ISSUE_ID` valide sans relancer l'agent le travail d'une tentative échouée (F-002, F-003). À l'échec, Devflow consigne `<activity>-attempt.json` (contrat, agent, HEAD, branche, empreintes des fichiers modifiés, périmètre reporté) ; la réconciliation vérifie que rien n'a changé, extrait la réponse finale de la trace avec l'adaptateur et rejoue la validation de `adaptive run`. Les preuves acceptées portent la source `reconciled`.
+
+### Fixed
+
+- Le contrat d'`implement` n'invente plus de remédiation (F-009). Chaque activité écrit désormais son propre `<activity>-result.json` (`implement-result.json`, `verify-result.json`…) au lieu d'un `activity-result.json` partagé et écrasé ; le périmètre reporté n'est lu que depuis un résultat dont le `contractId` provient d'`implement`.
+- `verify` ne reconstruit plus le résultat d'`implement` depuis sa trace brute (F-011) : la trace `*-result.raw.txt` n'est jamais une source de résultat.
+
+### Changed
+
+- Un échec agent affiche la dernière erreur émise au lieu de la première, et un échec dû au quota, à l'authentification ou au réseau devient `agent-unavailable` (code de sortie 8, nouveau) : l'activité reste courante et la reprise guidée propose `check --live`, `reconcile` et les autres agents (F-003, F-007, F-008). L'heure de reprise n'est pas extraite : aucun format stable n'est publié par les agents.
+- `devflow check --ai codex|claude-code --live` effectue un appel réel minimal à l'agent : la présence du binaire ne prouve pas qu'il répond. En cas d'échec, la cause affichée est la dernière erreur émise, classée en quota, authentification ou réseau quand elle est reconnue (F-007). L'option consomme du quota et n'est pas active par défaut.
+- `devflow adaptive complete ISSUE_ID` complète l'activité courante quand l'activité n'est pas précisée ; une activité fournie qui diffère de l'activité courante reste refusée (F-005).
+- `devflow feature` génère dans le dossier de la feature un `.gitignore` excluant `*.raw.txt` : les traces brutes d'agent, qui peuvent recopier le contenu des fichiers lus, ne sont plus versionnées par défaut (F-010).
+- Les sources acceptées par chaque preuve sont décrites par une table unique (`accepted_evidence_sources`), appliquée à l'identique par `complete` et par la relecture de l'état.
+- Une preuve de source `agent` enregistre le nom de l'agent qui l'a produite, affiché par `adaptive status`.
+- La commande suggérée après une activité reprend le dernier agent réellement exécuté (`agent-execution.json`) au lieu de `--agent codex` en dur ; sans exécution antérieure, elle affiche `--agent AGENT` (F-006).
+
+### Removed
+
+- **Rupture de compatibilité (ADR-0002).** Devflow 5 ne lit plus que ses propres schémas : `assessment` v3, `workflow-state` v4, `activity-contract` v3. Les schémas `assessment` v1/v2, `workflow-state` v2/v3 et `activity-contract` v1/v2, leurs lecteurs, `devflow adaptive migrate` et `devflow migrate` sont supprimés. Un workflow créé par une version antérieure est refusé avec un diagnostic « devflow < 5 » ; il se termine sous devflow 4.x.
+
+## [4.0.8] - 2026-08-29
+
+### Fixed
+
+- Une review qui rapporte les preuves de référence qu'elle a contrôlées ne réécrit plus leur origine. Le runner enregistrait toute preuve présente dans le résultat avec `source=agent`, y compris celles produites par `verify` : leur `source=devflow` était écrasée, l'invariant de la gate `verify` rompu, et l'état devenait illisible avec « invariants métier incohérents » — juste après une review pourtant validée. Seule la preuve propre à l'activité est désormais enregistrée. Régression introduite par 4.0.7, qui autorisait ce rapport sans en tirer la conséquence côté écriture.
+
+## [4.0.7] - 2026-08-29
+
+### Fixed
+
+- La review peut rapporter les preuves de référence que son propre contrat lui demande de contrôler. Le contrat impose de traiter les preuves `source=devflow` déjà validées par `verify` comme résultats d'exécution de référence et de « contrôler leur contenu, leur actualité et leur adéquation » ; un agent qui s'y conformait voyait ensuite son résultat refusé avec `preuves inattendues`. La règle n'étant évaluée que sur un résultat `completed`, la contradiction restait invisible tant qu'une review continuait à trouver de vrais défauts. Les preuves du profil actif sont désormais acceptées aux côtés de la preuve de review ; celles étrangères au profil restent refusées, et la preuve de review reste requise en `passed`.
+
+## [4.0.6] - 2026-08-28
+
+### Fixed
+
+- Le contrat d'activité énonce les deux règles que ses validateurs appliquaient sans les dire : cohérence `status`/`exitCode` des `checks`, et interdiction du mode silencieux sur les commandes de test Maven. Un agent ne pouvait les découvrir que par le refus, qui ne lui est jamais transmis lors d'une relance.
+
+## [4.0.5] - 2026-08-27
+
+### Fixed
+
+- Une commande de test Maven silencieuse (`-q`, `--quiet`) est refusée à l'écriture du plan, au lieu de produire une validation que la gate `verify` rejette forcément faute de bilan de tests lisible.
+- Les validations Maven générées automatiquement par Devflow n'utilisent plus `-q` : leur bilan de tests était jusqu'ici illisible, donc systématiquement refusé par la vérification automatique.
+
+## [4.0.4] - 2026-08-27
+
+### Fixed
+
+- Le périmètre d'implémentation reporté survit à une réouverture visant une activité située avant `implement`, au lieu d'être perdu et de faire échouer la reprise en `no-worktree-change`.
+- Un fichier reporté n'est retenu que s'il est encore réellement modifié dans le working tree, afin qu'un périmètre devenu fantôme ne valide aucune activité.
+
+## [4.0.3] - 2026-08-27
+
+### Fixed
+
+- Codex est exécuté en mode événements : sa réponse finale est récupérée depuis le flux lorsque `--output-last-message` reste absent ou vide, au lieu de bloquer l'activité.
+- Le flux d'événements Codex devient la trace d'exécution conservée dans `*-result.raw.txt`, que la reprise guidée désigne explicitement.
+- Un tour Codex interrompu est catégorisé `agent-turn-failed` et l'identifiant de session provient de l'événement `thread.started`.
+- Les agents n'héritent plus de l'entrée standard, qui pouvait être ajoutée au prompt du contrat ou bloquer l'exécution jusqu'au timeout.
+
 ## [4.0.2] - 2026-08-27
 
 ### Fixed

{devflow_cli-4.0.2 → devflow_cli-6.1.0}/CLAUDE.md

@@ -5,7 +5,7 @@ politique passent par `assessment.json`; les transitions passent par la CLI et
 ne doivent jamais être réalisées en éditant les fichiers d’état.
 
 <!-- devflow:pipeline:start -->
-Workflow adaptatif à quatre profils, sélectionné par `devflow assess` : quick: assess → preflight-evidence → implement → verify → done; standard: assess → prepare → preflight-evidence → implement → verify → done; deep: assess → spec → plan → tasks → preflight-evidence → implement → verify → review → done; critical: assess → risk-assessment → spec → research → contracts → plan → tasks → preflight-evidence → implement → verify → review → rollback-check → done. `assessment.json` porte la politique et `workflow-state.json` porte uniquement la progression et les preuves.
+Workflow adaptatif à quatre profils, sélectionné par `devflow assess` : quick: assess → preflight-evidence → implement → verify → done; standard: assess → prepare → preflight-evidence → implement → verify → done; deep: assess → spec → plan → tasks → preflight-evidence → implement → verify → review → done; critical: assess → risk-assessment → spec → research → contracts → plan → tasks → preflight-evidence → implement → verify → review → rollback-check → done. `assessment.json` porte la route par défaut et `workflow-state.json` porte la progression, les preuves et les éventuelles omissions justifiées de research ou contracts dans critical.
 <!-- devflow:pipeline:end -->
 
 ## Commandes de développement

devflow_cli-6.1.0/FEEDBACK.md

@@ -0,0 +1,176 @@
+# Retours d'usage devflow
+
+Observés en conditions réelles. Chaque entrée : ce qui s'est passé, pourquoi ça coûte, une piste.
+Les décisions t'appartiennent. Classement par gravité.
+
+Retours précédents traités en 5.0.0 : voir `docs/v5-decisions.md`. Ceux de la série suivante en
+6.0.0 : voir `docs/v6-decisions.md`.
+
+**Contexte des retours ci-dessous.** Projet k-review, trois parcours conduits les 23 et 24 septembre
+2026 : KKS-368 `deep`, KKS-369 `deep`, KKS-370 `standard`. Point de vue : celui du superviseur
+(Claude), qui enchaîne les activités, rédige lui-même les artefacts, délègue l'implémentation à des
+agents et répare les rejets.
+
+**Réserve à lire avant tout.** Ces parcours ont été conduits avec la **CLI v5.0.0** : la 6.0.0 a été
+publiée alors que le dernier se terminait. Chaque entrée ci-dessous a donc été **revérifiée contre le
+code de la 6.0.0** avant d'être écrite, et celles que la 6.0.0 corrige déjà ne figurent pas dans les
+sections de gravité — elles sont rassemblées en fin de document, à titre de confirmation.
+
+---
+
+## 1. Majeur
+
+### M1 — Le profil `standard` n'a aucune activité de revue
+
+**Ce qui s'est passé.** KKS-370 a été évalué `standard` : `assess → prepare → preflight-evidence →
+implement → verify → done`. Il n'y a **pas d'activité `review`**, et la preuve `implementation-review`
+n'est pas requise — contrairement au profil `deep`, où les deux existent.
+
+Or ce lot modifiait `app.html`, le gabarit du **shell partagé par les quatre écrans** de
+l'application, en changeant l'ordre du DOM. Une régression y aurait été visible partout à la fois. Le
+projet impose par ailleurs deux revues d'agent avant chaque commit ; elles ont été jouées, mais
+**hors du parcours**, sans point d'ancrage ni trace dans l'état du workflow.
+
+**Pourquoi ça coûte.** La rigueur de revue est indexée sur le profil, donc sur l'ampleur estimée du
+changement, et non sur le **risque de ce qui est touché**. Un lot `standard` qui modifie un composant
+partagé est moins contrôlé qu'un lot `deep` qui ajoute un fichier isolé. Le commit a lieu dans les
+deux cas, et rien dans les artefacts ne dit qu'une revue a eu lieu : `done` se complète sans elle.
+
+**Piste.** Permettre au `risk-assessment` de **recommander l'ajout** d'une activité `review` à un
+profil qui ne la porte pas, symétriquement à l'omission introduite en 6.0.0 pour `critical`
+(`adaptive omit`). Ou rendre `implementation-review` exigible dès qu'un fichier du périmètre est
+partagé par plusieurs modules. À défaut, un `adaptive review` accepté en `standard` pour consigner
+une revue qui a eu lieu, même sans activité dédiée.
+
+### M2 — Le plafond de dix commandes n'est pas dans la politique injectée
+
+**Ce qui s'est passé.** `activity_contracts.py:788` refuse tout `validationPlan` de plus de dix
+commandes : `validationPlan doit contenir entre 1 et 10 commandes`. La politique exposée aux agents
+par `validation_policy_guidance()` (`verification.py:70`) énumère les exécutables autorisés, les
+tâches Maven et Gradle, les opérateurs interdits, l'approbation des exécutables hors liste et la
+consigne sur `git ls-files` — **mais pas ce plafond**.
+
+Sur KKS-368, le plan comptait onze validations, toutes légitimes et distinctes. Le refus est arrivé à
+`verify`, après rédaction du plan **et** du document qui le décrit.
+
+**Pourquoi ça coûte.** Ce n'est pas seulement une commande à retirer : il faut en **fusionner** deux
+qui portaient des garanties différentes, puis amender le document de plan pour qu'aucun écart ne
+subsiste entre ce qui est écrit et ce qui s'exécute. Le retour de M1 de la série précédente — « la
+politique n'est connue qu'après coup » — a été traité, mais cette contrainte-là y a échappé, alors
+qu'elle est la plus facile à énoncer.
+
+**Piste.** Ajouter une ligne à `validation_policy_guidance()` : « le validationPlan contient entre 1
+et 10 commandes ; regrouper plutôt qu'énumérer ». Une seule phrase ferme le sujet.
+
+---
+
+## 2. Mineur
+
+### m1 — `adaptive review` complète l'activité, et son nom ne le dit pas
+
+**Ce qui s'est passé.** Sur KKS-369, `adaptive review` rend : « Revue humaine de … validée pour
+'review'. **Prochaine : done** ». L'enchaînement naturel, `adaptive complete KKS-369 review`, échoue
+alors avec « activité courante attendue : done ».
+
+**Pourquoi ça coûte.** Un aller-retour et un doute : on ne sait pas si la revue a été prise en compte
+ou si l'on a sauté une étape. Le verbe `review` suggère d'enregistrer une revue, pas de terminer
+l'activité.
+
+**Piste.** Le message de succès pourrait dire que l'activité est complétée, pas seulement quelle est
+la suivante : « Revue enregistrée, activité 'review' complétée. Prochaine : done ».
+
+### m2 — Le format `evidence` des résultats est accepté sans être compris
+
+**Ce qui s'est passé.** Les `*-result.json` acceptent un tableau `evidence`. Un objet de la forme
+`{id, kind, summary, path}` passe la validation du résultat **sans erreur**, mais ne compte comme
+aucune preuve : `complete review` a refusé avec « preuves manquantes : implementation-review » alors
+qu'une entrée portant `"id": "implementation-review"` figurait dans le fichier. Le format reconnu est
+`{id, outcome, report}`, et l'`id` doit être le **nom du type de preuve attendu**.
+
+**Pourquoi ça coûte.** Le message de refus décrit l'état des preuves, pas ce qui a été lu dans le
+fichier. On corrige le format à l'aveugle, on relance, on échoue encore — jusqu'à aller lire un
+`workflow-state.json` d'un lot précédent pour en déduire la forme attendue.
+
+**Piste.** Signaler les entrées `evidence` non reconnues au moment de la complétion, avec la forme
+attendue : « entrée ignorée : clés {kind, summary, path} ; attendu {id, outcome, report} ».
+
+### m3 — Le porteur du `validationPlan` change avec le profil, sans être annoncé
+
+**Ce qui s'est passé.** En `standard`, le `validationPlan` va dans `prepare-result.json`. En `deep`,
+il n'y a pas d'activité `prepare` : c'est `plan-result.json` qui doit le porter. Son absence ne se
+manifeste qu'à `verify`, par `invalid-preparation-result` — un code dont le nom désigne une activité
+qui n'existe pas dans ce profil.
+
+**Pourquoi ça coûte.** Le message n'indique pas quel fichier remplir, et son intitulé oriente vers la
+mauvaise piste. Sur KKS-368, la cause n'a été trouvée qu'en comparant avec le dossier d'un lot
+antérieur conduit sous un autre profil.
+
+**Piste.** Nommer le fichier attendu dans le refus : « validationPlan absent de plan-result.json
+(profil deep : pas d'activité prepare) ». Le contrat d'activité pourrait aussi le rappeler, puisqu'il
+demande déjà « un validationPlan exécutable et portable est fourni » sans dire où.
+
+---
+
+## 3. Hors outil, mais rencontré en le pilotant
+
+### h1 — Rien n'oblige une conclusion d'absence à se prouver
+
+**Ce qui s'est passé.** KKS-370 était un lot d'audit : son premier temps produisait un constat, le
+second corrigeait. Le constat a conclu deux fois à une **absence** — « aucune gestion de mise à jour
+du service worker n'existe », « aucun renvoi au principe de couleur dans le code ». Les deux étaient
+faux. Un service complet existait depuis quatre lots ; il y avait trois renvois. Les deux erreurs
+venaient de recherches dont la sortie avait été tronquée.
+
+Ces faux constats sont entrés dans `audit.md`, puis dans le périmètre, puis dans les instructions
+données à un agent d'implémentation — qui a refusé d'écrire le code et a corrigé le superviseur. Un
+arbitrage a été demandé à l'utilisateur pour un travail sans objet.
+
+**Pourquoi ça coûte.** L'activité `preflight-evidence` demande des « faits observés » et vérifie que
+les sections existent, mais ne distingue pas un fait **positif** — mesuré, reproductible — d'une
+**absence constatée**, qui n'est un fait que si la recherche était exhaustive. Une absence mal établie
+se propage plus loin qu'une mesure fausse, parce qu'elle justifie de **construire** quelque chose.
+
+**Piste.** Dans le contrat de `preflight-evidence`, demander que toute affirmation d'absence cite la
+commande qui l'établit, et que cette commande figure dans la section de reproductibilité. C'est une
+consigne, pas un contrôle — mais elle aurait suffi ici : écrire la commande aurait exposé le `head`
+qui la tronquait.
+
+---
+
+## 4. Ce que la 6.0.0 corrige, vérifié
+
+Ces points figuraient dans mes retours précédents ou ont été rencontrés en v5.0.0 pendant ces
+parcours. Ils sont **résolus**, et je les note pour fermer la boucle plutôt que pour demander quoi que
+ce soit.
+
+- **m4, preuves `manual` refusées.** `adaptive evidence --help` annonce désormais « Enregistre une
+  preuve manuelle informative, **sans ouvrir les gates** ». En v5.0.0, la commande acceptait
+  l'enregistrement puis la complétion échouait avec « preuves automatiques valides requises », sans
+  jamais nommer `adaptive review`. L'aide actuelle aurait évité l'aller-retour.
+- **M6, messages sans cible.** Le refus `regression-check-failed (PREP-conflit-plus-non-tranche)`
+  nomme l'identifiant exact de la validation fautive, en première ligne. J'ai trouvé la cause
+  immédiatement — c'était une validation que j'avais moi-même mal conçue.
+- **M1, politique connue après coup.** Les sections requises sont nommées dans le refus : « sections
+  de pré-vol manquantes : faits observés, reproductibilité, limites ». Trois mots suffisent à
+  corriger.
+- **Le refus de réduire un profil recommandé** reste strict, et c'est bien. Déclarer
+  `--contract-change` sur une route ajoutée fait recommander `deep` ; `--profile standard` est
+  refusé. Le contourner en retirant le drapeau marcherait, et mentirait sur la nature du changement.
+  Le garde-fou tient exactement là où il doit tenir.
+- **`devflow traceability`** joué avant de compléter `tasks` rend la couverture des exigences par les
+  tâches en une seconde. Deux écarts rattrapés sur KKS-369 à ce moment-là plutôt qu'à la revue.
+
+---
+
+## Priorités suggérées
+
+1. **M2** — une phrase dans `validation_policy_guidance()`. Coût nul, évite un rejet tardif et une
+   réécriture de document.
+2. **m3** — nommer le fichier attendu dans le refus `invalid-preparation-result`. Coût nul, supprime
+   la recherche à l'aveugle.
+3. **M1** — la revue absente du profil `standard` est le seul point qui touche la qualité du résultat
+   plutôt que le confort du pilote. C'est aussi le plus lourd à trancher : il engage la définition des
+   profils.
+4. **m2** et **m1** — messages, à traiter quand l'occasion se présente.
+5. **h1** — une consigne de contrat, si l'idée te paraît juste. Elle sort du périmètre habituel de
+   l'outil, et je la propose sans insister.

{devflow_cli-4.0.2 → devflow_cli-6.1.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: devflow-cli
-Version: 4.0.2
+Version: 6.1.0
 Summary: Spec-Driven Development workflow CLI
 Project-URL: Homepage, https://github.com/sopequenoteck/devflow
 Project-URL: Repository, https://github.com/sopequenoteck/devflow
@@ -57,6 +57,7 @@ Python 3.11+ et Git sont requis. `--ai` accepte `codex`, `claude-code` ou
 
 ```bash
 devflow feature KS-123 --short-name user-auth
+# Décrire le besoin dans need.md, dans le dossier de la feature créé
 devflow assess KS-123 --scope multiple --ambiguity medium --risk medium
 devflow adaptive start KS-123
 devflow adaptive run KS-123 --agent codex
@@ -73,7 +74,7 @@ Chaque invocation de `adaptive run` traite une activité. La politique est dans
 `workflow-state.json`. Les résultats agent sont validés par schéma et les
 preuves d’exécution sensibles sont produites localement par Devflow.
 
-En V4, chaque profil exécute `preflight-evidence` avant `implement`. Cette
+Chaque profil exécute `preflight-evidence` avant `implement`. Cette
 activité archive des faits externes reproductibles dans
 `preflight-evidence.md`, sans secret ni donnée utilisateur.
 
@@ -85,29 +86,13 @@ devflow adaptive run KS-123 --agent claude
 devflow adaptive run KS-123 --agent cursor
 ```
 
-## Migrer une ancienne feature
+## Features créées avant devflow 5
 
-Pour un workflow adaptatif V3 déjà persisté :
+Devflow 5 ne lit que ses propres schémas et ne fournit aucune migration : un
+`assessment.json`, un `workflow-state.json` ou un `state.json` créé par une
+version antérieure est refusé. Terminez ces features avec devflow 4.x avant la
+mise à jour. Voir [ADR-0002](docs/adr/0002-v5-rupture-and-provenance.md).
 
-```bash
-devflow adaptive migrate KS-123 --dry-run
-devflow adaptive migrate KS-123
-```
-
-La migration V4 traite ensemble `assessment.json` et `workflow-state.json`,
-conserve une sauvegarde auditée et restaure le couple original en cas d'échec.
-Voir [le guide V4](docs/v4-migration.md).
-
-Pour une feature antérieure au moteur adaptatif :
-
-```bash
-devflow migrate KS-123 --dry-run
-devflow migrate KS-123 --profile deep
-```
-
-La migration conserve les artefacts, archive `state.json` sous
-`legacy-state.json`, puis redémarre à la première activité vérifiable du profil.
-Sans identifiant, `devflow migrate` traite toutes les anciennes features.
 `devflow init` et `devflow upgrade` déplacent également les anciennes commandes
 Claude connues vers `~/.claude/.devflow-legacy-backup/` sans toucher aux
 commandes personnalisées.

{devflow_cli-4.0.2 → devflow_cli-6.1.0}/README.md

@@ -29,6 +29,7 @@ Python 3.11+ et Git sont requis. `--ai` accepte `codex`, `claude-code` ou
 
 ```bash
 devflow feature KS-123 --short-name user-auth
+# Décrire le besoin dans need.md, dans le dossier de la feature créé
 devflow assess KS-123 --scope multiple --ambiguity medium --risk medium
 devflow adaptive start KS-123
 devflow adaptive run KS-123 --agent codex
@@ -45,7 +46,7 @@ Chaque invocation de `adaptive run` traite une activité. La politique est dans
 `workflow-state.json`. Les résultats agent sont validés par schéma et les
 preuves d’exécution sensibles sont produites localement par Devflow.
 
-En V4, chaque profil exécute `preflight-evidence` avant `implement`. Cette
+Chaque profil exécute `preflight-evidence` avant `implement`. Cette
 activité archive des faits externes reproductibles dans
 `preflight-evidence.md`, sans secret ni donnée utilisateur.
 
@@ -57,29 +58,13 @@ devflow adaptive run KS-123 --agent claude
 devflow adaptive run KS-123 --agent cursor
 ```
 
-## Migrer une ancienne feature
+## Features créées avant devflow 5
 
-Pour un workflow adaptatif V3 déjà persisté :
+Devflow 5 ne lit que ses propres schémas et ne fournit aucune migration : un
+`assessment.json`, un `workflow-state.json` ou un `state.json` créé par une
+version antérieure est refusé. Terminez ces features avec devflow 4.x avant la
+mise à jour. Voir [ADR-0002](docs/adr/0002-v5-rupture-and-provenance.md).
 
-```bash
-devflow adaptive migrate KS-123 --dry-run
-devflow adaptive migrate KS-123
-```
-
-La migration V4 traite ensemble `assessment.json` et `workflow-state.json`,
-conserve une sauvegarde auditée et restaure le couple original en cas d'échec.
-Voir [le guide V4](docs/v4-migration.md).
-
-Pour une feature antérieure au moteur adaptatif :
-
-```bash
-devflow migrate KS-123 --dry-run
-devflow migrate KS-123 --profile deep
-```
-
-La migration conserve les artefacts, archive `state.json` sous
-`legacy-state.json`, puis redémarre à la première activité vérifiable du profil.
-Sans identifiant, `devflow migrate` traite toutes les anciennes features.
 `devflow init` et `devflow upgrade` déplacent également les anciennes commandes
 Claude connues vers `~/.claude/.devflow-legacy-backup/` sans toucher aux
 commandes personnalisées.

{devflow_cli-4.0.2 → devflow_cli-6.1.0}/commands/devflow.md

@@ -1,6 +1,6 @@
 ---
 description: Pilote le workflow adaptatif Devflow depuis Claude Code
-argument-hint: ISSUE_ID [--agent claude|codex|cursor]
+argument-hint: ISSUE_ID [--agent claude|codex|cursor] [--until ACTIVITY|done]
 allowed-tools: Bash(devflow:*)
 ---
 
@@ -9,7 +9,8 @@ allowed-tools: Bash(devflow:*)
 Utiliser exclusivement la machine adaptative de la CLI. Ne jamais créer ni
 interpréter de `state.json`.
 
-1. Lire `$ARGUMENTS` et extraire l'identifiant de feature.
+1. Lire `$ARGUMENTS` et extraire l'identifiant de feature, l'agent demandé
+   (`claude` par défaut) et la cible `--until` (`done` par défaut).
 2. Exécuter `devflow status ISSUE_ID`.
 3. Si la feature n'existe pas, demander à l'utilisateur de lancer
    `devflow feature ISSUE_ID`.
@@ -17,8 +18,11 @@ interpréter de `state.json`.
    `devflow assess ISSUE_ID` avec des options explicites.
 5. Si elle est évaluée mais non démarrée, lancer
    `devflow adaptive start ISSUE_ID`.
-6. Lancer une seule activité avec
-   `devflow adaptive run ISSUE_ID --agent AGENT`.
+6. Enchaîner les activités avec
+   `devflow adaptive run ISSUE_ID --agent AGENT --until CIBLE`.
+   `--until` inclut l'activité ciblée.
+   La CLI s'arrête au premier refus : ne pas relancer automatiquement la
+   tentative refusée et afficher sa commande de reprise.
 7. Afficher ensuite `devflow adaptive status ISSUE_ID`.
 
 Le contrat produit par Devflow est la seule autorité sur les actions,