devflow-engine 1.0.0__tar.gz → 1.1.1__tar.gz

devflow_engine-1.0.0/README.md → devflow_engine-1.1.1/PKG-INFO

@@ -1,7 +1,20 @@
-# DevFlow Engine
-
-CLI-first Python engine for DevFlow. The PyPI distribution is
-`devflow-engine`; it installs the `devflow` command.
+Metadata-Version: 2.4
+Name: devflow-engine
+Version: 1.1.1
+Summary: DevFlow v2 CLI-first engine (projects, stories, execution store, review packets)
+Author: DevFlow
+License: Proprietary
+Requires-Python: >=3.11
+Requires-Dist: cryptography>=45.0
+Requires-Dist: pydantic>=2.6
+Requires-Dist: pyyaml>=6.0
+Requires-Dist: rich>=13.7
+Requires-Dist: typer>=0.12
+Description-Content-Type: text/markdown
+
+# DevFlow Engine (v2)
+
+CLI-first Python engine for DevFlow v2.
 
 ## Goals
 - Project lifecycle: draft shell -> bind workspace/repo -> init/register/list/remove
@@ -14,27 +27,9 @@ CLI-first Python engine for DevFlow. The PyPI distribution is
 
 ## Documentation
 - `docs/story-implementation-planning-node.md` — per-story planning/gating node before TestDesign/Red, with dependency findings, queue decisions, and registry expectations consumed by downstream implementation nodes.
-- `docs/llm-input-primitives-v0.02.md` — v0.02 LLM-facing input primitive contract for `idea` and `story`.
-
-## Install
-
-Install the CLI from PyPI:
-
-```bash
-pipx install devflow-engine
-# or
-python -m pip install devflow-engine
-```
-
-Run the CLI:
-
-```bash
-devflow --help
-```
-
-## Development
 
-This repo is intended to be developed with **uv**.
+## Install / Dev
+This repo is intended to be run with **uv**.
 
 ```bash
 cd devflow_engine
@@ -42,16 +37,15 @@ uv venv
 uv pip install -e '.[dev]'
 ```
 
-Print the v0.02 LLM input guidance:
+Run the CLI:
 ```bash
-devflow llm guide
-devflow llm guide --primitive idea --json
+devflow --help
 ```
 
 ## Happy path
 1. project shell created in control plane
 2. workspace/repo bound to project
-3. registration DAG runs via `devflow project add`
+3. registration DAG runs via `devflow project init` or `devflow project import`
 4. project reaches `ready_for_source_scope`
 5. source docs -> scopes
 6. approved scope -> idea(s)
@@ -62,35 +56,46 @@ devflow llm guide --primitive idea --json
 ## Quickstart
 Register an existing repo with DevFlow:
 ```bash
-devflow project add --path /absolute/path/to/repo --name my-repo --json
+devflow project init --name my-repo
 ```
 
-Submit an idea or a ready story:
+Create and register a new repo from a template:
 ```bash
-devflow idea submit --project /absolute/path/to/repo --from idea.json --json
-# or
-devflow story submit --project /absolute/path/to/repo --from story.json --json
+devflow project import /absolute/path/to/my-repo --init python
 ```
 
-Run delivery and inspect health:
+Clone and register an existing GitHub repo:
 ```bash
-devflow run start --project /absolute/path/to/repo --json
-devflow run health --project /absolute/path/to/repo --json
+devflow project import owner/repo
+```
+
+Draft story contracts based on repo scan:
+```bash
+devflow plan analyze
+ls .devflow/drafts
+```
+
+Validate and register a story:
+```bash
+devflow story validate .devflow/drafts/DF-PLAN-001.yaml
+devflow story register .devflow/drafts/DF-PLAN-001.yaml
+```
+
+Run the "green gate":
+```bash
+devflow impl gate
+# or
+./scripts/green.sh
 ```
 
-Triage and repair failures:
+Generate a review packet:
 ```bash
-devflow doctor --project /absolute/path/to/repo --json
-devflow recovery run --project /absolute/path/to/repo --json
-devflow error solve --project /absolute/path/to/repo --json
+devflow review run DF-PLAN-001
 ```
 
