From b4382132a4eac06b8f887461fd9c58fbabf9b6e0 Mon Sep 17 00:00:00 2001 From: Vic <125237471+vicsanity623@users.noreply.github.com> Date: Wed, 11 Mar 2026 08:22:15 -0700 Subject: [PATCH] Update prompts_and_memory.py --- src/pyob/prompts_and_memory.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pyob/prompts_and_memory.py b/src/pyob/prompts_and_memory.py index 1fdb267..a346599 100644 --- a/src/pyob/prompts_and_memory.py +++ b/src/pyob/prompts_and_memory.py @@ -17,7 +17,7 @@ def _ensure_prompt_files(self) -> None: templates = { "UM.md": "You are the PyOB Memory Manager. Your job is to update MEMORY.md.\n\n### Current Memory:\n{current_memory}\n\n### Recent Actions:\n{session_summary}\n\n### INSTRUCTIONS:\n1. Update the memory with the Recent Actions.\n2. TRANSACTIONAL RECORDING: Only record changes as 'Implemented' if the actions specifically state 'SUCCESSFUL CHANGE'. If you see 'CRITICAL: FAILED' or 'ROLLED BACK', record this as a 'Failed Attempt' with the reason, so the engine knows to try a different approach next time.\n3. BREVITY: Keep the ENTIRE document under 200 words. Be ruthless. Delete old, irrelevant details.\n4. FORMAT: Keep lists strictly to bullet points. No long paragraphs.\n5. Respond EXCLUSIVELY with the raw markdown for MEMORY.md. Do not use ```markdown fences or blocks.", "RM.md": "You are the PYOB Memory Manager. The current MEMORY.md is too bloated and is breaking the AI context window.\n\n### Bloated Memory:\n{current_memory}\n\n### INSTRUCTIONS:\n1. AGGRESSIVELY COMPRESS this memory. \n2. Delete duplicate information, repetitive logs, and obvious statements.\n3. Keep ONLY the core architectural rules and crucial file dependencies.\n4. The final output MUST BE UNDER 150 WORDS.\n5. Respond EXCLUSIVELY with the raw markdown. No fences, no thoughts.", - "PP.md": "You are an elite PYOB Software Engineer. Analyze the code for bugs or architectural gaps.\n\n{memory_section}{ruff_section}{mypy_section}{custom_issues_section}### Source Code:\n```{lang_tag}\n{content}\n```\n\n### CRITICAL RULES:\n1. **SURGICAL FIXES**: Every block must be exactly 2-5 lines.\n2. **NO HALLUCINATIONS**: Do not invent bugs. If the code is functional, state 'The code looks good.'\n3. **ARCHITECTURAL BLOAT**: If 'Code Quality Issues' flags bloat (>800 lines), your Evaluation MUST prioritize identifying which classes or methods can be moved to a new file to restore modularity.\n4. **MISSING IMPORTS**: If you use a new module/type, you MUST add an block to import it at the top.\n5. **INDENTATION IS SYNTAX**: Your blocks must have perfect, absolute indentation.\n6. **DEFEATING MYPY**: If fixing a `[union-attr]` error, use `assert variable is not None` or `# type: ignore`.\n7. **IMPORT PATHS (MANDATORY)**: Never use the prefix `src.` in any import statement. The root of the package is `pyob`. (Example: Use `from pyob.core_utils import ...`, NOT `from src.pyob.core_utils import ...`).\n8. **TYPE HINTS (CRITICAL)**: Never use the `|` operator with quoted class names (Forward References). Use `Any` for objects that create circular dependencies.\n9. **ATOMIC REFACTORING**: Do not move large blocks or classes to new files in a single turn. If refactoring is needed, propose it as a plan first.\n10. **SURGICAL MOVEMENT**: If moving logic, use a 3-step process: A) Add new file/imports. B) Update call sites. C) Remove old code in a subsequent turn.\n\n### HOW TO RESPOND (CHOOSE ONE):\n\n**SCENARIO A: Code has bugs/bloat and needs edits:**\n\nSummary: ...\nEvaluation: [Address bloat here if flagged]\nImports Required: ...\nAction: I will fix X by doing Y.\n\n\n\nExact lines to replace\n\n\nNew lines\n\n\n\n**SCENARIO B: Code is perfect. NO EDITS NEEDED:**\n\nSummary: ...\nEvaluation: ...\nAction: The code looks good. No fixes needed.\n", + "PP.md": "You are an elite PYOB Software Engineer. Analyze the code for bugs or architectural gaps.\n\n{memory_section}{ruff_section}{mypy_section}{custom_issues_section}### Source Code:\n```{lang_tag}\n{content}\n```\n\n### CRITICAL RULES:\n1. **ITERATION BUDGET**: \n - IF iteration < 5: Focus ONLY on bug fixes, linting, and minor performance tweaks. Do NOT create new files, move classes, or extract logic. \n - IF iteration >= 5: You may propose architectural refactors, file extractions, and logic movement.\n2. **SURGICAL FIXES**: Every block must be exactly 2-5 lines. Only provide ONE block per response.\n3. **NO HALLUCINATIONS**: Do not invent bugs. If the code is functional, state 'The code looks good.'\n4. **ARCHITECTURAL BLOAT**: Only flag bloat for future planning until iteration 5.\n5. **MISSING IMPORTS**: If you use a new module/type, you MUST add an block to import it at the top.\n6. **INDENTATION IS SYNTAX**: Your blocks must have perfect, absolute indentation.\n7. **DEFEATING MYPY**: If fixing a `[union-attr]` error, use `assert variable is not None` or `# type: ignore`.\n8. **IMPORT PATHS (MANDATORY)**: Never use the prefix `src.` in any import statement. The root of the package is `pyob`. (Example: Use `from pyob.core_utils import ...`, NOT `from src.pyob.core_utils import ...`).\n9. **TYPE HINTS (CRITICAL)**: Never use the `|` operator with quoted class names (Forward References). Use `Any` for objects that create circular dependencies.\n10. **ATOMIC REFACTORING**: If you are beyond iteration 5 and need to move logic, use a 3-step process: A) Add new file/imports. B) Update call sites. C) Remove old code in a subsequent turn.\n\n### HOW TO RESPOND (CHOOSE ONE):\n\n**SCENARIO A: Code has bugs/bloat and needs edits:**\n\nSummary: ...\nEvaluation: [Address bloat here if flagged]\nImports Required: ...\nAction: I will fix X by doing Y.\n\n\n\nExact lines to replace (2-5 lines max)\n\n\nNew lines\n\n\n\n**SCENARIO B: Code is perfect. NO EDITS NEEDED:**\n\nSummary: ...\nEvaluation: ...\nAction: The code looks good. No fixes needed.\n", "ALF.md": "You are an elite developer fixing syntax errors.\nThe file `{rel_path}` failed validation with these exact errors:\n{err_text}\n\n### Current Code:\n```\n{code}\n```\n\n### Instructions:\n1. Fix the syntax errors (like stray brackets, unexpected tokens, or indentation) using surgical XML edits.\n2. Respond EXCLUSIVELY with a block followed by ONE OR MORE blocks.\n3. Ensure your edits perfectly align with the surrounding brackets.", "FRE.md": "You are an elite PYOB developer fixing runtime crashes.\n{memory_section}The application crashed during a test run.\n\n### Crash Logs & Traceback:\n{logs}\n\nThe traceback indicates the error occurred in `{rel_path}`.\n\n### Current Code of `{rel_path}`:\n```python\n{code}\n```\n\n### Instructions:\n1. Identify the EXACT root cause of the crash.\n2. Fix the error using surgical XML edits.\n3. Respond EXCLUSIVELY with a block followed by ONE OR MORE blocks.\n\n### REQUIRED XML FORMAT:\n\nExplanation of root cause...\nImports Needed: [List new imports required or 'None']\n\n\n\nExact lines to replace\n\n\nNew replacement lines\n\n", "PF.md": "You are the PYOB Product Architect. Review the source code and suggest ONE highly useful, INTERACTIVE feature.\n\n{memory_section}### Source Code:\n```{lang_tag}\n{content}\n```\n\n### CRITICAL RULES:\n1. Suggest an INTERACTIVE feature (UI elements, buttons, menus).\n2. **ARCHITECTURAL SPLIT (MANDATORY)**: If the source code is over 800 lines, you ARE NOT ALLOWED to propose a new feature. You MUST propose an 'Architectural Split'. Identify a logical module (like a Mixin) to move to a NEW file.\n3. **SINGLE FILE LIMIT**: If you are proposing an Architectural Split, you are ONLY allowed to create ONE new file per iteration. Do not attempt to split multiple modules at once. Focus on the largest logical block first.\n4. **NEW FILE FORMAT**: If proposing a split, your block MUST use this format: [Full Code for New File]. Your must then explain how to update the original file to import this new module.\n5. MULTI-FILE ORCHESTRATION: Explicitly list filenames of other files that will need updates in your .\n6. The block MUST contain ONLY the new logic or the block.\n\n### REQUIRED XML FORMAT:\n\n...\n\n\n# New logic OR tag here\n",