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

pdd/prompts/example_generator_LLM.prompt

@@ -4,7 +4,28 @@
 
 % The language of the example should be in: <language_for_example>{language}</language_for_example>
 
+% File path information:
+ - The code module file is located at: <code_module_file_path>{source_file_path}</code_module_file_path>
+ - The example file will be saved at: <example_file_path>{example_file_path}</example_file_path>
+ - The module name (without extension) is: <module_name>{module_name}</module_name>
+
+% IMPORT INSTRUCTIONS: Use the appropriate import mechanism for the target language
+ - CRITICAL: Use the exact module_name provided in the file path information above - DO NOT use generic names like "greetings" or "module"
+ - Avoid package-style imports unless the file is actually in a package structure
+ - Import the specific functions/classes that are defined in the code module
+ - CRITICAL: Do not assume module names - use the exact module_name provided
+ - CRITICAL: Import the appropriate functions/classes from the module (e.g., if module_name is "simple_math", import "add", "subtract", etc.)
+ - CRITICAL: Never include hardcoded absolute paths like "/Users/username/project/examples/" in comments or code
+    - Use only relative path descriptions in comments (e.g., "relative to project root" or "relative to this script")
+    - Make the example portable across different development environments
+    - Use dynamic path resolution with os.path.dirname(__file__) and relative path construction
+    - In comments, describe file structure using relative terms, not absolute paths
+ - CRITICAL: The 'extracted_code' field must preserve all newlines using proper JSON escaping (\\n). The output must be valid JSON where multi-line code is represented with \\n escape sequences for each line break.
+
 % Make sure the following happens:
     - Document in detail what the input and output parameters in the doc strings
-    - Someone needs to be able to fully understand how to use the module from the example.
+    - Someone needs to be able to fully understand how to use the module from the example.        
+    - Use correct import statements based on the actual file structure
+    - The example should be a complete, runnable script that imports from the actual module
+    - Include proper file path handling and module discovery if needed
 <include>./context/example.prompt</include>

pdd/prompts/extract_code_LLM.prompt

@@ -19,4 +19,8 @@
 % Output a JSON object with the following keys:
     - 'focus': String containing the focus of the generation.
     - 'explanation': String explanation of why this block_type was the focus of the generation and explain any errors detected in the code, if a code type of block.
-    - 'extracted_code': String containing the entire generated and corrected block_type of focus.
+    - 'extracted_code': String containing the entire generated and corrected block_type of focus.
+
+% CRITICAL: The 'extracted_code' field MUST preserve all newlines and indentation from the original code. In JSON, newlines must be represented as the escape sequence \n (backslash-n). Each line break in the code must appear as \n in the JSON string value. Do NOT concatenate lines together or remove line breaks. The extracted code must be properly formatted and runnable.
+
+% IMPORTANT: Output ONLY the JSON object. Do not add any trailing whitespace or newlines after the closing brace.

pdd/prompts/extract_program_code_fix_LLM.prompt

@@ -20,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

@@ -2,11 +2,21 @@
 
 % 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 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 program that is running the code_module that crashed and/or has errors: <program>{program}</program>
+% The program file is located at: {program_path}
+% The code module is located at: {code_path}
+
+% IMPORTANT for path-related errors: When fixing path calculations (e.g., os.path.dirname,
+% sys.path manipulation), consider the file's actual location relative to the project root.
+% For example, if the program is at "context/backend/example.py", it needs to traverse UP
+% two directories to reach the project root, not one.
+
+% 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>
 

pdd/prompts/fix_errors_from_unit_tests_LLM.prompt

@@ -10,6 +10,14 @@
 
 % If the verfication program fails to run, the code_under_test and unit_test are unchanged from the previous iteration.
 
+% 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
+
+
 
 <instructions>
 % Follow these steps to solve these errors:
@@ -20,4 +28,5 @@
     Step 5. Explain in detail step by step how to solve each of the errors and warnings. For each error and warning, there should be several paragraphs description of the solution steps. Sometimes logging or print statements can help debug the code in subsequent iterations. It is important to make sure the tests are still sufficiently comprehensive to catch potential errors.
     Step 6. Review the above steps and correct for any errors and warnings in the code under test or unit test.
     Step 7. For the code that need changes, write the corrected code_under_test and/or corrected unit_test in its/their entirety.
