teddy-cli 0.1.17.dev1311__tar.gz → 0.1.17.dev1312__tar.gz

{teddy_cli-0.1.17.dev1311 → teddy_cli-0.1.17.dev1312}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: teddy-cli
-Version: 0.1.17.dev1311
+Version: 0.1.17.dev1312
 Summary: The local-first, test-driven agentic engineering harness. Because you should own the means of development.
 Author: Raphael Atteritano
 License: AGPL-3.0-only

{teddy_cli-0.1.17.dev1311 → teddy_cli-0.1.17.dev1312}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "teddy-cli"
-version = "0.1.17.dev1311"
+version = "0.1.17.dev1312"
 description = "The local-first, test-driven agentic engineering harness. Because you should own the means of development."
 readme = "README.md"
 keywords = [

{teddy_cli-0.1.17.dev1311 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/MRP.md

@@ -124,6 +124,12 @@ Write in grammatically complete sentences using active voice, standard articles,
 
 Prefer config-level bypasses (pyproject `per-file-ignores`, pre-commit `exclude`) for anything repeated or file-wide. Allow a narrowly-scoped inline `# type: ignore[code]` / `# noqa: CODE` WITH a reason comment for genuine one-offs. Bare `# noqa` / `# type: ignore` are forbidden. Prompt steps reference this policy by NAME, never by rule number.
 
+### Code and Naming Hygiene
+
+All code comments and file names must remain self-contained without fragile document citations:
+- **Code Comments:** Explain intent, invariants, edge cases, and rationale directly in the code. Never cite internal documentation filenames, section headers, or rule numbers.
+- **File and Test Naming:** Name files, functions, and tests after the domain concept, scenario, or behavior under test. Never include document names, rule numbers, or workflow step names in filenames.
+
 ### Technical Debt Triage
 
 Handle technical debt using this 3-tier policy:

{teddy_cli-0.1.17.dev1311 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/config/prompts/debugger.md

@@ -65,16 +65,16 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    4. EDIT your MRE script to import the replica instead of the production module.
    5. EXECUTE the MRE. If it passes, you have empirically proven the fix without touching production code.
    6. Always EDIT the Case File to record verification results. If it fails, update the Causal Model and restart investigation.
-7. **Systemic Audit:**
-   Analyze the verified root cause to identify its abstract category. Propose a generalized fix that prevents this entire class of bugs in the future. Use EXECUTE `git grep` to search the codebase for other instances of the category and audit components touched by the proposed fix. If the fix modifies a port, signature, or data contract with more than one consumer, partition the change into non-breaking steps: expand the interface, migrate consumers, then contract obsolete code.
+7. **Impact Audit:**
+   Analyze components touched by the proposed fix. Use EXECUTE `git grep` to search for direct upstream callers and downstream consumers that the change affects. If the fix modifies a shared port, signature, or data contract with multiple consumers, document the required migration path so the Developer can partition the change into non-breaking steps.
 8. **Case File Synchronization:**
-   EDIT the Case File following conventions in `docs/project/PROJECT.md` to update the Diagnostic Analysis with systemic audit findings, ensure the Causal Model reflects verified reality from sandbox verification, and populate the Solution section with the proven fix and preventative measures. Set status to Resolved.
+   EDIT the Case File to update Diagnostic Analysis, verify the Causal Model reflects sandbox reality, and record the proven fix along with affected components in the Solution section. Set status to Resolved.
 
 ### Alignment
 **Goal:** Present the complete diagnosis and proposed fix for explicit user approval.
 
 1. **Synthesis Presentation:**
-   Message the user explaining the root cause analysis, verified MRE evidence, systemic audit findings, and the proven solution from the Case File in clear prose.
+   Message the user explaining the root cause analysis, verified MRE evidence, affected components, and the proven solution from the Case File in clear prose.
 2. **Approval Gate:**
    Await explicit user approval before proceeding to the Conclusion phase. If changes or refinements are requested, adjust the Case File, then re-align.
 

{teddy_cli-0.1.17.dev1311 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/templates/case-file.md

@@ -31,4 +31,8 @@ Continuously log diagnostic attempts and findings in chronological order:
 2. Investigated whether [hypothesis] by [action/probe]; observed [outcome], which [conclusion].
 
 ## Solution
-Root cause summary, verified sandbox fix, and systemic preventative measures to eliminate this bug class globally.
+### Root Cause Analysis
+Summary of verified root cause and sandbox fix.
+
+### Affected Components
+Direct upstream callers, downstream dependencies, or shared contracts affected by the fix.

{teddy_cli-0.1.17.dev1311 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/templates/makefile.md

@@ -78,7 +78,7 @@ EOF
 **Requirements:**
 - The output file MUST be written to `spikes/debug/probe_output.txt` — this path is uploaded as an artifact by the CI workflow.
 - The CI workflow running the probe must use a single job with no build matrix. This prevents multiple jobs from overwriting the uploaded artifact (`probe-result`).
-- The script must remain minimal and self-contained, using a single heredoc. See the Debugger's rule 11 (Remote Probing Protocol) for full protocol details.
+- The script must remain minimal and self-contained, using a single heredoc.
 
 ## Cross-Platform Design