pdd-cli 0.0.45__py3-none-any.whl → 0.0.118__py3-none-any.whl

pdd/prompts/agentic_e2e_fix_step7_verify_tests_LLM.prompt

@@ -0,0 +1,116 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to verify that the unit tests detect the bugs.
+
+% Context
+
+You are working on step 7 of 9 in an agentic e2e fix workflow. You need to verify that the unit tests created in Step 6 actually fail on the current buggy code.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Previous Step Outputs
+<step1_output>
+{step1_output}
+</step1_output>
+
+<step2_output>
+{step2_output}
+</step2_output>
+
+<step3_output>
+{step3_output}
+</step3_output>
+
+<step4_output>
+{step4_output}
+</step4_output>
+
+<step5_output>
+{step5_output}
+</step5_output>
+
+<step6_output>
+{step6_output}
+</step6_output>
+
+% Your Task
+
+1. **Run the newly created unit tests**
+   - Parse Step 6 output for FILES_CREATED/FILES_MODIFIED
+   - Execute pytest with the test files from Step 6's FILES_CREATED output
+   - Capture the test output
+
+2. **Verify tests fail as expected**
+   - Each test should FAIL on the current buggy code
+   - The failure message should relate to the bug being detected
+   - If a test passes, it's not detecting the bug correctly
+
+3. **Handle unexpected results**
+   - If tests pass instead of fail: the test is not detecting the bug
+   - If tests error (not assert fail): test setup issue
+   - Report issues and suggest fixes
+
+% Output
+
+After completing your analysis, use `gh issue comment` to post your findings to issue #{issue_number}:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+**If tests properly detect bugs:**
+```markdown
+## Step 7: Verify Tests Detect Bugs (Cycle {cycle_number})
+
+**Status:** Tests Correctly Detect Bugs
+
+### Test Results
+| Test | Status | Error |
+|------|--------|-------|
+| `test_{{name}}` | FAIL (expected) | {{assertion_error}} |
+
+### Verification Summary
+- {{N}} tests correctly fail on buggy code
+- Tests will pass once bugs are fixed via `pdd fix`
+
+---
+*Proceeding to Step 8: Run pdd fix*
+```
+
+**If tests don't detect bugs:**
+```markdown
+## Step 7: Verify Tests Detect Bugs (Cycle {cycle_number})
+
+**Status:** TESTS_NOT_DETECTING_BUGS
+
+### Problem
+| Test | Issue |
+|------|-------|
+| `test_{{name}}` | Passes when it should fail |
+
+### Analysis
+{{explanation of why tests aren't detecting the bug}}
+
+### Fix Applied
+{{description of how tests were corrected}}
+
+FILES_MODIFIED: {{comma_separated_list}}
+
+---
+*Proceeding to Step 8: Run pdd fix*
+```
+
+% Important
+
+- Tests MUST fail on current code to be valid bug-detecting tests
+- If tests pass, either the bug is already fixed or the test is wrong
+- Always fix invalid tests before proceeding
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_e2e_fix_step8_run_pdd_fix_LLM.prompt

