devflow-cli 2.3.0__tar.gz → 2.8.0__tar.gz

devflow_cli-2.8.0/.githooks/post-checkout

@@ -0,0 +1,26 @@
+#!/usr/bin/env bash
+# Hook devflow — promotion automatique vers ~/.claude/ sur checkout develop.
+# Déclenché uniquement pour un checkout de branche (flag $3 = 1).
+
+set -u
+
+prev_ref=$1
+new_ref=$2
+branch_checkout=$3
+
+# Ignore les checkout de fichiers (ex: git checkout -- file)
+[ "$branch_checkout" = "1" ] || exit 0
+
+# Ignore si la HEAD n'a pas changé (no-op rebase steps)
+[ "$prev_ref" != "$new_ref" ] || exit 0
+
+branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null)
+[ "$branch" = "develop" ] || exit 0
+
+if ! command -v devflow >/dev/null 2>&1; then
+  echo "[devflow hooks] devflow CLI introuvable dans le PATH — promotion ignorée." >&2
+  exit 0
+fi
+
+echo "[devflow hooks] checkout develop → devflow init --here --force"
+devflow init --here --force

devflow_cli-2.8.0/.githooks/post-merge

@@ -0,0 +1,15 @@
+#!/usr/bin/env bash
+# Hook devflow — promotion automatique vers ~/.claude/ sur merge develop.
+
+set -u
+
+branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null)
+[ "$branch" = "develop" ] || exit 0
+
+if ! command -v devflow >/dev/null 2>&1; then
+  echo "[devflow hooks] devflow CLI introuvable dans le PATH — promotion ignorée." >&2
+  exit 0
+fi
+
+echo "[devflow hooks] merge sur develop → devflow init --here --force"
+devflow init --here --force

{devflow_cli-2.3.0 → devflow_cli-2.8.0}/.github/workflows/ci.yml

@@ -32,5 +32,8 @@ jobs:
       - name: Run pytest
         run: uv run pytest tests/ -v
 
+      - name: Check generated documentation
+        run: uv run devflow docs-sync --check
+
       - name: Run bash tests
         run: ./tests/run-tests.sh

{devflow_cli-2.3.0 → devflow_cli-2.8.0}/.gitignore

@@ -12,3 +12,4 @@ venv/
 .DS_Store
 .coverage
 .devflow/
+.state.lock

devflow_cli-2.8.0/.idea/.gitignore

@@ -0,0 +1,10 @@
+# Default ignored files
+/shelf/
+/workspace.xml
+# Editor-based HTTP Client requests
+/httpRequests/
+# Ignored default folder with query files
+/queries/
+# Datasource local storage ignored files
+/dataSources/
+/dataSources.local.xml

devflow_cli-2.8.0/.idea/devflow.iml

@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<module type="JAVA_MODULE" version="4">
+  <component name="NewModuleRootManager" inherit-compiler-output="true">
+    <exclude-output />
+    <content url="file://$MODULE_DIR$" />
+    <orderEntry type="inheritedJdk" />
+    <orderEntry type="sourceFolder" forTests="false" />
+  </component>
+</module>

devflow_cli-2.8.0/.idea/misc.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ProjectRootManager" version="2" languageLevel="JDK_21" default="true" project-jdk-name="corretto-21" project-jdk-type="JavaSDK">
+    <output url="file://$PROJECT_DIR$/out" />
+  </component>
+</project>

devflow_cli-2.8.0/.idea/modules.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ProjectModuleManager">
+    <modules>
+      <module fileurl="file://$PROJECT_DIR$/.idea/devflow.iml" filepath="$PROJECT_DIR$/.idea/devflow.iml" />
+    </modules>
+  </component>
+</project>

devflow_cli-2.8.0/.idea/vcs.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="VcsDirectoryMappings">
+    <mapping directory="" vcs="Git" />
+  </component>
+</project>

devflow_cli-2.8.0/.specify/specs/027-pipeline-auto-execution/checklists/requirements.md

