teddy-cli 0.1.17.dev1228__tar.gz → 0.1.17.dev1229__tar.gz

{teddy_cli-0.1.17.dev1228 → teddy_cli-0.1.17.dev1229}/PKG-INFO

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

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

@@ -7,16 +7,17 @@ This section defines foundational engineering practices. Each entry MUST be a sp
 **Template format:** `- **Rule Name:** Description and enforcement mechanism.`
 
 ### Recommended: customize per project
-- **Version Control:** Branch strategy and commit conventions.
+- **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.
 - **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, test doubles policy, mock poisoning prevention, filesystem hygiene.
+- **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.
+- **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.
 - **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), required hooks (formatters, linters, type checkers, security scanners).
 - **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 VCP commit, 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 VCP commit (it runs the pre-commit hooks once and commits with `--no-verify`, while the post-commit test gate remains unskippable), 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.dev1228 → teddy_cli-0.1.17.dev1229}/src/teddy_executor/resources/templates/PROJECT.md

@@ -22,11 +22,12 @@ Defines the high-level artifact lifecycle and conventions for project management
     - **Milestones:** `MM-name.md` (in `docs/project/milestones/`).
     - **Case Files (Debugger):** `NN-name.md` — numbered sequentially.
     - **Task Briefs:** `NN-name.md` (in `docs/project/tasks/`) — numbered sequentially.
-    - **Ad-hoc work (not tied to a milestone):** `00-NN-name.md` — `00` is used as the Milestone prefix. Ad-hoc slices are NOT tracked in Milestone documents or the Roadmap.
+    - **Milestone 0 (bootstrapping) & Ad-hoc work (not tied to a milestone):** `00-NN-name.md` — `00` is used as the Milestone prefix for Milestone 0 bootstrapping slices and for ad-hoc slices. Ad-hoc slices are NOT tracked in Milestone documents or the Roadmap.
 - **Archiving Policy:** When and how completed artifacts are archived or deleted.
-- **Spec Organization:** Organize specification documents by lifecycle into two subfolders: `docs/project/specs/invariants/` (formats, contracts, and workflows of record — long-lived system invariants) and `docs/project/specs/features/` (to-be-implemented initiatives that feed the Spec → Milestone → Slice lifecycle — deleted per the Archiving Policy once implemented).
+- **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).
+- **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
 
@@ -34,7 +35,7 @@ Before creating or modifying any documentation artifact, agents MUST read the co
 
 | Template | Purpose |
 | -------- | ------- |
-| `specification-document.md` | Specification documents (features and invariants) |
+| `specification-document.md` | Specification documents (permanent system invariants) |
 | `milestone.md` | Milestone documents |
 | `vertical-slice.md` | Vertical slice definitions |
 | `component-design.md` | Component design documents (ports and contracts) |
@@ -75,15 +76,4 @@ A living list of upcoming Milestones and their high-level features.
     - **Post-commit Hook:** Implement a hook that runs the full test suite via `make test` and reverts the commit on failure (via `git reset --soft HEAD~1`, keeping changes staged). This is the unskippable safety net — `--no-verify` MUST NOT bypass it.
     - **Debug Workflow:** Create `.github/workflows/debug.yml` following [docs/templates/ci.md](docs/templates/ci.md) to enable the Remote Probing Protocol.
     - **Makefile:** Create a `Makefile` following [docs/templates/makefile.md](docs/templates/makefile.md) with `make commit`, `make probe`, and `make test` commands. `make commit` implements the VCP workflow, `make probe` implements the Debugger's Remote Probing Protocol, and `make test` runs the full suite on demand.
-
-## Technical Debt
-Tracks known technical debt for future cleanup.
-
-**Format:** `- [Description including context and location of the debt item.]`
-
-**Logging Hygiene (MUST):**
-- **Never re-log the same debt.** If a debt item recurs across commits, fold the new occurrence into the existing entry — do NOT append a new bullet.
-- **Prefer fixing directly over logging.** Only log debt that genuinely cannot be resolved in the moment. Do not log-then-resolve a defect that could be fixed immediately.
-- **Never log resolved items.** Do not add "informational" or "completed" entries.
-
-**Deletion Policy:** When a technical debt item is addressed (the underlying issue is resolved in a completed milestone/slice), the entry MUST be deleted from this section. Do not mark it as "completed" or "resolved" — remove it entirely. Git history serves as the permanent record.
+    - **`.gitignore` Configuration:** Configure a project-tailored `.gitignore` covering language/OS cache files, build artifacts, virtual environments, and the transient `.tmp/` directory. The `spikes/` directory MUST remain tracked so prototypes and probes stay version-controlled.

