Dev Flow

Maintient Codex et DeepSeek dans le périmètre, borne la vérification et reprend après une interruption.

简体中文 · English · 繁體中文 · 日本語 · 한국어 · Español · Français · Deutsch · Português (Brasil)

Dev Flow ajoute aux tâches de programmation assistées par IA un état local et durable, indépendant du chat. Il mémorise :

• ce que la tâche peut modifier et ce qui est explicitement hors périmètre ;
• si le travail se trouve en exigences, conception, implémentation, tests ou livraison ;
• le volume de vérification convenu et les preuves déjà obtenues ;
• si une écriture interrompue ou incertaine doit être récupérée, bloquée ou relancée sans risque.

Ce n’est ni un autre Agent de programmation ni un orchestrateur de tâches. Codex et DeepSeek continuent de lire les dépôts, modifier le code et exécuter les commandes. Dev Flow gère le périmètre, l’étape, l’effort de vérification, les preuves et la récupération d’une tâche de développement.

Commencer ici : parcours en deux minutes · versions actuelles et preuves réelles · installer la version stable

Ce README décrit les capacités de main. npm @latest est la version stable validée sur l’artefact final et peut être en retard sur main. Voir Project Status pour distinguer stable, beta et source.

Comprendre en 30 secondes

Sans Dev Flow	Ce que Dev Flow ajoute
Le Prompt répète « ne pas élargir le périmètre »	Le Task conserve l’intention initiale et chaque étape indique ce qui peut changer
Une session redémarrée rescane le dépôt et devine la progression	L’étape, les preuves et les blockers sont persistés localement
Un test ciblé devient une suite complète ou une matrice de plateformes	Chaque Task possède un verification budget explicite
Les tests passent, mais le résultat reste difficile à expliquer ou reprendre	COMPREHENSION_REVIEW précède la livraison
Une réponse d’écriture perdue est rejouée dangereusement	L’état autoritatif est lu avant de décider si le retry est sûr

Déroulement d’une tâche

flowchart LR
    A["Décrire la tâche et ses limites"] --> B["Exigences et conception"]
    B --> C["Implémentation"]
    C --> D["Tests ciblés"]
    D --> E["Revue de compréhension"]
    E --> F["Livraison"]
    F --> G["DONE"]
    D -. problème d'implémentation .-> C
    E -. complexité excessive .-> H["Refactorisation"]
    H --> D

Si le Host redémarre après l’implémentation, la nouvelle session lit le même Task et retrouve l’étape, les preuves terminées, le budget restant et les prochaines transitions légales. Elle ne reconstruit pas le processus depuis l’historique. Voir la démonstration.

Place dans la chaîne d’outils

Outil	Responsabilité
Codex / DeepSeek Harness	Lire les dépôts, modifier le code et exécuter les commandes
Spec Kit / OpenSpec	Fournir des méthodes pour exigences, conception et planification
Dev Flow	Conserver périmètre, étape, budget, chemins de reprise et état de récupération d’une tâche

Installer la version stable

Les artefacts stables actuels prennent en charge macOS arm64 et Node.js >=24. Voir la Support Matrix pour les versions et compatibilités exactes.

L’entrée dev-flow gère installation, mise à niveau, réparation, réinstallation, désinstallation et réinstallation propre. Les commandes natives du Host restent disponibles pour la reprise diagnostique. Pendant l’exécution, l’installateur affiche chaque action du Host et les étapes réellement terminées, notamment l’installation du package, la configuration de l’enregistrement, la vérification de l’artefact et la relecture de l’état prêt ; --json continue de produire un seul objet de résultat. L’interface interactive utilise le chinois simplifié pour les locales zh* et l’anglais pour toutes les autres.

Codex

npm install -g @imotong/dev-flow@latest
dev-flow

Pour forcer Dev Flow :

$dev-flow-codex:dev-flow Fix idempotency in the order-creation endpoint and run targeted tests.

Détails dans le guide Codex.

DeepSeek Harness

npm install -g @imotong/dev-flow@latest
dev-flow

Redémarrer le profile, puis saisir :

/dev-flow Fix idempotency in the order-creation endpoint and run targeted tests.

Détails dans le guide DeepSeek.

Quand l’utiliser

• travail réel traversant exigences, conception, implémentation, tests et livraison ;
• changement susceptible de nécessiter des reprises et devant conserver ses preuves ;
• tâche reprise entre sessions, jours, compactage du contexte ou redémarrage du Host ;
• travail nécessitant une limite de vérification ou une confirmation de compréhension ;
• tâche bornée sur un dépôt principal et quelques dépôts supplémentaires explicites.

Une question ponctuelle ou une modification mécanique d’un fichier sans état persistant est généralement plus simple avec Codex ou DeepSeek directement.

Capacités principales

