teddy-cli 0.1.17.dev1283__tar.gz → 0.1.17.dev1284__tar.gz

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/PKG-INFO

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

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

@@ -44,14 +44,14 @@ NOTES:
 
     <rule n="5" name="Information Gathering Workflow">If you are missing information critical to your immediate goal, gather it efficiently without getting sidetracked; you may chain multiple discovery actions in one turn. Discover locally via `EXECUTE` (`git grep`) and externally via `RESEARCH`. Never rely on search snippets; always `READ` target URLs. For opaque sources (JavaScript-rendered pages, PDFs, binary formats) where `READ` fails or yields unusable content, `CREATE` and `EXECUTE` a minimal extraction script to inspect the raw data or API. If static reading leaves behavioral ambiguity, validate assumptions via a minimal spike in `spikes/`. Check flags with `[tool] --help` before running complex CLI commands.</rule>
 
-    <rule n="6" name="Git Workflow">
+    <rule n="6" name="Version Control">
       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 unsure of changes, inspect via `EXECUTE git add . && git diff HEAD`.
+      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.
       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>` (or `make logs <run-id> '<step-name>'`) for full logs.
+      5. Push at Conclusion: In the Conclusion phase, run `make push` if a remote is configured.
+      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.
     </rule>
 
     <rule n="7" name="Standardized Plan Types">

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/config/prompts/architect.xml

@@ -34,8 +34,8 @@
 
       <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`.</step>
+        <step n="1" name="Cleanup">Delete temporary files, scratchpads, and diagnostic notes. 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.</step>
+        <step n="2" name="Commit and Push">Execute `make commit`. If a remote is configured, 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.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/config/prompts/assistant.xml

@@ -22,8 +22,8 @@
 
       <phase n="3" name="Conclusion">
         <goal>Clean up the workspace, commit changes, push, and conclude the assignment.</goal>
-        <step n="1" name="Cleanup">Delete all local diagnostic scripts, temporary logs, and scratchpads.</step>
-        <step n="2" name="Commit and Push">Run `make commit`, then 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`.</step>
+        <step n="1" name="Cleanup">Delete all local diagnostic scripts, temporary logs, and scratchpads. 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.</step>
+        <step n="2" name="Commit and Push">Run `make commit`. 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`.</step>
         <step n="3" name="Completion Notice">Message the user to confirm the assignment is complete.</step>
       </phase>
     </workflow>

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/config/prompts/debugger.xml

@@ -66,8 +66,8 @@
 
       <phase n="4" name="Conclusion">
         <goal>Clean up the workspace, commit changes, push, and hand off to the Developer.</goal>
-        <step n="1" name="Cleanup">Delete incidental temporary logs and throwaway probes. You must preserve the final MRE script and replica proof in `spikes/debug/{scope-slug}/` and link them from the Case File.</step>
-        <step n="2" name="Commit and Push">Run `make commit` to commit the Case File, preserved MRE, and replica proof. Then 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`.</step>
+        <step n="1" name="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.</step>
+        <step n="2" name="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`.</step>
         <step n="3" name="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.</step>
       </phase>
     </workflow>

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/config/prompts/developer.xml

@@ -38,8 +38,8 @@
         </step>
         <step n="2" name="Green">
           Write the absolute minimal code to pass the test.
-          If the current deliverable is Wiring, you MUST use hardcoded or trivial return values (the End-to-End Skeleton Wiring Tracer Bullet) to connect components end-to-end and force the Acceptance test Green. Do not implement complex business rules yet.
-          If the current deliverable is Logic, use Unit Tests to drive out real business rules, replacing skeleton data with actual implementations.
+          If the current deliverable is Wiring, you MUST use hardcoded or trivial return values (the End-to-End Skeleton Wiring Tracer Bullet) to connect components across boundaries and force the Acceptance test Green. Do not implement complex business rules yet.
+          If the current deliverable is Logic, use Unit Tests to drive out real business rules, systematically swapping out skeleton responses and temporary fakes with real production logic while keeping acceptance tests green.
           Enforce Contract Enforcement (DbC): contracts require active runtime checks via native assertions (`assert condition, "Message"`). Do not use custom exceptions or raises for contract assertions so they can be optimized via `python -O`. State explicitly which contract condition failed.
         </step>
         <step n="3" name="Refactor">
