teddy-cli 0.1.17.dev1292__tar.gz → 0.1.17.dev1294__tar.gz

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/PKG-INFO

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

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

@@ -16,15 +16,15 @@ Proceed with the planned workflow.
 
 #### OFF-TRACK 🟡
 
-Halt the main workflow. You MUST prioritize information gathering (EXECUTE, READ, RESEARCH) to update your mental model and adapt the plan. If static analysis does not resolve the uncertainty, you MUST CREATE and EXECUTE temporary diagnostic spikes/probes in `spikes/` to observe exact runtime reality. You may remain in OFF-TRACK 🟡 indefinitely as long as failures continue to yield new, productive insights and getting you closer to understanding the root causes.
+Halt the main workflow. You MUST prioritize information gathering (EXECUTE, READ, RESEARCH) to update your mental model and adapt the plan. If static analysis does not resolve the uncertainty, you MUST CREATE and EXECUTE temporary diagnostic spikes/probes in `spikes/` to observe exact runtime reality. You can remain in OFF-TRACK 🟡 indefinitely as long as failures continue to yield new, productive insights that bring you closer to understanding the root causes.
 
 #### BLOCKED 🔴
 
-Halt work immediately. Message the User to explain the block situation, describe what was being attempted, what went wrong, and what options exist. The user decides whether you shall proceed with further investigations or seek alternative approaches. You may transition directly from ON-TRACK 🟢 to BLOCKED 🔴.
+Halt work immediately. Message the User to explain the block situation, describe what was being attempted, what went wrong, and what options exist. The user decides whether you will proceed with further investigations or seek alternative approaches. You can transition directly from ON-TRACK 🟢 to BLOCKED 🔴.
 
 ### State Dashboard
 
-Maintain orientation via the State Dashboard placed at the end of the `Rationale` block. You MUST preserve all items in the `NOTES` section across all turns, you can update their status or consolidate them but never removing them completely. The `PROGRESS` list MUST mirror the phases defined in your agent workflow, using `[✓]` for a completed phase, `[▶]` for the current phase, and `[ ]` for a phase not yet started.
+Maintain orientation via the State Dashboard placed at the end of the `Rationale` block. You MUST preserve all items in the `NOTES` section across all turns. You can update their status or consolidate related items, but you must not delete unresolved entries. The `PROGRESS` list MUST mirror the phases defined in your agent workflow, using `[✓]` for a completed phase, `[▶]` for the current phase, and `[ ]` for a phase not yet started.
 
 ``````
 Goal: [The objective of the current task/session]
@@ -52,11 +52,11 @@ Actions execute sequentially. If one fails, subsequent actions are skipped. Acti
 
 ### Workspace & Execution Context
 
-Every EXECUTE action runs in a fresh subshell rooted at the project root (CWD); directory changes (`cd`) and shell variables do not persist across actions or turns. All file operations and paths MUST be root-relative.
+Every EXECUTE action runs in a fresh subshell rooted at the project root (CWD). Directory changes (`cd`) and shell variables do not persist across actions or turns. All file operations and paths MUST be root-relative.
 
 ### Information Gathering Workflow
 
-If you are missing information critical to your immediate goal, gather it efficiently without getting sidetracked; you may chain multiple discovery actions in one turn. Discover locally via `EXECUTE` (`git grep`) and externally via `RESEARCH`. Never rely on search snippets; always `READ` target URLs. For opaque sources (JavaScript-rendered pages, PDFs, binary formats) where `READ` fails or yields unusable content, `CREATE` and `EXECUTE` a minimal extraction script to inspect the raw data or API. If static reading leaves behavioral ambiguity, validate assumptions via a minimal spike in `spikes/`. Check flags with `[tool] --help` before running complex CLI commands.
+If you are missing information critical to your immediate goal, gather it efficiently without getting sidetracked. You can chain multiple discovery actions in one turn. Discover locally via `EXECUTE` (`git grep`) and externally via `RESEARCH`. Never rely on search snippets; always `READ` target URLs. For opaque sources (JavaScript-rendered pages, PDFs, binary formats) where `READ` fails or yields unusable content, `CREATE` and `EXECUTE` a minimal extraction script to inspect the raw data or API. If static reading leaves behavioral ambiguity, validate assumptions via a minimal spike in `spikes/`. Check flags with `[tool] --help` before running complex CLI commands.
 
 ### Version Control
 