-When you have a deterministic project-code repro, pass it to error solving:
+Inspect errors:
 ```bash
-devflow error solve \
-  --project /absolute/path/to/repo \
-  --repro-command 'uv run pytest' \
-  --json
+devflow error list
 ```
 
 Inspect per-node outputs from a stored run:

devflow_engine-1.0.0/PKG-INFO → devflow_engine-1.1.1/README.md

@@ -1,35 +1,6 @@
-Metadata-Version: 2.4
-Name: devflow-engine
-Version: 1.0.0
-Summary: DevFlow v2 CLI-first engine (projects, stories, execution store, review packets)
-Project-URL: Homepage, https://github.com/Nuosis/devflow_engine
-Project-URL: Repository, https://github.com/Nuosis/devflow_engine
-Project-URL: Issues, https://github.com/Nuosis/devflow_engine/issues
-Author: DevFlow
-License: Proprietary
-Keywords: agentic,automation,cli,devflow,testing,workflow
-Classifier: Development Status :: 5 - Production/Stable
-Classifier: Environment :: Console
-Classifier: Intended Audience :: Developers
-Classifier: License :: Other/Proprietary License
-Classifier: Operating System :: OS Independent
-Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.11
-Classifier: Programming Language :: Python :: 3.12
-Classifier: Topic :: Software Development
-Classifier: Topic :: Software Development :: Build Tools
-Requires-Python: >=3.11
-Requires-Dist: cryptography>=45.0
-Requires-Dist: pydantic>=2.6
-Requires-Dist: pyyaml>=6.0
-Requires-Dist: rich>=13.7
-Requires-Dist: typer>=0.12
-Description-Content-Type: text/markdown
-
-# DevFlow Engine
-
-CLI-first Python engine for DevFlow. The PyPI distribution is
-`devflow-engine`; it installs the `devflow` command.
+# DevFlow Engine (v2)
+
+CLI-first Python engine for DevFlow v2.
 
 ## Goals
 - Project lifecycle: draft shell -> bind workspace/repo -> init/register/list/remove
@@ -42,27 +13,9 @@ CLI-first Python engine for DevFlow. The PyPI distribution is
 
 ## Documentation
 - `docs/story-implementation-planning-node.md` — per-story planning/gating node before TestDesign/Red, with dependency findings, queue decisions, and registry expectations consumed by downstream implementation nodes.
-- `docs/llm-input-primitives-v0.02.md` — v0.02 LLM-facing input primitive contract for `idea` and `story`.
-
-## Install
-
-Install the CLI from PyPI:
-
-```bash
-pipx install devflow-engine
-# or
-python -m pip install devflow-engine
-```
-
-Run the CLI:
-
-```bash
-devflow --help
-```
-
-## Development
 
-This repo is intended to be developed with **uv**.
+## Install / Dev
+This repo is intended to be run with **uv**.
 
 ```bash
 cd devflow_engine
@@ -70,16 +23,15 @@ uv venv
 uv pip install -e '.[dev]'
 ```
 
-Print the v0.02 LLM input guidance:
+Run the CLI:
 ```bash
-devflow llm guide
-devflow llm guide --primitive idea --json
+devflow --help
 ```
 
 ## Happy path
 1. project shell created in control plane
 2. workspace/repo bound to project
-3. registration DAG runs via `devflow project add`
+3. registration DAG runs via `devflow project init` or `devflow project import`
 4. project reaches `ready_for_source_scope`
 5. source docs -> scopes
 6. approved scope -> idea(s)
@@ -90,35 +42,46 @@ devflow llm guide --primitive idea --json
 ## Quickstart
 Register an existing repo with DevFlow:
 ```bash
-devflow project add --path /absolute/path/to/repo --name my-repo --json
+devflow project init --name my-repo
 ```
 
-Submit an idea or a ready story:
+Create and register a new repo from a template:
 ```bash
-devflow idea submit --project /absolute/path/to/repo --from idea.json --json
-# or
-devflow story submit --project /absolute/path/to/repo --from story.json --json
+devflow project import /absolute/path/to/my-repo --init python
 ```
 