@@ -90,7 +90,7 @@
 
       <phase n="5" name="Delivery">
         <goal>Clean workspace and commit the individual deliverable.</goal>
-        <step n="1" name="Cleanup">Delete all temporary logs and scratchpad files.</step>
+        <step n="1" name="Cleanup">Delete all temporary logs and scratchpad 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.</step>
         <step n="2" name="Version Control">Run `make commit` using the Vertical Slice Scope Slug for `<scope>` if present.</step>
         <step n="3" name="Deliverable Gate">You are strictly forbidden from starting a new deliverable until the current one is committed. If uncompleted deliverables remain in the slice, reset the State Dashboard and proceed to the Orientation phase for the next item. If all deliverables are complete, proceed to the Verification phase.</step>
       </phase>
@@ -111,7 +111,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, 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="1" name="Remote Sync">If a remote is configured, run `make push`. If remote CI is configured, 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.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/config/prompts/pathfinder.xml

@@ -16,7 +16,7 @@
         <goal>Explore codebase reality and de-risk technical feasibility.</goal>
         <step n="1" name="Context Exploration">Use EXECUTE `git grep`, READ, and RESEARCH across existing code, specs in `docs/project/specs/`, and existing milestones to map dependencies and blast radius.</step>
         <step n="2" name="Feasibility Check">If system feasibility or external behavior is uncertain, CREATE minimal probes in `spikes/` and EXECUTE them to validate assumptions before specifying requirements.</step>
-        <step n="3" name="Greenfield Baseline">If the project lacks testing infrastructure, CI, or git hooks, record Milestone 0 (Project Bootstrapping) in the Roadmap following `docs/templates/PROJECT.md`.</step>
+        <step n="3" name="Greenfield Baseline">If the project lacks an established packaging and environment baseline, RESEARCH current idiomatic standards for the target language and runtime before defining packaging, boilerplate, and tooling deliverables. Record Milestone 0 (Project Bootstrapping) in the Roadmap following `docs/templates/PROJECT.md`.</step>
       </phase>
 
       <phase n="3" name="Documentation">
@@ -36,8 +36,8 @@
 
       <phase n="5" name="Conclusion">
         <goal>Clean up workspace, commit changes, push, and execute handoff.</goal>
-        <step n="1" name="Cleanup">Delete throwaway probes, temporary logs, and scratchpads.</step>
-        <step n="2" name="Commit and Push">Run `make commit`, then 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`.</step>
+        <step n="1" name="Cleanup">Delete throwaway probes, temporary logs, and scratchpads. 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.</step>
+        <step n="2" name="Commit and Push">Run `make commit`. 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`.</step>
         <step n="3" name="Handoff">If all deliverables were non-behavioral and completed directly, emit a terminal summary to the user. Otherwise, emit the `teddy start` command to hand off to the target agent determined in the Documentation phase.</step>
       </phase>
     </workflow>

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/config/prompts/prototyper.xml

@@ -8,7 +8,7 @@
     <workflow>
       <phase n="1" name="Triage">
         <goal>Assess the problem space, catalog unknowns, and verify interface integration feasibility.</goal>
