teddy-cli 0.1.17.dev1276__tar.gz → 0.1.17.dev1278__tar.gz

{teddy_cli-0.1.17.dev1276 → teddy_cli-0.1.17.dev1278}/PKG-INFO

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

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

@@ -18,18 +18,18 @@
         <step n="2" name="Iteration Loop">Iterate until internal workings are deeply understood and all Technical and Functional unknowns are resolved. If an unexpected failure occurs, isolate it using a focused sub-prototype. Update Key Unknowns with any emerging uncertainties.</step>
       </phase>
 
-      <phase n="3" name="Documentation">
-        <goal>Translate verified findings into buildable slices, component designs, and specifications.</goal>
-        <step n="1" name="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.</step>
-        <step n="2" name="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.</step>
-      </phase>
-
-      <phase n="4" name="Alignment">
+      <phase n="3" name="Alignment">
         <goal>Present prototype findings and demo to the user for explicit validation and approval.</goal>
         <step n="1" name="Showcase Presentation">Message the user to present findings in clear prose. For Technical unknowns, provide raw assertion evidence or benchmarks. For Functional unknowns, provide copy-pasteable execution commands and list adjustable knobs. Present the updated slice deliverables and component specifications.</step>
         <step n="2" name="Approval Gate">Await explicit user approval before proceeding to the Conclusion phase. If the user requests changes, refine the prototypes and artifacts, re-run verification, and re-align.</step>
       </phase>
 
+      <phase n="4" name="Documentation">
+        <goal>Translate verified findings into buildable slices, component designs, and specifications.</goal>
+        <step n="1" name="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.</step>
+        <step n="2" name="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.</step>
+      </phase>
+
       <phase n="5" name="Conclusion">
         <goal>Clean workspace, commit changes, push, and hand off to the Developer.</goal>
         <step n="1" name="Cleanup">Delete scratch files and unapproved probes, preserving only the approved prototype directory under `spikes/prototypes/{scope-slug}/`.</step>

{teddy_cli-0.1.17.dev1276 → teddy_cli-0.1.17.dev1278}/src/teddy_executor/resources/templates/ci.md

@@ -15,8 +15,8 @@ The CI pipeline consists of two parallel jobs:
 - **Blocking:** If this job fails, the CI pipeline is marked as failed.
 
 ### Job 2: Non-Blocking Quality Checks
-- Runs the pre-commit hooks in two explicit passes: the fast hooks (formatters, `detect-secrets`, merge-conflict check) at the default `pre-commit` stage, then the heavy hooks (type checkers, security/dependency scanners, and the repository-wide structural checkers) at the non-default `manual` stage.
-- The heavy hooks are scoped to the `manual` stage so they never slow down the local pre-commit loop; CI invokes both stages explicitly.
+- Runs granular quality checks in separate steps with `if: success() || failure()`, ensuring that all checks execute and report their outcomes even if an earlier check fails.
+- Scopes heavy checks (type checkers, security/dependency scanners, structural checkers) to the non-default `manual` stage so they never slow down the local pre-commit loop.
 - Excludes sandboxes (`spikes/`) and third-party dependencies.
 - **Non-Blocking:** Configured with `continue-on-error: true` so quality failures do not block the pipeline.
 
@@ -97,16 +97,32 @@ jobs:
       - name: Install dependencies
         run: {runner} sync --frozen
 
-      # Quote any step name that contains a colon. An unquoted YAML plain
-      # scalar cannot contain ": " (colon+space) — it would be parsed as a
-      # nested mapping and fail the entire workflow.
-      - name: "Run Pre-commit Hooks (fast: formatters, secrets)"
+      # Each check runs with `if: success() || failure()` so all checks run
+      # even if an earlier check fails.
+      - name: "Secrets Check (detect-secrets)"
+        if: success() || failure()
         run: |
-          {runner} pre-commit run --all-files
+          {runner} pre-commit run detect-secrets --all-files
 
-      - name: "Run Pre-commit Hooks (heavy: types, security, structural)"
+      - name: "Code Formatting (ruff format)"
+        if: success() || failure()
         run: |
-          {runner} pre-commit run --all-files --hook-stage manual
+          {runner} pre-commit run ruff-format --all-files
+
+      - name: "Linter (ruff check)"
+        if: success() || failure()
+        run: |
+          {runner} pre-commit run ruff-lint --all-files
+
+      - name: "Type Checker (mypy)"
+        if: success() || failure()
+        run: |
+          {runner} pre-commit run mypy --all-files --hook-stage manual
+
+      - name: "Security Audit (bandit & pip-audit)"
+        if: success() || failure()
+        run: |
+          {runner} pre-commit run bandit pip-audit --all-files --hook-stage manual
 ```
 
 ## Debug Workflow (Remote Probing Protocol)

{teddy_cli-0.1.17.dev1276 → teddy_cli-0.1.17.dev1278}/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