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

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

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

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

@@ -51,7 +51,7 @@ WIP & REMINDERS:
       1. Pre-conditions: Clean up temporary files (spikes/, .tmp/). If unsure of changes, `EXECUTE git add . && git diff HEAD`.
       2. Commit Message: Use Conventional Commits '<type>(<scope>): <description>' wrapped in single quotes. Use imperative mood. Append ! for breaking changes.
       3. Execution: You MUST test, stage, commit locally, pull safely with rebase, and push by running `make commit '<type>(<scope>): <description>'`. There is no `no-verify` flag: the `make commit` target runs the pre-commit hooks once via `pre-commit run` (re-staging any auto-formatted files) and then commits with `git commit --no-verify`, which suppresses Git's own redundant second invocation of the pre-commit hook. The post-commit test gate is unaffected by this flag and always runs.
-      4. Post-conditions: All tests MUST pass — the post-commit hook runs the full suite and reverts the commit on failure; this gate is unskippable and MUST NEVER be bypassed. The pre-commit stage is advisory (its failures do not block the local commit), but if it reported non-trivial quality-gate issues (e.g. file length), you MUST make a follow-up cleanup commit that resolves them before resuming feature work, and log the debt in PROJECT.md if it cannot be resolved immediately.
+      4. Post-conditions: All tests MUST pass — the post-commit hook runs the full suite and reverts the commit on failure; this gate is unskippable and MUST NEVER be bypassed. The pre-commit stage is advisory (its failures do not block the local commit), but if it reported non-trivial quality-gate issues (e.g. file length), you MUST make a follow-up cleanup commit that resolves them before resuming feature work. Triage any resulting `[DEBT]` per the 3-Tier Debt Triage policy — there is no `## Technical Debt` holding pen.
     </rule>
 
     <rule n="7" name="Standardized Plan Types">

{teddy_cli-0.1.17.dev1233 → 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.dev1233 → 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>

{teddy_cli-0.1.17.dev1233 → teddy_cli-0.1.17.dev1235}/src/teddy_executor/resources/templates/makefile.md

@@ -92,7 +92,7 @@ test:
 ### Example
 
 ```makefile
-commit: ARGS := $(filter-out commit,$(MAKECMDGOALS))
+commit: ARGS := $(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS))
 
 commit:
 	@[ -n "$(ARGS)" ] || { echo "Usage: make commit '<message>'"; exit 1; }
@@ -115,7 +115,7 @@ commit:
 ### Example
 
 ```makefile
-probe: REASON := $(filter-out probe,$(MAKECMDGOALS))
+probe: REASON := $(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS))
 
 probe:
 	@[ -n "$(REASON)" ] || { echo "Usage: make probe '<reason>'"; exit 1; }
@@ -139,8 +139,8 @@ The Debugger's Reproduction phase needs to read the logs of a specific failed CI
 ### Example
 
 ```makefile
-logs: LOGS_RUN := $(word 1,$(filter-out logs,$(MAKECMDGOALS)))
-logs: LOGS_STEP := $(wordlist 2,99,$(filter-out logs,$(MAKECMDGOALS)))
+logs: LOGS_RUN := $(word 2,$(MAKECMDGOALS))
+logs: LOGS_STEP := $(wordlist 3,99,$(MAKECMDGOALS))
 
 logs:
 	@[ -n "$(LOGS_RUN)" ] || { echo "Usage: make logs <run-id> '<step-name>'"; exit 1; }
@@ -155,7 +155,7 @@ logs:
 - First discover the run ID and the failed step name with `gh run view 12345` (the execution tree), then pass both to `make logs`.
 
 **How it works:**
-- `$(filter-out logs,$(MAKECMDGOALS))` drops the target name from the goal list; `$(word 1, ...)` takes the run ID and `$(wordlist 2,99, ...)` takes the (space-containing) step name.
+- `$(word 2,$(MAKECMDGOALS))` takes the run ID and `$(wordlist 3,99,$(MAKECMDGOALS))` takes the (space-containing) step name; the first goal (the `logs` target itself) is dropped.
 - The `awk` program matches rows whose second tab-separated field equals the step name via `-v step=...`, trims the leading timestamp, strips ANSI escape sequences, and removes GitHub's group boilerplate, prefixing `##[error]` lines with `Error: `.
 - It reuses the same cross-platform Make constructs as the other targets (see [Cross-Platform Design](#cross-platform-design)); the `%: @:` catch-all prevents the extra `make` goals from being treated as files.