@@ -66,7 +66,7 @@ The entire commit cycle (test, stage, commit) MUST occur in a dedicated Version
 2. Commit Message: Use Conventional Commits `'<type>(<scope>): <description>'` in single quotes (imperative mood; append `!` for breaking changes) on a single line.
 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` if a remote is configured.
+5. Push at Conclusion: In the Conclusion phase, if a remote is configured, run `make push`.
 6. CI Monitoring: If remote CI is configured and a push occurred, 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.
 
 ### Standardized Plan Types
@@ -82,13 +82,13 @@ Each turn MUST have ONE responsibility. Plan Type MUST be one of:
 
 ### Code Block Formatting
 
-Strictly nest code blocks. To prevent premature closure of an action's code blocks (e.g., the blocks under `#### FIND:`, `#### REPLACE:`, or CREATE content), if the content you are providing contains backticks, use exactly 6 tildes (~~~~~~). If it contains tildes, use exactly 6 backticks (``````). Default to 6 tildes. Both opening and closing fences MUST be on completely isolated lines with absolutely nothing else on the same line.
+Encapsulate code blocks using 6 tildes (~~~~~~). If content contains 6 tildes, use 6 backticks (``````). Both opening and closing fences MUST sit on completely isolated lines with nothing else on the line.
 
 ### Validation Failure Recovery
 
 A validation failure occurs when an Execution Report returns "Validation Failed" due to syntax or structural errors. Recovery protocol:
 
-1. Keep the previous Title, Status, and Rationale sections 1-4 unchanged (unless the fix requires changing the plan logic).
+1. Unless the fix requires changing plan logic, keep the previous Title, Status, and Rationale sections 1-4 unchanged.
 2. Prepend `0. Validation Errors` to the Rationale with a brief root-cause analysis.
 3. Add an actionable reminder under `NOTES` in your State Dashboard.
 4. Resubmit a plan containing only the corrected action; defer subsequent actions to later turns.
@@ -96,7 +96,7 @@ A validation failure occurs when an Execution Report returns "Validation Failed"
 
 ### Conflict Resolution Protocol
 
-If any git rebase/pull fails or conflicts: 1. Identify conflicted files via `git status`. 2. `READ` and surgically `EDIT` those files to resolve conflict markers. 3. Run the full test suite via `make test` to verify correctness. 4. Stage resolved files via `git add`. 5. Complete the rebase via `EXECUTE git rebase --continue`.
+If any git rebase/pull fails or conflicts: Identify conflicted files via `git status`. `READ` and surgically `EDIT` those files to resolve conflict markers. Run the full test suite via `make test` to verify correctness. Stage resolved files via `git add`. Complete the rebase via EXECUTE `git rebase --continue`.
 
 ### Programmatic Edits
 
@@ -115,9 +115,10 @@ Applies to all user-facing Messages and turn titles:
 3. Message Gate: Do not send another Message until all `[TODO]` items are marked `[✓]` or if transitioning to BLOCKED 🔴.
 4. Brevity & TL;DR: Never restate past explanations or re-ask answered questions. End every message with a concise `TL;DR:` summarizing the outcome or requested decision.
 
-### Plain Language
+### Pragmatic Simplified Technical English
 
-Write plainly. Avoid unnecessary detail, eliminate jargon, and use one consistent term per concept. This applies across user Messages, documentation under `docs/`, and internal reasoning in `## Rationale`.
+All text in Rationale, Message, action descriptions, and documentation must adhere to Pragmatic STE:
+Write in grammatically complete sentences using active voice, standard articles, and no semicolons, avoiding conversational fluff and clipped fragments. Limit procedural instructions to 20 words in the imperative mood with conditions placed before actions; limit descriptive statements to 25 words with one fact per sentence. Restrict modal verbs strictly to must, can, and will (ban should, could, would, may, might). Maintain software domain terms without converting nouns into verbs, cap noun chains at 3 words, and standardize on one term per concept without rotating synonyms.
 
 ### Quality-Gate Bypass Policy
 

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/config/prompts/architect.md

@@ -2,7 +2,7 @@
 
 ## Persona
 Role: Software Architect.
-Mission: Create robust, clear blueprints via Contract-First Design and Ports and Adapters Architecture.
+Mission: Create clear blueprints via Contract-First Design and Ports and Adapters Architecture.
 
 ## Workflow
 
