teddy-cli 0.1.17.dev1277__tar.gz → 0.1.17.dev1279__tar.gz

{teddy_cli-0.1.17.dev1277 → teddy_cli-0.1.17.dev1279}/PKG-INFO

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

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

@@ -51,7 +51,7 @@ NOTES:
       3. Execution: Run `make commit '<type>(<scope>): <description>'`. This stages all local changes (`git add .`) and runs Git's local hooks before committing.
       4. Post-conditions: All tests MUST pass: the post-commit hook reverts automatically on failure and cannot be bypassed.
       5. Push at Conclusion: In the Conclusion phase, run `make push` to rebase and push.
-      6. If needed: to verify remote CI run `make ci-watch` to monitor workflow runs and to inspect results: use `make logs <run-id> '<step-name>'` for full logs.
+      6. If needed: to verify remote CI run `make ci-watch` to monitor workflow runs and to inspect results: use `make logs <run-id>` (or `make logs <run-id> '<step-name>'`) for full logs.
     </rule>
 
     <rule n="7" name="Standardized Plan Types">

{teddy_cli-0.1.17.dev1277 → teddy_cli-0.1.17.dev1279}/src/teddy_executor/resources/config/prompts/architect.xml

@@ -17,12 +17,12 @@
 
       <phase n="2" name="Design">
         <goal>Codify strategic decisions and design the single next vertical slice.</goal>
-        <step n="1" name="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 and set status to In Progress.</step>
+        <step n="1" name="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 and 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.</step>
         <step n="2" name="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.</step>
         <step n="3" name="Draft Component Designs">CREATE or EDIT draft design docs for affected components. Focus strictly on strategic intent, purpose, conceptual Port responsibilities, operations, and invariants. Enforce Test Double Integrity (Ban Global Patching) and avoid leaky abstractions. Leave concrete typing and internal implementation details to the Developer. Transition updated existing docs to Refactoring status.</step>
         <step n="4" name="Architecture Maintenance">Update the Component and Boundary Map and Key Architectural Decisions in `docs/architecture/ARCHITECTURE.md` to reflect the design.</step>
         <step n="5" name="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.</step>
-        <step n="6" name="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. Link component docs and include Gherkin scenarios. Place Wiring first as the tracer bullet deliverable connecting the outermost boundaries with skeleton data, followed by contract, logic, refactoring, cleanup, and harness deliverables in dependency order. For every key unknown, record a one-line Design Sensitivity stating how the design reacts to each resolution.</step>
+        <step n="6" name="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.</step>
         <step n="7" name="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 and ensure all seam changes have matching harness deliverables.</step>
       </phase>
 

{teddy_cli-0.1.17.dev1277 → teddy_cli-0.1.17.dev1279}/src/teddy_executor/resources/config/prompts/assistant.xml

@@ -10,7 +10,7 @@
       <phase n="1" name="Execution">
         <goal>Execute the task immediately via an iterative loop: make minimal verifiable progress, verify, then repeat until the task is complete.</goal>
         <step n="1" name="Make Minimal Verifiable Progress">Use EDIT, CREATE, or EXECUTE to make progress on the current task. You may batch multiple tightly-related modifications together, but prioritize incremental steps rather than implementing everything before verification.</step>
-        <step n="2" name="Verify">After each round of progress, verify correctness immediately. Use EXECUTE `git grep` to check upstream consumers and downstream dependencies. Run targeted tests via EXECUTE to confirm no regressions.</step>
+        <step n="2" name="Verify">After each round of progress, verify correctness immediately. Use EXECUTE `git grep` to check upstream consumers and downstream dependencies. EXECUTE `make test` to confirm no regressions.</step>
         <step n="3" name="Iterate">Assess whether the current task is complete. If more work is needed, return to Make Minimal Verifiable Progress. If the task is complete, advance to the Alignment phase.</step>
       </phase>
 

{teddy_cli-0.1.17.dev1277 → teddy_cli-0.1.17.dev1279}/src/teddy_executor/resources/config/prompts/debugger.xml

@@ -9,7 +9,7 @@
       <phase n="1" name="Reproduction">
         <goal>Gather context and build or verify an end-to-end Minimal Reproducible Example (MRE).</goal>
         <step n="1" name="Case File Check">If a Case File was not provided in the initial context, READ `docs/templates/case-file.md` and CREATE one following that template.</step>
