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

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

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

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

@@ -50,7 +50,8 @@ NOTES:
       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` to rebase, push, and inspect CI: use `make logs <run-id> '<step-name>'` for full logs. If blocking test failures occur, fix them immediately, commit, and push again. For non-blocking quality gate results, address directly if localized, or record them in the roadmap in `docs/project/PROJECT.md` if not already planned.
+      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.
     </rule>
 
     <rule n="7" name="Standardized Plan Types">

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

@@ -35,7 +35,7 @@
       <phase n="4" name="Conclusion">
         <goal>Clean up the workspace, commit changes, push, and hand off to the next agent.</goal>
         <step n="1" name="Cleanup">Delete temporary files, scratchpads, and diagnostic notes.</step>
-        <step n="2" name="Commit and Push">Execute `make commit`, then run `make push` and inspect CI results</step>
+        <step n="2" name="Commit and Push">Execute `make commit`, then run `make push`.</step>
         <step n="3" name="Handoff">Message the user with instructions to start the next session, including the new Vertical Slice as a reference file. Route to the Prototyper if the slice contains unresolved Key Unknowns; otherwise route directly to the Developer.</step>
       </phase>
     </workflow>

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

@@ -110,7 +110,7 @@
 
       <phase n="7" name="Conclusion">
         <goal>Finalize remote synchronization and dynamically route the next session handoff.</goal>
-        <step n="1" name="Remote Sync">Run `make push` to push commits and inspect CI results. If blocking test failures occur, fix them immediately, commit, and push again. For non-blocking quality gate issues, address them if contained or record them in the roadmap in `docs/project/PROJECT.md`.</step>
+        <step n="1" name="Remote Sync">Run `make push` to push commits, then run `make ci-watch` to monitor and inspect remote CI results. If blocking test failures occur, fix them immediately, commit, and push again. For non-blocking quality gate issues, address them if contained or record them in the roadmap in `docs/project/PROJECT.md`.</step>
         <step n="2" name="Handoff">Message the user to route the next session based on milestone state: the Architect if the next slice is un-designed, the Prototyper if it has unresolved Key Unknowns, the Developer if ready to implement, or the Pathfinder if all milestone slices are complete.</step>
       </phase>
     </workflow>

{teddy_cli-0.1.17.dev1275 → teddy_cli-0.1.17.dev1277}/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.dev1275 → teddy_cli-0.1.17.dev1277}/src/teddy_executor/resources/templates/ARCHITECTURE.md

@@ -17,7 +17,7 @@ This section defines foundational engineering practices. Each entry MUST be a sp
 - **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, pushes, and reports CI results back (deferred to the session Conclusion), and `make probe '<reason>'` runs the Remote Probing Protocol. See [docs/templates/makefile.md](docs/templates/makefile.md).
+- **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
 

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

@@ -25,7 +25,7 @@ Defines the high-level artifact lifecycle and conventions for project management
 - **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`.
-- **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), and `make probe '<reason>'` (Remote Probing Protocol).
+- **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.
 
 ## Templates

{teddy_cli-0.1.17.dev1275 → teddy_cli-0.1.17.dev1277}/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.dev1275 → teddy_cli-0.1.17.dev1277}/src/teddy_executor/resources/templates/makefile.md

@@ -13,13 +13,21 @@ make commit 'feat(templates): add PROJECT.md template'
 ```
 
 **What is `.PHONY`?**
-`.PHONY` is a Makefile directive that declares `commit`, `push`, `probe`, `test`, and `logs` as phony targets — they do not correspond to actual files. Without `.PHONY`, if a file named `commit` or `probe` existed in the directory (e.g., a script called `commit`), Make would see it as up-to-date and skip the target entirely. By declaring them phony, Make always runs the recipe when you call `make commit`, `make push`, `make probe`, or `make test`.
+`.PHONY` is a Makefile directive that declares `commit`, `push`, `ci-watch`, `probe`, `test`, and `logs` as phony targets — they do not correspond to actual files. Without `.PHONY`, if a file named `commit` or `probe` existed in the directory (e.g., a script called `commit`), Make would see it as up-to-date and skip the target entirely. By declaring them phony, Make always runs the recipe when you call `make commit`, `make push`, `make ci-watch`, `make probe`, or `make test`.
 
 ### Push
 ```shell
 make push
 ```
 
+### CI Watch
+```shell
+make ci-watch
+```
+
+**What does `make ci-watch` do?**
+`make ci-watch` resolves the commit hash from `HEAD` (or an explicit `COMMIT=<sha>`), polls GitHub Actions to allow for workflow registration lag, watches all running workflows for that commit, prints failing step details, and attributes regressions. It is used by the Developer at slice conclusion to verify remote CI without slowing down routine pushes.
+
 ### Test
 ```shell
 make test
@@ -128,7 +136,21 @@ commit:
 
 ## Push (Deferred to Conclusion)
 