@@ -0,0 +1,35 @@
+# Specification Quality Checklist: Pipeline Auto-Execution
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-03-24
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- All items pass validation. Spec is ready for `/speckit.clarify` or `/speckit.plan`.
+- La spec fait reference a des composants existants (fichiers, constantes) dans la section "Comportement existant" et "Impact sur l'existant" car c'est un projet brownfield — ceci est attendu pour documenter le delta, pas pour prescrire l'implementation.

devflow_cli-2.8.0/.specify/specs/027-pipeline-auto-execution/contracts/orchestrator-contract.md

@@ -0,0 +1,77 @@
+# Contract: Orchestrateur /devflow
+
+**Feature**: 027-pipeline-auto-execution
+**Date**: 2026-03-25
+
+## Interface — commande `/devflow`
+
+### Arguments (mis a jour)
+
+```
+/devflow <ISSUE_ID> [STEP] [--step] [--recover]
+```
+
+| Argument | Type | Requis | Description |
+|----------|------|--------|-------------|
+| ISSUE_ID | string | oui | Identifiant de l'issue (ex: KS-123) |
+| STEP | string | non | Force la reprise a une etape specifique |
+| --step | flag | non | Mode une-etape-a-la-fois (desactive le chainage) |
+| --recover | flag | non | Reconstruit state.json depuis les artefacts |
+
+### Comportement par defaut (chainage)
+
+```
+ENTREE: ISSUE_ID
+SORTIE: Pipeline execute jusqu'a un point d'arret naturel
+
+1. Creer/checkout branche git (si necessaire)
+2. Lire state.json → currentStep
+3. BOUCLE (max 15 iterations):
+   a. Si currentStep == "done" → afficher resume, SORTIE
+   b. Si etape optionnelle:
+      - mode fast → skip automatique
+      - mode full → demander a l'utilisateur
+   c. Executer /devflow.{currentStep} ISSUE_ID
+   d. Relire state.json
+   e. Verifier progression (anti-boucle)
+   f. Si review gate:
+      - PASS → continuer
+      - WARNING → afficher, demander confirmation
+      - BLOQUANT → ARRET
+   g. Si --step → ARRET
+4. SORTIE
+```
+
+### Points d'arret du chainage
+
+| Condition | Action |
+|-----------|--------|
+| `currentStep == "done"` | Afficher resume final |
+| Review gate BLOQUANT | Arreter, afficher les blockers |
+| Review gate WARNING | Pause, demander confirmation |
+| Etape optionnelle (mode full) | Pause, demander skip/execute |
+| Flag `--step` | Arreter apres 1 etape |
+| Compteur >= 15 | Arreter avec avertissement de securite |
+| currentStep n'a pas progresse | Arreter avec erreur (anti-boucle) |
+
+## Interface — sync Linear (toutes commandes)
+
+### Protocole de non-regression
+
+```
+ENTREE: issue_id, statut_cible (depuis STEP_LINEAR_MAPPING)
+SORTIE: statut Linear mis a jour ou conserve
+
+1. get_issue(issue_id) → statut_actuel
+2. Si erreur (API down, issue inexistante) → warning, SORTIE sans modification
+3. index_actuel = STEP_LINEAR_ORDER.index(statut_actuel) ou -1 si inconnu
+4. index_cible = STEP_LINEAR_ORDER.index(statut_cible)
+5. Si index_actuel >= index_cible → log "conserve", SORTIE sans modification
+6. save_issue(issue_id, statut_cible)
+```
+
+### Cas limites
+
+- Statut Linear inconnu (custom/non-mappe) : traiter index comme -1 → toujours mettre a jour
+- API Linear indisponible : continuer sans sync, logger warning
+- Issue inexistante : continuer sans sync, logger warning

devflow_cli-2.8.0/.specify/specs/027-pipeline-auto-execution/data-model.md