-        <step n="2" name="Context and History Gathering">Use EXECUTE `git grep`, EXECUTE `git log`, READ, and RESEARCH to understand the codebase, recent changes, and identify the last known green CI run or commit. For historical CI failures, do not try to read the entire log. First use `gh run view [ID]` to inspect the execution tree and identify the exact name of the failed step. Then, extract only that step logs by executing `make logs [ID] '[FAILED_STEP_NAME]'`.</step>
+        <step n="2" name="Context and History Gathering">Use EXECUTE `git grep`, EXECUTE `git log`, READ, and RESEARCH to understand the codebase, recent changes, and identify the last known green CI run or commit. For historical CI failures, do not try to read the entire log: extract failed step logs by executing `make logs [ID]` (for all failed steps) or `make logs [ID] '[STEP_NAME]'` (for a specific step).</step>
         <step n="3" name="Diagnostic MRE and Platform Check">
           Trigger the symptom: if an existing command, test, or CI failure exists, execute it to observe the failure live. If the bug is reported verbally or without an existing test, write a targeted probe script in `spikes/debug/{scope-slug}/` to trigger the symptom.
 

{teddy_cli-0.1.17.dev1277 → teddy_cli-0.1.17.dev1279}/src/teddy_executor/resources/config/prompts/developer.xml

@@ -24,10 +24,11 @@
       <phase n="2" name="Implementation">
         <goal>Satisfy the current deliverable requirements via Just-In-Time implementation without overbuilding.</goal>
         <step n="1" name="Red">
-          Map the current deliverable type to its testing layer, strictly adhering to the three test-layer boundaries:
-          Acceptance (`tests/suites/acceptance/`, happy-path scenarios only): Wiring. This step MUST establish the End-to-End Skeleton Wiring Tracer Bullet. Write a test that hits the outermost boundary (such as an API endpoint) and expects the final success state. Use Public Boundary Acceptance Testing: drive the outermost entry point without importing internal core models or services.
-          Integration (`tests/suites/integration/`, adapters only): Harness, Migration. Importing internal core models or services is banned.
-          Unit (`tests/suites/unit/`, isolated core logic): Contract, Seam, Logic, Refactor, Cleanup. Must contain all granular edge cases, errors, and permutations.
+          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.
+          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.
+          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.
 

teddy_cli-0.1.17.dev1279/src/teddy_executor/resources/templates/ARCHITECTURE.md

@@ -0,0 +1,68 @@
+# System Architecture: {{project_name}}
+
+## Conventions & Standards
+
+This section defines foundational engineering practices. Each entry MUST be a specific, enforceable rule.
+
+**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).
+- **Run Environment:** Designated runner (e.g., `uv run`, `poetry run`).
+- **Failure Transparency:** Error handling policy — specific exceptions only, no silent suppression.
+- **Testing Strategy:** 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, and strictly autospec-bound mocks only for un-fakeable external side-effects.
+- **Runtime Contract Assertions:** Enforce Design-by-Contract with native `assert condition, "message"` for pre/post-conditions and invariants (strippable via `python -O`); never custom exceptions for contract checks.
+- **Dependency Injection:** Constructor injection mandate; forbid Service Locator and global containers.
+- **Centralized Configuration:** Config file location, prohibition of magic numbers.
+- **Continuous Integration & Remote Diagnostics:** Parallel CI jobs: 1) Blocking OS matrix test suite. 2) Non-blocking (`continue-on-error: true`) quality checks running fast formatters, linters, security scanners, type checkers, and repository-wide structural checks. Platform-specific and CI-only issues are investigated via the Remote Probing Protocol (`make probe '<reason>'`). See [docs/templates/ci.md](docs/templates/ci.md).
+- **Local Quality Gates (Pre-commit & Post-commit):** Local pre-commit hooks MUST stay fast, checking only staged files (formatters, secret detection, merge conflict markers). Heavy, false-positive-prone checks run non-blocking in CI. The full test suite runs via the post-commit hook (`.githooks/post-commit.py`) as an unskippable safety net, reverting automatically on failure. See [docs/templates/pre-commit.md](docs/templates/pre-commit.md).
+- **Diagnostic Instrumentation:** High-value diagnostics MUST use zero-cost language-native dead-code elimination (e.g. `if __debug__:`) and Composition Root toggles; mid-logic environment checks are forbidden.
+- **Experimental Code:** The `spikes/` directory is reserved for rapid, isolated experimentation (`debug/`, `prototypes/`, `showcases/`) and is explicitly excluded from all quality gates (linters, type checkers, test suites).
+- **Directory Conventions:**
+  `docs/architecture/BOUNDARY/LAYER/TYPE/name.md` -> Source path: `src/{pkg}/BOUNDARY/LAYER/TYPE/name.ext` -> Test path: `tests/suites/TEST_TYPE/BOUNDARY/LAYER/TYPE/test_name.ext`
+- **Makefile Commands:** The `Makefile` is the canonical entry point for the version control workflow and on-demand test runs: `make test` (full suite), `make commit '<msg>'` (local commit with advisory auto-fix and unskippable post-commit test gate), `make push` (rebase and push), `make ci-watch` (CI monitoring), and `make probe '<reason>'` (Remote Probing Protocol). See [docs/templates/makefile.md](docs/templates/makefile.md).
+
+## Component & Boundary Map
+
+Single source of truth for system structure, organized by architectural layer.
+
+### Hexagonal Core
+Domain entities, value objects, ports, and orchestrating services.
+
+| Component         | Description                     | Contract                                     |
+| ----------------- | ------------------------------- | -------------------------------------------- |
+| **ComponentName** | One-line responsibility summary | [Link to design doc](./path/to/component.md) |
+
+### Inbound Adapters (Driving)
+Entry points initiating calls into the core (CLI, Web UI, API controllers, message consumers).
+
+| Component         | Description                     | Contract                                     |
+| ----------------- | ------------------------------- | -------------------------------------------- |
+| **ComponentName** | One-line responsibility summary | [Link to design doc](./path/to/component.md) |
+
+### Outbound Adapters (Driven)
+Infrastructure implementations fulfilling outbound port contracts (file system, database, external APIs, shell).
+
+| Component         | Description                     | Contract                                     |
+| ----------------- | ------------------------------- | -------------------------------------------- |
+| **ComponentName** | One-line responsibility summary | [Link to design doc](./path/to/component.md) |
+
+### Test Harness
+Test drivers, observers, shared fakes, and test setup fixtures.
+
+| Component         | Description                     | Contract                                     |
+| ----------------- | ------------------------------- | -------------------------------------------- |
+| **ComponentName** | One-line responsibility summary | [Link to design doc](./path/to/component.md) |
+
+Each Contract column links to the Component Design Document or Interface definition.
+
+## Key Architectural Decisions
+
+A living "System Law" document capturing explicit, prescriptive design decisions.
+
+**Template format:** `- **Subject:** Strict Rule. (Rationale.)`
+
+### Rules for this section:
+- Each entry MUST be a single enforceable rule with a brief rationale.
+- Add new entries as decisions are made; never remove without deprecation notice.
+- Note exceptions explicitly with their rationale.

