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

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

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

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

@@ -118,12 +118,18 @@ Applies to all user-facing Messages and turn titles:
 ### Pragmatic Simplified Technical English
 
 All text in Rationale, Message, action descriptions, and documentation must adhere to Pragmatic STE:
-Write in grammatically complete sentences using active voice, standard articles, and no semicolons, avoiding conversational fluff and clipped fragments. Limit procedural instructions to 20 words in the imperative mood with conditions placed before actions; limit descriptive statements to 25 words with one fact per sentence. Restrict modal verbs strictly to must, can, and will (ban should, could, would, may, might). Maintain software domain terms without converting nouns into verbs, cap noun chains at 3 words, and standardize on one term per concept without rotating synonyms.
+Write in grammatically complete sentences using active voice, standard articles, and no semicolons, avoiding conversational fluff and clipped fragments. Limit procedural instructions to 20 words in the imperative mood with conditions placed before actions. Limit descriptive statements to 25 words with one fact per sentence. Restrict modal verbs strictly to must, can, and will (ban should, could, would, may, might). Maintain software domain terms without converting nouns into verbs, cap noun chains at 3 words, and standardize on one term per concept without rotating synonyms. Use only standard industry terms instead of invented jargon and metaphors.
 
 ### Quality-Gate Bypass Policy
 
 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.dev1310 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/config/prompts/architect.md

@@ -38,7 +38,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    Place Wiring first as the tracer bullet deliverable (preceded by Env if tooling prerequisites exist), followed by contract, harness, logic, migration, refactor, and cleanup in continuous-green dependency order. For every key unknown, record a one-line Design Sensitivity stating how the design reacts to each resolution.
    EDIT the active milestone document in `docs/project/milestones/` to link all created slice documents under `## Slices` using unbolded markdown links.
 7. **Impact Audit:**
-   Run EXECUTE `git grep` on target components. If a component has more than one consumer, categorize it as a Shared Seam and partition the work into a non-breaking parallel change: expand, migrate, contract. Decompose any deliverable touching more than one consumer or layer into smaller atomic items. Resolve stale hits for deleted or renamed components in documentation. Verify that all seam changes have matching harness deliverables.
+   Run EXECUTE `git grep` on target components. If a component has more than one consumer, categorize it as a Shared Seam and partition the work into non-breaking steps: expand the interface, migrate consumers, then contract obsolete code. Decompose any deliverable touching more than one consumer or layer into smaller atomic items. Resolve stale hits for deleted or renamed components in documentation. Verify that all seam changes have matching harness deliverables.
 
 ### Alignment
 **Goal:** Present the design proposal and secure user alignment.