@@ -0,0 +1,54 @@
+# Data Model: Pipeline Auto-Execution
+
+**Feature**: 027-pipeline-auto-execution
+**Date**: 2026-03-25
+
+## Entites existantes (inchangees)
+
+### FeatureState (state.json)
+
+Aucun changement de schema. Les champs existants suffisent :
+- `currentStep` : etape courante (utilise par la boucle de chainage)
+- `completedSteps` : etapes terminees (utilise pour detecter la progression)
+- `skippedSteps` : etapes sautees (utilise pour l'auto-skip)
+- `mode` : "full" ou "fast" (determine le comportement des etapes optionnelles)
+- `reviewIterations` : compteur par gate (utilise pour les verdicts)
+
+### STEP_LINEAR_MAPPING (existant)
+
+Inchange. Mapping complet etape → statut Linear.
+
+## Nouvelle constante
+
+### STEP_LINEAR_ORDER
+
+**Fichier**: `src/devflow_cli/__init__.py`
+
+Liste ordonnee des statuts Linear par progression croissante :
+
+```python
+STEP_LINEAR_ORDER = [
+    "Backlog",
+    "Spec",
+    "Research",
+    "Plan",
+    "Tasks",
+    "Review",
+    "In Progress",
+    "Doc",
+    "Done",
+]
+```
+
+**Usage**: Permet de comparer deux statuts Linear pour determiner si une mise a jour constituerait une regression.
+
+**Regle**: `statut_actuel_index >= statut_cible_index` → ne pas mettre a jour.
+
+**Coherence**: Doit etre maintenu en parallele avec `STEP_LINEAR_MAPPING`. Un assert de coherence sera ajoute (meme pattern que les asserts existants dans `__init__.py`).
+
+## Relations
+
+```
+STEP_LINEAR_MAPPING --mappe vers--> STEP_LINEAR_ORDER (statuts)
+FeatureState.currentStep --determine--> STEP_LINEAR_MAPPING[currentStep] --compare avec--> statut actuel Linear
+```

devflow_cli-2.8.0/.specify/specs/027-pipeline-auto-execution/plan.md

@@ -0,0 +1,187 @@
+# Implementation Plan: Pipeline Auto-Execution
+
+**Branch**: `027-pipeline-auto-execution` | **Date**: 2026-03-25 | **Spec**: [spec.md](spec.md)
+**Input**: Feature specification from `/specs/027-pipeline-auto-execution/spec.md`
+
+## Summary
+
+Trois ameliorations au pipeline devflow : (1) creation automatique de branche git par l'orchestrateur `/devflow`, (2) synchronisation Linear systematique a chaque transition d'etape, avec regle de non-regression du statut, (3) chainage automatique des etapes avec flag `--step` pour opt-out. Les modifications portent principalement sur les commandes markdown Claude Code (`commands/devflow.md` et `commands/devflow.clarify.md`) et marginalement sur le code Python CLI.
+
+## Technical Context
+
+**Language/Version**: Python 3.11 (CLI) + Markdown (commandes Claude Code)
+**Primary Dependencies**: Typer >=0.12, Rich >=13 (CLI), MCP Linear plugin (sync)
+**Storage**: Fichiers locaux (state.json, markdown)
+**Testing**: pytest (Python, 244+ tests), bash tests (41 tests via `tests/run-tests.sh`)
+**Target Platform**: macOS/Linux CLI + extension Claude Code
+**Project Type**: CLI + Claude Code extensions (hybride)
+**Performance Goals**: N/A (outil CLI interactif)
+**Constraints**: Retrocompatibilite avec state.json et commandes existantes
+**Scale/Scope**: Utilisateur unique par session Claude Code
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+| Principe | Statut | Justification |
+|----------|--------|---------------|
+| I. Spec-Driven Development | PASS | spec.md complete avec 4 US, 10 FR, 5 SC, clarifications resolues |
+| II. Pipeline Sequentiel | PASS | Le chainage automatique respecte l'ordre du pipeline — il automatise le dispatch, pas la sequence |
+| III. Gates de Review (NON-NEGOCIABLE) | PASS | Les review gates restent bloquantes : BLOQUANT = arret, WARNING = pause + confirmation, PASS = continue |
+| IV. Retrocompatibilite | PASS | Changements additifs — commandes individuelles inchangees, `--step` preserve le comportement actuel |
+| V. Simplicite (YAGNI) | PASS | Modifications minimales : 1 commande reecrite (devflow.md), 1 commande amendee (devflow.clarify.md), ajout de logique dans la commande existante sans nouvelle abstraction |
+| VI. Testabilite | PASS | Tests Python pour la logique de non-regression Linear (compare_linear_status), tests bash inchanges |
+| VII. Integration Linear | PASS | Cette feature renforce directement ce principe — sync systematique a chaque etape |
+
+Aucune violation detectee. Pas de Complexity Tracking necessaire.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/027-pipeline-auto-execution/
+├── spec.md              # Specification (complete)
+├── plan.md              # This file
+├── research.md          # Phase 0 output
+├── data-model.md        # Phase 1 output
+├── contracts/           # Phase 1 output
+│   └── orchestrator-contract.md
+├── quickstart.md        # Phase 1 output
+└── tasks.md             # Phase 2 output (/speckit.tasks)
+```
+
+### Source Code (repository root)
+
+```text
+commands/
+├── devflow.md                  # MODIFIE — chainage, branche git, --step
+├── devflow.clarify.md          # MODIFIE — ajout sync Linear en fin d'etape
+└── devflow.*.md                # MODIFIE — ajout regle non-regression Linear
+
+src/devflow_cli/
+├── __init__.py                 # MODIFIE — ajout STEP_LINEAR_ORDER pour comparaison
+└── core/
+    └── git.py                  # INCHANGE — fonctions existantes reutilisees
+
+tests/
+├── test_linear_order.py        # NOUVEAU — tests comparaison statuts Linear
+└── fixtures/                   # INCHANGE
+```
+
+**Structure Decision**: Projet existant brownfield. Aucun nouveau module ou package. Les modifications sont localisees dans les fichiers existants. Un seul nouveau fichier de test.
+
+## Phase 0: Research
+
+### Analyse des commandes existantes — couverture Linear sync
+
+**Decision**: La quasi-totalite des commandes d'etape ont deja la sync Linear.
+
+| Commande | Sync Linear | Statut cible | Action |
+|----------|-------------|--------------|--------|
+| devflow.spec | Oui | "Spec" | Ajouter regle non-regression |
+| devflow.clarify | **Non** | "Spec" | **Ajouter sync** + non-regression |
+| devflow.review-spec | Oui | "Review" | Ajouter regle non-regression |
+| devflow.research | Oui | "Research" | Ajouter regle non-regression |
+| devflow.plan | Oui | "Plan" | Ajouter regle non-regression |
+| devflow.contracts | Oui | "Plan" | Ajouter regle non-regression |
+| devflow.tasks | Oui | "Tasks" | Ajouter regle non-regression |
+| devflow.review-tasks | Oui | "Review" | Ajouter regle non-regression |
+| devflow.implement | Oui | "In Progress" | Ajouter regle non-regression |
+| devflow.review-impl | Oui | "Review" | Ajouter regle non-regression |
+| devflow.docs | Oui | "Doc" | Ajouter regle non-regression |
+| devflow.md (transition done) | Non | "Done" | Ajouter sync finale |
+
+**Rationale**: Seule `devflow.clarify` manque completement la sync. Les autres ont besoin uniquement de la regle de non-regression (comparer le statut actuel avant d'ecraser).
+
+### Ordre des statuts Linear pour la non-regression
+
+**Decision**: Definir un ordre de progression des statuts Linear pour pouvoir comparer "plus avance" vs "moins avance".
+
+Ordre derive du pipeline :
+```
+Backlog < Spec < Research < Plan < Tasks < Review < In Progress < Doc < Done
+```
+
+**Rationale**: Le mapping `STEP_LINEAR_MAPPING` mappe plusieurs etapes vers le meme statut Linear (ex: `clarify` et `spec` → "Spec", `review-spec` et `review-tasks` et `review-impl` → "Review"). L'ordre ci-dessus suit la progression logique. Un statut ne doit jamais regresser.
+
+**Alternative rejetee**: Comparer par index d'etape devflow plutot que par statut Linear — rejete car les statuts Linear sont le domaine de reference pour Linear, et un utilisateur pourrait avoir change manuellement vers un statut custom.
+
+### Mecanisme de chainage dans les commandes Claude Code
+
+**Decision**: Le chainage est implemente directement dans `commands/devflow.md` comme une boucle dans les instructions markdown. Apres l'execution d'une sous-commande, l'orchestrateur relit `state.json`, verifie la progression, et relance la commande suivante.
+
+**Rationale**: Les commandes Claude Code sont des instructions en markdown interpetees par le modele. L'orchestrateur `/devflow` peut boucler en relisant l'etat apres chaque etape — pas besoin d'outil programmatique de chainage.
+
+**Alternative rejetee**: Utiliser le Skill tool pour chainer — rejete car l'orchestrateur est deja le point d'entree et peut simplement boucler dans son propre workflow.
+
+## Phase 1: Design & Contracts
+
+### Data Model
+
+Pas de nouvelles entites. Extension mineure de la constante `STEP_LINEAR_ORDER` dans `__init__.py` :
+
+```python
+# Ordre de progression des statuts Linear (pour non-regression)
+STEP_LINEAR_ORDER = [
+    "Backlog",
+    "Spec",
+    "Research",
+    "Plan",
+    "Tasks",
+    "Review",
+    "In Progress",
+    "Doc",
+    "Done",
+]
+```
+
+Cette liste est utilisee par les commandes pour determiner si le statut Linear actuel est "plus avance" que le statut cible. Si oui, ne pas mettre a jour.
+
+### Contracts
+
+#### Orchestrateur `/devflow` — nouveaux comportements
+
+**Nouveau flag** : `--step`
+- Syntaxe : `/devflow KS-123 --step`
+- Effet : execute une seule etape puis s'arrete (comportement actuel)
+- Par defaut (sans `--step`) : chainage automatique
+
+**Branche git automatique** (avant etape 7 du workflow actuel) :
+- Detecter le nom de la feature depuis le dossier `.specify/specs/`
+- Si la branche correspondante n'existe pas → la creer et checkout
+- Si elle existe → checkout
+- Si changements non commites → avertir et demander confirmation
+
+**Boucle de chainage** (remplace l'etape 7 actuelle) :
+```
+TANT QUE currentStep != "done" ET compteur < 15 ET pas --step:
+  1. Lire state.json → currentStep
+  2. Si etape optionnelle en mode full → demander skip/execute
+  3. Si etape optionnelle en mode fast → skip automatique
+  4. Executer la commande correspondante
+  5. Relire state.json
+  6. Verifier que currentStep a progresse (anti-boucle)
+  7. Si review gate → verifier verdict:
+     - PASS → continuer
+     - WARNING → afficher, demander confirmation
+     - BLOQUANT → STOP
+  8. Incrementer compteur
+```
+
+#### Regle de non-regression Linear (toutes commandes)
+
+Instruction ajoutee a chaque commande qui fait un `save_issue` :
+
+```
+Avant de mettre a jour le statut Linear :
+1. Lire le statut actuel de l'issue via get_issue
+2. Comparer avec le statut cible selon STEP_LINEAR_ORDER
+3. Si statut actuel >= statut cible → ne pas mettre a jour, logger "Statut Linear conserve (deja a [statut])"
+4. Si statut actuel < statut cible → mettre a jour normalement
+5. Si l'issue n'existe pas ou API indisponible → ignorer avec warning
+```
+
+### Quickstart
+
+Voir `quickstart.md` genere separement.

devflow_cli-2.8.0/.specify/specs/027-pipeline-auto-execution/quickstart.md

@@ -0,0 +1,49 @@
+# Quickstart: Pipeline Auto-Execution
+
+**Feature**: 027-pipeline-auto-execution
+**Date**: 2026-03-25
+
+## Utilisation
+
+### Lancer le pipeline complet (chainage automatique)
+
+```
+/devflow KS-123
+```
+
+Le pipeline s'execute automatiquement de l'etape courante jusqu'a la fin ou un point d'arret (review bloquante, interruption).
+
+### Mode une-etape-a-la-fois
+
+```
+/devflow KS-123 --step
+```
+
+Comportement identique a l'ancien : execute une seule etape puis s'arrete.
+
+### Forcer une etape specifique
+
+```
+/devflow KS-123 plan --step
+```
+
+Reprend a l'etape `plan` et s'arrete apres.
+
+## Ce qui change
+
+| Avant | Apres |
+|-------|-------|
+| Relancer `/devflow KS-123` apres chaque etape | Une seule invocation suffit |
+| Pas de branche git automatique | Branche creee/checkout au lancement |
+| Sync Linear partielle | Sync a chaque transition d'etape |
+| Skip manuel des etapes optionnelles | Proposition de skip avec justification |
+
+## Branche git
+
+Au premier lancement, `/devflow` cree automatiquement la branche git correspondant a la feature et effectue le checkout. Si la branche existe deja, il bascule dessus.
+
+Si des changements non commites sont detectes, un avertissement est affiche avant le changement de branche.
+
+## Synchronisation Linear
+
+A chaque fin d'etape, le statut de l'issue Linear est mis a jour automatiquement. Le statut ne regresse jamais : si quelqu'un l'a avance manuellement dans Linear, il est conserve tel quel.

devflow_cli-2.8.0/.specify/specs/027-pipeline-auto-execution/research.md

@@ -0,0 +1,41 @@
+# Research: Pipeline Auto-Execution
+
+**Feature**: 027-pipeline-auto-execution
+**Date**: 2026-03-25
+
+## R1: Couverture Linear sync existante
+
+**Decision**: Seule `devflow.clarify.md` manque la sync Linear. Toutes les autres commandes d'etape (spec, review-spec, research, plan, contracts, tasks, review-tasks, implement, review-impl, docs) ont deja une instruction `mcp__plugin_linear_linear__save_issue`.
+
+**Rationale**: Verification exhaustive par grep sur tous les fichiers `commands/devflow.*.md`. L'effort de sync est minimal — 1 commande a completer, 11 commandes a amender avec la regle de non-regression.
+
+**Alternatives considered**: Centraliser la sync dans l'orchestrateur uniquement — rejete car les commandes doivent rester autonomes (FR-010).
+
+## R2: Ordre de progression des statuts Linear
+
+**Decision**: Definir `STEP_LINEAR_ORDER` comme constante Python dans `__init__.py` :
+`Backlog < Spec < Research < Plan < Tasks < Review < In Progress < Doc < Done`
+
+**Rationale**: Le mapping `STEP_LINEAR_MAPPING` associe plusieurs etapes devflow au meme statut Linear (ex: `clarify` et `spec` → "Spec"). Pour la regle de non-regression, il faut un ordre total sur les statuts Linear eux-memes. L'ordre ci-dessus suit la progression naturelle du pipeline.
+
+**Alternatives considered**:
+- Comparer par index d'etape devflow → rejete car un utilisateur pourrait avoir change le statut Linear manuellement vers un statut qui ne correspond a aucune etape devflow.
+- Laisser la comparaison aux commandes markdown → rejete car error-prone, mieux vaut une constante centralisee.
+
+## R3: Mecanisme de chainage dans l'orchestrateur
+
+**Decision**: Implementer le chainage comme une boucle dans les instructions markdown de `commands/devflow.md`. L'orchestrateur relit `state.json` apres chaque sous-commande et decide de continuer ou s'arreter.
+
+**Rationale**: Les commandes Claude Code sont des instructions interpretees par le modele. L'orchestrateur peut boucler nativement — pas besoin d'API programmatique. Le modele lit state.json, execute la commande, relit state.json, etc.
+
+**Alternatives considered**:
+- Skill tool pour chainer les commandes → rejete car A-002 (incertitude sur le chainage programmatique) et complexite inutile.
+- Modifier le code Python pour ajouter un mode "chain" a la CLI → rejete car le point d'entree principal est la commande slash, pas la CLI Python.
+
+## R4: Detection de branche dans l'orchestrateur
+
+**Decision**: L'orchestrateur detecte le nom de la feature depuis le dossier `.specify/specs/` (ex: `027-pipeline-auto-execution`) et utilise ce nom comme nom de branche. Il reutilise les fonctions `branch_exists`, `create_branch`, `checkout_branch` de `core/git.py` via des commandes `git` bash equivalentes dans le markdown.
+
+**Rationale**: Les commandes markdown n'ont pas acces direct au code Python. Elles utilisent des commandes bash (`git checkout -b`, `git status --porcelain`). Les fonctions Python existantes ont la meme logique.
+
+**Alternatives considered**: Appeler la CLI `devflow feature` depuis l'orchestrateur → viable mais surcharge (cree aussi state.json et review-log.md qui existent deja). Mieux vaut juste gerer la branche git.