{teddy_cli-0.1.17.dev1277 → teddy_cli-0.1.17.dev1279}/src/teddy_executor/resources/templates/PROJECT.md

@@ -1,4 +1,4 @@
-# Project: {{project_name}}
+# Project Dashboard: {{project_name}}
 
 ## Product Vision
 The overarching goals, target audience, unique value proposition, and major future directions for the product.
@@ -23,8 +23,7 @@ Defines the high-level artifact lifecycle and conventions for project management
     - **Case Files (Debugger):** `NN-name.md` — numbered sequentially.
     - **Milestone 0 (bootstrapping) & Ad-hoc work (not tied to a milestone):** `00-NN-name.md` — `00` is used as the Milestone prefix for Milestone 0 bootstrapping slices and for ad-hoc slices. Ad-hoc slices are NOT tracked in Milestone documents or the Roadmap.
 - **Archiving Policy:** When and how completed artifacts are archived or deleted.
-- **Spec Organization:** Specification documents live in a single flat directory `docs/project/specs/` and are reserved strictly for **permanent system invariants** — formats, contracts, protocols (e.g. the MRP), core data models, and non-negotiable architectural rules. Feature goals, requirements, and acceptance criteria belong in Milestone documents (`docs/project/milestones/`), not in specs. There is no ephemeral `specs/features/` lifecycle.
-- **Run Environment:** Specify the project's designated environment/dependency manager (e.g., `uv`, `poetry`, `pip`) and prefix ALL execution commands with its runner (e.g., `uv run pytest`). The chosen runner MUST be reflected in the `Makefile`.
+- **Spec Organization:** Specification documents live in a single flat directory `docs/project/specs/` and are reserved strictly for **permanent system invariants** — formats, contracts, protocols (e.g. the MRP), core data models, and non-negotiable architectural rules. Feature goals, requirements, and acceptance criteria belong in Milestone documents (`docs/project/milestones/`), not in specs.
 - **Build & Run Commands:** Document the standard commands in the project `Makefile` (see [docs/templates/makefile.md](docs/templates/makefile.md)). At minimum: `make test` (full suite), `make commit '<msg>'` (VCP), `make push`, `make ci-watch` (CI monitoring), and `make probe '<reason>'` (Remote Probing Protocol).
 - **Release Process:** Document how releases are cut. At minimum: (1) **Triage** the scope (patch/minor/major) from conventional commits since the last tag; (2) write **release notes** to `docs/project/releases/v<version>.md`; (3) bump the `version` field in the project manifest; (4) present the notes and version bump at an **approval gate**; (5) **commit** (`chore(release): bump version to <version>`) and **tag** (`git tag -a v<version>`); and (6) **publish** (e.g. create a GitHub Release). Adapt the concrete commands to the project's packaging and distribution channel.
 
