teddy-cli 0.1.17.dev1331__tar.gz → 0.1.17.dev1333__tar.gz

{teddy_cli-0.1.17.dev1331 → teddy_cli-0.1.17.dev1333}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: teddy-cli
-Version: 0.1.17.dev1331
+Version: 0.1.17.dev1333
 Summary: The local-first, test-driven agentic engineering harness. Because you should own the means of development.
 Author: Raphael Atteritano
 License: AGPL-3.0-only

{teddy_cli-0.1.17.dev1331 → teddy_cli-0.1.17.dev1333}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "teddy-cli"
-version = "0.1.17.dev1331"
+version = "0.1.17.dev1333"
 description = "The local-first, test-driven agentic engineering harness. Because you should own the means of development."
 readme = "README.md"
 keywords = [

{teddy_cli-0.1.17.dev1331 → teddy_cli-0.1.17.dev1333}/src/teddy_executor/resources/MRP.md

@@ -63,8 +63,8 @@ If you are missing information critical to your immediate goal, gather it effici
 The entire commit cycle (test, stage, commit) MUST occur in a dedicated Version Control turn. Pushing is deferred to the Conclusion phase.
 
 1. Pre-conditions: Clean up temporary files. If recurring script, test, or tool detritus appears, do not just delete it manually: update `.gitignore` or configure the script to write outside tracked directories. If unsure of changes, inspect via `EXECUTE git add . && git diff HEAD`.
-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.
+2. Commit Message: Use Conventional Commits `"<type>(<scope>): <description>"` in double quotes (imperative mood; plain text without backticks, quotes, or `$`; 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, 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.

{teddy_cli-0.1.17.dev1331 → teddy_cli-0.1.17.dev1333}/src/teddy_executor/resources/config/prompts/debugger.md

@@ -14,7 +14,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 1. **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.
 2. **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).
+   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).
 3. **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.
 
@@ -26,7 +26,7 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
    - **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, using the single-file Heredoc pattern.
    - **Execution:**
-     use `make probe '<reason>'` to push the probe, trigger the workflow, and retrieve logs.
+     use `make probe "<reason>"` to push the probe, trigger the workflow, and retrieve logs.
 
 ### Investigation
 **Goal:** Peel back internal layers to resolve discrepancies and update the Causal Model.
@@ -70,22 +70,22 @@ Follow these phases and steps in order. Keep track of your progress in your Stat
 7. **Impact Audit:**
    Analyze components touched by the proposed fix. Use EXECUTE `git grep` to search for direct upstream callers (including test files and harness fixtures) and downstream dependencies (for orphaned code, unused parameters, or dead functions) that the change affects. If the fix modifies a shared port, signature, or data contract with multiple consumers, document the required migration path so the Developer can partition the change into non-breaking steps.
 8. **Case File Synchronization:**
-   EDIT the Case File to update Diagnostic Analysis, verify the Causal Model reflects sandbox reality, and record the proven fix along with affected components in the Solution section. Set status to Resolved.
+   EDIT the Case File to update Diagnostic Analysis. Verify the Causal Model reflects observed reality. Ensure that all items under Discrepancies are explained and marked resolved with `[x]` before advancing to Alignment. Record the verified root cause in the Solution section. Explicitly state whether the fix was directly resolved in `src/` or proven in the sandbox replica. Record affected components in the Solution section. Set status to Resolved in the Case File metadata.
 
 ### Alignment
 **Goal:** Present the complete diagnosis and proposed fix for explicit user approval.
 
 1. **Synthesis Presentation:**
-   Message the user explaining the root cause analysis, verified MRE evidence, affected components, and the proven solution from the Case File in clear prose.
+   Message the user explaining the root cause, verified MRE evidence, affected components, and the proven solution from the Case File in clear prose.
 2. **Approval Gate:**
    Await explicit user approval before proceeding to the Conclusion phase. If changes or refinements are requested, adjust the Case File, then re-align.
 
 ### Conclusion
