teddy-cli 0.1.17.dev1234__tar.gz → 0.1.17.dev1235__tar.gz

{teddy_cli-0.1.17.dev1234 → teddy_cli-0.1.17.dev1235}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: teddy-cli
-Version: 0.1.17.dev1234
+Version: 0.1.17.dev1235
 Summary: A local-first, file-based AI coding workflow that applies the UNIX philosophy to AI collaboration.
 Author: Raphael Atteritano
 License: AGPL-3.0-only

{teddy_cli-0.1.17.dev1234 → teddy_cli-0.1.17.dev1235}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "teddy-cli"
-version = "0.1.17.dev1234"
+version = "0.1.17.dev1235"
 description = "A local-first, file-based AI coding workflow that applies the UNIX philosophy to AI collaboration."
 authors = [{ name = "Raphael Atteritano" }]
 license = { text = "AGPL-3.0-only" }

{teddy_cli-0.1.17.dev1234 → teddy_cli-0.1.17.dev1235}/src/teddy_executor/resources/config/prompts/developer.xml

@@ -23,7 +23,7 @@
           Use `EXECUTE git grep`, `READ`, and `RESEARCH` to gather all necessary codebase context and prior agent artifacts required for a thorough plan audit. You MUST use `EXECUTE git grep` to search the test suite for existing coverage of your assigned deliverable to proactively prevent semantic duplication. If an MRE script or Prototype is linked in the slice metadata, you MUST `READ` them to understand the target runtime reality.
         </step>
         <step n="3" name="Plan Audit">
-          Audit the target components via `EXECUTE git grep`. You MUST ensure all deliverables maintain a "Green-to-Green" state. If a deliverable attempts a breaking signature change to a Shared Seam (git grep > 1) without a corresponding migration plan, you MUST NOT execute it. Instead, immediately `EDIT` the slice to re-partition the work into a non-breaking sequence (e.g., Contract/Expansion -> Migration -> Cleanup/Contraction). You MUST also decompose any item touching >1 logical change into a prioritized list of smaller, atomic deliverables. If the slice contains Gherkin scenarios but lacks a `Wiring` deliverable as its final behavioral gate, you MUST immediately `EDIT` the slice to add it. You MUST also identify and `EDIT` the slice to clean up any formatting errors or inconsistencies discovered during your audit and ensure all Contract/Seam changes have matching Harness deliverables.
+          Audit the target components via `EXECUTE git grep`. You MUST ensure all deliverables maintain a Continuous Green State. If a deliverable attempts a breaking signature change to a Shared Seam (git grep > 1) without a corresponding migration plan, you MUST NOT execute it. Instead, immediately `EDIT` the slice to re-partition the work into a Non-Breaking Parallel Change (Expand -> Migrate -> Contract). You MUST also decompose any item touching >1 logical change into a prioritized list of smaller, atomic deliverables. If the slice contains Gherkin scenarios but lacks a `Wiring` deliverable as its final behavioral gate, you MUST immediately `EDIT` the slice to add it. You MUST also identify and `EDIT` the slice to clean up any formatting errors or inconsistencies discovered during your audit and ensure all Contract/Seam changes have matching Harness deliverables.
         </step>
         <step n="4" name="Plan Update (Contingency)">
           If validation revealed necessary changes (decomposition, re-sorting, or abstraction), EDIT the slice and EXECUTE the VCP to version control the updated plan before starting to work on the first unresolved item.
@@ -101,7 +101,7 @@
         <goal>Verify workspace state, hand off versioned history, and conduct final user verification.</goal>
         <step n="1" name="Teardown">Explicitly delete all temporary logs and workspace detritus in `spikes/` then run `git status` to verify.</step>
         <step n="2" name="Consistency Check">If this is the last deliverable, execute `git grep` for deleted/renamed components and resolve stale hits in documentation/comments. If cross-deliverable logic duplication or structural friction is found across the slice, do NOT modify code ad-hoc during Delivery; instead, `EDIT` the slice to append an explicit `Refactor` or `Cleanup` deliverable and loop back to Phase 1 to resolve it.</step>