{teddy_cli-0.1.17.dev1310 → 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 a non-breaking parallel change: expand, migrate, contract.
+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.dev1310 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/config/prompts/developer.md

@@ -19,7 +19,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 3. **Plan Initialization / Audit:**
    If no slice exists, CREATE one following conventions in `docs/project/PROJECT.md` informed by discovery findings, linking any reference files and placing Wiring first as the tracer bullet.
 
-   If a slice already exists, audit target components via EXECUTE `git grep`. Verify that all deliverables maintain a Continuous Green State. If a deliverable attempts a breaking signature change to a Shared Seam (git grep count greater than 1) without a migration plan, immediately EDIT the slice to re-partition the work into a non-breaking parallel change (expand, migrate, contract). Decompose any item touching more than one logical change into smaller atomic deliverables. Verify Wiring is placed first.
+   If a slice already exists, audit target components via EXECUTE `git grep`. Verify that all deliverables keep all tests passing at every commit. If a deliverable attempts a breaking signature change to a Shared Seam (git grep count greater than 1) without a migration plan, immediately EDIT the slice to re-partition the work into non-breaking steps (expand -> migrate -> contract). Decompose any item touching more than one logical change into smaller atomic deliverables. Verify Wiring is placed first.
 
    Set slice Status to In Progress. If the slice was newly created or modified during audit, run `make commit` to version control the plan before starting work.
 4. **Mark Deliverable:**

{teddy_cli-0.1.17.dev1310 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/config/prompts/prototyper.md

@@ -36,7 +36,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 **Goal:** Translate verified findings into buildable slices, component designs, and specifications.
 
 1. **Impact and Debt Audit:**
-   Run EXECUTE `git grep` on target components. If a modified component has more than one consumer, treat it as a Shared Seam and structure deliverables as a non-breaking parallel change: expand, migrate, contract. Verify that all contract changes include matching harness deliverables.
+   Run EXECUTE `git grep` on target components. If a modified component has more than one consumer, treat it as a Shared Seam and structure deliverables as non-breaking steps: expand the interface, migrate consumers, then contract obsolete code. Verify that all contract changes include matching harness deliverables.
 2. **Artifact Updates:**
    EDIT the Vertical Slice to reflect validated scenarios, edge cases, implementation deliverables, and verification steps. Place Wiring first as the tracer bullet deliverable, followed by contract, logic, refactoring, and harness deliverables. Mark resolved unknowns as completed, link the prototype directory in the slice metadata, and set status to Planned. EDIT linked Component Design Docs and specs in `docs/project/specs/` to reflect as-tested contracts, parameters, and invariants discovered during prototyping.
 

{teddy_cli-0.1.17.dev1310 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/templates/ARCHITECTURE.md

@@ -7,7 +7,7 @@ This section defines foundational engineering practices. Each entry MUST be a sp
 **Template format:** `- **Rule Name:** Description and enforcement mechanism.`
 
 ### Recommended: customize per project
-- **Version Control:** Branch strategy and commit conventions. Every commit MUST leave the suite in a **Continuous Green State** — the full test suite passes before and after each change. Commit locally per deliverable; defer the push to the session Conclusion and report CI results back (blocking only on failures the push introduced).
+- **Version Control:** Branch strategy and commit conventions. Every commit MUST pass the full test suite before and after each change (`make test`). Commit locally per deliverable; defer the push to the session Conclusion and report CI results back (blocking only on failures the push introduced).
 - **Run Environment:** Designated runner (e.g., `uv run`, `poetry run`).
 - **Failure Transparency:** Error handling policy — specific exceptions only, no silent suppression.
 - **Testing Strategy:** Define test types (Unit, Integration, Acceptance), boundaries, and filesystem hygiene. Mandate **Test Double Integrity**. Ban global patching. Use in-memory fakes for state-managing outbound ports. Use strictly autospec-bound mocks only for external side-effects.

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

@@ -1,8 +1,8 @@
 # Bug: {{bug_title}}
 - **Status:** Unresolved
-- **Milestone:** [link or N/A]
-- **Vertical Slice:** [link or N/A]
-- **Specs:** [links or N/A]
+- **Milestone:** [link]
+- **Vertical Slice:** [link]
+- **Specs:** [links]
 
 ## Symptoms
 Expected vs. actual behavior and minimal reproduction steps.
@@ -22,7 +22,6 @@ Components, modules, or hypotheses definitively eliminated during investigation.
 Concise description of how the faulty system operates based strictly on verified observations.
 
 ### Discrepancies
-<!-- Check off items and append `(Resolved: <explanation>)` ONLY once verified. Do NOT add resolution before proof. -->
 - [ ] Discrepancy between expected and observed behavior.
 - [x] Discrepancy between expected and observed behavior (Resolved: explanation of root cause).
 
@@ -32,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.dev1310 → 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
 

{teddy_cli-0.1.17.dev1310 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/templates/milestone.md

@@ -12,6 +12,6 @@ The What: Strategic architecture, chosen design patterns, system boundaries, and
 The How: Actionable strategy, engineering invariants, architectural rules, and test harness considerations.
 
 ## Slices
-<!-- Decompose into end-to-end vertical slices cutting across all layers. -->
+Decompose requirements into end-to-end vertical slices cutting across all layers.
 - [ ] [MM-01-slice-slug](../slices/MM-01-slice-slug.md): Tackles Req X. Brief scope statements.
 - [ ] [MM-02-slice-slug](../slices/MM-02-slice-slug.md): Tackles Req Y and Z. Brief scope statements.

{teddy_cli-0.1.17.dev1310 → teddy_cli-0.1.17.dev1312}/src/teddy_executor/resources/templates/vertical-slice.md

@@ -1,7 +1,7 @@
 # Slice: {{feature_name}}
 - **Status:** [Planned | In Progress | Completed]
-- **Milestone:** [MM-name](../milestones/MM-name.md)
-- **Depends On:** [MM-01-slice-slug.md](./MM-01-slice-slug.md) <!-- Link prerequisite slice or 'None' -->
+- **Milestone:** [link]
+- **Depends On:** [link]
 - **Specs:** [links]
 - **Prototype:** [link]
 - **Component Docs:** [links]
@@ -11,7 +11,8 @@
 1-2 sentences describing the user need and measurable value delivered by this slice.
 
 ## Scenarios
-<!-- Primary user journeys and happy paths. These drive End-to-End Acceptance Tests in the Wiring deliverable. -->
+Primary user journeys and happy paths. These drive End-to-End Acceptance Tests in the Wiring deliverable.
+
 > As a [user type], I want to [action] so that [benefit].
 
 ```gherkin
@@ -21,7 +22,7 @@ Then [expected outcome]
 ```
 
 ## Edge Cases
-<!-- Boundary conditions, errors, and validation edge cases. These drive granular Unit Tests in Logic deliverables. -->
+Boundary conditions, errors, and validation edge cases. These drive granular Unit Tests in Logic deliverables.
 - **Title**: If [condition], then [behavior], because [reason/invariant].
 
 ## Key Unknowns
@@ -42,8 +43,7 @@ Then [expected outcome]
 **Design Sensitivity:** For every unknown, record a one-line Design Sensitivity stating how the design reacts to each resolution (e.g., "if this resolves as X → contracts hold; if Y → this port/DTO changes").
 
 ## Impact
-Surface of affected components using the Parallel Change (Expand-Migrate-Contract) model.
-Execute deliverables strictly in this order to maintain a Continuous Green State (`make test` passes at every commit). Never mutate shared contracts in place when existing consumers exist.
+Map affected components using non-breaking steps (expand -> migrate -> contract) to protect existing consumers.
 
 **Format:**
 1. `[NEW]` `ComponentOrModule` — Create new boundary or component.
@@ -63,9 +63,11 @@ Execute deliverables strictly in this order to maintain a Continuous Green State
 - **Refactor:** Improving code design without altering behavior (DRY, SRP, extracting helpers).
 - **Cleanup:** Removing deprecated methods, dead code, and temporary shims.
 
-**Order:** Order deliverables to maintain a Continuous Green State (`make test` passes at every commit). `(Env)` is placed first whenever tooling or environment setup is a prerequisite:
+**Order:** Order deliverables to keep all tests passing at every commit (`make test`). `(Env)` is placed first whenever tooling or environment setup is a prerequisite:
 `(Env) -> Wiring -> Contract -> Harness -> Logic -> Migration -> Refactor -> Cleanup`
 
+**Tests:** Do not specify individual tests in deliverables. Scenarios and Edge Cases must define test requirements.
+
 **Format:**
 - [ ] **Wiring** - Connect outermost boundaries with skeleton response.
 - [ ] **Contract** - Define port interfaces and DTOs.
@@ -75,9 +77,7 @@ Execute deliverables strictly in this order to maintain a Continuous Green State
 Free-form notes recording decisions, deviations, or discoveries during implementation.
 
 ## Verification
-<!-- Manual User Acceptance Testing (UAT) steps for the user to execute at slice conclusion. -->
-<!-- Provide clear, step-by-step instructions. Use copy-pasteable commands for CLI/APIs, or exact interactive steps for UI/visual flows. -->
-<!-- Do NOT include running automated tests here; those are covered by the automated test suite. -->
+Manual verification steps for user execution at slice conclusion. Provide clear instructions with copy-pasteable commands or interactive UI steps. Do not include automated test commands.
 
 **Format:**
 - [ ] **Title:**