@@ -0,0 +1,120 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to run pdd fix sequentially on dev units identified during e2e failure analysis.
+
+% Context
+
+You are working on step 8 of 9 in an agentic e2e fix workflow. You need to run `pdd fix` on each dev unit identified in Step 5 to fix the bugs causing e2e test failures.
+
+**Important distinction from Step 1:**
+- Step 1: Fixes dev units associated with unit tests **explicitly listed in the GitHub issue** (from `pdd bug`)
+- Step 8 (this step): Fixes dev units **identified during e2e failure analysis** in Steps 3-5 (may be different or additional dev units discovered through stack trace analysis)
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Previous Step Outputs
+<step1_output>
+{step1_output}
+</step1_output>
+
+<step2_output>
+{step2_output}
+</step2_output>
+
+<step3_output>
+{step3_output}
+</step3_output>
+
+<step4_output>
+{step4_output}
+</step4_output>
+
+<step5_output>
+{step5_output}
+</step5_output>
+
+<step6_output>
+{step6_output}
+</step6_output>
+
+<step7_output>
+{step7_output}
+</step7_output>
+
+% Failing Dev Units
+{failing_dev_units}
+
+% Your Task
+
+1. **Run pdd fix for each failing dev unit**
+   - For each dev unit from Step 5 (DEV_UNITS_IDENTIFIED):
+   - Execute pdd fix in manual mode:
+     ```bash
+     # Create a temp error file for pdd fix
+     touch /tmp/pdd_fix_errors_{dev_unit}.log
+     pdd fix --manual prompts/{dev_unit}_python.prompt pdd/{dev_unit}.py tests/test_{dev_unit}.py /tmp/pdd_fix_errors_{dev_unit}.log --loop
+     ```
+   - Wait for completion before starting next
+   - Capture output from each run
+
+2. **Track results**
+   - Note which dev units were successfully fixed
+   - Note which dev units still have failing tests
+   - Capture any error messages
+
+3. **Run unit tests to verify fixes**
+   - After all pdd fix runs complete
+   - Run: `pytest tests/test_{dev_unit}.py -v` for each
+   - Report pass/fail status
+
+% Output
+
+After completing your analysis, use `gh issue comment` to post your findings to issue #{issue_number}:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+Your comment should follow this format:
+
+```markdown
+## Step 8: Run pdd fix (Cycle {cycle_number})
+
+**Status:** {N}/{M} Dev Units Fixed
+
+### pdd fix Results
+| Dev Unit | pdd fix Status | Tests After |
+|----------|----------------|-------------|
+| `{name}` | Success | {N}/{M} pass |
+| `{name}` | Failed | {error} |
+
+### Files Changed
+{list_of_modified_files}
+
+### Summary
+- Dev units fixed: {list}
+- Dev units still failing: {list}
+- Total pdd fix runs: {N}
+- Total cost: ${cost:.4f}
+
+FILES_MODIFIED: {comma_separated_list_of_code_files}
+
+---
+*Proceeding to Step 9: Final Verification*
+```
+
+% Important
+
+- Run pdd fix SEQUENTIALLY, not in parallel
+- Each dev unit may take significant time - be patient
+- Track costs from each pdd fix invocation
+- Always output FILES_MODIFIED line
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_e2e_fix_step9_verify_all_LLM.prompt

@@ -0,0 +1,146 @@
+% You are an expert software engineer fixing bugs identified in a GitHub issue. Your task is to perform final verification and control the outer loop.
+
+% Context
+
+You are working on step 9 of 9 in an agentic e2e fix workflow. This step verifies the current state and determines if another cycle is needed.
+
+% Inputs
+
+- GitHub Issue URL: {issue_url}
+- Repository: {repo_owner}/{repo_name}
+- Issue Number: {issue_number}
+- Cycle: {cycle_number}/{max_cycles}
+
+% Issue Content
+<issue_content>
+{issue_content}
+</issue_content>
+
+% Previous Step Outputs
+<step1_output>
+{step1_output}
+</step1_output>
+
+<step2_output>
+{step2_output}
+</step2_output>
+
+<step3_output>
+{step3_output}
+</step3_output>
+
+<step4_output>
+{step4_output}
+</step4_output>
+
+<step5_output>
+{step5_output}
+</step5_output>
+
+<step6_output>
+{step6_output}
+</step6_output>
+
+<step7_output>
+{step7_output}
+</step7_output>
+
+<step8_output>
+{step8_output}
+</step8_output>
+
+% Your Task
+
+1. **Run full test suite**
+   - Run all unit tests: `pytest tests/ -v`
+   - Run all e2e tests identified in the issue
+   - Capture complete results
+
+2. **Assess current state**
+   - How many tests pass vs fail?
+   - Are the original bugs fixed?
+   - Are there new failures?
+
+3. **Determine next action**
+   - If all tests pass: Workflow complete
+   - If tests still fail and cycle < max_cycles: Another cycle needed
+   - If tests still fail and cycle >= max_cycles: Max cycles reached, report status
+
+% Output
+
+After completing your analysis, use `gh issue comment` to post your findings to issue #{issue_number}:
+
+```
+gh issue comment {issue_number} --repo {repo_owner}/{repo_name} --body "..."
+```
+
+**If all tests pass:**
+```markdown
+## Step 9: Final Verification (Cycle {cycle_number})
+
+**Status:** ALL_TESTS_PASS
+
+### Test Results
+- Unit tests: {N}/{M} pass
+- E2E tests: {N}/{M} pass
+
+### Summary
+All bugs fixed successfully in {cycle_number} cycle(s).
+
+### Files Changed (Total)
+{list_of_all_files_modified}
+
+---
+*Workflow complete - all tests passing*
+```
+
+**If more cycles needed:**
+```markdown
+## Step 9: Final Verification (Cycle {cycle_number})
+
+**Status:** CONTINUE_CYCLE
+
+### Test Results
+- Unit tests: {N}/{M} pass ({K} still failing)
+- E2E tests: {N}/{M} pass ({K} still failing)
+
+### Remaining Failures
+| Test | Failure Type |
+|------|--------------|
+| `test_{name}` | {type} |
+
+### Analysis
+{explanation_of_remaining_failures}
+
+---
+*Starting Cycle {next_cycle}*
+```
+
+**If max cycles reached:**
+```markdown
+## Step 9: Final Verification (Cycle {cycle_number})
+
+**Status:** MAX_CYCLES_REACHED
+
+### Test Results
+- Unit tests: {N}/{M} pass ({K} still failing)
+- E2E tests: {N}/{M} pass ({K} still failing)
+
+### Remaining Failures
+| Test | Failure Type |
+|------|--------------|
+| `test_{name}` | {type} |
+
+### Recommendation
+{manual_intervention_suggestions}
+
+---
+*Workflow stopped - max cycles reached*
+```
+
+% Important
+
+- The exact strings "ALL_TESTS_PASS", "CONTINUE_CYCLE", or "MAX_CYCLES_REACHED" control the outer loop
+- Be accurate in test counts - don't round or estimate
+- Include specific failure information for debugging
+- Always post your findings as a GitHub comment before completing