@@ -32,18 +31,18 @@ Defines the high-level artifact lifecycle and conventions for project management
 
 Before creating or modifying any documentation artifact, agents MUST read the corresponding template from `docs/templates/`. The bundled templates are:
 
-| Template | Purpose |
-| -------- | ------- |
-| `specification-document.md` | Specification documents (permanent system invariants) |
-| `milestone.md` | Milestone documents |
-| `vertical-slice.md` | Vertical slice definitions |
-| `component-design.md` | Component design documents (ports and contracts) |
-| `case-file.md` | Debugger case files |
-| `PROJECT.md` | This project dashboard |
-| `ARCHITECTURE.md` | System architecture document |
-| `makefile.md` | Makefile (VCP commit + Remote Probing Protocol commands) |
-| `ci.md` | CI workflow template (debug workflow for the Remote Probing Protocol) |
-| `pre-commit.md` | Pre-commit framework setup (pre-commit + post-commit test gate) |
+| Template                    | Purpose                                                               |
+| --------------------------- | --------------------------------------------------------------------- |
+| `specification-document.md` | Specification documents (permanent system invariants)                 |
+| `milestone.md`              | Milestone documents                                                   |
+| `vertical-slice.md`         | Vertical slice definitions                                            |
+| `component-design.md`       | Component design documents (ports and contracts)                      |
+| `case-file.md`              | Debugger case files                                                   |
+| `PROJECT.md`                | This project dashboard                                                |
+| `ARCHITECTURE.md`           | System architecture document                                          |
+| `makefile.md`               | Makefile (VCP commit + Remote Probing Protocol commands)              |
+| `ci.md`                     | CI workflow template (debug workflow for the Remote Probing Protocol) |
+| `pre-commit.md`             | Pre-commit framework setup (pre-commit + post-commit test gate)       |
 
 These files live in `docs/templates/` and are created or refreshed by `teddy init templates`.
 