• Périmètre explicite : TaskIntent conserve la demande, les critères d’acceptation et le hors-périmètre.
• Vérification bornée : chaque Task possède un verification budget ; les matrices complètes ne sont pas la norme.
• Récupération intersession : étape, preuves, blockers et prochaines actions sont stockés dans SQLite local.
• Désinstallation sûre : la désinstallation Codex valide le runtime receipt et arrête d’abord la WebUI correspondante ; si l’arrêt échoue, elle conserve l’enregistrement et le package afin qu’une ancienne version supprimée ne continue pas d’écouter sur un port.
• Revue de compréhension : COMPREHENSION_REVIEW suit les tests et peut renvoyer vers une reprise.
• Écriture incertaine : Core valide entièrement la prochaine Task puis conserve l’entrée Action normalisée dans un enregistrement d’opération indépendant ; après une réponse perdue, Task ID et Action ID suffisent sans reconstruire le payload.
• Multi-dépôts borné : le source actuel gère un dépôt principal et jusqu’à sept dépôts supplémentaires dans un état unique.
• Tasks parallèles dans un même dépôt : un dépôt Git logique peut exécuter plusieurs Tasks indépendantes en parallèle grâce à des linked worktrees. Chaque worktree physique conserve au plus une Task active. Lorsque le Host fournit une capacité task/thread adossée aux worktrees, Codex crée un enfant par élément borné avant l’admission pour un lot parallèle explicite ; si dev_flow_open_task d’une seule nouvelle demande renvoie ACTIVE_TASK_CONFLICT, il crée exactement un enfant après ce résultat. L’enfant du conflit utilise target.environment.type="worktree" sans startingState, part uniquement de l’état validé de la branche par défaut et ne reçoit ni l’index, ni les modifications suivies du working tree, ni les fichiers non suivis du checkout occupé. Un resume explicite, HOST_OWNERSHIP_CONFLICT et les autres erreurs conservent leur arrêt actuel. Core ne crée, ne change et ne nettoie pas les worktrees ; la Task active et le worktree d’origine restent inchangés.

Vérifier dans Project Status si le multi-dépôts est déjà inclus dans la version stable.

Limites

• Core observe Git de façon bornée et en lecture seule ; il ne fait ni commit, push, merge, rebase, tag ni publish.
• Les changements de fichiers et commandes restent sous la responsabilité du Host autorisé par l’utilisateur.
• Dev Flow n’intercepte pas chaque opération du Host et n’est pas un sandbox de sécurité général.
• Le code source actuel contient une WebUI partagée limitée au loopback, avec chinois simplifié/anglais, langue système par défaut et sélection locale au navigateur. Le cadre de page commun réorganise la navigation, les filtres, les listes de Tasks, les détails, les formulaires et l’état système selon la largeur, exploite l’espace sur grand écran et garde les informations essentielles directement lisibles sur écran étroit ; remote MCP, telemetry, graph utilisateur et migration historique automatique restent exclus.
• Un index optionnel aide seulement à rechercher ; il ne décide ni périmètre, ni permission, ni Recovery, ni état.
• Une Action autorisée en écriture fournit uniquement les changed_paths apparus depuis l’émission de cette Action, ou no_file_changes lorsque ce nœud n’a modifié aucun fichier. Core les valide par rapport à la base d’émission et à une fresh Git observation ; les changements autorisés se terminent avec l’Action d’origine, tandis qu’un changement de branch, HEAD, repository identity ou de chemin non déclaré renvoie toujours REPOSITORY_DRIFT. Si le dépôt est inchangé alors que le résultat déclare des modifications, Core renvoie la règle de champ repository_effect_not_observed.
• Les soumissions Design, Tasks et Implementation omettent respectivement requirements_revision, design_revision et task_plan_revision ; après validation de l’identité de l’Action actuelle, Core renseigne ces champs depuis la même Task snapshot. Les soumissions Delivery ne contiennent ni acceptance, ni identifiants d’evidence automated/manual, ni identifiants de record Test/Comprehension ; Core les génère depuis la Task actuelle et leur envoi est rejeté comme unknown_member. Avant conservation, Core continue de vérifier la sémantique du résultat par rapport à la Task actuelle. Un required_member_missing dont l’absence d’écriture est prouvée dans une soumission de nœud peut être corrigé une seule fois à son chemin exact, uniquement avec des faits déjà établis pendant le travail du nœud actuel. Si le contenu manquant exige une nouvelle décision utilisateur, le Host doit s’arrêter et la demander ; les autres valeurs impossibles à déduire sûrement n’autorisent aucune correction automatique.
• La Skill Codex exige de relire le live schema du submission_tool actuel avant chaque soumission ordinaire et l’unique soumission corrigée autorisée, puis de comparer membre par membre le brouillon complet : membres requis ou supplémentaires, types des valeurs imbriquées et des éléments de tableau, nullability, enums et consts. Si la correspondance n’est pas exacte, elle s’arrête avant l’appel de l’outil et ne déduit pas les types du nom du champ ni du texte d’erreur.

Voir Security Policy et Threat Model.

Support stable actuel

Produit	Environnement vérifié
dev-flow-codex	macOS arm64, Node.js >=24, Codex >=0.147.0
dev-flow-deepseek	macOS arm64, Node.js >=24, DSH >=0.1.0-rc.6

Voir Project Status et Support Matrix pour les preuves et l’état beta/source.

Documentation

Besoin	Entrée
Comprendre une tâche réelle en deux minutes	Demo
État stable, beta, source et preuves	Project Status
Capacités et limites	Product
Architecture	Architecture
Versions et plateformes	Support Matrix
Commandes et outils MCP	Command Reference
WebUI locale et reset uniquement en CLI	WebUI
Sécurité	Security · Threat Model
Contribuer	Contributing

License

Apache License 2.0