-Run delivery and inspect health:
+Clone and register an existing GitHub repo:
 ```bash
-devflow run start --project /absolute/path/to/repo --json
-devflow run health --project /absolute/path/to/repo --json
+devflow project import owner/repo
+```
+
+Draft story contracts based on repo scan:
+```bash
+devflow plan analyze
+ls .devflow/drafts
+```
+
+Validate and register a story:
+```bash
+devflow story validate .devflow/drafts/DF-PLAN-001.yaml
+devflow story register .devflow/drafts/DF-PLAN-001.yaml
+```
+
+Run the "green gate":
+```bash
+devflow impl gate
+# or
+./scripts/green.sh
 ```
 
-Triage and repair failures:
+Generate a review packet:
 ```bash
-devflow doctor --project /absolute/path/to/repo --json
-devflow recovery run --project /absolute/path/to/repo --json
-devflow error solve --project /absolute/path/to/repo --json
+devflow review run DF-PLAN-001
 ```
 
-When you have a deterministic project-code repro, pass it to error solving:
+Inspect errors:
 ```bash
-devflow error solve \
-  --project /absolute/path/to/repo \
-  --repro-command 'uv run pytest' \
-  --json
+devflow error list
 ```
 
 Inspect per-node outputs from a stored run:

devflow_engine-1.1.1/docs/error-solving-dag-note.md

@@ -0,0 +1,49 @@
+# Error-Solving DAG Note
+
+## Current state in `devflow_engine`
+
+`devflow_engine` does **not** currently have a first-class error-solving DAG module comparable to the recovery DAG.
+
+What exists today is legacy inline/service-style error-solving logic in:
+- `src/devflow_engine/cli/app.py`
+
+Relevant clue in code:
+- around `app.py:4870+`
+- prompt text includes:
+  - `You are Devin, an automated error solver.`
+
+This means the existing error-solving path in `devflow_engine` is:
+- present
+- story/error oriented
+- but **not** modeled as a proper standalone DAG/module yet
+
+## Important architecture note
+
+This was identified as legacy/problematic architecture.
+
+The intended long-term direction is **not** to keep growing the inline/service implementation in `cli/app.py`.
+Instead, error solving should be reimplemented as a first-class DAG with a clean queue/worker contract, parallel to the new recovery DAG work.
+
+## External reference / source of truth for intended pattern
+
+The legacy DevFlow Electron app has a **first-party error-solving DAG** implementation (written in Node).
+That app should be treated as the reference implementation to inspect when porting/implementing the proper error-solving DAG in `devflow_engine`.
+
+## Why this note exists
+
+We traced multiple clues while trying to place an error-solving queue after recovery:
+- `runtime_errors` helped identify the old error-solving path
+- but that path led to inline/service logic in `cli/app.py`, not a proper DAG module
+
+This distinction matters:
+- the recovery queue can be implemented cleanly now
+- the error-solving queue should **not** be wired to the legacy inline/service flow as if it were already a proper DAG substrate
+- instead, the proper next step is to port/implement the first-party error-solving DAG pattern from the Electron app into `devflow_engine`
+
+## Recommendation
+
+When this work is picked up:
+1. inspect the Node-based first-party error-solving DAG in the legacy DevFlow Electron app
+2. document its input contract, node sequence, and queue contract
+3. implement a real error-solving DAG in `devflow_engine`
+4. only then add a first-class error-solving queue to sit after recovery and before source-doc mutation in queue priority

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/docs/recovery-dag-contract.md

@@ -2,19 +2,14 @@
 
 ## Purpose
 
-Recover DevFlow operational state without assuming a deterministic-first repair
-path.
-
-Recovery owns queue/run/artifact/worker state. It should not own project-source
-repairs. Project-code failures belong to the error-solving lane described in
-`docs/doctor-recovery-error-solving-contract.md`.
+Recover failed queue items without assuming a deterministic-first repair path.
 
 ## Core doctrine
 
 Recovery is agentic first:
 1. load failed queue item
 2. investigate failure agentically
