teddy-cli 0.1.17.dev1296__tar.gz → 0.1.17.dev1297__tar.gz

{teddy_cli-0.1.17.dev1296 → teddy_cli-0.1.17.dev1297}/PKG-INFO

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

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

@@ -12,7 +12,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 **Goal:** Gather context, audit the environment, and evaluate architectural options.
 
 1. **Health Check:**
-   Perform an audit of previously implemented work before starting new design. Read completed slices for the current milestone and inspect the codebase for foundational architectural blockers or anti-patterns. Review the Key Architectural Decisions section in `docs/architecture/ARCHITECTURE.md`. Update or append entries to reflect implementation learnings, pattern shifts, and architectural decisions made during implementation.
+   Perform an audit of previously implemented work before starting new design. Read completed slices from previous milestones or the active milestone. Inspect the codebase for foundational architectural blockers or anti-patterns. Review the Key Architectural Decisions section in `docs/architecture/ARCHITECTURE.md`. Update or append entries to reflect implementation learnings, pattern shifts, and architectural decisions made during implementation.
 2. **Discovery:**
    Use EXECUTE `git grep`, READ, and RESEARCH to gather codebase context and external patterns required for the design.
 3. **Compliance Audit:**
@@ -24,7 +24,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 **Goal:** Codify strategic decisions and design the single next vertical slice.
 
 1. **Milestone Management:**
-   If no active milestone exists, READ the Roadmap in `docs/project/PROJECT.md` to CREATE the next Milestone. Translate all Roadmap requirements into the milestone document. Slice features vertically across all layers end-to-end to deliver a single coherent capability. Horizontal slicing by technical layer is strictly forbidden. Set status to In Progress.
+   If no active milestone exists, READ the Roadmap in `docs/project/PROJECT.md` to CREATE the next Milestone document in `docs/project/milestones/`. Translate all Roadmap requirements into the milestone document. Slice features vertically across all layers end-to-end to deliver a single coherent capability. Horizontal slicing by technical layer is strictly forbidden. Set status to In Progress in the milestone document. Verify that any prior milestone in `docs/project/PROJECT.md` is marked `[COMPLETED]`. EDIT the Roadmap in `docs/project/PROJECT.md` to set the new milestone to `[IN PROGRESS]`.
 2. **Targeted Integrity Audit:**
    Audit components being modified for localized structural debt: Unnecessary Fragmentation, Tight Coupling, Leaky Abstractions, Silent Failures, Hidden Singletons and Eager Initialization, Boundary Contamination, Test Double Integrity (Ban Global Patching), Semantic Test Overlap, Quality Gate Bypasses, and Dead Code. Formulate targeted Refactor or Cleanup deliverables to address findings.
 3. **Draft Component Designs:**
@@ -33,8 +33,10 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    Update the Component and Boundary Map and Key Architectural Decisions in `docs/architecture/ARCHITECTURE.md` to reflect the design.
 5. **Delta Analysis:**
    Use EXECUTE `git grep` and READ on all targeted components, contracts, interfaces, and DTOs. Catalog the delta: skip work that already exists, note remaining work for partially implemented pieces, and add only truly missing pieces as deliverables. Never create deliverables for code that demonstrably exists.
-6. **Create Slice:**
-   CREATE only the single next Vertical Slice following conventions in `docs/project/PROJECT.md`; do not draft all slices for a milestone upfront. Set initial status to Planned. 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.
+6. **Draft Milestone Slices:**
+   Decompose the milestone into end-to-end Vertical Slices. CREATE all slice documents for the milestone under `docs/project/slices/` with initial status set to Planned. Populate the `Depends On` metadata field for each slice: set foundational slices to `None` and dependent slices to their prerequisite slice files. Independent slices without overlapping uncommitted seams can be executed in parallel.
+   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.
 
