teddy-cli 0.1.17.dev1184__tar.gz → 0.1.17.dev1186__tar.gz

{teddy_cli-0.1.17.dev1184 → teddy_cli-0.1.17.dev1186}/PKG-INFO

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

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

@@ -79,11 +79,11 @@ WIP & REMINDERS:
       7. You are strictly forbidden from wasting turns sending a `## Message` to the user about a validation error. Validation errors are internal formatting mistakes; silently fix and resubmit.
     </rule>
 
-    <rule n="10" name="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 to verify correctness. 4. Stage resolved files via `git add`. 5. Complete the rebase via `EXECUTE git rebase --continue`.</rule>
+    <rule n="10" name="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`.</rule>
     <rule n="11" name="Programmatic Edits">You may use `EXECUTE` with bash tools to modify files when surgical `EDIT` matching is brittle or for bulk changes. You MUST scope these actions to specific files and chain a verification command to output the results. Example: `sed 's/old/new/g' <file> > <file>.tmp && mv <file>.tmp <file> && git grep "new_string" <file>`</rule>
 
     <rule n="12" name="Template-First Documentation & Tooling">
-      <description>Before creating or modifying a documentation file under docs/, you MUST first READ the corresponding template from docs/templates/. Templates define the required structure and format for each artifact type. Template files are named by artifact type (e.g., specification-document.md, task-brief.md, case-file.md, PROJECT.md, ARCHITECTURE.md). If no template exists for your artifact, READ the most similar one as a reference. The same template-first principle governs project tooling: before invoking any project command (e.g., `make commit`, `make probe`, `make logs`, `make test`), if the `Makefile` does not exist in the project root you MUST create one following the template at `docs/templates/makefile.md`; and if the `Makefile` already exists but lacks the required target, you MUST add that target following that same template. The `makefile.md` template defines how the targets SHOULD look (usage, recipe, and cross-platform conventions).</description>
+      <description>Before creating or modifying a documentation file under docs/, you MUST first READ the corresponding template from docs/templates/. Templates define the required structure and format for each artifact type. Template files are named by artifact type (e.g., specification-document.md, task-brief.md, case-file.md, PROJECT.md, ARCHITECTURE.md, ci.md, pre-commit.md, makefile.md). If no template exists for your artifact, READ the most similar one as a reference. The same template-first principle governs project tooling: before invoking any project command (e.g., `make commit`, `make probe`, `make logs`, `make test`), if the `Makefile` does not exist in the project root you MUST create one following the template at `docs/templates/makefile.md`; and if the `Makefile` already exists but lacks the required target, you MUST add that target following that same template. The `makefile.md` template defines how the targets SHOULD look (usage, recipe, and cross-platform conventions). Likewise, project infrastructure configuration is template-first: when creating or modifying a CI workflow you MUST follow `docs/templates/ci.md`, and when setting up or modifying pre-commit hooks (including the post-commit test gate) you MUST follow `docs/templates/pre-commit.md`; create either file if it does not exist.</description>
     </rule>
 
     <rule n="13" name="Communication Hygiene">

{teddy_cli-0.1.17.dev1184 → teddy_cli-0.1.17.dev1186}/src/teddy_executor/resources/config/prompts/debugger.xml

@@ -61,7 +61,7 @@
         <step n="2" name="Red Phase">EXECUTE the newly created regression test in isolation to confirm it fails (RED). This empirically proves the test correctly captures the original bug. If the test passes, it does not accurately reproduce the bug; return to step 1 and refine the test.</step>
         <step n="3" name="Apply Fix">Apply the verified hypothesis from the shadow file to the target production file(s) in `src/`. Execute the regression test again to confirm it now passes (GREEN). This proves the fix resolves the specific bug.</step>
         <step n="4" name="MRE Re-Verification">Re-run the original MRE script against the fixed production code to confirm the exact original symptom is resolved. This ensures the regression test did not accidentally over-specify or under-specify the bug; the original reproduction scenario must still pass against the real fixed code.</step>
-        <step n="5" name="Integration Verification">EXECUTE the entire test suite (acceptance, unit and integration) to ensure no regressions were introduced. If any test fails, revert all changes via `git reset --hard` and return to the Investigation phase.</step>
+        <step n="5" name="Integration Verification">EXECUTE `make test` to run the entire suite (acceptance, unit and integration) and ensure no regressions were introduced. If any test fails, revert all changes via `git reset --hard` and return to the Investigation phase.</step>
       </phase>
 
       <phase n="7" name="Version Control">

{teddy_cli-0.1.17.dev1184 → teddy_cli-0.1.17.dev1186}/src/teddy_executor/resources/config/prompts/developer.xml

@@ -69,7 +69,7 @@
       <phase n="3" name="Integration">
         <goal>Mandatory Gate ensuring continuous integration scoped at the deliverable level.</goal>
         <step n="1" name="Global Test Run">
-          Run the full test suite (no filters). If it passes, proceed to Phase 4. If it fails, proceed to Fault Evaluation.
+          Run the full test suite via `make test` (no filters). If it passes, proceed to Phase 4. If it fails, proceed to Fault Evaluation.
         </step>
         <step n="2" name="Fault Evaluation">
           Classify the failure using this empirical rule: If fixing the global suite requires modifying ANY application code outside the exact scope of your current deliverable, it is a Systemic Regression. If the fix ONLY requires modifying the current deliverable's components or updating existing test files, it is a Local Flaw.

{teddy_cli-0.1.17.dev1184 → teddy_cli-0.1.17.dev1186}/src/teddy_executor/resources/templates/PROJECT.md