-`make push` runs `git pull --rebase`, captures the base and the pushed SHA, pushes, then discovers **every** CI run for the pushed SHA (`gh run list --commit <sha>`) and waits for and reports each workflow with its jobs. It answers ONE question: **did this push turn a BLOCKING gate red?**
+`make push` is fast and non-blocking: it runs `git pull --rebase` and pushes local commits to remote.
+
+### Example
+
+```makefile
+push:
+	git pull --rebase
+	git push
+```
+
+**Usage:** `make push`
+
+## CI Watch & Attribution
+
+`make ci-watch` discovers **every** CI run for the target commit (`HEAD` by default, or `COMMIT=<sha>`), waits for and reports each workflow with its jobs. It answers ONE question: **did this commit turn a BLOCKING gate red?**
 
 The pushed RUN's own conclusion is authoritative: it already folds in `continue-on-error`, so a **non-blocking** job (e.g. the CI `Quality Checks` job) can NEVER block the session — it is reported as a triage item instead. Only when the run-level conclusion is `failure` does attribution run, comparing the pushed run's failing-JOB set against the base run's:
 
@@ -141,24 +163,22 @@ When any step fails — blocking or not — the target prints the failing step's
 
 Attribution is deterministic: SHA → run → run-level + per-job conclusion (never "the latest run").
 
-Three behaviors make the attribution trustworthy:
+Key behaviors:
 
-1. **The base is captured BEFORE the push.** `BASE=$$(git rev-parse origin/main)` is read immediately after `git pull --rebase` and before `git push`; otherwise the push advances `origin/main` and `BASE` collapses onto the pushed SHA, making every comparison trivially equal (a real regression would be silently misclassified as pre-existing). `git push` is folded into the same shell block behind `|| exit $$?` so a rejected push still aborts the target.
-2. **Registration lag is tolerated by a bounded retry.** CI may not have registered a run for the pushed SHA yet; the target polls `gh run list --commit <sha>` up to `RETRY_POLLS × RETRY_SLEEP` (default 10 × 1s ≈ 10s) before attributing, then 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 — a CI-less repo is never blocked. This is distinct from a repo WITH CI whose pushed SHA registered no run (that still fail-safe blocks).
+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.
+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
 
 ```makefile
 RETRY_POLLS ?= 10
-RETRY_SLEEP ?= 1
+RETRY_SLEEP ?= 2
 DETAIL_LINES ?= 50
 
-push:
-	git pull --rebase
-	@BASE=$$(git rev-parse origin/main); \
-	SHA=$$(git rev-parse HEAD); \
-	git push || exit $$?; \
+ci-watch:
+	@SHA=$$(git rev-parse $${COMMIT:-HEAD}); \
+	BASE=$$(git rev-parse $${COMMIT:-HEAD}~1 2>/dev/null || echo ""); \
 	if [ -z "$$(ls .github/workflows/*.yml .github/workflows/*.yaml 2>/dev/null)" ]; then \
 	  echo "No CI configured - skipping attribution"; \
 	  exit 0; \
@@ -170,9 +190,9 @@ push:
 	  ATTEMPTS=$$((ATTEMPTS + 1)); \
 	  sleep $(RETRY_SLEEP); \
 	done; \
-	echo "Pushed $$SHA (base $$BASE) after $$ATTEMPTS poll(s)"; \
+	echo "Watching CI for $$SHA (base $${BASE:-none}) after $$ATTEMPTS poll(s)"; \
 	if [ -z "$$WFS" ]; then \
-	  echo "CI: no run registered for $$SHA after $(RETRY_POLLS) poll(s) - fail-safe block"; \
+	  echo "CI: no run registered for $$SHA after $$(( $(RETRY_POLLS) * $(RETRY_SLEEP) ))s - fail-safe block"; \
 	  exit 1; \
 	fi; \
 	for WF in $$WFS; do \
@@ -194,6 +214,10 @@ push:
 	    fi; \
 	    continue; \
 	  fi; \
+	  if [ -z "$$BASE" ]; then \
+	    echo "$$WF: BLOCKING failure ($$NEWFAIL) — no base commit — YOUR regression"; \
+	    STATUS=1; continue; \
+	  fi; \
 	  OLD=$$(gh run list --commit "$$BASE" --workflow "$$WF" --json databaseId --jq '.[0].databaseId'); \
 	  if [ -z "$$OLD" ]; then \
 	    echo "$$WF: BLOCKING failure ($$NEWFAIL) — base has no run (unknown base) — YOUR regression"; \
@@ -215,7 +239,9 @@ push:
 	exit $$STATUS
 ```
 
-**Usage:** `make push`
+**Usage:**
+- `make ci-watch` (watches CI for current `HEAD`)
+- `make ci-watch COMMIT=<sha>` (watches CI for a specific commit)
 
 ## Remote Probing Protocol (RPP)
 
@@ -273,4 +299,5 @@ logs:
 - Post-commit hook lives at `.githooks/post-commit.py` and runs the full `uv run pytest` suite.
 - Ensure `gh` (GitHub CLI) is authenticated for `make push`, the Remote Probing Protocol, and CI Log Extraction.
 - The `make logs` target abstracts the Debugger's CI-log extraction (Phase 1, Step 2). See [CI Log Extraction](#ci-log-extraction).
-- `make push` runs in the session Conclusion phase (see [Push (Deferred to Conclusion)](#push-deferred-to-conclusion)); it rebases, pushes, and reports CI results back.
+- `make push` runs in the session Conclusion phase (see [Push (Deferred to Conclusion)](#push-deferred-to-conclusion)); it rebases and pushes.
+- `make ci-watch` monitors and attributes CI results for `HEAD` or an explicit commit (see [CI Watch & Attribution](#ci-watch--attribution)).