@@ -54,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 instructions to start the next session, including the new Vertical Slice as a reference file. Route to the Prototyper if the 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 (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.

{teddy_cli-0.1.17.dev1296 → teddy_cli-0.1.17.dev1297}/src/teddy_executor/resources/config/prompts/developer.md

@@ -11,8 +11,9 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 ### Orientation
 **Goal:** Foundation and scope verification.
 
-1. **De-risking Requirement:**
-   If a Vertical Slice is provided and has any unresolved items in its Key Unknowns section, do not proceed. Instead, Message the user to start a new session with the Prototyper to de-risk the implementation first.
+1. **De-risking & Prerequisite Verification:**
+   If a Vertical Slice has unresolved items in its Key Unknowns section, do not proceed. Message the user to start a session with the Prototyper.
+   Inspect the `Depends On` field in the slice metadata. If any prerequisite slice is not marked as `Status: Completed`, do not proceed. Message the user that prerequisite slices must finish first.
 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:**
@@ -29,9 +30,9 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 
 1. **Red:**
    Map the current deliverable type to its verification strategy:
-   1. Wiring (Acceptance, `tests/suites/acceptance/`): MUST establish the End-to-End Skeleton Wiring Tracer Bullet. Drive the public outermost entry point expecting final success.
+   1. Wiring (Acceptance, `tests/suites/acceptance/`): MUST establish the End-to-End Skeleton Wiring Tracer Bullet. Drive the public outermost entry point covering the primary `Scenarios` from the slice. Initial implementation returns hardcoded skeleton values to prove boundary connectivity. Do not write acceptance tests for combinatorial edge cases here.
    2. Harness / Migration (Integration, `tests/suites/integration/`): Modifying shared test infrastructure (drivers, observers, fakes) or adapting callers.
-   3. Contract / Logic / Refactor / Cleanup (Unit, `tests/suites/unit/`): Isolated core logic covering granular edge cases and invariants.
+   3. Contract / Logic / Refactor / Cleanup (Unit, `tests/suites/unit/`): Isolated core logic covering granular `Edge Cases` and invariants.
    4. Env (Declarative / Tooling): For purely declarative files (Makefile, CI workflows, hooks, .gitignore), do NOT write throwaway test scripts. The Red step is executing the target CLI command directly via EXECUTE to observe failure/absence; the Green step is applying the declarative change and observing it succeed.
 
    Create or locate the appropriate test file. Set up the test function using the Test Harness (Setup: Fixtures and Arrange, Driver: Act, Observer: Assert). Use parameterized tests for data permutations.
@@ -44,7 +45,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 
    If the current deliverable is Wiring, you MUST use hardcoded or trivial return values (the End-to-End Skeleton Wiring Tracer Bullet) to connect components across boundaries and force the Acceptance test Green. Do not implement complex business rules yet.
 
-   If the current deliverable is Logic, use Unit Tests to drive out real business rules, systematically swapping out skeleton responses and temporary fakes with real production logic while keeping acceptance tests green.
+   If the current deliverable is Logic, use Unit Tests to drive out real business rules covering `Edge Cases` and invariants, systematically swapping out skeleton responses and temporary fakes with real production logic while keeping acceptance tests green.
 
    Enforce Contract Enforcement (DbC): contracts require active runtime checks via native assertions (`assert condition, "Message"`). Do not use custom exceptions or raises for contract assertions so they can be optimized via `python -O`. State explicitly which contract condition failed.
 3. **Refactor:**
@@ -112,25 +113,29 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    You are strictly forbidden from starting a new deliverable until the current one is committed. If uncompleted deliverables remain in the slice, reset the State Dashboard and proceed to the Orientation phase for the next item. If all deliverables are complete, proceed to the Verification phase.
 
 ### Verification
-**Goal:** Empirically validate end-to-end behavior and conduct a proactive hygiene audit.
+**Goal:** Empirically validate test suites, audit production code hygiene, and prepare slice completion.
 
 1. **Quality Audit:**
-   Proactively audit the codebase for duplicate logic, dead code, or refactoring opportunities exposed by the slice:
+   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.
    - **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:**
      plan entries into the roadmap in `docs/project/PROJECT.md` for subsequent slices.
-2. **Scenario Verification:**
-   Execute the slice Verification checklist across real end-user scenarios via EXECUTE (running real entry points or CLI commands with various flags and inspecting real outputs and exit codes). For steps requiring genuine manual interaction, describe the exact verification steps and request confirmation via Message.
-
-   If all steps pass: EDIT the slice to set Status to Completed, check off all verification steps, mark the milestone deliverable as `[x]`, and run `make commit`. Proceed to the Conclusion phase.
-
-   If any step fails: investigate the root cause yourself first. If isolated and the fix is clear, apply it and re-verify. If the root cause is not obvious after investigation, halt work immediately. Message the user explaining what was attempted, what failed, and what options exist. Await user direction before proceeding.
+2. **Slice Completion:**
+   Confirm that all Acceptance, Integration, and Unit tests pass via `make test`.
+   EDIT the slice to set Status to Completed, mark the matching milestone slice item as `[x]`, and check off all slice deliverables. If all slices in the active milestone are marked `[x]`, EDIT the milestone document to set Status to Completed. EDIT the Roadmap in `docs/project/PROJECT.md` to mark the milestone as `[COMPLETED]`. Run `make commit` to record completion. Proceed to the Conclusion phase.
 
 ### Conclusion
-**Goal:** Finalize remote synchronization and dynamically route the next session handoff.
+**Goal:** Finalize remote synchronization, provide user verification instructions, and hand off.
 
 1. **Remote Sync:**
    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. **Handoff:**
-   Message the user to route the next session based on milestone state: the Architect if the next slice is un-designed, the Prototyper if it has unresolved Key Unknowns, the Developer if ready to implement, or the Pathfinder if all milestone slices are complete.
+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.
+   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).
+   - **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.dev1296 → teddy_cli-0.1.17.dev1297}/src/teddy_executor/resources/config/prompts/pathfinder.md

