devflow-cli 3.0.1__tar.gz → 6.0.0__tar.gz

devflow_cli-6.0.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-3.0.1 → devflow_cli-6.0.0}/.gitignore

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

{devflow_cli-3.0.1 → devflow_cli-6.0.0}/CHANGELOG.md

@@ -5,6 +5,128 @@ 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.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
+
+- La vérification V4 accepte les preuves de plan V1 conservées lors d'une migration V3 vers V4, sans réécrire les artefacts historiques.
+- Une régression couvre la reprise d'un workflow critical migré avec un plan V1 et une implémentation V2.
+
+## [4.0.1] - 2026-08-26
+
+### Fixed
+
+- Les échecs de clôture structurée Codex sont catégorisés sans exposer de contenu de dépôt ou de sortie.
+- Les écritures observées sont tracées par indicateur et compteur dans l'audit et le worklog, sans relance automatique.
+- La migration V3 → V4 est couverte pour les quatre profils, y compris une reprise critical avancée.
+
+## [4.0.0] - 2026-08-26
+
+### Added
+
+- Activité `preflight-evidence` dédiée avant toute implémentation, avec artefact unique, contrôle de fraîcheur et détection de secrets.
+- Schémas publics `assessment` v2 et `workflow-state` v3, sans modification des schémas V3 publiés.
+- Migration atomique et auditée via `devflow adaptive migrate`, avec dry-run et sauvegarde restaurable.
+
+### Changed
+
+- Les quatre profils utilisent une route V4 explicite et transmettent la preuve de pré-vol à `implement`.
+- La version du paquet et de la CLI passe à 4.0.0.
+
 ## [3.0.1] - 2026-08-25
 
 ### Fixed

devflow_cli-6.0.0/CLAUDE.md

@@ -0,0 +1,20 @@
+# Devflow
+
+Ce dépôt implémente exclusivement un workflow adaptatif. Les changements de
+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 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
+
+```bash
+uv run pytest -q
+./tests/run-tests.sh
+uv run devflow docs-sync --check
+```
+
+Pour un essai réel : `feature`, `assess`, `adaptive start`, puis une activité à
+la fois avec `adaptive run`.

devflow_cli-6.0.0/FEEDBACK.md