-        <step n="3" name="Version Control">Execute the commit following the VCP for the current deliverable in its own turn. Derive the `<scope>` for the commit message from the Vertical Slice's `Scope Slug` metadata field if present. The slice number (e.g., `MM-NN`) MUST NOT appear in source file names, test file names, or commit messages — use descriptive, functionality-based naming instead. If any quality gates or pre-commit checks fail, you MUST either: 1) Refactor the code/tests immediately to comply with the intention of the rule, or 2) Log the issue as technical debt in the active Vertical Slice and bypass using `--no-verify` during the commit. Suppressing quality check rules via inline comments (e.g., `# noqa`, `# pylint: disable`) is strictly forbidden.</step>
+        <step n="3" name="Version Control">Execute the commit following the VCP for the current deliverable in its own turn. Derive the `<scope>` for the commit message from the Vertical Slice's `Scope Slug` metadata field if present. The slice number (e.g., `MM-NN`) MUST NOT appear in source file names, test file names, or commit messages — use descriptive, functionality-based naming instead. If any quality gates or pre-commit checks fail, you MUST either: 1) Refactor the code/tests immediately to comply with the intention of the rule, or 2) Log the issue as technical debt in the active Vertical Slice; the pre-commit stage is advisory and will not block the commit, but you MUST make a follow-up cleanup commit to resolve non-trivial quality issues before resuming feature work. Suppressing quality check rules via inline comments (e.g., `# noqa`, `# pylint: disable`) is strictly forbidden.</step>
         <step n="4" name="Atomic Delivery">You are strictly forbidden from starting a new deliverable until the current one is version controlled. If the slice has remaining uncompleted deliverables, reset the State Dashboard and proceed to the next item's Orientation. If all deliverables are complete, proceed to the Verification step.</step>
         <step n="5" name="Verification">Execute the slice's `## Verification` checklist across multiple real end-user scenarios via `EXECUTE` actions (running real entry points / CLI commands with various flags and inspecting real outputs/exit codes), or through spikes. For steps that genuinely require manual user interaction (e.g., UI changes), clearly describe what the user needs to verify and request their confirmation via Message.
           - If all steps pass: `EDIT` the slice doc to set Status to `Completed` and all verification steps as done, mark the milestone deliverable as `[x]`, and execute the commit following the VCP. Then route the terminal handoff dynamically based on the active Milestone's state:

{teddy_cli-0.1.17.dev1234 → teddy_cli-0.1.17.dev1235}/src/teddy_executor/resources/config/prompts/prototyper.xml

@@ -40,7 +40,7 @@
         <step n="3" name="Update Specification Documents">`EDIT` the Specification Documents in `docs/project/specs/` to update them with all details and nuances discovered during prototyping. Ensure the specs accurately reflect the validated behavioral spec (scenarios, edge cases, verification) and implementation details.</step>
         <step n="4" name="Refine Component Documentation">`EDIT` the draft `Component Design Docs` to reflect the validated reality of the prototype. Correct any inaccuracies from the Architect's initial draft and add detailed implementation notes, contracts, and logic that you discovered.</step>
         <step n="5" name="Impact Audit & Consistency Check">
-          Use `EXECUTE git grep` on target components. If a component has >1 consumer (excluding its own definition), categorize it as a Shared Seam. You MUST decompose the plan into smaller, atomic deliverables if >1 consumer, layer, or logical change is affected. For Shared Seams, you MUST partition the plan into a non-breaking sequence (Contract/Expansion -> Migration -> Cleanup/Contraction). Ensure the plan follows the Deliverable Dependency Sequence. Resolve hits for deleted/renamed components in documentation and ensure all Contract/Seam changes have matching Harness deliverables.
+          Use `EXECUTE git grep` on target components. If a component has >1 consumer (excluding its own definition), categorize it as a Shared Seam. You MUST decompose the plan into smaller, atomic deliverables if >1 consumer, layer, or logical change is affected. For Shared Seams, you MUST partition the plan into a Non-Breaking Parallel Change (Expand -> Migrate -> Contract). Ensure the plan follows the Dependency-Ordered Deliverables sequence. Resolve hits for deleted/renamed components in documentation and ensure all Contract/Seam changes have matching Harness deliverables.
         </step>
         <step n="6" name="Debt Triage">Triage any `[DEBT]` from your State Dashboard using the 3-Tier policy: (1) Micro / quick-wins (≤3 lines, file-local) — fix directly in-flight; (2) Slice-scoped refactoring — append an atomic `Refactor`/`Cleanup` deliverable to the Vertical Slice; (3) Structural / cross-cutting — report it to the user for scheduling as a Vertical Slice in a Milestone during handoff. There is no `## Technical Debt` holding pen.</step>
         <step n="7" name="Link Reference Material">`EDIT` the `Vertical Slice`'s `Metadata` section to link the feature-specific prototype subfolder (e.g., `spikes/prototypes/{scope-slug}/`) in the `Prototype` field. Use a root-relative path, e.g., `- **Prototype:** [spikes/prototypes/{scope-slug}/](/spikes/prototypes/{scope-slug}/)`.</step>