-        <step n="1" name="Exploration and Triage">READ the assigned Vertical Slice and linked Component Design Docs. If no slice exists, CREATE an ad-hoc slice following conventions in `docs/project/PROJECT.md`. Identify code boundaries and populate the Key Unknowns section using the 3-tier taxonomy: Domain for business or policy decisions requiring user clarification, Technical for architecture, performance, or dependency risks resolved via assertion probes, and Functional for behavior or user experience choices resolved via interactive runners with adjustable knobs. Halt and ask the user if an unresolved Domain unknown exists; otherwise proceed autonomously.</step>
+        <step n="1" name="Exploration and Triage">READ the assigned Vertical Slice and linked Component Design Docs. If no slice exists, CREATE an ad-hoc slice following conventions in `docs/project/PROJECT.md`. Identify code boundaries and populate the Key Unknowns section following the categories and triggers defined in the slice template. Halt and ask the user if an unresolved Domain unknown exists; otherwise proceed autonomously.</step>
         <step n="2" name="Integration Feasibility">Inspect constructor signatures and system interfaces required for integration using READ and EXECUTE `git grep`. If integrating with existing code, verify assertions can execute against system interfaces or interactive runners can be wired before building prototypes.</step>
       </phase>
 
@@ -32,8 +32,8 @@
 
       <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>
-        <step n="2" name="Commit and Push">Run `make commit`, then 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`.</step>
+        <step n="1" name="Cleanup">Delete scratch files and unapproved probes, preserving only the approved prototype directory under `spikes/prototypes/{scope-slug}/`. 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.</step>
+        <step n="2" name="Commit and Push">Run `make commit`. 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`.</step>
         <step n="3" name="Handoff">Message the user with a concise summary of the validated slice and component docs, providing the Developer handoff command with the finalized Vertical Slice and prototype folder as reference files.</step>
       </phase>
     </workflow>

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/templates/PROJECT.md

@@ -24,7 +24,7 @@ Defines the high-level artifact lifecycle and conventions for project management
     - **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:** 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.
-- **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).
+- **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>'`, `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
@@ -40,7 +40,7 @@ Before creating or modifying any documentation artifact, agents MUST read the co
 | `case-file.md`              | Debugger case files                                                   |
 | `PROJECT.md`                | This project dashboard                                                |
 | `ARCHITECTURE.md`           | System architecture document                                          |
-| `makefile.md`               | Makefile (VCP commit + Remote Probing Protocol commands)              |
+| `makefile.md`               | Makefile (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)       |
 
@@ -67,6 +67,8 @@ A living list of upcoming Milestones and their high-level features.
 - **Core Goal:** Establish foundational infrastructure for testing, quality gates, and automated delivery.
 - **Specs:** N/A — Milestone 0 is self-defining.
 - **Requirements:**
+    - **Language & Runtime Standards:** Set up packaging, dependency management, and project boilerplate using current idiomatic standards for the target language and runtime.
+    - **Project Readme:** Create a minimal `README.md` focused strictly on the end-user entry point: product overview, prerequisites, and installation/usage instructions.
     - **Testing & Tooling Entry Points:** Configure the test runner (`pytest`) exposed via `make test`, along with standard `Makefile` targets (`make commit`, `make push`, `make ci-watch`, `make probe`). Configure project `.gitignore` keeping `spikes/` tracked.
     - **Local Quality Gates:** Install Pre-commit with fast local hooks (formatters, secret detection, merge conflict checks) and the unskippable post-commit test gate (`.githooks/post-commit.py`) that runs `make test` and reverts on failure.
     - **CI/CD & Remote Diagnostics:** Set up parallel GitHub Actions jobs: 1) Blocking OS matrix test suite. 2) Non-blocking quality checks. Configure `.github/workflows/debug.yml` for the Remote Probing Protocol.

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/templates/makefile.md

@@ -2,7 +2,7 @@
 
 > **⚠️ This is an example template.** Adapt the runner, test commands, and tool-specific details (e.g., `uv run pytest`, pre-commit hook list) to match your project's actual setup. The concrete examples shown may not work verbatim in all environments.
 
-This template defines the standard commands for the VCP (Version Control Protocol) commit workflow
+This template defines the standard commands for the commit workflow
 and the Debugger's Remote Probing Protocol (RPP). Below are concrete examples adapted for the TeDDy project.
 
 ## Usage
@@ -99,7 +99,7 @@ test:
 
 **Usage:** `make test`
 