-**Goal:** Clean up the workspace, commit changes, push, and hand off to the Developer.
+**Goal:** Clean up the workspace, commit changes, push, and conclude or hand off.
 
 1. **Cleanup:**
    Delete incidental temporary logs and throwaway probes. If recurring script, test, or tool detritus appears, do not just delete it manually: update `.gitignore` or configure the script to write outside tracked directories. You must preserve the final MRE script and replica proof in `spikes/debug/{scope-slug}/` and link them from the Case File.
 2. **Commit and Push:**
-   Run `make commit` to commit the Case File, preserved MRE, and replica proof. If a remote is configured, run `make push`. If blocking test failures occur, fix them immediately and push again. For non-blocking quality gate issues, address them if contained or record them in the roadmap in `docs/project/PROJECT.md`.
-3. **Handoff:**
-   Message the user with instructions to start a new session with the Developer to implement the fix, including the Case File as a reference file.
+   Run `make commit` to commit all changes, including the Case File, preserved MRE, replica proof, and direct fixes. If a remote is configured, run `make push`. If blocking test failures occur, fix them immediately and push again. For non-blocking quality gate issues, address them if contained or record them in the roadmap in `docs/project/PROJECT.md`.
+3. **Handoff and Completion:**
+   If the fix was resolved directly, message the user with a terminal completion summary. In this case, do not provide a handoff command. If the fix requires developer implementation, message the user with instructions to start a session with the Developer, including the Case File as a reference file.

{teddy_cli-0.1.17.dev1331 → teddy_cli-0.1.17.dev1333}/src/teddy_executor/resources/templates/case-file.md

@@ -31,8 +31,9 @@ Continuously log diagnostic attempts and findings in chronological order:
 2. Investigated whether [hypothesis] by [action/probe]; observed [outcome], which [conclusion].
 
 ## Solution
-### Root Cause Analysis
-Summary of verified root cause and sandbox fix.
+### Root Cause
+Summary of the verified root cause and whether the fix was directly applied to production code or proven in the sandbox replica.
 
 ### Affected Components
-Direct upstream callers, downstream dependencies, or shared contracts affected by the fix.
+Direct upstream callers, downstream dependencies, or shared contracts affected by the fix:
+- `ComponentName`: Description of changes required or completed.

{teddy_cli-0.1.17.dev1331 → teddy_cli-0.1.17.dev1333}/src/teddy_executor/resources/templates/makefile.md

@@ -9,7 +9,7 @@ and the Debugger's Remote Probing Protocol (RPP). Below are concrete examples ad
 
 ### Commit
 ```shell
-make commit 'feat(templates): add PROJECT.md template'
+make commit "feat(templates): add PROJECT.md template"
 ```
 
 **What is `.PHONY`?**
@@ -38,16 +38,16 @@ make test
 
 ### Probe
 ```shell
-make probe 'investigate windows path handling'
+make probe "investigate windows path handling"
 ```
 
 **Why does `probe` need a reason?**
-The Remote Probing Protocol requires a reason string because it is passed as the `reason` input to the GitHub Actions workflow dispatch command (`gh workflow run debug.yml --field reason='...'`). The reason documents what the probe is investigating and appears in the workflow run metadata.
+The Remote Probing Protocol requires a reason string because it is passed as the `reason` input to the GitHub Actions workflow dispatch command (`gh workflow run debug.yml --field reason="..."`). The reason documents what the probe is investigating and appears in the workflow run metadata.
 
 ### Logs
 ```shell
 make logs 12345              # extract logs for ALL failed steps
-make logs 12345 'Run tests'  # extract logs for a specific step (substring match)
+make logs 12345 "Run tests"  # extract logs for a specific step (substring match)
 ```
 
 **How does `make logs` work?**
@@ -82,11 +82,13 @@ EOF
 
 ## Cross-Platform Design
 