-3. route DevFlow state repair vs error-solving handoff
+3. route code error vs process error
 4. diagnose recovery strategy agentically
 5. execute recovery agentically
 6. verify recovery agentically
@@ -34,10 +29,8 @@ Recovery is agentic first:
 ## Routing
 
 ### `FailureTypeRouter`
-- `project_code_error` -> publish `delegated_to_error_solving`; do not edit project source
-- `devflow_state_error` -> `AgenticRecoveryDiagnosisNode`
-- `mixed` -> recover DevFlow state first, then recommend error solving
-- `unknown` -> gather more evidence or block without mutation
+- `code_error` -> `AgenticRecoveryExecutionNode` with delegation outcome
+- `process_error` -> `AgenticRecoveryDiagnosisNode`
 
 ### `RecoveryStrategyRouter`
 - `handoff_to_code_error`
@@ -68,9 +61,8 @@ These nodes are model-backed and must not be heuristic stubs:
 
 Recovery may end in:
 - `reenqueued`
-- `delegated_to_error_solving`
+- `delegated`
 - `blocked`
 - `recovered`
-- `manual_required`
 
 `PublishRecoveryStateNode` is responsible for surfacing the terminal recovery state into DFS.

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/prompts/implementation/red/prompt.md

@@ -15,13 +15,6 @@
 - Do not default to broad destructive database reset/isolation patterns (for example dropping or recreating the whole public schema) just to make story tests feel safe. Unless the story truly requires that blast radius, prefer the least-destructive isolation strategy that still proves the story contract.
 - Do not weaken the story contract, narrow scope to fit current code, or produce greenwashed tests that only prove page-load/visibility when stronger contract oracles are required.
 - Do not emit placeholders, heuristics, mocks, stubs, or fake passing tests as the primary behavior.
-- Never assert that a mock component, mock test id, or fake placeholder exists as proof of story behavior. Test the real component behavior, or if a dependency must be isolated, assert only the parent behavior and preserve required side effects.
-- Before mocking a method, identify its real side effects and whether the test depends on them. Mock the slow/external boundary, not the higher-level method whose behavior the test is meant to prove.
-- Mock responses must mirror the complete real data shape the system may consume downstream. Do not create partial mocks that hide schema assumptions.
-- Do not add or depend on production methods that exist only for tests. Use test utilities for cleanup and fixture lifecycle.
-- Do not claim user-facing functionality with a single shallow E2E/page-load test. If the story touches business rules, backend boundaries, persistence/auth/provider side effects, and UI flow, write the matching unit, integration/API, and Playwright proof planes required by the claim.
-- For Playwright tests, fail early when seeded/demo data required by the workflow is missing, unless the test name and oracle explicitly target an empty-state behavior.
-- For visible business controls, assert the resulting business state: route/context preservation for navigation, reset behavior for filters, durable/request-visible effects for mutations, negative role/status visibility, and observable side effects for downloads/copy/upload/provider actions.
 - Do not rely on deterministic fallback generation. If context is insufficient, say so in notes and still produce your best honest test draft from the available contract.
 - Prefer editing existing story-scoped tests over creating duplicate overlapping tests when possible.
 - If prior_passes show runtime_command_unverified, treat that as unresolved Red work and consult any supplied success_pattern_docs before changing the tests/runtime shape.

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/prompts/implementation/redreview/prompt.md

@@ -13,11 +13,5 @@
 - Rationale must justify only the planes you included and/or why the file should be registered. Never justify excluded or missing planes.
 - Set register_for_validation=true only for files that should participate in deterministic story-scoped validation.
 - Treat broad destructive database reset or isolation patterns as suspicious unless the story explicitly justifies them; if you keep one, say why that story needs it.