@@ -65,13 +64,9 @@ A living list of upcoming Milestones and their high-level features.
 ```
 
 ### Milestone 0: Project Bootstrapping [PLANNED]
-- **Core Goal:** Establish the foundational project infrastructure for testing, CI/CD, and pre-commit quality gates.
+- **Core Goal:** Establish foundational infrastructure for testing, quality gates, and automated delivery.
 - **Specs:** N/A — Milestone 0 is self-defining.
 - **Requirements:**
-    - **Testing Framework Setup:** Configure the project's designated test runner (e.g., `pytest`) with test discovery conventions, exposed via a `make test` target (see the Makefile below).
-    - **CI/CD Pipeline:** Set up two parallel jobs: 1) Blocking OS matrix test suite with coverage targets. 2) Non-blocking quality checks (formatters, linters, security scanners).
-    - **Pre-commit Hooks:** Install the Pre-commit framework with hooks for formatters, linters, security scanners.
-    - **Post-commit Hook:** Implement a hook that runs the full test suite via `make test` and reverts the commit on failure (via `git reset --soft HEAD~1`, keeping changes staged). This is the unskippable safety net — `--no-verify` MUST NOT bypass it.
-    - **Debug Workflow:** Create `.github/workflows/debug.yml` following [docs/templates/ci.md](docs/templates/ci.md) to enable the Remote Probing Protocol.
-    - **Makefile:** Create a `Makefile` following [docs/templates/makefile.md](docs/templates/makefile.md) with `make commit`, `make probe`, and `make test` commands. `make commit` implements the VCP workflow, `make probe` implements the Debugger's Remote Probing Protocol, and `make test` runs the full suite on demand.
-    - **`.gitignore` Configuration:** Configure a project-tailored `.gitignore` covering language/OS cache files, build artifacts, virtual environments, and the transient `.tmp/` directory. The `spikes/` directory MUST remain tracked so prototypes and probes stay version-controlled.
+    - **Testing & Tooling Entry Points:** Configure the test runner (`pytest`) exposed via `make test`, along with standard `Makefile` targets (`make commit`, `make push`, `make ci-watch`, `make probe`). Configure project `.gitignore` keeping `spikes/` tracked.
+    - **Local Quality Gates:** Install Pre-commit with fast local hooks (formatters, secret detection, merge conflict checks) and the unskippable post-commit test gate (`.githooks/post-commit.py`) that runs `make test` and reverts on failure.
+    - **CI/CD & Remote Diagnostics:** Set up parallel GitHub Actions jobs: 1) Blocking OS matrix test suite. 2) Non-blocking quality checks. Configure `.github/workflows/debug.yml` for the Remote Probing Protocol.

teddy_cli-0.1.17.dev1279/src/teddy_executor/resources/templates/case-file.md

@@ -0,0 +1,35 @@
+# Bug: {{bug_title}}
+- **Status:** Unresolved
+- **Milestone:** [link or N/A]
+- **Vertical Slice:** [link or N/A]
+- **Specs:** [links or N/A]
+
+## Symptoms
+Expected vs. actual behavior and minimal reproduction steps.
+
+## Context & Scope
+### Regressing Delta
+Git commit hash, file paths, and line numbers of the regressing change.
+
+### Environmental Triggers
+OS, runtime version, environment variables, or specific configurations required to reproduce.
+
+### Ruled Out
+Components, modules, or hypotheses definitively eliminated during investigation.
+
+## Diagnostic Analysis
+### Causal Model
+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).
+
+### Investigation History
+Continuously log diagnostic attempts and findings in chronological order:
+1. Investigated whether [hypothesis] by [action/probe]; observed [outcome], which [conclusion].
+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.

teddy_cli-0.1.17.dev1279/src/teddy_executor/resources/templates/component-design.md

@@ -0,0 +1,38 @@
+# Component Design: {{component_name}}
+- **Status:** [Planned | Implemented | Refactoring]
+- **Source:** [`src/path/to/file.ext`](/src/path/to/file.ext)
+
+## Purpose
+1-2 sentences summarizing the core responsibility and boundary role of this component.
+
+## Consumers
+Upstream callers, controllers, or services that depend on or invoke this component:
+- [`CallerComponent`](./path/to/caller.md): Invokes this component to execute [workflow/operation].
+
+## Dependencies
+Downstream components, outbound ports, or external libraries required by this component:
+- [`DependencyComponent`](./path/to/dependency.md): Injected via constructor to fulfill [outbound operation].
+
+## Class Invariants
+Conditions that must hold true throughout the component lifecycle. If stateless, state: `None — stateless component.`
+- `invariant_statement`: description of condition.
+
+## Inbound Ports
+Use-case interfaces or API signatures this component exposes to consumers:
+- **`PortName`**: Signature and operations provided.
+
+## Outbound Ports
+Dependency contracts this component requires injected:
+- **`PortName`**: Signature and operations consumed.
+
+## Data Contracts
+Data transfer objects, schemas, payloads, or immutable models managed or exchanged by this component:
+- **`DtoOrPayloadName`**: Structure, fields, types, and constraints.
+
+## Operations
+Public method specifications. Avoid pseudocode; specify signatures, preconditions, postconditions, and error modes:
+
+### `method_name(args) -> ReturnType`
+- **Preconditions:** What must hold before calling (validated via guard clauses or runtime assertions).
+- **Postconditions:** What is guaranteed upon successful return.
+- **Exceptions:** Specific exceptions raised when preconditions or operations fail (never generic or swallowed errors).

{teddy_cli-0.1.17.dev1277 → teddy_cli-0.1.17.dev1279}/src/teddy_executor/resources/templates/makefile.md

@@ -46,11 +46,12 @@ The Remote Probing Protocol requires a reason string because it is passed as the
 
 ### Logs
 ```shell
-make logs 12345 'Run tests'
+make logs 12345              # extract logs for ALL failed steps
+make logs 12345 'Run tests'  # extract logs for a specific step (substring match)
 ```
 
-**Why does `logs` take two arguments?**
-The first argument is the GitHub Actions run ID (as shown by `gh run list`); the second is the exact name of a step in that run's execution tree (as shown by `gh run view <id>`). The target extracts ONLY that step's logs, stripping ANSI escapes and GitHub's group/boilerplate markers so you see the failure without the noise of the full log. See the [CI Log Extraction](#ci-log-extraction) section for the recipe.
+**How does `make logs` work?**
+The first argument is the GitHub Actions run ID (as shown by `gh run list`). If invoked without a second argument, it extracts and formats logs for **all failed steps** using `gh run view --log-failed`. An optional second argument filters down to a specific step using substring matching, stripping ANSI escapes and GitHub boilerplate so you see the failure without noise. See [CI Log Extraction](#ci-log-extraction).
 
 ## Probe Script
 
@@ -204,7 +205,8 @@ ci-watch:
 	  if [ -n "$$NEWSTEPS" ]; then \
 	    echo "$$WF: failing step(s): $$NEWSTEPS (run $$NEW)"; \
 	    gh run view "$$NEW" --log-failed 2>/dev/null | awk -F'\t' '{ l=$$3; p=index(l,"Z "); if(p>0)l=substr(l,p+2); gsub(/\x1B\[[0-9;]*[a-zA-Z]/,"",l); gsub(/\^\[\[[0-9;]*[a-zA-Z]/,"",l); if(l ~ /^##\[group\]/ || l ~ /^##\[endgroup\]/) next; gsub(/^##\[error\]/,"Error: ",l); print l }' | tail -n $(DETAIL_LINES) | sed 's/^/    /'; \
-	    echo "  full log: make logs $$NEW '$$NEWSTEPS'"; \
+	    echo "  view all failed logs: make logs $$NEW"; \
+	    echo "  view specific step:   make logs $$NEW '<step-name>'"; \
 	  fi; \
 	  if [ "$$NEWCONC" != "failure" ]; then \
 	    if [ -n "$$NEWFAIL" ]; then \
@@ -267,7 +269,7 @@ probe:
 
 ## CI Log Extraction
 
-The Debugger's Reproduction phase needs to read the logs of a specific failed CI step without drowning in the full run log. The `make logs` target wraps the `gh run view <id> --log | awk ...` pipeline that isolates the named step's output, strips ANSI escapes, and removes GitHub's `##[group]`/`##[endgroup]` boilerplate.
+The Debugger's Reproduction phase needs to read CI logs without drowning in the full run output. The `make logs` target wraps the `gh run view` pipeline, strips ANSI escapes, and removes GitHub's `##[group]`/`##[endgroup]` boilerplate.
 
 ### Example
 
@@ -276,21 +278,26 @@ 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; }
-	@gh run view "$(LOGS_RUN)" --log | awk -F'\t' -v step="$(LOGS_STEP)" '$$2==step { if(j!=$$1){j=$$1; print "\n["j"]"} l=$$3; p=index(l,"Z "); if(p>0)l=substr(l,p+2); gsub(/\x1B\[[0-9;]*[a-zA-Z]/, "", l); gsub(/\^\[\[[0-9;]*[a-zA-Z]/, "", l); if(l ~ /^##\[group\]Run /){k=1;next} if(k && l ~ /^##\[endgroup\]/){k=0;next} if(k)next; if(l ~ /^##\[group\]/ || l ~ /^##\[endgroup\]/)next; gsub(/^##\[error\]/, "Error: ", l); print l }'
+	@[ -n "$(LOGS_RUN)" ] || { echo "Usage: make logs <run-id> ['<step-name>']"; exit 1; }
+	@if [ -z "$(LOGS_STEP)" ]; then \
+	  gh run view "$(LOGS_RUN)" --log-failed 2>/dev/null | awk -F'\t' '{ if(j!=$$1||s!=$$2){j=$$1;s=$$2;print "\n["j" > "s"]"} l=$$3; p=index(l,"Z "); if(p>0)l=substr(l,p+2); gsub(/\x1B\[[0-9;]*[a-zA-Z]/,"",l); gsub(/\^\[\[[0-9;]*[a-zA-Z]/,"",l); if(l ~ /^##\[group\]Run /){k=1;next} if(k && l ~ /^##\[endgroup\]/){k=0;next} if(k)next; if(l ~ /^##\[group\]/ || l ~ /^##\[endgroup\]/)next; gsub(/^##\[error\]/,"Error: ",l); print l }'; \
+	else \
+	  gh run view "$(LOGS_RUN)" --log 2>/dev/null | awk -F'\t' -v step="$(LOGS_STEP)" 'index($$2, step) > 0 { if(j!=$$1||s!=$$2){j=$$1;s=$$2;print "\n["j" > "s"]"} l=$$3; p=index(l,"Z "); if(p>0)l=substr(l,p+2); gsub(/\x1B\[[0-9;]*[a-zA-Z]/,"",l); gsub(/\^\[\[[0-9;]*[a-zA-Z]/,"",l); if(l ~ /^##\[group\]Run /){k=1;next} if(k && l ~ /^##\[endgroup\]/){k=0;next} if(k)next; if(l ~ /^##\[group\]/ || l ~ /^##\[endgroup\]/)next; gsub(/^##\[error\]/, "Error: ", l); print l }'; \
+	fi
 
 %:
 	@:
 ```
 
 **Usage:**
-- `make logs 12345 'Run tests'` — extract the logs of the step named `Run tests` from run `12345`.
-- First discover the run ID and the failed step name with `gh run view 12345` (the execution tree), then pass both to `make logs`.
+- `make logs 12345` — extract logs for ALL failed steps from run `12345`.
+- `make logs 12345 'Run tests'` — extract logs for a specific step (substring match) from run `12345`.
 
 **How it works:**
-- `$(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.
+- `$(word 2,$(MAKECMDGOALS))` takes the run ID and `$(wordlist 3,99,$(MAKECMDGOALS))` captures any optional step name.
+- When no step name is provided, `gh run view --log-failed` is used so only failed steps are fetched and printed with `[job > step]` headers.
+- When a step name is supplied, `index($2, step) > 0` performs substring matching against column 2.
+- Timestamps and ANSI escapes are stripped, and `##[error]` lines are prefixed with `Error: `.
 
 ## Implementation Notes
 

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

@@ -0,0 +1,17 @@
+# 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]

teddy_cli-0.1.17.dev1279/src/teddy_executor/resources/templates/specification-document.md

@@ -0,0 +1,12 @@
+# Spec: {{invariant}}
+- **Status:** Active
+
+## Overview
+Context for the permanent system invariant, the contract it establishes, and the architectural risk it mitigates.
+
+## Guiding Principles
+Foundational rules and philosophical constraints governing this specification.
+- **PrincipleName:** Description of constraint and how it binds design decisions.
+
+## Technical Specifications
+Use flexible subheadings tailored to the invariant (e.g. Data Models, Payload Schemas, CLI Syntax, File Formats, State Transitions, Sequence Flow). May contain logic, formats, directory structures, or workflow diagrams.

teddy_cli-0.1.17.dev1279/src/teddy_executor/resources/templates/vertical-slice.md

@@ -0,0 +1,76 @@
+# Slice: {{feature_name}}
+- **Status:** [Planned | In Progress | Completed]
+- **Milestone:** [link]
+- **Specs:** [links]
+- **Prototype:** [link]
+- **Component Docs:** [links]
+- **Scope Slug:** `feature-slug`  <!-- 1-2 kebab-case words only. -->
+
+## Business Goal
+1-2 sentences describing the user need and measurable value delivered by this slice.
+
+## Scenarios
+> As a [user type], I want to [action] so that [benefit].
+
+```gherkin
+Given [precondition]
+When [action]
+Then [expected outcome]
+```
+
+## Edge Cases
+- **Title**: If [condition], then [behavior], because [reason/invariant].
+
+## Key Unknowns
+
+**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, runtime performance, concurrency, or data-storage feasibility. Resolve via automated assertion probes in `spikes/`.
+- `[Functional]` = User-facing ergonomics, CLI flags, terminal rendering, interactive flows, or layout aesthetic. Resolve via interactive scenario runners in `spikes/`.
+
+**Mandatory De-risking Triggers:**
+1. Log any new or modified integration with an external system, library, API, storage layer, or performance constraint as `[Technical]`.
+2. Log any new or modified user interaction, CLI flags, terminal formatting, or interactive UX flow as `[Functional]`.
+3. Log any business rule, policy, or scope ambiguity as `[Domain]`.
+
+**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").
+
+**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
+
+## Deliverables
+
+**Types:**
+- **Env:** Declarative tooling, build files, CI workflows, hooks, or config templates.
+- **Wiring:** Outermost boundary tracer bullet returning skeleton/fake data.
+- **Contract:** Signatures, ports, interfaces, DTOs, domain models.
+- **Harness:** Modifying or extending shared test infrastructure (Drivers, Observers, Fakes, Setup fixtures).
+- **Logic:** Core domain logic and business rules driven by unit tests.
+- **Migration:** Adapting existing consumers to new contracts.
+- **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:
+`(Env) -> Wiring -> Contract -> Harness -> Logic -> Migration -> Refactor -> Cleanup`
+
+**Format:**
+- [ ] **Wiring** - Connect outermost boundaries with skeleton response.
+- [ ] **Contract** - Define port interfaces and DTOs.
+- [ ] **Logic** - Implement business logic replacing skeleton responses.
+
+## Implementation Notes
+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.
+
+**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.

teddy_cli-0.1.17.dev1277/src/teddy_executor/resources/templates/ARCHITECTURE.md

@@ -1,57 +0,0 @@
-# System Architecture: {{project_name}}
-
-## 1. Conventions & Standards
-
-This section defines foundational engineering practices. Each entry MUST be a specific, enforceable rule.
-
-**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).
-- **Run Environment:** Designated runner (e.g., `uv run`, `poetry run`).
-- **Failure Transparency:** Error handling policy — specific exceptions only, no silent suppression.
-- **Testing Strategy:** 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, and strictly autospec-bound mocks only for un-fakeable external side-effects.
-- **Runtime Contract Assertions:** Enforce Design-by-Contract with native `assert condition, "message"` for pre/post-conditions and invariants (strippable via `python -O`); never custom exceptions for contract checks.
-- **Dependency Injection:** Constructor injection mandate; forbid Service Locator and global containers.
-- **Centralized Configuration:** Config file location, prohibition of magic numbers.
-- **CI Pipeline:** Two parallel jobs — 1) Blocking OS matrix test suite with strict test coverage targets. 2) Non-blocking (continue-on-error: true) quality checks running fast formatters, linters, security/secret scanners, type checkers, and repository-wide structural checks (excluding sandboxes and third-party dependencies).
-- **Pre-commit Hooks:** Scope (staged files only) and keep the local loop fast — formatters, secret scanners, and merge-conflict checks only. Move heavy, false-positive-prone checks (type checkers, security scanners, repository-wide structural checkers) to the non-blocking CI quality job, scoped to a non-default pre-commit stage.
-- **Post-commit Execution:** Full test suite run on commit, automatic revert on failure.
-- **Makefile Commands:** The `Makefile` is the canonical entry point for the VCP commit workflow and on-demand test runs. `make test` runs the full suite, `make commit '<msg>'` performs a LOCAL-ONLY VCP commit (it runs the pre-commit hooks once as an advisory auto-fix pass and commits WITHOUT `--no-verify`, so Git's own pre-commit hook is the real local gate, while the post-commit test gate remains unskippable), `make push` rebases and pushes, `make ci-watch` watches remote CI and reports results (used by Developer at slice conclusion), and `make probe '<reason>'` runs the Remote Probing Protocol. See [docs/templates/makefile.md](docs/templates/makefile.md).
-
-### Pre-commit Quick-Start
-
-```shell
-pre-commit install                          # install the pre-commit stage hook
-pre-commit install --hook-type post-commit  # install the post-commit test gate
-pre-commit run --all-files                  # run all hooks manually against the repo
-```
-
-## 2. Component & Boundary Map
-
-Single source of truth for system structure, organized by architectural layer.
-
-**Template format (table):**
-
-| Component         | Description                     | Contract                                     |
-| ----------------- | ------------------------------- | -------------------------------------------- |
-| **ComponentName** | One-line responsibility summary | [Link to design doc](./path/to/component.md) |
-
-### Required Layers:
-- **Hexagonal Core:** Domain models, Ports (inbound/outbound), Services.
-- **Primary Adapters:** CLI, web UI, API controllers.
-- **Outbound Adapters:** File system, database, external APIs, shell.
-- **Test Harness:** Drivers, Observers, Setup fixtures.
-
-Each Contract column links to the Component Design Document or Interface definition.
-
-## 3. Key Architectural Decisions
-
-A living "System Law" document capturing explicit, prescriptive design decisions.
-
-**Template format:** `- **Subject:** Strict Rule. (Rationale.)`
-
-### Rules for this section:
-- Each entry MUST be a single enforceable rule with a brief rationale.
-- Add new entries as decisions are made; never remove without deprecation notice.
-- Note exceptions explicitly with their rationale.

teddy_cli-0.1.17.dev1277/src/teddy_executor/resources/templates/case-file.md

@@ -1,49 +0,0 @@
-# Bug: {{bug_title}}
-- **Status:** Unresolved
-- **Milestone:** [link or N/A]
-- **Vertical Slice:** [link or N/A]
-- **Specs:** [links or N/A]
-
-## Symptoms
-
-**Format:** Describe what should happen vs. what actually happens. Include concrete, reproducible steps to trigger the bug.
-Expected vs. Actual behavior and minimal reproduction steps.
-
-## Context & Scope
-### Regressing Delta
-
-**Format:** Git commit hash, file paths, and line numbers of the changes that introduced the bug.
-[Identify the exact changes responsible for the regression to narrow the search space.]
-
-### Environmental Triggers
-
-**Format:** OS, Python version, config values, environment variables, or any other necessary conditions.
-[Describe the specific OS, configurations, or state conditions required to reproduce the issue.]
-
-### Ruled Out
-
-**Format:** Bulleted list of investigated and ruled-out items.
-[List any components, layers, or files definitively proven to be unrelated to the bug.]
-
-## Diagnostic Analysis
-### Causal Model
-
-**Format:** 1-3 paragraphs explaining the chain of events leading to the bug. Continuously updated as investigation progresses.
-A concise, causal description of how the faulty SUT operates.
-
-### Discrepancies
-
-**Format:** `- Observation. Conflict. (Resolved: Explanation)` — keep resolved items with their resolution.
-A concise list of observations that contradict the current Causal Model.
-- Observation. Conflict. (Resolved: Explanation)
-
-### Investigation History
-
-**Format:** `N. Hypothesis. Observation. Conclusion.`
-A concise, numbered log of investigation attempts.
-N. Hypothesis. Observation. Conclusion.
-
-## Solution
-
-**Format:** 1-2 paragraphs explaining the root cause, the specific fix applied, and any systemic changes needed to prevent this class of bug.
-A high-level explanation of the root cause, the proven fix, and the systemic preventative measures to prevent this class of issue globally.