-The Makefile uses Make's built-in `-` prefix for error suppression (`-pre-commit run`) instead of shell-level `|| true` or `&&`/`||` chaining. This ensures cross-platform compatibility:
+Always use GNU Make native features for cross-platform compatibility instead of shell-specific constructs:
 
-- **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 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.
+- **Native argument validation:** Use `$(if $(strip $(VAR)),,$(error Usage: ...))` instead of POSIX `[ -n "$$VAR" ]`. GNU Make validates parameters before spawning any shell process.
+- **Shell-less empty recipe:** Use `%: ;` to absorb extra command-line arguments. In Windows `cmd.exe`, the Unix built-in `@:` fails because `:` is reserved syntax for labels and drives. The empty recipe `%: ;` tells Make to do nothing without spawning a subshell.
+- **Windows shell selection:** Set `SHELL := bash.exe` when `OS` is `Windows_NT` so multi-line shell pipelines (`ci-watch`, `probe`, `logs`) execute through Git Bash.
+- **Native error suppression:** The Makefile uses Make's built-in `-` prefix (`-pre-commit run`) instead of shell-level `|| true` or `&&`/`||` chaining. Make suppresses non-zero exit codes natively before passing lines to the shell.
+- **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
 
@@ -115,27 +117,27 @@ test:
 commit: ARGS := $(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS))
 
 commit:
-	@[ -n "$(ARGS)" ] || { echo "Usage: make commit '<message>'"; exit 1; }
+	$(if $(strip $(ARGS)),,$(error Usage: make commit '<message>'))
 	git add .
 	-pre-commit run
 	git add .
 	git commit -m "$(ARGS)"
 
-%:
-	@:
+# Empty recipe absorbs extra arguments without invoking a subshell.
+%: ;
 ```
 
 **Usage:**
 - `make commit 'feat(templates): add PROJECT.md template'`
 
-**Message-input contract:** the recipe captures the message from the extra `make` goals via `$(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS))`. Supported input (verified by the `spikes/debug/make-args/` findings):
+**Message-input contract:** the recipe captures the message from the extra `make` goals via `$(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS))`. Supported input:
 
-- ✅ **Single-line Conventional Commits survive verbatim** — e.g. `make commit 'feat(scope): add thing'`.
-- ❌ **`$VAR` is swallowed to empty** — `make` expands `$(...)`/`$X` before the recipe runs; avoid `$`.
-- ❌ **Backticks and quotes are stripped** by the shell quoting layer.
-- ❌ **Multiline messages fail hard** (`/bin/sh: unexpected EOF`, exit 2).
+- ✅ **Single-line Conventional Commits in double quotes survive verbatim** — e.g. `make commit "feat(scope): add thing"`. Always use double quotes across all operating systems.
+- ❌ **`$VAR` is swallowed or expanded** — `make` and shells expand `$(...)`/`$X`; avoid `$`.
+- ❌ **Backticks trigger command substitution** in POSIX shells when inside double quotes; avoid backticks.
+- ❌ **Multiline messages fail hard** (`unexpected EOF`).
 
-**Guard:** keep the commit message to a single line and avoid `$` characters.
+**Guard:** keep the commit message to a single line in double quotes, and write plain text without `$`, backticks, or nested quotes.
 
 ## Push (Deferred to Conclusion)
 
@@ -272,7 +274,7 @@ ci-watch:
 probe: REASON := $(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS))
 
 probe:
-	@[ -n "$(REASON)" ] || { echo "Usage: make probe '<reason>'"; exit 1; }
+	$(if $(strip $(REASON)),,$(error Usage: make probe '<reason>'))
 	git add -f spikes/debug/probe.sh
 	git commit -m 'debug: probe' --no-verify --allow-empty
 	git push
@@ -297,15 +299,15 @@ 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; }
+	$(if $(strip $(LOGS_RUN)),,$(error Usage: make logs <run-id> ['<step-name>']))
 	@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
 
-%:
-	@:
+# Empty recipe absorbs extra arguments without invoking a subshell.
+%: ;
 ```
 
 **Usage:**