-- Reject or withhold validation registration for tests that only prove page load, clickability, mocked component existence, placeholder labels, or mock behavior when the story requires real behavior.
-- Treat tests that rely on partial mocks, unexplained mocks, or mocks of high-level methods with required side effects as weak unless the file preserves the real side effects needed by the oracle.
-- Treat production APIs or methods added solely for test cleanup as a test-quality problem unless the story proves the class owns that lifecycle in production.
-- For user-facing stories, require browser-level evidence for visible business controls and require deeper non-browser planes when the claim includes business rules, backend/API contracts, persistence, auth, schemas, providers, or durable side effects.
-- For seeded/demo Playwright flows, tests must fail when required seed data is absent unless they explicitly test the empty state.
-- For role/status/filter/mutation/external-action controls, count coverage only when the test asserts the required business result, not merely the visible control.
 - If a file has no directly supported allowable planes, return covered_planes as an empty list and set register_for_validation=false.
 - Use any supplied success_pattern_docs as repo-grounded examples of how this project expects deterministic test/runtime success to look.

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/prompts/implementation/redreview_repair/prompt.md

@@ -9,8 +9,3 @@
 - Do not change implementation code. Only emit test files.
 - Keep the repair bounded to the story-scoped tests already under review unless the supplied context makes an additional test file strictly necessary.
 - Every emitted file must include a concrete path and full file content.
-- Remove or rewrite tests that assert mock existence, placeholder labels, page load only, or mocked behavior instead of real story behavior.
-- If mocks remain necessary, repair them so they preserve required side effects and complete real response shapes. Prefer moving the mock lower to the slow/external boundary.
-- Do not repair test failures by adding test-only methods to production classes or by depending on production methods that exist only for cleanup.
-- If a user-facing claim is under-tested, add or repair the missing proof plane: unit for business rules, integration/API for persistence/auth/schema/provider effects, and Playwright for real visible workflows.
-- For Playwright repairs, add seed precondition assertions, business-result assertions, negative role/status assertions, filter reset assertions, or observable external-action assertions as required by the control category. Do not weaken assertions just to get green.

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/prompts/implementation/test_design/prompt.md

@@ -10,13 +10,6 @@
 - Every emitted test case must include a non-empty title, oracle, and anchor. Include plane when inferable from context.
 - Do not write implementation code. Do not silently weaken scope. Preserve the planning contract and canonical pathway expectations.
 - Prefer a compact but sufficient test design that makes downstream Red/RedReview bundle behavior and Green verification inspectable.
-- Match the test suite to the claim being made. Unit tests prove business rules and edge cases; integration/API tests prove persistence, auth, schemas, provider boundaries, and durable side effects; Playwright/E2E proves real user-facing workflows. Do not claim full functionality from one shallow plane.
-- For user-facing stories, include browser-level proof when a visible control changes business state, filters business data, triggers an API, gates role/status behavior, or advances a workflow.
-- Seeded/demo flows must fail when required seed data is absent. Empty-state assertions are valid only when the empty state is the explicit behavior under test.
-- Do not design tests that assert mock existence, placeholder labels, page-load only, or mocked component behavior as story proof.
-- When mocks are unavoidable, specify the real side effects that must be preserved and require complete real-shaped mock data, not partial fields needed only by the immediate assertion.
-- Do not add or require test-only production methods. Put cleanup/lifecycle helpers in test utilities unless the production class genuinely owns that lifecycle.
-- If the story touches UI business controls, include a ledger-oriented test plan: route/control, category, expected behavior source, required proof, test id, and any assumption that needs user/product review.
 
 ## Critical: Runtime Contract Ports
 

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/pyproject.toml

@@ -1,24 +1,11 @@
 [project]
 name = "devflow-engine"
-version = "1.0.0"
+version = "1.1.1"
 description = "DevFlow v2 CLI-first engine (projects, stories, execution store, review packets)"
 readme = "README.md"
 requires-python = ">=3.11"
 authors = [{ name = "DevFlow" }]
 license = { text = "Proprietary" }
