pdd-cli 0.0.42__py3-none-any.whl → 0.0.90__py3-none-any.whl

pdd/prompts/extract_program_code_fix_LLM.prompt

@@ -1,4 +1,10 @@
-% You are an expert Software Engineer. Your goal is to extract a JSON from a analysis of a program and code module bug fix report. If there is a choice of updating the program or the code module, you should chose to update the code module.
+% You are an expert Software Engineer. Your goal is to extract a JSON from a analysis of a program and code module bug fix report. 
+
+% IMPORTANT: The crash command is designed to fix errors in BOTH the code module AND the calling program that caused the crash. You should fix whatever needs to be fixed to make the program run successfully:
+- If the code module has bugs, fix the code module
+- If the calling program has bugs, fix the calling program  
+- If both have issues that contribute to the crash, fix BOTH
+- The goal is to ensure the program runs without errors after the fix
 
 % Here is the original program: <program>{program}</program>
 
@@ -14,4 +20,10 @@
     - 'update_program': Boolean indicating whether the program needs to be updated.
     - 'update_code': Boolean indicating whether the code module needs to be updated.
     - 'fixed_program': The entire updated program code or empty String if no update is needed.
-    - 'fixed_code': The entire updated code module or empty String if no update is needed.
+    - 'fixed_code': The entire updated code module or empty String if no update is needed.
+
+% IMPORTANT JSON formatting rules for code strings:
+    - Use standard JSON escaping for newlines: a single backslash-n (\n) represents an actual newline
+    - Do NOT double-escape newlines. Use \n not \\n for line breaks in code
+    - String literals in code that need to print newlines should use \n (which appears as \\n in JSON)
+    - Example: for code with two lines "def foo():\n    pass", the JSON should be: "def foo():\n    pass"

pdd/prompts/extract_prompt_update_LLM.prompt

@@ -1,14 +1,13 @@
-% You are an expert Software Engineer. Your goal is to extract the updated prompt from the LLM output.
+% You are an expert Software Engineer. Your goal is to extract the updated prompt from the LLM output in JSON format.
 
 % Here is the generated llm_output: <llm_output>{llm_output}</llm_output>
 
-% The LLM output contains the modified prompt that will generate the modified code, possibly with some additional commentary or explanation.
-% Your task is to identify and extract ONLY the modified prompt itself, without adding any JSON structure or additional formatting.
+% The LLM output contains the modified prompt that will generate the modified code, possibly with some additional commentary or explanation. Your task is to identify and extract ONLY the modified prompt itself, without adding any additional formatting.
 
 % Ensure you:
-% 1. Remove any "# Modified Prompt" headers or similar text that isn't part of the actual prompt
-% 2. Preserve all markdown, code blocks, and formatting within the actual prompt
-% 3. Don't add any explanatory text, JSON wrappers, or your own commentary
-% 4. Return only the text that constitutes the actual prompt
+  1. Remove any "# Modified Prompt" headers or similar text that isn't part of the actual prompt
+  2. Preserve all markdown, code blocks, and formatting within the actual prompt
+  3. Don't add any explanatory text, JSON wrappers, or your own commentary
+  4. Return only the text that constitutes the actual prompt
 
-% The "modified_prompt" should be the complete, standalone prompt that could be used directly to generate the modified code.
+% The "modified_prompt" JSON key should be the complete, standalone prompt that could be used directly to generate the modified code.

pdd/prompts/extract_promptline_LLM.prompt

@@ -1,11 +1,17 @@
-% You are an expert Software Engineer. Your goal is to extract the closest matching substring described by the prompt's output to be outputed in JSON format.
-
-% Here is the llm_output to parse: <llm_output>{llm_output}</llm_output>
-
-% When extracting the closest matching substring from llm_output, consider and correct the following for the extracted code:
-    - Should be a substring of prompt_file.
-    - Should be a a substring that closely matches code_str in content.
-
-% Output a JSON object with the following keys:
-    - 'explanation': String explanation of why this prompt_line matches the code_str and explain any errors detected in the code.
-    - 'prompt_line': String containing the closest matching verbatim substring of the prompt_file that matches code_str in content. This is not the line number.
+% You are an extremely literal parser. The LLM output below follows this structure:
+%   <analysis> ... </analysis>
+%   <verbatim_prompt_line>
+%   <<EXACT SUBSTRING FROM PROMPT_FILE>>
+%   </verbatim_prompt_line>
+%
+% Task
+%   • Extract the text between <verbatim_prompt_line> and </verbatim_prompt_line> (if present).
+%   • Output ONLY JSON with the keys:
+%       - "prompt_line": the exact substring between the tags. Do not alter whitespace or characters except for JSON escaping.
+%       - "explanation": short confirmation (<=120 characters) that the substring was copied verbatim, or describe why extraction failed.
+%   • If the tags are missing or empty, set "prompt_line" to "" and explain the issue.
+%   • Do not wrap the JSON in Markdown. No commentary, no additional keys.
+%
+<llm_output>
+{llm_output}
+</llm_output>