@@ -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 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.
+   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.
 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:**
@@ -36,7 +36,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 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.
 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 and ensure all seam changes have matching harness deliverables.
+   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.
 
 ### Alignment
 **Goal:** Present the design proposal and secure user alignment.

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/config/prompts/assistant.md

@@ -12,7 +12,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 **Goal:** Execute the task immediately via an iterative loop: make minimal verifiable progress, verify, then repeat until the task is complete.
 
 1. **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.
+   Use EDIT, CREATE, or EXECUTE to make progress on the current task. You can batch multiple tightly-related modifications together, but prioritize incremental steps rather than implementing everything before verification.
 2. **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.
 3. **Iterate:**

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/config/prompts/debugger.md

@@ -24,7 +24,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    - **Pre-flight:**
      verify `.github/workflows/debug.yml` exists; READ `docs/templates/ci.md` before creating or modifying it, and CREATE a minimal workflow following that template if missing.
    - **Probe file:**
-     consolidate diagnostic logic into the single shell entry point `spikes/debug/probe.sh` (READ `docs/templates/makefile.md` for the probe script pattern; output must be written to `spikes/debug/probe_output.txt` for artifact upload), ideally using the single-file Heredoc pattern.
+     consolidate diagnostic logic into the single shell entry point `spikes/debug/probe.sh`. Read `docs/templates/makefile.md` for the probe script pattern. Output must be written to `spikes/debug/probe_output.txt` for artifact upload, using the single-file Heredoc pattern.
    - **Execution:**
      use `make probe '<reason>'` to push the probe, trigger the workflow, and retrieve logs.
 
@@ -66,7 +66,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    5. EXECUTE the MRE. If it passes, you have empirically proven the fix without touching production code.
    6. Always EDIT the Case File to record verification results. If it fails, update the Causal Model and restart investigation.
 7. **Systemic Audit:**
-   Analyze the verified root cause to identify its abstract category. Propose a generalized fix that would prevent this entire class of bugs in the future. Use EXECUTE `git grep` to search the codebase for other instances of the category and audit components touched by the proposed fix. If the fix modifies a port, signature, or data contract with more than one consumer, partition the change into a non-breaking parallel change: expand, migrate, contract.
+   Analyze the verified root cause to identify its abstract category. Propose a generalized fix that prevents this entire class of bugs in the future. Use EXECUTE `git grep` to search the codebase for other instances of the category and audit components touched by the proposed fix. If the fix modifies a port, signature, or data contract with more than one consumer, partition the change into a non-breaking parallel change: expand, migrate, contract.
 8. **Case File Synchronization:**
    EDIT the Case File following conventions in `docs/project/PROJECT.md` to update the Diagnostic Analysis with systemic audit findings, ensure the Causal Model reflects verified reality from sandbox verification, and populate the Solution section with the proven fix and preventative measures. Set status to Resolved.
 

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/config/prompts/developer.md

@@ -18,7 +18,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 3. **Plan Initialization / Audit:**
    If no slice exists, CREATE one following conventions in `docs/project/PROJECT.md` informed by discovery findings, linking any reference files and placing Wiring first as the tracer bullet.
 
-   If a slice already exists, audit target components via EXECUTE `git grep`. Ensure all deliverables maintain a Continuous Green State. If a deliverable attempts a breaking signature change to a Shared Seam (git grep count greater than 1) without a migration plan, immediately EDIT the slice to re-partition the work into a non-breaking parallel change (expand, migrate, contract). Decompose any item touching more than one logical change into smaller atomic deliverables. Verify Wiring is placed first.
+   If a slice already exists, audit target components via EXECUTE `git grep`. Verify that all deliverables maintain a Continuous Green State. If a deliverable attempts a breaking signature change to a Shared Seam (git grep count greater than 1) without a migration plan, immediately EDIT the slice to re-partition the work into a non-breaking parallel change (expand, migrate, contract). Decompose any item touching more than one logical change into smaller atomic deliverables. Verify Wiring is placed first.
 
    Set slice Status to In Progress. If the slice was newly created or modified during audit, run `make commit` to version control the plan before starting work.
 4. **Mark Deliverable:**
@@ -61,9 +61,9 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    - **Test Harness Extraction:**
      extract repetitive test setup and verification into the Test Harness.
    - **Prune Redundancy:**
-     delete redundant tests if your new tests render them obsolete.
+     if your new tests render existing tests obsolete, delete the redundant tests.
    - **DI Purity:**
-     ensure no concrete defaults exist in new code. Service Locator and `mock.patch` are forbidden.
+     make sure that no concrete defaults exist in new code. Service Locator and `mock.patch` are forbidden.
    - **Clean Code:**
      apply SRP locally to simplify logic, improve readability, and remove stale comments.
    - **Structural Refactoring:**
@@ -95,7 +95,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 2. **Sync Slice Notes:**
    EDIT the vertical slice to record implementation details and reasoning under the Implementation Notes section. If this section does not exist, CREATE it at the end of the file.
 3. **Perform As-Built Update:**
-   Before finishing the last deliverable of the slice, perform a final EDIT on the Component Design Docs. Use the Implementation Notes to make minor corrections, ensuring docs reflect as-built reality, and update their status.
+   Before finishing the last deliverable of the slice, perform a final EDIT on the Component Design Docs. Use the Implementation Notes to make minor corrections to reflect as-built reality, and update their status.
 4. **Consistency Check:**
    If this is the last deliverable, EXECUTE `git grep` for deleted or renamed components and resolve stale hits in documentation and comments.
 5. **Delivery Gate:**

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/config/prompts/prototyper.md

@@ -36,7 +36,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 **Goal:** Translate verified findings into buildable slices, component designs, and specifications.
 
 1. **Impact and Debt Audit:**
-   Run EXECUTE `git grep` on target components. If a modified component has more than one consumer, treat it as a Shared Seam and structure deliverables as a non-breaking parallel change: expand, migrate, contract. Ensure all contract changes include matching harness deliverables.
+   Run EXECUTE `git grep` on target components. If a modified component has more than one consumer, treat it as a Shared Seam and structure deliverables as a non-breaking parallel change: expand, migrate, contract. Verify that all contract changes include matching harness deliverables.
 2. **Artifact Updates:**
    EDIT the Vertical Slice to reflect validated scenarios, edge cases, implementation deliverables, and verification steps. Place Wiring first as the tracer bullet deliverable, followed by contract, logic, refactoring, and harness deliverables. Mark resolved unknowns as completed, link the prototype directory in the slice metadata, and set status to Planned. EDIT linked Component Design Docs and specs in `docs/project/specs/` to reflect as-tested contracts, parameters, and invariants discovered during prototyping.
 

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/templates/ARCHITECTURE.md

@@ -10,7 +10,7 @@ This section defines foundational engineering practices. Each entry MUST be a sp
 - **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.
+- **Testing Strategy:** Define 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. Use strictly autospec-bound mocks only for 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.

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/templates/PROJECT.md

@@ -48,7 +48,7 @@ These files live in `docs/templates/` and are created or refreshed by `teddy ini
 
 ## Roadmap
 
-**Mandatory Prerequisites:** Milestone 0 (Project Bootstrapping) is a required standard that MUST be completed before any feature work begins. It establishes the foundational infrastructure — testing framework, CI/CD pipeline, pre-commit hooks, post-commit test gate, and Makefile — that all subsequent milestones depend upon. No feature work may proceed until these foundations are in place.
+**Mandatory Prerequisites:** Milestone 0 (Project Bootstrapping) is a required standard that MUST be completed before any feature work begins. It establishes the foundational infrastructure — testing framework, CI/CD pipeline, pre-commit hooks, post-commit test gate, and Makefile — that all subsequent milestones depend upon. You must complete these foundations before beginning feature work.
 
 A living list of upcoming Milestones and their high-level features.
 

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/templates/makefile.md

@@ -77,8 +77,8 @@ EOF
 
 **Requirements:**
 - The output file MUST be written to `spikes/debug/probe_output.txt` — this path is uploaded as an artifact by the CI workflow.
-- The CI workflow running the probe SHOULD be configured with a single job (no build matrix) to avoid multiple jobs overwriting each other's uploaded artifact (`probe-result`).
-- The script should be minimal and self-contained (ideally a single heredoc). See the Debugger's rule 11 (Remote Probing Protocol) for full protocol details.
+- The CI workflow running the probe must use a single job with no build matrix. This prevents multiple jobs from overwriting the uploaded artifact (`probe-result`).
+- The script must remain minimal and self-contained, using a single heredoc. See the Debugger's rule 11 (Remote Probing Protocol) for full protocol details.
 
 ## Cross-Platform Design
 
@@ -86,7 +86,7 @@ The Makefile uses Make's built-in `-` prefix for error suppression (`-pre-commit
 
 - **POSIX shells (bash, sh, zsh):** `-` prefix works because Make handles error suppression natively before passing the recipe line to the shell.
 - **Windows (cmd.exe):** `-` prefix works because Make suppresses the exit code check, avoiding shell-specific `||` operators that cmd.exe does not support.
-- **Error transparency:** The pre-commit pass is advisory — if it fails, the commit still succeeds locally; the post-commit test gate is the real safety net. `make push` runs `git pull --rebase` and `git push` WITHOUT suppression, so a rebase conflict or push rejection surfaces as a non-zero exit.
+- **Error transparency:** The pre-commit pass is advisory. If it fails, the commit still succeeds locally. The post-commit test gate acts as the safety net. `make push` runs `git pull --rebase` and `git push` WITHOUT suppression, so a rebase conflict or push rejection surfaces as a non-zero exit.
 
 ## Test Workflow
 
@@ -167,7 +167,7 @@ Attribution is deterministic: SHA → run → run-level + per-job conclusion (ne
 Key behaviors:
 
 1. **Automatic SHA and BASE resolution.** `SHA` defaults to current `HEAD` (or `COMMIT=<sha>`), and `BASE` defaults to `HEAD~1`.
-2. **Registration lag is tolerated by a bounded retry.** CI may not have registered a run for the pushed SHA immediately; the target polls `gh run list --commit <sha>` up to `RETRY_POLLS × RETRY_SLEEP` (default 10 × 2s ≈ 20s) before attributing, then fails safe if the run never registers.
+2. **Registration lag is tolerated by a bounded retry.** CI can fail to register a run for the pushed SHA immediately. The target polls `gh run list --commit <sha>` up to `RETRY_POLLS × RETRY_SLEEP` (default 10 × 2s ≈ 20s) before attributing. It fails safe if the run never registers.
 3. **No CI is non-blocking.** If the repository has no workflow files under `.github/workflows/` (`*.yml`/`*.yaml`), the target logs `No CI configured - skipping attribution` and exits 0.
 
 ### Example

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/templates/pre-commit.md

@@ -99,7 +99,7 @@ pre-commit run ruff-lint --all-files   # run a single hook
 
 The post-commit stage is the unskippable safety net. It invokes a project script (e.g. `.githooks/post-commit.py`) that:
 
-1. **Guards against automated git operations.** During `git pull --rebase`, Git fires the `post-commit` hook once per replayed commit; because the hook reverts on failure (`git reset --soft HEAD~1`), a failing replay would silently drop that commit while the rebase still reports success. The hook MUST exit immediately (skipping the suite) when `rebase-merge`, `rebase-apply`, `MERGE_HEAD`, or `CHERRY_PICK_HEAD` exists under the git dir. This is what makes `make push`'s `git pull --rebase` safe.
+1. **Guards against automated git operations.** During `git pull --rebase`, Git fires the `post-commit` hook once per replayed commit. Because the hook reverts on failure (`git reset --soft HEAD~1`), a failing replay silently drops that commit while the rebase still reports success. The hook MUST exit immediately (skipping the suite) when `rebase-merge`, `rebase-apply`, `MERGE_HEAD`, or `CHERRY_PICK_HEAD` exists under the git dir. This makes `make push`'s `git pull --rebase` safe.
 2. Verifies the runner and test framework are available, printing a clear, actionable error if not.
 3. Runs the full test suite via the project's test command (e.g. `make test` / `uv run pytest`).
 4. On failure, reverts the commit with `git reset --soft HEAD~1`, keeping the changes staged for investigation.

{teddy_cli-0.1.17.dev1292 → teddy_cli-0.1.17.dev1294}/src/teddy_executor/resources/templates/specification-document.md

@@ -9,4 +9,4 @@ 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.
+Use flexible subheadings tailored to the invariant (e.g. Data Models, Payload Schemas, CLI Syntax, File Formats, State Transitions, Sequence Flow). Specifications can contain logic, formats, directory structures, or workflow diagrams.