-keywords = ["devflow", "cli", "agentic", "workflow", "testing", "automation"]
-classifiers = [
-  "Development Status :: 5 - Production/Stable",
-  "Environment :: Console",
-  "Intended Audience :: Developers",
-  "License :: Other/Proprietary License",
-  "Operating System :: OS Independent",
-  "Programming Language :: Python :: 3",
-  "Programming Language :: Python :: 3.11",
-  "Programming Language :: Python :: 3.12",
-  "Topic :: Software Development",
-  "Topic :: Software Development :: Build Tools",
-]
 
 dependencies = [
   "cryptography>=45.0",
@@ -28,11 +15,6 @@ dependencies = [
   "PyYAML>=6.0",
 ]
 
-[project.urls]
-Homepage = "https://github.com/Nuosis/devflow_engine"
-Repository = "https://github.com/Nuosis/devflow_engine"
-Issues = "https://github.com/Nuosis/devflow_engine/issues"
-
 [dependency-groups]
 dev = [
   "pytest>=8.0",
@@ -51,7 +33,13 @@ build-backend = "hatchling.build"
 
 [tool.hatch.build.targets.wheel]
 packages = ["src/devflow_engine", "src/devin"]
-force-include = { "prompts" = "devflow_engine/prompts", "docs/prompts" = "devflow_engine/docs/prompts" }
+
+# Bundle the repo-root `prompts/` directory inside the wheel at
+# devflow_engine/prompts/. agentic_prompts._PROMPTS_ROOT prefers the
+# package-local copy when it exists (installed mode) and falls back
+# to the repo-root copy (editable / dev mode).
+[tool.hatch.build.targets.wheel.force-include]
+"prompts" = "devflow_engine/prompts"
 
 [tool.ruff]
 line-length = 120

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/src/devflow_engine/__init__.py

@@ -1,3 +1,3 @@
 __all__ = ["__version__"]
 
-__version__ = "1.0.0"
+__version__ = "0.1.0"

{devflow_engine-1.0.0 → devflow_engine-1.1.1}/src/devflow_engine/agentic_prompts.py

@@ -1,11 +1,15 @@
 from __future__ import annotations
 
-from importlib.resources import files
 from pathlib import Path
-from typing import Any
 
+
+# Prefer the package-local prompts dir (bundled into the wheel by
+# hatch's force-include) so installed users find them; fall back to
+# the repo-root copy for editable / dev installs where this file
+# lives at <repo>/src/devflow_engine/agentic_prompts.py.
 _REPO_ROOT = Path(__file__).resolve().parents[2]
-_PROMPTS_ROOT = _REPO_ROOT / "prompts"
+_PACKAGE_PROMPTS_ROOT = Path(__file__).resolve().parent / "prompts"
+_PROMPTS_ROOT = _PACKAGE_PROMPTS_ROOT if _PACKAGE_PROMPTS_ROOT.is_dir() else (_REPO_ROOT / "prompts")
 
 _PROMPT_LAYOUT: dict[str, tuple[str, str]] = {
     "idea_response_doctrine": ("idea", "response_doctrine"),
@@ -55,25 +59,11 @@ def agentic_prompt_path(prompt_name: str) -> Path:
         group, agent_name = _PROMPT_LAYOUT[prompt_name]
     except KeyError as exc:
         raise KeyError(f"Unknown agentic prompt mapping: {prompt_name}") from exc
-    source_path = _PROMPTS_ROOT / group / agent_name / "prompt.md"
-    if source_path.exists():
-        return source_path
-    return Path(str(_packaged_prompts_root().joinpath(group, agent_name, "prompt.md")))
-
-
-def _packaged_prompts_root() -> Any:
-    return files("devflow_engine").joinpath("prompts")
-
-
-def _prompt_text(path: Path) -> str:
-    if path.exists():
-        return path.read_text(encoding="utf-8").strip()
-    package_path = _packaged_prompts_root().joinpath(*path.parts[-3:])
-    return package_path.read_text(encoding="utf-8").strip()
+    return _PROMPTS_ROOT / group / agent_name / "prompt.md"
 
 
 def load_agentic_prompt_markdown(prompt_name: str) -> str:
-    return _prompt_text(agentic_prompt_path(prompt_name))
+    return agentic_prompt_path(prompt_name).read_text(encoding="utf-8").strip()
 
 
 def load_agentic_prompt_lines(prompt_name: str) -> list[str]: