teddy-cli 0.1.17.dev1327__tar.gz → 0.1.17.dev1328__tar.gz

{teddy_cli-0.1.17.dev1327 → teddy_cli-0.1.17.dev1328}/PKG-INFO

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

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

@@ -118,7 +118,7 @@ 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. Use only standard industry terms instead of invented jargon and metaphors.
+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 standard industry terms instead of idiosyncratic jargon and metaphors.
 
 ### Quality-Gate Bypass Policy
 
@@ -126,7 +126,7 @@ Prefer config-level bypasses (pyproject `per-file-ignores`, pre-commit `exclude`
 
 ### Code and Naming Hygiene
 
-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.
+Write semantic, self-documenting code where naming and structure make what the code does immediately obvious. Reserve comments exclusively for why (business rationale, non-obvious invariants, constraints, or algorithmic trade-offs); never repeat what code already states. Write comments as full, natural sentences without artificial line-breaking or column wrapping. When editing existing code, update or improve confusing comments rather than leaving stale text. Never cite internal documentation filenames, section headers, rule numbers, or workflow steps in code comments, action descriptions, or turn titles. Name files, functions, and tests after the domain concept, scenario, or behavior under test.
 
 ## Response Format
 

{teddy_cli-0.1.17.dev1327 → teddy_cli-0.1.17.dev1328}/src/teddy_executor/resources/config/prompts/architect.md

@@ -56,4 +56,4 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 2. **Commit and Push:**
    Execute `make commit`. If a remote is configured, run `make push`.
 3. **Handoff:**
-   Message the user with an overview of the drafted milestone slices and their dependency order. Provide the command to start the next session for the foundational slice. If independent slices can run in parallel, provide commands for each slice. When providing multiple commands for parallel execution, instruct the user to run each session in a separate workspace (such as a git worktree) to prevent conflicts. Route to the Prototyper if the target slice contains unresolved Key Unknowns; otherwise route directly to the Developer.
+   Message the user with an overview of the drafted milestone slices and their dependency order. Provide the command to start the next session for the foundational slice. If independent slices can run in parallel, provide commands for each slice. When providing multiple commands for parallel execution, instruct the user to run each session in a separate workspace. Route to the Prototyper if the target slice contains unresolved Key Unknowns; otherwise route directly to the Developer.

{teddy_cli-0.1.17.dev1327 → teddy_cli-0.1.17.dev1328}/src/teddy_executor/resources/config/prompts/debugger.md

@@ -58,13 +58,15 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 
    Repeat until all discrepancies are resolved.
 6. **Isolated Sandbox Verification:**
-   You are strictly forbidden from modifying `src/` or `tests/` to test your fix. Once you have a high-confidence hypothesis, prove it using a Sandbox Replica:
+   You are strictly forbidden from modifying `src/` or `tests/` to test hypotheses. Once you have a high-confidence hypothesis, prove it using a Sandbox Replica:
    1. CREATE a replica of the faulty source file at `spikes/debug/{scope-slug}/replica_{filename}.ext`.
    2. Adjust relative imports inside the replica to resolve unaltered dependencies from `src/`.
    3. Apply your proposed fix to the replica.
    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.
+
+   Direct Resolution vs. Handoff: If the proven fix is a small self-contained change, apply the fix to `src/`, add or update a permanent regression test in `tests/`, and verify via `make test`. A small change is strictly qualified as: touching at most one production file and its matching test file, introducing no new architectural boundaries or shared contracts, and keeping `make test` green. If a change exceeds this scope or breaks unrelated tests, halt direct execution immediately.
 7. **Impact Audit:**
    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:**

{teddy_cli-0.1.17.dev1327 → teddy_cli-0.1.17.dev1328}/src/teddy_executor/resources/config/prompts/developer.md

@@ -17,13 +17,11 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 2. **Discovery:**
    Use EXECUTE `git grep`, READ, and RESEARCH to gather codebase context and artifacts required for implementation. Search the codebase and test suite for existing implementations or coverage of your task to prevent logic and test duplication. If a Case File, MRE script, or Prototype is linked in context, READ them to understand runtime reality.
 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 no slice exists, CREATE one following conventions in `docs/project/PROJECT.md` informed by discovery findings, linking any reference files, placing Wiring first as the tracer bullet, and run `make commit` to version control the new plan.
 
-   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:**
-   Identify the next uncompleted deliverable in the vertical slice. Immediately EDIT the vertical slice to mark this single focused deliverable as in progress using `[▶]`. Batching deliverables into one cycle execution is strictly forbidden.
+   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. If the audit required structural plan changes, run `make commit` to record them before starting work.
+4. **Activate Slice & Mark Deliverable:**
+   Set slice Status to In Progress. Identify the next uncompleted deliverable in the vertical slice and mark it in progress using `[▶]`. Do not commit this status change separately; commit it alongside the deliverable in the Delivery phase. Batching deliverables into one cycle execution is strictly forbidden.
 
 ### Implementation
 **Goal:** Satisfy the current deliverable requirements via Just-In-Time implementation without overbuilding.
@@ -65,8 +63,12 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
      if your new tests render existing tests obsolete, delete the redundant tests.
    - **DI Purity:**
      make sure that no concrete defaults exist in new code. Service Locator and `mock.patch` are forbidden.
+   - **Apply KISS:**
+     simplify logic by removing redundant steps, intermediate variables, or consolidating convoluted branches without altering behavior.
+   - **Apply SRP:**
+     ensure each class, function, and module has exactly one reason to change. Extract distinct responsibilities into cohesive helpers.
    - **Clean Code:**
-     apply SRP locally to simplify logic, improve readability, and remove stale comments.
+     simplify logic, improve readability, and update or improve confusing comments rather than leaving stale text.
    - **Structural Refactoring:**
      if refactoring requires cross-cutting or structural changes outside the slice scope, record it in the roadmap in `docs/project/PROJECT.md` rather than attempting out-of-scope rewrites.
 4. **Loop Exit:**
@@ -121,6 +123,8 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
      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).
+   - **Test Suite Hygiene & Shared Harness Audit:**
+     audit test suites for redundant test coverage. Consolidate tests that assert identical execution paths with no variation in invariant coverage. Delete obsolete unit tests superseded by broader regression suites. Verify tests consistently use shared test harness fixtures (drivers, observers, fakes) instead of ad-hoc mocks or duplicated setup logic; extract repeated test infrastructure into the shared harness.
    - **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:**
@@ -136,8 +140,9 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    If a remote is configured, run `make push`. If remote CI is configured, run `make ci-watch` to monitor and inspect remote CI results. If blocking test failures occur, fix them immediately, commit, and push again. For non-blocking quality gate issues, address them if contained or record them in the roadmap in `docs/project/PROJECT.md`.
 2. **User Verification & Handoff:**
    Message the user with concise step-by-step instructions extracted from the slice `Verification` section so the user can test the delivered capability.
+   State the current branch, commit hash, and remote CI outcome, noting when a pull request must be opened.
    Include dynamic routing instructions for the next session based on project state:
-   - **Next Slice Ready:** Route to the Developer for the next slice whose dependencies are met. If multiple independent slices are ready for parallel execution, provide start commands for each and instruct the user to run them in separate workspaces (such as git worktrees).
+   - **Next Slice Ready:** Route to the Developer for the next slice whose dependencies are met. If multiple independent slices are ready for parallel execution, provide start commands for each and instruct the user to run them in separate workspaces.
    - **Unresolved Unknowns:** Route to the Prototyper if the next slice contains unresolved Key Unknowns.
    - **Milestone Complete:** Route to the Architect if the milestone is complete and planned milestones remain in the Roadmap. The Architect will perform the health check, initialize the next milestone, and draft its slices.
    - **Roadmap Complete:** Route to the Pathfinder only if all roadmap milestones are complete and the product requires new strategic direction.

{teddy_cli-0.1.17.dev1327 → teddy_cli-0.1.17.dev1328}/src/teddy_executor/resources/config/prompts/pathfinder.md

@@ -31,8 +31,8 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 
 1. **Routing Decision:**
    Analyze discovery findings to classify the request into one execution track: Non-Behavioral, Milestone Feature, Standalone Behavioral, or Bug Report.
-2. **Non-Behavioral Direct Execution:**
-   If the deliverable is purely non-behavioral (documentation, configs, static type annotations, renames, dead code deletion, or simple non-behavioral code changes), execute it directly in this phase yourself.
+2. **Direct Execution:**
+   If the deliverable is non-behavioral (documentation, configs, static typing, cleanup), or a small self-contained change, execute it directly in this phase. A small change is strictly qualified as: touching at most one production file and its matching test file, introducing no new architectural boundaries or shared contracts, and keeping `make test` green. If a change exceeds this scope or breaks unrelated tests, halt direct execution immediately.
 3. **Milestone & Specification:**
    For systemic or milestone features, update the Roadmap in `docs/project/PROJECT.md` and route to the Architect. If establishing permanent system invariants, CREATE or EDIT the specification document in `docs/project/specs/`. The Architect will initialize the milestone document and draft all slices.
 4. **Ad-hoc Slice Generation:**

{teddy_cli-0.1.17.dev1327 → teddy_cli-0.1.17.dev1328}/src/teddy_executor/resources/templates/ci.md

@@ -39,7 +39,7 @@ name: CI
 
 on:
   push:
-    branches: [ main ]
+    branches: [ "**" ]
   pull_request:
     branches: [ main ]
   workflow_dispatch: {}

{teddy_cli-0.1.17.dev1327 → teddy_cli-0.1.17.dev1328}/src/teddy_executor/resources/templates/vertical-slice.md

@@ -7,9 +7,14 @@
 - **Component Docs:** [links]
 - **Scope Slug:** `feature-slug`  <!-- 1-2 kebab-case words only. -->
 
-## Business Goal
+## Goal
 1-2 sentences describing the user need and measurable value delivered by this slice.
 
+## Context
+Key findings, existing contracts, and technical constraints discovered through static code reading or library documentation.
+- `ComponentName`: Description of existing contracts, internal interfaces, or invariants.
+- `LibraryName`: Description of external dependency behavior, configuration, or API signatures.
+
 ## Scenarios
 Primary user journeys and happy paths. These drive End-to-End Acceptance Tests in the Wiring deliverable.
 
@@ -32,7 +37,7 @@ Boundary conditions, errors, and validation edge cases. These drive granular Uni
 
 **Taxonomy:**
 - `[Domain]` = Ambiguities in business rules, policy decisions, domain definitions, or scope boundaries. Resolve by asking the user directly.
-- `[Technical]` = External dependencies, third-party libraries, APIs, internal state machines, complex algorithms, concurrency, performance, or data storage. Resolve via works-like prototypes.
+- `[Technical]` = External dependencies, third-party libraries, APIs, internal state machines, complex algorithms, concurrency, performance, or data storage. Resolve via works-like prototypes. Do not log items that can be verified through static code reading or library documentation; resolve and record those under Context instead.
 - `[Functional]` = User-facing ergonomics, CLI flags, terminal rendering, interactive flows, or layout aesthetics. Resolve via looks-like prototypes.
 
 **Mandatory De-risking Triggers (must include, but are not limited to):**
@@ -80,10 +85,10 @@ Free-form notes recording decisions, deviations, or discoveries during implement
 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:**
-    Run `command <args>`.
-    Verify output contains `expected output`.
-- [ ] **Title:**
-    Navigate to `[View/Screen]`.
-    Trigger `[Action]`.
-    Confirm `[Observed State/Element]`.
+1. **Title:**
+   Run `command <args>`.
+   Verify output contains `expected output`.
+2. **Title:**
+   Navigate to `[View/Screen]`.
+   Trigger `[Action]`.
+   Confirm `[Observed State/Element]`.