pdd/prompts/agentic_fix_explore_LLM.prompt

@@ -0,0 +1,45 @@
+You are fixing a test failure in a PDD (Prompt-Driven Development) project.
+You are running as FALLBACK after PDD's normal fix loop failed multiple times. This loop was only allowed to change the code and/or test file.
+
+## PDD Principle
+The PROMPT FILE is the source of truth. Code and tests are generated artifacts.
+If tests expect behavior not defined in the prompt, the TESTS may be wrong.
+
+## Files (you have full read/write access)
+- Prompt file (THE SPEC): {prompt_path}
+- Code file: {code_path}
+- Test file: {test_path}
+- Example program file: {example_program_path}
+- Project root: {project_root}
+
+## Previous Fix Attempts
+The following shows what PDD's normal fix loop already tried.
+DO NOT repeat these approaches - try something different.
+
+{error_content}
+
+## Your Task
+1. Read the prompt file to understand the intended behavior
+2. Read the code and test files
+3. Run test file to get the error(s)
+4. Explore related files (helpers, fixtures, etc.) if needed
+5. Determine what needs fixing:
+   - Code doesn't match the prompt spec -> fix the code
+   - Tests don't match the prompt spec -> fix the tests
+   - Tests have implementation issues (mocking, isolation) -> fix test implementation
+   - Issue requires changes to other files -> make those changes
+5. Make ALL necessary changes to fix the tests
+6. Run the example program file to verify the fix didn't break the program
+7. Repeat steps 4-6 until the program output aligns with the prompt's intent
+8. Output a JSON string with the following fields:
+   - success: bool
+   - message: str
+   - cost: float
+   - model: str
+   - changed_files: list[str]
+
+## Critical Rules
+- The prompt file defines what's correct - code and tests should conform to it
+- DO NOT repeat approaches from the fix history above
+- You may modify existing files or create new ones
+- If the error involves mocking/test isolation, focus on the TEST implementation

pdd/prompts/agentic_fix_harvest_only_LLM.prompt

@@ -0,0 +1,48 @@
+% You are a strictly constrained code emitter. Your goal is to make {test_abs} run without errors. The bug could be in EITHER {code_abs} (the source code) OR {test_abs} (the test/example file). Analyze the error carefully to determine which file needs fixing. Read the prompt content which describes the intended functionality, then fix the appropriate file(s). Your ONLY task is to output fully corrected contents of one or more changed files, and optionally one shell command to run the tests. Wrap outputs between the provided BEGIN/END markers. No commentary or extra text.
+
+% IMPORTANT: Analyze the error traceback carefully:
+  - If the error is in how the test/example USES the code (wrong exception caught, wrong API usage), fix {test_abs}
+  - If the error is in the code's IMPLEMENTATION (wrong behavior, missing functionality), fix {code_abs}
+  - You may need to fix BOTH files in some cases
+
+% IMPORTANT: If you see ModuleNotFoundError or ImportError:
+  - For external packages: include "pip install <package> &&" before the test command in TESTCMD
+  - For local imports: fix the sys.path or import statement to correctly locate {code_abs}
+  - The code file is at: {code_abs} - ensure imports can find this path
+
+<inputs>
+    <paths>
+        <begin_marker>{begin}</begin_marker>
+        <end_marker>{end}</end_marker>
+        <code_file>{code_abs}</code_file>
+    </paths>
+
+    <context>
+        <prompt_content>
+            {prompt_content}
+        </prompt_content>
+        <relevant_error>
+            {error_content}
+        </relevant_error>
+    </context>
+</inputs>
+
+% Follow these instructions:
+
+  1) Output ALL files you changed that are needed to make tests pass (source files, tests, or small support files).
+     Use one block per file, with this exact wrapping:
+       <<<BEGIN_FILE:{code_abs}>>>
+       <FULL CORRECTED FILE CONTENT>
+       <<<END_FILE:{code_abs}>>>
+
+     If you also modify the test file:
+       <<<BEGIN_FILE:{test_abs}>>>
+       <FULL CORRECTED FILE CONTENT>
+       <<<END_FILE:{test_abs}>>>
+
+  2) If you cannot run tests, ALSO print a single block containing the exact shell command to run tests such that it returns 0 on success:
+       <<<BEGIN_TESTCMD>>>
+       python {test_abs}
+       <<<END_TESTCMD>>>
+
+  3) Print nothing else. No code fences, no comments, no prose.