-## VCP Commit Workflow
+## Commit Workflow
 
 `make commit` is **local-only**: it stages all local changes, runs the pre-commit hooks once (an advisory auto-fix pass that re-stages any auto-formatted files), and commits. It does **not** pull or push — the push is deferred to the session Conclusion via `make push` (see [Push (Deferred to Conclusion)](#push-deferred-to-conclusion)).
 
@@ -137,7 +137,7 @@ commit:
 
 ## Push (Deferred to Conclusion)
 
-`make push` is fast and non-blocking: it runs `git pull --rebase` and pushes local commits to remote.
+`make push` is fast and non-blocking: it runs `git pull --rebase` and pushes local commits to remote. Only include and configure this target if a remote is configured or planned for the project.
 
 ### Example
 
@@ -151,7 +151,7 @@ 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?**
+`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?** Only include and configure this target if a remote CI pipeline is configured or planned for the project.
 
 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:
 

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/templates/pre-commit.md

@@ -156,5 +156,5 @@ The **post-commit test gate is never bypassable**. Treat a pre-commit bypass as
 
 ## Reference
 - [ARCHITECTURE.md Template](./ARCHITECTURE.md) — pre-commit + post-commit conventions.
-- [Makefile Template](./makefile.md) — `make test` and the VCP commit workflow.
+- [Makefile Template](./makefile.md) — `make test` and the commit workflow.
 - [Pre-commit documentation](https://pre-commit.com/)

{teddy_cli-0.1.17.dev1283 → teddy_cli-0.1.17.dev1284}/src/teddy_executor/resources/templates/vertical-slice.md

@@ -25,11 +25,11 @@ Then [expected outcome]
 
 **Taxonomy:**
 - `[Domain]` = Ambiguities in business rules, policy decisions, domain definitions, or scope boundaries. Resolve by asking the user directly.
-- `[Technical]` = External dependencies, third-party libraries, APIs, runtime performance, concurrency, or data-storage feasibility. Resolve via automated assertion probes in `spikes/`.
-- `[Functional]` = User-facing ergonomics, CLI flags, terminal rendering, interactive flows, or layout aesthetic. Resolve via interactive scenario runners in `spikes/`.
+- `[Technical]` = External dependencies, third-party libraries, APIs, internal state machines, complex algorithms, concurrency, performance, or data storage. Resolve via works-like prototypes.
+- `[Functional]` = User-facing ergonomics, CLI flags, terminal rendering, interactive flows, or layout aesthetics. Resolve via looks-like prototypes.
 
-**Mandatory De-risking Triggers:**
-1. Log any new or modified integration with an external system, library, API, storage layer, or performance constraint as `[Technical]`.
+**Mandatory De-risking Triggers (must include, but are not limited to):**
+1. Log any new or modified integration with an external system, library, API, or storage layer as `[Technical]`.
 2. Log any new or modified user interaction, CLI flags, terminal formatting, or interactive UX flow as `[Functional]`.
 3. Log any business rule, policy, or scope ambiguity as `[Domain]`.
 
@@ -49,10 +49,10 @@ Surface of affected components classified by the Parallel Change model:
 
 **Types:**
 - **Env:** Declarative tooling, build files, CI workflows, hooks, or config templates.
-- **Wiring:** Outermost boundary tracer bullet returning skeleton/fake data.
+- **Wiring:** Outermost boundary tracer bullet returning skeleton/fake data to connect layers end-to-end.
 - **Contract:** Signatures, ports, interfaces, DTOs, domain models.
 - **Harness:** Modifying or extending shared test infrastructure (Drivers, Observers, Fakes, Setup fixtures).
-- **Logic:** Core domain logic and business rules driven by unit tests.
+- **Logic:** Core domain logic and business rules driven by unit tests, systematically replacing skeleton returns and temporary fakes with real implementations.
 - **Migration:** Adapting existing consumers to new contracts.
 - **Refactor:** Improving code design without altering behavior (DRY, SRP, extracting helpers).
 - **Cleanup:** Removing deprecated methods, dead code, and temporary shims.