+    Step 8. CRITICAL: You MUST preserve ALL existing test functions from the original unit_test. Only modify the tests that are failing. Do not remove, skip, or omit any test functions that were present in the original unit_test, even if they seem unrelated to the current errors. The output must include every single test function from the input.
 </instructions>

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,25 @@
 
 % 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>
+
+% EXISTING TESTS (if provided - your output will be APPENDED to this file):
+<existing_tests>{existing_tests}</existing_tests>
+
+% If existing tests are provided above:
+    - Generate ONLY NEW test functions (your output will be appended to the existing file)
+    - Do NOT include import statements (they already exist in the file)
+    - Do NOT duplicate any existing test function names
+    - Maintain consistent style with existing tests (fixtures, naming conventions)
+    - Focus on testing functionality NOT already covered by existing tests
+
 % 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.
@@ -14,13 +32,29 @@
     - Setup and teardown methods should only use public APIs and environment variables, never reset internal module state directly.
     - Design tests to be independent of implementation details that might change when code is regenerated.
     - For test isolation, use fixtures and mocking of external dependencies rather than manipulating internal module state. In general minimize the amount of mocking needed so that the tests are more robust to changes in the code under test and more code is tested.
-<include>./context/test.prompt</include>
+
+% TEST ISOLATION PRINCIPLE:
+% CRITICAL: Each test MUST be isolated and not pollute state for other tests.
+    - Tests must clean up any state they modify (environment variables, global state, files, mocks)
+    - Use the testing framework's built-in isolation mechanisms (fixtures, setup/teardown, context managers)
+    - Avoid modifying global or module-level state directly; if unavoidable, always restore original state
+    - Prefer function-scoped test resources over shared/module-scoped ones to ensure isolation
+
+<include>context/test.prompt</include>
+<include>context/pytest_isolation_example.py</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/generate_test_from_example_LLM.prompt