pdd/prompts/agentic_fix_primary_LLM.prompt

@@ -0,0 +1,85 @@
+% YOU ARE A DEBUGGING AGENT with full file system access.
+
+% TASK: Fix the failing test at {test_abs}
+
+% APPROACH:
+1. Read the error traceback carefully to understand what's failing
+2. Explore the relevant files to understand the codebase structure
+3. Identify the root cause - is the bug in the code module or the test file or both?
+4. Use your file editing tools to make minimal, targeted fixes
+5. After fixing, output the test command to verify your changes
+
+% FILES YOU CAN READ AND EDIT:
+<code_module>
+    {code_abs}
+  </code_module>
+<test_file>
+    {test_abs}
+</test_file>
+
+
+% ORIGINAL SPECIFICATION:
+<prompt_content> 
+    {prompt_content}
+</prompt_content>
+
+
+% ERROR LOG:
+<error_content>
+  {error_content}
+</error_content>
+
+
+% DEBUGGING GUIDELINES:
+- Analyze the traceback to find WHERE the error occurs and WHY
+- The bug could be in EITHER file - don't assume it's always in the code
+- If the error is in how the test USES the code → fix the test
+- If the error is in the code's IMPLEMENTATION → fix the code
+- You may need to fix BOTH files in some cases
+
+% COMMON ERROR TYPES AND FIXES:
+- ImportError/ModuleNotFoundError for LOCAL modules: The import statement may be wrong.
+  FIX: Change the import to use the correct module name (look at what modules exist).
+  DO NOT create new modules to match a wrong import - fix the import instead!
+- ImportError/ModuleNotFoundError for EXTERNAL packages (pip packages like toml, requests, humanize, etc.):
+  PREFERRED: Install the missing package using TESTCMD:
+    <<<BEGIN_TESTCMD>>>
+    pip install <package_name> && python -m pytest "{test_abs}" -q
+    <<<END_TESTCMD>>>
+
+  DO NOT rewrite the code to remove or replace the dependency unless the specification
+  explicitly says the dependency is optional. If the code uses a library, INSTALL IT.
+
+  ONLY use try/except fallback if the specification says the feature is optional:
+    ```python
+    try:
+        import toml
+    except ImportError:
+        toml = None  # Only if spec says toml is optional
+    ```
+- TypeError/AttributeError: Check function signatures and method names
+- AssertionError: Check if the test expectation or the code logic is wrong
+- ZeroDivisionError/ValueError: Add proper error handling
+- SyntaxError (unterminated string literal / unexpected character):
+  This often means the file has garbage appended at the end (common LLM extraction bug).
+  FIX: Read the end of the file and look for JSON-like metadata patterns such as:
+    - Lines starting with `"explanation":`, `"focus":`, `"description":`
+    - Lines with only `}}` or `]`
+    - Code lines ending with `",` followed by JSON keys
+  SOLUTION: Delete all the garbage lines at the end of the file to restore valid Python.
+
+% EDIT POLICY:
+- Keep changes minimal and directly related to the failure
+- Prefer fixing import statements over creating new files
+- Prefer fixing implementation bugs over weakening tests
+- You MAY create new files if truly needed (e.g., __init__.py for packages)
+
+% AFTER FIXING, OUTPUT VERIFICATION COMMAND:
+<<<BEGIN_TESTCMD>>>
+python -m pytest "{test_abs}" -q
+<<<END_TESTCMD>>>
+
+% IMPORTANT:
+- Use your file tools to directly read and modify the files
+- Do NOT output the full file contents - just make targeted edits
+- The test command will be run automatically to verify your fix worked