@@ -44,6 +44,7 @@ Before creating or modifying any documentation artifact, agents MUST read the co
 | `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`.
 

teddy_cli-0.1.17.dev1186/src/teddy_executor/resources/templates/pre-commit.md

@@ -0,0 +1,149 @@
+# Pre-Commit Template
+
+> **⚠️ This is an example template.** Adapt the runner, hook set, and tool-specific details (e.g., `uv run`, the pre-commit hook list) to match your project's actual setup. The concrete examples shown may not work verbatim in all environments.
+
+This template documents how to set up the [Pre-commit](https://pre-commit.com/) framework as the project's local quality gate. It runs fast checks before a commit is recorded and the full test suite after, keeping the repository green-to-green.
+
+Pre-commit has two stages:
+
+- **`pre-commit`** — fast checks (formatters, linters, type checkers, secret scanners), scoped strictly to the files being committed.
+- **`post-commit`** — the full test suite, run after the commit is recorded. If it fails, the commit is reverted while keeping the changes staged. This stage is **not** affected by `--no-verify` and is the only truly unskippable gate.
+
+## 1. Install the Pre-commit framework
+
+```shell
+uv tool install pre-commit   # or: pip install pre-commit   # or: brew install pre-commit
+pre-commit --version
+```
+
+## 2. Create `.pre-commit-config.yaml`
+
+Place this in the project root. Start with the universal hooks, then add security and project-local hooks that shell out to the project runner.
+
+```yaml
+# Exclude experimental sandboxes from every hook.
+exclude: '^spikes/'
+repos:
+  # ── Universal (every project) ──
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v6.0.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-toml
+      - id: check-added-large-files
+        args: ['--maxkb=500']
+      - id: check-case-conflict
+      - id: check-merge-conflict
+
+  # ── Secrets & security ──
+  - repo: https://github.com/Yelp/detect-secrets
+    rev: v1.5.0
+    hooks:
+      - id: detect-secrets
+        args: ['--baseline', '.secrets.baseline']
+  - repo: https://github.com/PyCQA/bandit
+    rev: 1.7.9
+    hooks:
+      - id: bandit
+        args: ["-c", "pyproject.toml"]
+        exclude: ^(tests|spikes)/
+
+  # ── Language-specific: run tools through the project runner ──
+  - repo: local
+    hooks:
+      - id: ruff-lint
+        name: Ruff Linter
+        entry: uv run ruff check --fix --force-exclude
+        language: system
+        types: [python]
+        require_serial: true
+      - id: ruff-format
+        name: Ruff Formatter
+        entry: uv run ruff format --force-exclude
+        language: system
+        types: [python]
+        require_serial: true
+      - id: mypy
+        name: Mypy
+        entry: uv run mypy
+        language: system
+        types: [python]
+        require_serial: true
+
+  # ── Post-commit test gate (unskippable) ──
+  - repo: local
+    hooks:
+      - id: post-commit-test-gate
+        name: Post-commit test gate
+        entry: uv run python .githooks/post-commit.py
+        language: system
+        stages: [post-commit]
+        always_run: true
+        pass_filenames: false
+```
+
+**Tip:** Pin exact `rev` tags so every teammate runs identical checks.
+
+## 3. Install the hooks
+
+```shell
+pre-commit install                          # pre-commit stage
+pre-commit install --hook-type post-commit  # post-commit test gate
+```
+
+`pre-commit install` writes the runner into `.git/hooks/`. The pre-commit stage runs only against the files you have staged; the post-commit stage runs the full suite after every commit.
+
+## 4. Run hooks manually
+
+```shell
+pre-commit run --all-files             # run all pre-commit hooks against the repo (first setup)
+pre-commit run ruff-lint --all-files   # run a single hook
+```
+
+`--all-files` is for the initial setup only; normal commits check just the staged files.
+
+## 5. The post-commit test gate
+
+The post-commit stage is the unskippable safety net. It invokes a project script (e.g. `.githooks/post-commit.py`) that:
+
+1. Verifies the runner and test framework are available, printing a clear, actionable error if not.
+2. Runs the full test suite via the project's test command (e.g. `make test` / `uv run pytest`).
+3. On failure, reverts the commit with `git reset --soft HEAD~1`, keeping the changes staged for investigation.
+
+```python
+# .githooks/post-commit.py (sketch)
+import subprocess
+import sys
+
+
+def main() -> None:
+    # Pre-flight: verify the runner + test framework are available.
+    # Run the full suite.
+    result = subprocess.run(["uv", "run", "pytest", "--tb=short", "-q"])
+    # On failure, revert the commit but keep the changes staged.
+    if result.returncode != 0:
+        print("TESTS FAILED \u2014 reverting commit")
+        subprocess.run(["git", "reset", "--soft", "HEAD~1"], check=True)
+        sys.exit(1)
+
+
+if __name__ == "__main__":
+    main()
+```
+
+Because the hook is declared with `stages: [post-commit]`, `git commit --no-verify` cannot bypass it.
+
+## 6. Bypass (emergency only)
+
+```shell
+git commit --no-verify      # skip the pre-commit stage for this commit
+SKIP=ruff-lint git commit   # skip a single hook
+```
+
+The **post-commit test gate is never bypassable**. Treat a pre-commit bypass as a temporary measure followed by a cleanup commit that resolves the underlying issue.
+
+## Reference
+- [ARCHITECTURE.md Template](./ARCHITECTURE.md) — pre-commit + post-commit conventions.
+- [Makefile Template](./makefile.md) — `make test` and the VCP commit workflow.
+- [Pre-commit documentation](https://pre-commit.com/)