@@ -34,7 +34,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 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.
 3. **Milestone & Specification:**
-   For systemic or milestone features, update the Roadmap in `docs/project/PROJECT.md` and active milestone in `docs/project/milestones/` for the Architect. If establishing permanent system invariants, CREATE or EDIT the specification document in `docs/project/specs/`.
+   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:**
    For standalone behavioral work, CREATE an ad-hoc slice following conventions in `docs/project/PROJECT.md`, placing Wiring first as the tracer bullet deliverable. If it contains unresolved technical or functional unknowns, target the Prototyper; if patterns and behavior are established, target the Developer.
 5. **Case File Generation:**

teddy_cli-0.1.17.dev1297/src/teddy_executor/resources/templates/milestone.md

@@ -0,0 +1,17 @@
+# Milestone: {{milestone_title}}
+- **Status:** [Planned | In Progress | Completed]
+- **Specs:** [links]
+
+## Goal
+The Why: Problem definition, customer motivation, and measurable value delivered by this milestone.
+
+## Solution
+The What: Strategic architecture, chosen design patterns, system boundaries, and key trade-offs.
+
+## Guidelines
+The How: Actionable strategy, engineering invariants, architectural rules, and test harness considerations.
+
+## Slices
+<!-- Decompose 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.dev1296 → teddy_cli-0.1.17.dev1297}/src/teddy_executor/resources/templates/vertical-slice.md

@@ -1,6 +1,7 @@
 # Slice: {{feature_name}}
 - **Status:** [Planned | In Progress | Completed]
-- **Milestone:** [link]
+- **Milestone:** [MM-name](../milestones/MM-name.md)
+- **Depends On:** [MM-01-slice-slug.md](./MM-01-slice-slug.md) <!-- Link prerequisite slice or 'None' -->
 - **Specs:** [links]
 - **Prototype:** [link]
 - **Component Docs:** [links]
@@ -10,6 +11,7 @@
 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. -->
 > As a [user type], I want to [action] so that [benefit].
 
 ```gherkin
@@ -19,6 +21,7 @@ Then [expected outcome]
 ```
 
 ## Edge Cases
+<!-- 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
@@ -38,12 +41,15 @@ Then [expected outcome]
 **Format:**
 - [ ] [Tag] Title: Description of the unknown. Design Sensitivity.
 
-## Scope & Impact
-Surface of affected components classified by the Parallel Change model:
-- `[NEW]` `ComponentOrModule` — role and responsibility
-- `[EXPAND]` `ComponentOrModule.method` — additive/non-breaking extension
-- `[MIGRATE]` `ConsumerComponent` — updating callers to new contract
-- `[CONTRACT]` `ObsoleteComponentOrMethod` — removal of retired code/shims
+## 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.
+
+**Format:**
+1. `[NEW]` `ComponentOrModule` — Create new boundary or component.
+2. `[EXPAND]` `ComponentOrModule.method` — Additive, non-breaking contract extension alongside existing code.
+3. `[MIGRATE]` `ConsumerComponent` — Transition consumers one by one to use the expanded contract.
+4. `[CONTRACT]` `ObsoleteComponentOrMethod` — Safely remove deprecated methods, shims, or dead code once all callers have migrated.
 
 ## Deliverables
 
@@ -69,8 +75,9 @@ Surface of affected components classified by the Parallel Change model:
 Free-form notes recording decisions, deviations, or discoveries during implementation.
 
 ## Verification
-Action-oriented black-box checks executed strictly from the outside as an end user would (e.g. CLI commands, flags, observable output, exit codes). All must pass before slice completion.
+<!-- 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. -->
 
 **Format:**
-- [ ] Run `command <args>` and verify output contains `expected output` and exits with code 0.
-- [ ] Run `command <invalid-args>` and verify error message and non-zero exit.
+- [ ] **CLI / API:** Run `command <args>` and verify output contains `expected output`.
+- [ ] **UI / Interactive:** Navigate to `[View/Screen]`, trigger `[Action]`, and confirm `[Observed State/Element]`.

teddy_cli-0.1.17.dev1296/src/teddy_executor/resources/templates/milestone.md

@@ -1,17 +0,0 @@
-# Milestone: {{milestone_title}}
-- **Status:** [Planned | In Progress | Completed]
-- **Specs:** [links]
-
-## Goal
-Problem definition and core objectives.
-
-## Proposed Solution
-Technical architecture, selected patterns, and trade-offs.
-
-## Guidelines
-Actionable strategy, architectural boundaries, and test harness considerations.
-
-## Vertical Slices
-<!-- Decompose into end-to-end vertical slices cutting across all layers; do not slice horizontally by technical layer. -->
-- [ ] {{MM-NN}}: [Slice Title] — [Tackles Req X: brief scope statement]
-- [ ] {{MM-NN}}: [Slice Title] — [Tackles Req Y: brief scope statement]