teddy_cli-0.1.17.dev1229/src/teddy_executor/resources/templates/specification-document.md

@@ -0,0 +1,29 @@
+# Spec: {{invariant}}
+- **Status:** Active
+
+> **Scope:** This template codifies **permanent system invariants** only — stable formats, contracts, protocols (e.g. the MRP), core data models, and non-negotiable architectural rules of record. It is NOT for feature goals, requirements, or acceptance criteria; those belong in Milestone documents (`docs/project/milestones/`) and Vertical Slices.
+
+## Overview / Problem Statement
+
+**Format:** 2-3 paragraphs describing the invariant being codified, why it exists, and what it guarantees.
+Context for the invariant, the contract it establishes, and the risk it mitigates.
+
+## Guiding Principles / Core Logic
+
+**Format:** Bulleted list. Each entry: `- **Principle:** Description and how it constrains design decisions.`
+Foundational rules, engineering philosophy, or logical constraints.
+
+## Technical Specification
+
+**Format:** Use sub-sections as needed. Include:
+- Data models / contracts (tables or code blocks)
+- File paths and directory structures
+- Workflow diagrams (Mermaid) where applicable
+- Algorithm descriptions
+- Configuration options
+Detailed logic, file formats, directory structures, or workflow diagrams (Mermaid).
+
+## Guidelines
+
+**Format:** Bulleted or numbered list of rules for conforming to and evolving this invariant. Each entry should constrain design decisions, not prescribe specific implementation.
+Conformance requirements and the process for amending the invariant.

{teddy_cli-0.1.17.dev1228 → teddy_cli-0.1.17.dev1229}/src/teddy_executor/resources/templates/vertical-slice.md

@@ -29,7 +29,11 @@ Then [expected outcome]
 
 ## Key Unknowns
 
-**Format:** Checklist of unresolved risks. Tags: `[Technical]` for code/architecture, `[Functional]` for behavior/UX. Mark as `[x]` when resolved.
+**Format:** Checklist of unresolved risks, each tagged with one of three tiers. Mark as `[x]` when resolved.
+- `[Formal]` — Ambiguities in business rules, policy decisions, domain definitions, or scope boundaries. Resolve by asking the user directly in an alignment turn; speculative coding or prototyping for formal questions is forbidden.
+- `[Technical]` (works-like) — External dependencies, third-party libraries, APIs, runtime performance, concurrency, or data-storage feasibility. Resolve via automated assertion probes and benchmarks.
+- `[Functional]` (looks-like) — User-facing ergonomics, CLI flags, terminal rendering, interactive flows, or layout aesthetic. Resolve via interactive demo runners with configurable knobs.
+
 - [ ] [Tag] Title: Description of the unknown.
 
 ## Implementation Plan

teddy_cli-0.1.17.dev1228/src/teddy_executor/resources/templates/specification-document.md

@@ -1,27 +0,0 @@
-# Spec: {{feature}}
-- **Status:** Active
-
-## Overview / Problem Statement
-
-**Format:** 2-3 paragraphs describing the problem being solved, why existing solutions are insufficient, and what makes this approach valuable.
-Core problem, context, and value proposition.
-
-## Guiding Principles / Core Logic
-
-**Format:** Bulleted list. Each entry: `- **Principle:** Description and how it constrains design decisions.`
-Foundational rules, engineering philosophy, or logical constraints.
-
-## Technical Specification
-
-**Format:** Use sub-sections as needed. Include:
-- Data models / contracts (tables or code blocks)
-- File paths and directory structures
-- Workflow diagrams (Mermaid) where applicable
-- Algorithm descriptions
-- Configuration options
-Detailed logic, file formats, directory structures, or workflow diagrams (Mermaid).
-
-## Guidelines
-
-**Format:** Bulleted or numbered list of actionable guidelines. Each entry should guide decision-making, not prescribe specific implementation.
-High-level phasing, sequencing, and technical strategy for the Architect.