@@ -0,0 +1,115 @@
+% You are an expert Software Test Engineer. Your goal is to generate tests based on the intended behavior described in a prompt and demonstrated in an example file.
+
+% Here a description of what the code is supposed to do and was the prompt that generated the code: <prompt_that_generated_code>{prompt_that_generated_code}</prompt_that_generated_code>
+
+% Here is an example showing how the module should be used: <example_usage>{example}</example_usage>
+
+% File path information:
+ - The example file is located at: <example_file_path>{source_file_path}</example_file_path>
+ - The test 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>
+
+% EXISTING TESTS (if provided - your output will be APPENDED to this file):
+<existing_tests>{existing_tests}</existing_tests>
+
+% If existing tests are provided above:
+    - Generate ONLY NEW test functions (your output will be appended to the existing file)
+    - Do NOT include import statements (they already exist in the file)
+    - Do NOT duplicate any existing test function names
+    - Maintain consistent style with existing tests (fixtures, naming conventions)
+    - Focus on testing functionality NOT already covered by existing tests
+
+% Follow these rules:
+    - CRITICAL: Analyze the EXAMPLE to understand the API (function names, parameters, return values)
+    - CRITICAL: Import statements must match the module structure shown in the example
+    - CRITICAL: Test the intended function names and behavior based on the prompt
+    - 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.
+    - Focus on testing the INTENDED FUNCTIONALITY, not implementation details.
+    - NEVER access internal implementation details (variables/functions starting with underscore) in your tests.
+    - Setup and teardown methods should only use public APIs and environment variables, never reset internal module state directly.
+    - Design tests to be independent of implementation details.
+    - For test isolation, use fixtures and mocking of external dependencies rather than manipulating internal module state. In general minimize the amount of mocking needed so that the tests are more robust to changes in the code under test and more code is tested.
+    - Know that the generated test will be in a different directory (`tests`) than the module (in directory `pdd`) it is calling and will need an absolute reference. The module file name will be same as the function name.
+    - Created files should be in the `output` directory.
+    - Data files (language_format.csv and llm_model.csv) already exist in the PDD_PATH/`data` directory. Do not write over them. It already contains data for popular languages and LLM models and can be used for tests.
+    - The PDD_PATH environment variable is already set.
+
+% PYTEST TEST ISOLATION AND ANTI-POLLUTION RULES:
+% CRITICAL: Generated tests MUST be isolated and not pollute state for other tests. Follow these rules strictly:
+
+% 1. ENVIRONMENT VARIABLES:
+    - ALWAYS use monkeypatch.setenv() or monkeypatch.delenv() instead of os.environ["VAR"] = "value"
+    - NEVER use direct os.environ manipulation - it persists beyond the test and pollutes other tests
+    - BAD:  os.environ["API_KEY"] = "test_key"  # POLLUTION: persists after test ends
+    - GOOD: monkeypatch.setenv("API_KEY", "test_key")  # Auto-cleaned by pytest
+
+% 2. MOCKING EXTERNAL DEPENDENCIES:
+    - Use context managers or monkeypatch for mocks - they auto-cleanup after the test
+    - Prefer monkeypatch.setattr() over unittest.mock.patch() decorators at module level
+    - BAD:  @patch('module.func') at module/class level  # Can leak if exception occurs
+    - GOOD: monkeypatch.setattr('module.func', mock_func)  # Always cleaned up
+    - GOOD: with patch('module.func') as mock:  # Context manager ensures cleanup
+
+% 3. FIXTURE CLEANUP WITH YIELD:
+    - Use yield-based fixtures with cleanup code after yield for any resources
+    - Prefer function-scoped fixtures over module or session scope to ensure isolation
+    - BAD:  @pytest.fixture(scope="module") without cleanup  # State leaks between tests
+    - GOOD: @pytest.fixture with yield and cleanup after yield  # Always cleans up
+    - Example of proper fixture:
+        @pytest.fixture
+        def temp_resource():
+            resource = setup_resource()
+            yield resource
+            resource.cleanup()  # Always runs after test, even on failure
+
+% 4. SYS.MODULES MANIPULATION:
+    - AVOID manipulating sys.modules directly whenever possible
+    - If unavoidable, ALWAYS save and restore in try/finally or fixture with yield
+    - BAD:  sys.modules["module"] = mock_module  # Pollutes all subsequent tests
+    - GOOD: Use a fixture that saves, mocks, and restores:
+        @pytest.fixture
+        def mock_module():
+            saved = sys.modules.get("module")
+            sys.modules["module"] = MagicMock()
+            yield
+            if saved is not None:
+                sys.modules["module"] = saved
+            elif "module" in sys.modules:
+                del sys.modules["module"]
+
+% 5. FILE SYSTEM OPERATIONS:
+    - ALWAYS use the tmp_path fixture for creating temporary files and directories
+    - NEVER create files in the working directory or fixed paths
+    - BAD:  with open("test_output.txt", "w") as f: ...  # Leaves file behind
+    - GOOD: def test_file(tmp_path): (tmp_path / "test_output.txt").write_text(...)
+
+% 6. GLOBAL/MODULE STATE:
+    - Never modify global variables or module-level state directly in tests
+    - Use monkeypatch.setattr() for any module-level variables that need changing
+    - Reset any singleton instances using fixtures with proper teardown
+
+% SUMMARY OF GOOD PATTERNS:
+    - Use tmp_path fixture for file operations
+    - Use monkeypatch fixture for environment variables and attributes
+    - Use pytest.raises() as context manager for exception testing
+    - Prefer function-scoped fixtures over module or session scope
+    - Use yield in fixtures to ensure cleanup runs even on test failure
+
+
+<instructions>
+    1. FIRST: Carefully analyze the EXAMPLE to understand:
+        - How to import the module (exact import statements)
+        - What functions/classes are exposed
+        - How they are called (parameters, return values)
+    2. SECOND: Analyze the prompt that describes 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 intended functionality 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 matching the module structure from the example
+        c) Tests for the intended function names and behavior from the prompt
+        d) Z3 formal verification tests that are runnable as unit tests.
+</instructions>

pdd/prompts/increase_tests_LLM.prompt

@@ -12,8 +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.
-    - Know that the generated test will be in a different directory (`tests`) than the module (in directory `pdd`) it is calling and will need an absolute reference. The module file name will be same as the function name.
-    - Created files should be in the `output` directory.
-    - Data files (language_format.csv and llm_model.csv) already exist in the PDD_PATH/`data` directory. Do not write over them. It already contains data for popular languages and LLM models and can be used for tests.
-    - The PDD_PATH environment variable is already set.
+    - Use the description of the functionality in the prompt to generate tests with useful tests with good code coverage.