@@ -0,0 +1,224 @@
+# 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`.
+
+Contexte des retours ci-dessous : devflow CLI v5.0.0, projet k-review, six parcours adaptatifs conduits
+entre le 16 et le 18 septembre 2026 (KKS-371 `deep`, KKS-361 `critical`, KKS-362 `deep`, KKS-363
+`critical`, KKS-364 `critical`), avec les agents `codex` puis `claude`. Point de vue : celui du
+superviseur (Claude), qui enchaîne les activités, relit les artefacts et répare les rejets —
+l'utilisateur n'intervient que pour trancher.
+
+---
+
+## 1. Critique
+
+### C1 — Une feature d'infrastructure ne peut pas être close légitimement
+
+**Ce qui s'est passé.** KKS-363 (bascule du déploiement derrière nginx) ne modifiait que `app/nginx.conf`,
+`app/Dockerfile`, `compose.yaml` et `deploy/README.md`. `adaptive verify` sélectionne ses commandes à partir
+des modules de stack situés au-dessus des fichiers modifiés (`select_validation_commands`,
+`core/automatic_evidence.py`) : aucun `pom.xml` ni `package.json` au-dessus de ces fichiers, donc aucune
+commande, donc refus `no-safe-validation`. Ajouter `mvn -B verify` au `validationPlan` n'y change rien, la
+sélection ignorant le plan. Les preuves enregistrées avec `adaptive evidence` (193 tests et 10 contrôles
+réellement exécutés) sont marquées `manual`, et la clôture d'un profil `critical` les refuse.
+
+**Pourquoi ça coûte.** Il n'existe aucune voie honnête pour terminer le parcours : il reste « actif » pour
+toujours, ou le superviseur est tenté de faire entrer un fichier de code dans le périmètre pour débloquer la
+détection — exactement la dérive que la règle existe pour empêcher. Toute bascule de déploiement à venir
+rencontrera le même mur. Sur KKS-363, clôture manuelle consignée au worklog, sur décision de l'utilisateur.
+
+**Piste.** Quand aucun module n'est détecté, accepter le `validationPlan` du plan comme source de preuves
+automatiques. Ou reconnaître des stacks d'infrastructure (`docker compose config`, `nginx -t` dans l'image
+construite, `yamllint`). À défaut, une preuve `manual` auditée, sur le modèle de `waive` : motif obligatoire,
+auteur, trace durable.
+
+### C2 — Un travail terminé est rejeté pour des raisons de forme, et le seul recours contourne le garde-fou
+
+**Ce qui s'est passé.** Sept rejets en une semaine, chaque fois avec un agent qui avait fini et des contrôles
+verts :
+
+- chemin absolu dans `changedFiles` → « chemin non portable » (KKS-363, spec) ;
+- entrée descriptive au lieu de chemins, `api/src/ (81 fichiers déplacés…)` → échec de l'inspection du diff
+  (KKS-362) ;
+- reprise après interruption : les fichiers de la tentative précédente comptent comme déclarés mais non
+  attendus → « declares vs attendus » (KKS-371, KKS-363) ;
+- contrôle doublon marqué en échec, alors que sa variante corrigée passe (KKS-362) ;
+- expression `${{ github.sha }}` recopiée dans les contrôles → placeholder (KKS-362) ;
+- `structured_output` absent après une limite d'API, alors que `plan.md` était complet (KKS-361) ;
+- `research.md` complet, dix décisions argumentées chacune sous un `### Décision`, rejeté pour l'absence
+  d'un titre de premier niveau `## Décisions` → `invalid-artifact` (KKS-364). Le superviseur a ajouté
+  une section de synthèse, sans rien changer sur le fond : exactement le recours décrit ci-dessous.
+
+**Pourquoi ça coûte.** Un résultat rejeté n'écrit pas `<activite>-result.json`. Le seul recours a été, à
+chaque fois, de reconstruire ce fichier à la main depuis `<activite>-result.raw.txt`, en corrigeant le champ
+fautif, puis `adaptive complete`. Ça fonctionne, mais c'est le superviseur qui corrige ce que le garde-fou
+est censé vérifier : un superviseur moins attentif validerait n'importe quoi par le même chemin.
+
+**Piste.**
+- Normaliser avant de valider : relativiser les chemins, développer une entrée de dossier par
+  `git diff --name-only`, ignorer un contrôle en échec quand une variante réussie couvre la même cible.
+- Faire accepter par `reconcile` l'union des mutations de toutes les tentatives de l'activité
+  (`carriedChangedFiles` existe mais reste vide).
+- Si un recours manuel doit subsister, en faire une commande explicite — `adaptive accept-raw --reason`, par
+  exemple — qui rejoue les contrôles de forme après correction et trace l'intervention dans le worklog.
+
+---
+
+## 2. Majeur
+
+### M1 — La politique de validation n'est connue des agents qu'après coup
+
+**Ce qui s'est passé.** L'agent de plan écrit naturellement `mvn -B clean verify` et `docker build` dans son
+`validationPlan`. Le premier est refusé à la complétion du plan (`clean` hors des tâches Maven autorisées),
+le second à `adaptive verify` (exécutable non approuvé). Le message de refus du plan ne nommait ni la commande
+ni le VAL en cause.
+
+**Pourquoi ça coûte.** Chaque refus impose de corriger `plan.md` et `plan-result.json` à la main, puis de
+compléter l'activité — voir C2. Sur KKS-362, trois garde-fous différents ont été rencontrés dans la même
+feature.
+
+**Piste.** Injecter la politique (exécutables autorisés, tâches Maven admises, motifs interdits comme les
+doubles accolades) dans le contrat d'activité de `plan` et `tasks`, pour que l'agent ne produise pas ce qui
+sera refusé. Même chose pour les **sections requises** de chaque artefact (le `## Décisions` de
+`research.md`, cf. C2) : les nommer dans le contrat, ou accepter une sous-section équivalente.
+
+**Constat qui appuie la piste (KKS-364).** Les garde-fous de forme ont été écrits par le superviseur dans
+`need.md` avant le démarrage (chemins relatifs, pas de `clean`, pas de `docker`, pas de doubles
+accolades, `changedFiles` sans entrée descriptive). Résultat : aucun rejet de ce type sur treize
+activités, contre sept la semaine précédente. La politique connue en amont fonctionne ; elle doit venir
+de l'outil, pas de la vigilance du superviseur.
+
+### M2 — Deux moteurs de vérification incohérents
+
+**Ce qui s'est passé.** `devflow verify` accepte `--allow-command docker`, mais ne sait pas lire un tableau
+de validation qui porte une colonne « Répertoire » (« Ligne de validation mal formée »). `adaptive verify`
+lit ce plan, mais n'a pas d'`--allow-command`. `adaptive waive` ne s'applique qu'à un contrôle exécuté et en
+échec, pas à un contrôle refusé avant exécution (« aucun échec exécuté trouvé »).
+
+**Pourquoi ça coûte.** Une validation légitime (construire une image localement, sans push) ne peut être
+exécutée par aucun des deux chemins. Sur KKS-362, les deux `docker build` ont dû être remplacés par des
+contrôles de contenu des `Dockerfile`, trace consignée au worklog.
+
+**Piste.** Un seul moteur. Une approbation d'exécutable enregistrée dans le plan lui-même, avec motif, et
+auditée comme une dérogation.
+
+### M3 — Plus de chaînage en v5, et un skill resté en v4
+
+**Ce qui s'est passé.** `devflow run` n'existe plus. Le superviseur a réécrit à chaque feature la même boucle
+shell : lire `currentActivity` dans `workflow-state.json`, lancer `adaptive run`, s'arrêter au premier refus.
+Le skill Claude `/devflow` documente encore `devflow run`, `state.json`, les étapes v4 (`review-spec`,
+`clarify`…) et une synchronisation Linear qui n'existe plus.
+
+**Pourquoi ça coûte.** Du bricolage répété, et une documentation de façade qui induit en erreur le premier
+agent qui la suit.
+
+**Piste.** `adaptive run --until <activite>|done` : enchaîne, s'arrête au premier refus, affiche un statut
+compact et la commande de reprise. Mettre le skill `/devflow` à jour sur le parcours adaptatif.
+
+### M4 — Les limites d'usage des agents ne sont pas un état géré
+
+**Ce qui s'est passé.** Limite Codex jusqu'au 19 septembre en pleine implémentation (KKS-371), limite de
+session Claude deux fois (plan de KKS-361, implémentation de KKS-363). La reprise suggérée, `reconcile`,
+échoue quand le résultat est incomplet ; une relance fraîche avec un autre agent déclare les fichiers de la
+tentative précédente, d'où le rejet décrit en C2.
+
+Sur KKS-364, la limite de session a interrompu `rollback-check` : `agent-failed`, avec l'heure de
+réinitialisation dans le message. L'activité étant en lecture seule, une relance à l'identique a suffi —
+preuve que la reprise peut être simple quand rien n'a été écrit.
+
+**Pourquoi ça coûte.** Chaque limite se transforme en réparation manuelle, alors que la situation est
+banale et prévisible.
+
+**Piste.** Détecter la limite (statut 429, message « usage limit » ou « session limit ») et passer en
+`agent-unavailable` avec l'heure de réinitialisation. La reprise continue la même tentative en reportant ses
+mutations déjà observées, quel que soit le backend.
+
+### M5 — Profil disproportionné pour un petit correctif de sécurité
+
+**Ce qui s'est passé.** `--data-security` a placé KKS-361 — une ligne de production — en `critical` :
+13 activités, dont `research` et `contracts`. La recherche a été réellement utile (dépendance du
+`JSESSIONID` à l'en-tête `Accept`) ; les contrats beaucoup moins.
+
+**Pourquoi ça coûte.** Temps et quota d'agent, sur un correctif dont la taille ne justifiait pas toutes les
+étapes.
+
+**Piste.** Dissocier le risque de la taille. Laisser `risk-assessment` recommander de sauter une activité,
+avec justification tracée et gardée par la revue.
+
+### M6 — Messages d'erreur tronqués ou sans cible
+
+**Ce qui s'est passé.** Le refus du plan de KKS-362 disait seulement « test/check/lint/verify/build sont
+autorisées », sans le VAL ni la commande en cause. Sur les messages longs, le début — souvent la cause — est
+coupé dans la sortie console.
+
+**Pourquoi ça coûte.** Le superviseur doit fouiller les JSON pour retrouver l'élément fautif.
+
+**Piste.** Première ligne : identifiant du contrôle et élément fautif. Une option `--json` sur `adaptive run`
+et `adaptive verify` pour une lecture outillée.
+
+### M7 — Une écriture du superviseur pendant une activité est imputée à l'agent
+
+**Ce qui s'est passé.** Pendant `contracts` (KKS-364), l'utilisateur a tranché un nouvel arbitrage. Le
+superviseur l'a consigné dans `issue-KKS-364.md` et `need.md`, dans le dossier feature, pendant que
+l'agent travaillait. À la complétion : `artifact-files-mismatch` — observés `contracts.md`,
+`issue-KKS-364.md`, `need.md`, déclaré `contracts.md` seul. L'agent n'avait rien fait de mal ; il avait
+même intégré l'arbitrage, lu à la volée.
+
+**Pourquoi ça coûte.** Un rejet de plus à réparer depuis le raw (C2). Et la règle implicite — « ne rien
+écrire dans le dossier feature pendant une activité » — n'est écrite nulle part : le superviseur l'a
+découverte en la violant.
+
+**Piste.** Exclure de l'observation les entrées déclarées du besoin (`need.md`, `issue-*.md`), ou les
+figer au démarrage de l'activité et signaler leur modification comme un avertissement distinct
+(« entrée modifiée en cours d'activité ») plutôt que comme une mutation de l'agent. À défaut, documenter
+la règle et la faire respecter par un verrou visible (`workflow-state.json` → `running`).
+
+### M8 — Les corrections faites après la revue échappent à la revue
+
+**Ce qui s'est passé.** Sur KKS-364, la revue indépendante et `rollback-check` ont relevé quatre défauts
+réels : un test de sécurité qui ne prouvait rien (assertions sous une condition jamais vraie), un contrôle
+shell inversé dans la procédure de retour arrière, une source manquante pour l'image précédente, `spec.md`
+non amendé. Le superviseur les a corrigés à la main, puis `adaptive verify --refresh` a rafraîchi les
+preuves de tests et `done` a été accepté. Les corrections elles-mêmes n'ont été revues par personne.
+
+**Pourquoi ça coûte.** La preuve `independent-review` porte sur un diff qui n'est plus celui qui est
+livré. Ici les corrections étaient petites et tracées au worklog ; rien n'empêche qu'elles ne le soient
+pas.
+
+**Piste.** Marquer `independent-review` périmée quand du code change après la revue (comme les preuves de
+tests), et offrir un `adaptive review --delta` qui ne relit que le diff postérieur. Ou, a minima, exiger
+une entrée de worklog motivée pour toute modification après `review`.
+
+---
+
+## 3. Mineur
+
+- **m1 — Détecteur de placeholders trop large.** Il signale les expressions GitHub Actions (`${{ }}`) et les
+  légendes entre crochets (`[USX]`). Ignorer les blocs de code et les spans `code`, et indiquer la ligne.
+- **m2 — Péremption des preuves trop large.** Corriger « 11 variables » en « 12 » dans un README (KKS-371)
+  a rendu `test-suite` périmée et imposé un `mvn verify` complet. Une modification purement documentaire ne
+  devrait invalider que les preuves documentaires.
+- **m3 — Contrôles fondés sur l'index git.** VAL-001 (`git ls-files --error-unmatch`) a échoué sur KKS-362
+  parce que l'implémentation n'indexe pas les fichiers qu'elle crée. Faire indexer les créations par
+  l'activité, ou vérifier sur le système de fichiers.
+- **m4 — `adaptive evidence` produit des preuves `manual` que `deep` et `critical` refusent à la clôture.**
+  L'aide de la commande devrait le dire.
+- **m5 — Synchronisation Linear absente en v5.** `devflow linear decision` existe mais n'est appelé nulle
+  part : le passage en Done se fait à la main. Un crochet à `done` suffirait.
+
+---
+
+## Priorités suggérées
+
+1. **C2** — normaliser et accepter les résultats. Cause de la moitié des interventions manuelles, et la plus
+   risquée, parce que le recours actuel contourne le garde-fou.
+2. **C1** — clôture des features d'infrastructure. Bloquant pour chaque bascule de déploiement à venir.
+3. **M1 + M2** — politique de validation connue des agents, moteur de vérification unique. Supprime la
+   plupart des rejets en amont.
+4. **M3** — `adaptive run --until`. Petit coût, gain à chaque feature.
+5. **M4** — reprise après limite d'usage.
+6. **M7** — ne pas imputer à l'agent les écritures du superviseur. Petit coût, supprime un rejet absurde.
+7. **M8** — revue du delta après correction. Ferme un trou de traçabilité dans le profil `critical`.

{devflow_cli-3.0.1 → devflow_cli-6.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: devflow-cli
-Version: 3.0.1
+Version: 6.0.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,6 +74,10 @@ 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.
 
+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.
+
 Les trois adaptateurs acceptent les mêmes contrats structurés :
 
 ```bash
@@ -81,16 +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
 
-```bash
-devflow migrate KS-123 --dry-run
-devflow migrate KS-123 --profile deep
-```
+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).
 
-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-3.0.1 → devflow_cli-6.0.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,6 +46,10 @@ 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.
 
+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.
+
 Les trois adaptateurs acceptent les mêmes contrats structurés :
 
 ```bash
@@ -53,16 +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
 
-```bash
-devflow migrate KS-123 --dry-run
-devflow migrate KS-123 --profile deep
-```
+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).
 
-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-3.0.1 → devflow_cli-6.0.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,