pdd/prompts/find_verification_errors_LLM.prompt

@@ -21,6 +21,12 @@
     Step 4. Identify any potential edge cases, error handling issues, or performance concerns that could cause problems in the future.
     Step 5. Check the code for potential bugs that haven't manifested yet.
     Step 6. If any issues are found, explain in detail the root cause of each issue and how it could impact the program's functioning.
+    Step 6.5. When analyzing errors involving mocked dependencies:
+       - Identify if 'program' uses MagicMock, unittest.mock, or similar mocking
+       - Trace the mock configuration to verify it matches expected real API behavior
+       - For AttributeError on mock objects: check if mock.return_value or mock.__getitem__.return_value has correct type
+       - Flag errors as "Mock Configuration Error" when the mock setup doesn't match real API return types
+       - Flag errors as "Production Code Error" only when the API usage is clearly incorrect
     Step 7. Carefully distinguish between:
        a. Incompatibilities (functions called by program but missing from code_module) - these are critical issues
        b. Prompt adherence issues (code doesn't match prompt requirements) - these are important but secondary to compatibility

pdd/prompts/fix_code_module_errors_LLM.prompt

@@ -1,6 +1,14 @@
-% You are an expert Software Engineer. Your goal is to fix the errors in a code_module or program that is causing that program to crash.
+% You are an expert Software Engineer. Your goal is to fix the errors in a code_module AND/OR program that is causing that program to crash.
 
-% Here is the program that is running the code_module that crashed and/or has errors: <program>{program}</program>
+% IMPORTANT: The crash command should fix whatever needs to be fixed to make the program run successfully:
+- If the code module has bugs, fix the code module
+- If the calling program has bugs, fix the calling program
+- If both have issues that contribute to the crash, fix BOTH
+- The goal is to ensure the program runs without errors after all fixes are applied
+- If you are not able to fix the calling program, or if you cannot access it, you shouldn't guess at fixes to the calling program. Do not add the functionality of the calling program to the code_module.
+- You must ensure that the code_module strictly adheres to the prompt requirements
+
+% Here is the calling program that is running the code_module that crashed and/or has errors: <program>{program}</program>
 
 % Here is the prompt that generated the code_module below: <prompt>{prompt}</prompt>
 
@@ -41,6 +49,10 @@
     Step 1. Compare the prompt to the code_module and explain differences, if any.
     Step 2. Compare the prompt to the program and explain differences, if any.
     Step 3. Explain in detail step by step why there might be an an error and why prior attempted fixes, if any, may not have worked. Write several paragraphs explaining the root cause of each of the errors.
-    Step 4. Explain in detail step by step how to solve each of the errors. For each error, there should be several paragraphs description of the steps. Sometimes logging or print statements can help debug the code_module or program.
+    Step 4. Explain in detail step by step how to solve each of the errors. For each error, there should be several paragraphs description of the steps. Consider whether the fix requires:
+        - Updating the code_module only
+        - Updating the calling program only  
+        - Updating BOTH the code_module AND the calling program
+        Sometimes logging or print statements can help debug the code_module or program.
     Step 5. Review the above steps and correct for any errors in the logic.
-    Step 6. For the code that need changes, write the corrected code_module and/or corrected program in its/their entirety.
+    Step 6. For ALL code that needs changes, write the corrected code_module and/or corrected program in their entirety. If both need fixes, provide both complete fixed versions.

pdd/prompts/fix_errors_from_unit_tests_LLM.prompt

@@ -9,50 +9,15 @@
 % This prompt is run iteratively. Here are the current errors and past potential fix attempts, if any, from the unit test and verification program run(s): <errors>{errors}</errors>
 
 % If the verfication program fails to run, the code_under_test and unit_test are unchanged from the previous iteration.
-<pdd>
-<examples>
-    <example_1>
-    % Here is an example_unit_test for the example_code_under_test: <example_unit_test><include>context/fix_errors_from_unit_tests/1/test_conflicts_in_prompts.py</include></example_unit_test>
-    
-    % Here is an example_code_under_test that fully passes the example_unit_test: <example_code_under_test><include>context/fix_errors_from_unit_tests/1/conflicts_in_prompts.py</include></example_code_under_test>
 
-    % Here is the prompt that generated the example_code_under_test: <example_prompt><include>context/fix_errors_from_unit_tests/1/conflicts_in_prompts_python.prompt</include></example_prompt>
-    </example_1>
+% IMPORTANT: The original prompt is the authoritative specification for what the code should do.
+% When analyzing errors:
+%   - If the code doesn't match the prompt specification, fix the CODE
+%   - If the unit_test expects behavior not specified in the prompt, fix the TEST
+%   - Never add functionality to the code that isn't specified in the prompt
+%   - Tests should verify prompt-specified behavior, not arbitrary expectations
 
-    <example_2>
-    % Here is an example_unit_test for the example_code_under_test: <example_unit_test><include>context/fix_errors_from_unit_tests/2/test_code_generator.py</include></example_unit_test>
 
-    % Here is an example_code_under_test that fully passes the example_unit_test: <example_code_under_test><include>context/fix_errors_from_unit_tests/2/code_generator.py</include></example_code_under_test>
-
-    % Here is the prompt that generated the example_code_under_test: <example_prompt><include>context/fix_errors_from_unit_tests/2/code_generator_python.prompt</include></example_prompt>
-    </example_2>
-
-    <example_3>
-    % Here is an example_unit_test for the example_code_under_test: <example_unit_test><include>context/fix_errors_from_unit_tests/3/test_context_generator.py</include></example_unit_test>
-
-    % Here is an example_code_under_test that fully passes the example_unit_test: <example_code_under_test><include>context/fix_errors_from_unit_tests/3/context_generator.py</include></example_code_under_test>
-
-    % Here is the prompt that generated the example_code_under_test: <example_prompt><include>context/fix_errors_from_unit_tests/3/context_generator_python.prompt</include></example_prompt>
-    </example_3>
-
-
-    <example_4>
-    % Here is an example_unit_test for the example_code_under_test: <example_unit_test><include>context/fix_errors_from_unit_tests/4/test_detect_change.py</include></example_unit_test>
-
-    % Here is an example_code_under_test that fully passes the example_unit_test: <example_code_under_test><include>context/fix_errors_from_unit_tests/4/detect_change.py</include></example_code_under_test>
-
-    % Here is the prompt that generated the example_code_under_test: <example_prompt><include>context/fix_errors_from_unit_tests/4/detect_change_python.prompt</include></example_prompt>
-    </example_4>
-
-    <example_5>
-    % Here is an example_unit_test for the example_code_under_test: <example_unit_test><include>context/fix_errors_from_unit_tests/4/test_detect_change_1_0_1.py</include></example_unit_test>
-
-    % Here is an example_code_under_test that didn't fully pass the example_unit_test: <example_code_under_test><include>context/fix_errors_from_unit_tests/4/detect_change_1_0_1.py</include></example_code_under_test>
-
-    % Here is an example error/fix log showing how the issues were resolved: <example_error_fix_log><include>context/fix_errors_from_unit_tests/4/error.log</include></example_error_fix_log>
-    </example_5>
-</examples>
-</pdd>
 
 <instructions>
 % Follow these steps to solve these errors:

pdd/prompts/fix_verification_errors_LLM.prompt

@@ -21,6 +21,28 @@
     5. Prefer making additive changes (adding new functions, improving existing ones) rather than removing functionality, even if that means going beyond the minimal requirements of the prompt.
     6. If your previous fixes resulted in verification failures related to missing functions, ensure those functions are included in your solution.
 
+% MOCK VS PRODUCTION CODE GUIDANCE:
+    1. IDENTIFY THE TEST FILE: The 'program' file may be a TEST FILE that uses mocks (MagicMock, unittest.mock, patch) to simulate external dependencies.
+       - Look for imports: `from unittest.mock import MagicMock, patch`
+       - Look for mock setup patterns: `mock_obj.return_value`, `mock_obj.__getitem__.return_value`
+
+    2. WHEN ERRORS OCCUR IN MOCK INTERACTIONS:
+       - FIRST check if the mock setup is incorrect (wrong return_value structure, missing __getitem__ configuration)
+       - Mock return types must match the REAL API return types exactly
+       - Common mock bugs:
+         * `__getitem__.return_value = [item]` when it should be `= item` (for APIs where indexing returns single item)
+         * Missing chained mock configuration (e.g., `mock.method().other_method()`)
+
+    3. PRESERVE PRODUCTION CODE API USAGE:
+       - The 'code_module' implements PRODUCTION code that calls real APIs
+       - Assume production code uses CORRECT API patterns unless you have documentation proving otherwise
+       - Do NOT change production code indexing patterns (like `[0][0]`) without external API documentation
+
+    4. DIAGNOSIS PRIORITY for "AttributeError" or type mismatch:
+       a. First: Check mock.return_value / mock.__getitem__.return_value structure
+       b. Second: Check if mock chaining matches expected API call pattern
+       c. Third: Only then consider if production code has wrong API usage
+
 % Follow these steps to fix the program or code_module:
     Step 1. Analyze and understand each identified issue in the context of the code_module and program.
     Step 2. Analyze how the program uses the code_module to determine all functions that must be preserved.

pdd/prompts/generate_test_LLM.prompt

@@ -4,7 +4,15 @@
 
 % Here is the code under test: <code_under_test>{code}</code_under_test>
 
+% File path information:
+ - The code under test module file is located at: <code_under_test_file_path>{source_file_path}</code_under_test_file_path>
+ - The example file will be saved at: <test_file_path>{test_file_path}</test_file_path>
+ - The module name (without extension) is: <module_name>{module_name}</module_name>
+
 % Follow these rules:
+    - CRITICAL: You MUST analyze the actual code provided in code_under_test and generate tests for the EXACT functions defined in that code
+    - CRITICAL: Import statements must use the ACTUAL module name from the code file path, not generic names. Include the necessary code/path info to import the code under test.
+    - CRITICAL: Test the ACTUAL function names, parameters, and behavior shown in the provided code
     - The module name for the code under test will have the same name as the function name
     - The unit test should be in {language}. If Python, use pytest.
     - Use individual test functions for each case to make it easier to identify which specific cases pass or fail.
@@ -17,10 +25,17 @@
 <include>./context/test.prompt</include>
 
 <instructions>
-    1. Carefully read the prompt that generated the code under test and determine what might be possible edge cases.
-    2. For each edge case explain whether it is better to do the test using Z3 formal verification or unit tests.
-    3. Develop a detailed test plan that will ensure the code under test is correct. This should involve both Z3 formal verification and unit tests.
-    4. Now write the test file. 
-        a) The first part of the test file should be the detailed test plan from step 3 above in comments. 
-        b) Then write the tests and Z3 formal verification tests that are runnable as unit tests.
+    1. FIRST: Carefully analyze the ACTUAL code provided in code_under_test:
+        - Identify the EXACT function names defined in the code
+        - Identify the EXACT parameters and their types
+        - Identify the EXACT return values and behavior
+        - Identify any error conditions or edge cases
+    2. SECOND: Analyze the prompt that generated the code to understand the intended functionality and edge cases.
+    3. THIRD: For each edge case explain whether it is better to do the test using Z3 formal verification or unit tests.
+    4. FOURTH: Develop a detailed test plan that will ensure the code under test is correct. This should involve both Z3 formal verification and unit tests.
+    5. FIFTH: Write the test file with:
+        a) The first part of the test file should be the detailed test plan from step 4 above in comments. 
+        b) Import statements using the ACTUAL module name from the code file path (e.g., if code is in "my_function.py", use "from my_function import function_name")
+        c) Tests for the ACTUAL function names and behavior shown in the provided code
+        d) Z3 formal verification tests that are runnable as unit tests.
 </instructions>

pdd/prompts/increase_tests_LLM.prompt

@@ -12,5 +12,4 @@ Here is the coverage report: ```{coverage_report}```
     - The module name for the code under test will have the same name as the function name
     - The unit test should be in {language}. If Python, use pytest.
     - Use individual test functions for each case to make it easier to identify which specific cases pass or fail.
-    - Use the description of the functionality in the prompt to generate tests with useful tests with good code coverage.
-<include>./context/test.prompt</include>
+    - Use the description of the functionality in the prompt to generate tests with useful tests with good code coverage.