teddy-cli 0.1.17.dev1315__tar.gz → 0.1.17.dev1316__tar.gz

{teddy_cli-0.1.17.dev1315 → teddy_cli-0.1.17.dev1316}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: teddy-cli
-Version: 0.1.17.dev1315
+Version: 0.1.17.dev1316
 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.dev1315 → teddy_cli-0.1.17.dev1316}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "teddy-cli"
-version = "0.1.17.dev1315"
+version = "0.1.17.dev1316"
 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.dev1315 → teddy_cli-0.1.17.dev1316}/src/teddy_executor/resources/MRP.md

@@ -24,7 +24,7 @@ Halt work immediately. Message the User to explain the block situation, describe
 
 ### State Dashboard
 
-Maintain orientation via the State Dashboard placed at the end of the `Rationale` block. You MUST preserve all items in the `NOTES` section across all turns. You can update their status or consolidate related items, but you must not delete unresolved entries. The `PROGRESS` list MUST mirror the phases defined in your agent workflow, using `[✓]` for a completed phase, `[▶]` for the current phase, and `[ ]` for a phase not yet started.
+Maintain orientation via the State Dashboard placed at the end of the `Rationale` block. You MUST preserve all items in the `NOTES` section across all turns. You can update their status or consolidate related items, but you must not delete unresolved entries. Any unresolved `[DEBT]` items must be addressed or escalated before session conclusion. The `PROGRESS` list MUST mirror the phases defined in your agent workflow, using `[✓]` for a completed phase, `[▶]` for the current phase, and `[ ]` for a phase not yet started.
 
 ``````
 Goal: [The objective of the current task/session]
@@ -128,14 +128,6 @@ Prefer config-level bypasses (pyproject `per-file-ignores`, pre-commit `exclude`
 
 All code comments and file names must remain self-contained without fragile document citations. Explain intent, invariants, edge cases, and rationale directly in the code. Never cite internal documentation filenames, section headers, or rule numbers. 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:
-
-1. Micro or quick-wins: Fix directly in-flight.
-2. Slice-scoped refactoring: Append an atomic Refactor or Cleanup deliverable to the active Vertical Slice.
-3. Structural or cross-cutting: Plan it into the roadmap in `docs/project/PROJECT.md` (and add to the active milestone in `docs/project/milestones/` if needed), then Message the user to approve before committing.
-
 ## Response Format
 
 Your entire response is parsed into an AST and must strictly adhere to the formatting rules below. Any deviation will cause a validation failure.

{teddy_cli-0.1.17.dev1315 → teddy_cli-0.1.17.dev1316}/src/teddy_executor/resources/config/prompts/assistant.md

@@ -14,7 +14,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 1. **Make Minimal Verifiable Progress:**
    Use EDIT, CREATE, or EXECUTE to make progress on the current task. You can batch multiple tightly-related modifications together, but prioritize incremental steps rather than implementing everything before verification.
 2. **Verify:**
-   After each round of progress, verify correctness immediately. Use EXECUTE `git grep` to check upstream consumers and downstream dependencies. EXECUTE `make test` to confirm no regressions.
+   After each round of progress, verify correctness immediately. Use EXECUTE `git grep` to audit upstream callers (including test files and harness fixtures for breaking changes) and downstream dependencies (for orphaned code, unused parameters, or dead functions). EXECUTE `make test` to confirm no regressions.
 3. **Iterate:**
    Assess whether the current task is complete. If more work is needed, return to Make Minimal Verifiable Progress. If the task is complete, advance to the Alignment phase.
 

{teddy_cli-0.1.17.dev1315 → teddy_cli-0.1.17.dev1316}/src/teddy_executor/resources/config/prompts/debugger.md

@@ -66,7 +66,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    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. **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.
+   Analyze components touched by the proposed fix. Use EXECUTE `git grep` to search for direct upstream callers (including test files and harness fixtures) and downstream dependencies (for orphaned code, unused parameters, or dead functions) 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 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.
 

{teddy_cli-0.1.17.dev1315 → teddy_cli-0.1.17.dev1316}/src/teddy_executor/resources/config/prompts/developer.md

@@ -97,8 +97,8 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    EDIT the vertical slice to record implementation details and reasoning under the Implementation Notes section. If this section does not exist, CREATE it at the end of the file.
 3. **Perform As-Built Update:**
    Before finishing the last deliverable of the slice, perform a final EDIT on the Component Design Docs. Use the Implementation Notes to make minor corrections to reflect as-built reality, and update their status.
-4. **Consistency Check:**
-   If this is the last deliverable, EXECUTE `git grep` for deleted or renamed components and resolve stale hits in documentation and comments.
+4. **Stale Reference Check:**
+   If this is the last deliverable, EXECUTE `git grep` for deleted or renamed components and resolve stale references in documentation and comments.
 5. **Delivery Gate:**
    Upon completing all documentation steps, proceed immediately to the Delivery phase. You are strictly forbidden from beginning orientation for the next deliverable until the current one is committed.
 
@@ -119,6 +119,8 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    Proactively audit the codebase for hygiene and refactoring opportunities:
    - **Production Double Audit:**
      verify that NO skeleton responses, hardcoded mock values, or temporary stubs remain in `src/`. All outputs must derive from production logic.
+   - **Upstream & Downstream Audit:**
+     run EXECUTE `git grep` to audit upstream callers (verifying all callers, test files, and harness fixtures use updated contracts) and downstream dependencies (pruning orphaned helper methods, unused parameters, or dead functions).
    - **Immediate or slice-scoped:**
      append Refactor or Cleanup deliverables to the active Vertical Slice and execute them through the delivery cycle before completing the slice.
    - **Systemic or out-of-scope:**

{teddy_cli-0.1.17.dev1315 → teddy_cli-0.1.17.dev1316}/src/teddy_executor/resources/templates/specification-document.md

@@ -1,7 +1,7 @@
-# Spec: {{Descriptive Title of Invariant}}
+# Spec: {{Specification Name}}
 
 ## Overview
-Context for the permanent system invariant, the contract it establishes, and the architectural risk it mitigates.
+Context for this specification: the system contract, format, protocol, or architectural invariant it establishes and why.
 
 ## Guiding Principles
 Foundational rules and philosophical constraints governing this specification.