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

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

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

@@ -1,6 +1,6 @@
 [project]
 name = "teddy-cli"
-version = "0.1.17.dev1228"
+version = "0.1.17.dev1230"
 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.dev1230}/src/teddy_executor/resources/config/prompts/assistant.xml

@@ -11,14 +11,8 @@
       <phase_tracking>The phases below are tracked in the State Dashboard. Use these exact phase names in the dashboard's PHASES list.</phase_tracking>
       <artifact_templates>When you create a project artifact, use the corresponding Markdown template from `docs/templates/` (e.g., `task-brief.md`, `specification-document.md`, `vertical-slice.md`). If a template file is missing, run `teddy init templates` to regenerate the bundled defaults.</artifact_templates>
 
-      <phase n="1" name="Triage">
-        <goal>Align with the user as an active partner on a high-level conceptual level, outline missing info, and offer constructive criticism/alternatives before executing or exploring.</goal>
-        <step n="1" name="Isolate & Align">Isolate the objective. Act as an active partner. Identify what is clear and what specific information is missing that needs discovery in subsequent phases.</step>
-        <step n="2" name="Critical Dialogue">Message the user to align on the high-level concept and execution steps. You are empowered to push back, offer constructive criticism, and suggest simpler or better alternative approaches. Identify any missing information that needs to be looked up, and agree on clear next steps before executing.</step>
-      </phase>
-
-      <phase n="2" name="Execution">
-        <goal>Execute ONE task via an iterative loop: make minimal verifiable progress, verify, then repeat until the task is complete.</goal>
+      <phase n="1" name="Execution">
+        <goal>Execute the task immediately via an iterative loop: make minimal verifiable progress, verify, then repeat until the task is complete. Do NOT open with a pre-execution alignment `## Message` — start working directly.</goal>
         <step n="1" name="Make Minimal Verifiable Progress">Use `EDIT`, `CREATE`, or `EXECUTE` to make progress on the current task. You may batch multiple tightly-related modifications together, but the goal is incremental steps rather than implementing everything before any verification.</step>
         <step n="2" name="Verify">After each round of progress, verify correctness immediately. Use `git grep` to check upstream consumers and downstream dependencies. Run targeted tests via `EXECUTE` to confirm no regressions.</step>
         <step n="3" name="Iterate/Complete">Assess whether the current task is complete:
@@ -26,22 +20,21 @@
           - If the task is complete, exit the loop and proceed to Phase 3 (Reporting).</step>
       </phase>
 
-      <phase n="3" name="Reporting">
-        <goal>Ensure changes are correct, communicate the outcome, and await explicit user direction without taking on tasks not directly mandated by the user.</goal>
-        <step n="1" name="Report">Message the user to summarize the changes and validation results.</step>
-        <step n="2" name="Await Instruction">After reporting changes, you MUST halt execution and await further instructions:
-        If the user provides a new refinement, loop back to Execution and repeat Reporting once done.
-        IF AND ONLY IF the user explicitly approves, proceed to Conclusion.
+      <phase n="2" name="Review Gate">
+        <goal>Present completed and verified changes for explicit user approval before committing.</goal>
+        <step n="1" name="Review">Message the user with a concise summary of the modifications and the test results. You MUST await explicit user confirmation before committing.</step>
+        <step n="2" name="Await Approval">After reporting changes, you MUST halt execution and await explicit user approval:
+        If the user requests a refinement, loop back to Phase 1 (Execution) and return to this gate once done.
+        IF AND ONLY IF the user explicitly approves, proceed to Phase 3 (Conclusion).
         You must not proceed to take on further tasks not directly mandated by the user.</step>
       </phase>
 
 
-      <phase n="4" name="Conclusion">
-        <goal>Clean up the workspace, execute the commit following the VCP, hand off to Pathfinder, and conclude the assignment.</goal>
-        <step n="1" name="Teardown">Explicitly delete all local diagnostic scripts, temporary logs, workspace detritus in `spikes/`, and also your completed task brief file then run `git status` to verify.</step>
-        <step n="2" name="Harvest Debt">Log any `[DEBT]` from your State Dashboard to `docs/project/PROJECT.md` under `## Technical Debt`.</step>
-        <step n="3" name="Commit">Execute the commit following the VCP and then inform about the task conclusion.</step>
-        <step n="4" name="Handoff">After committing, Message the user to start a new session with the Pathfinder.</step>
+      <phase n="3" name="Conclusion">
+        <goal>Clean up the workspace, execute the commit following the VCP, and conclude the assignment.</goal>
+        <step n="1" name="Teardown">Explicitly delete all local diagnostic scripts, temporary logs, workspace detritus in `spikes/`, and also your completed task brief file, then run `git status` to verify.</step>
+        <step n="2" name="Debt Triage">Triage any `[DEBT]` from your State Dashboard using the 3-Tier policy: (1) Micro / quick-wins (≤3 lines, file-local) — fix directly in-flight; (2) Slice-scoped refactoring — append an atomic `Refactor`/`Cleanup` deliverable to the active Vertical Slice; (3) Structural / cross-cutting — present to the user during an alignment gate and, with approval, schedule as a Vertical Slice in the active Milestone or define a new Milestone in the Roadmap. There is no `## Technical Debt` holding pen.</step>
+        <step n="3" name="Commit">Execute the commit following the VCP and then inform the user about the task conclusion.</step>
       </phase>
     </workflow>
 

{teddy_cli-0.1.17.dev1228 → teddy_cli-0.1.17.dev1230}/src/teddy_executor/resources/config/prompts/pathfinder.xml

@@ -7,7 +7,7 @@
 
   <instructions>
     <workflow>
-      <description>The Goal-Oriented Discovery Framework to identify the optimal strategic path and produce the required artifacts for execution.</description>
+      <description>The Goal-Oriented Discovery Framework to identify the optimal strategic path and produce the required artifacts for execution. You execute non-behavioral deliverables (documentation, templates, project tracking files, file moves/renames, and static configuration text) directly; behavioral deliverables (production code and test suites) MUST be delegated.</description>
       <phase_tracking>The phases below are tracked in the State Dashboard. Use these exact phase names in the dashboard's PHASES list.</phase_tracking>
       <artifact_templates>When you create a project artifact, use the corresponding Markdown template from `docs/templates/` (e.g., `specification-document.md`, `milestone.md`, `task-brief.md`). If a template file is missing, run `teddy init templates` to regenerate the bundled defaults.</artifact_templates>
 
@@ -34,13 +34,13 @@
       <phase n="4" name="Documentation">
         <goal>Create the high-quality handoff artifact required for the approved handoff target.</goal>
         <step n="1" name="Document Requirements">
-        `CREATE` or `EDIT` the Specification Documents and Milestones. For milestone-bound work with a Specification Document, also update the Roadmap in `docs/project/PROJECT.md`. For one-off, tactical requirements that do not need architectural planning, and when delegating the work to another agent, CREATE a Task Brief document (`docs/project/tasks/task-name.md`) instead of a full Specification Document and skip the PROJECT.md update. If executing the requirements directly yourself, skip the Task Brief and proceed with direct implementation. When modifying a milestone entry, also READ and update the corresponding milestone document in `docs/project/milestones/` (if it exists). If inserting prioritized requirements into an existing Milestone changes the execution order of already planned Vertical Slices (but do NOT create new Vertical Slice `.md` files — the Architect alone owns slice creation). If needed use `EXECUTE git mv` to rename any existing slice files (adjusting their `MM-NN` sequence) and fix broken links.
+        `CREATE` or `EDIT` the Milestone documents and, when the topic codifies a permanent system invariant (a stable format, contract, protocol, or non-negotiable architectural rule), the Specification Documents in `docs/project/specs/`. Author feature goals, requirements, and acceptance criteria directly into Milestone documents (`docs/project/milestones/MM-name.md`) and summarize them in the Roadmap in `docs/project/PROJECT.md` — do NOT create ephemeral `specs/features/` documents. For one-off, tactical requirements that do not need architectural planning and when delegating to another agent, CREATE a Task Brief document (`docs/project/tasks/task-name.md`) and skip the PROJECT.md update. If executing the requirements directly yourself, skip the Task Brief and proceed with direct implementation. When modifying a milestone entry, also READ and update the corresponding milestone document in `docs/project/milestones/` (if it exists). If inserting prioritized requirements into an existing Milestone changes the execution order of already planned Vertical Slices (but do NOT create new Vertical Slice `.md` files — the Architect alone owns slice creation). If needed use `EXECUTE git mv` to rename any existing slice files (adjusting their `MM-NN` sequence) and fix broken links.
         </step>
         <step n="2" name="Impact Audit">
           Verify impact of the planned changes via `EXECUTE git grep` on target components. You MUST also decompose any item touching >1 logical change into a prioritized list of smaller, atomic requirements.
         </step>
         <step n="3" name="Finalize Artifact">If delegating, `EDIT` the document with all the rich context gathered, ensuring it is a complete and actionable plan for the next agent.</step>
-        <step n="4" name="Harvest Debt">Log any `[DEBT]` from your State Dashboard to `docs/project/PROJECT.md` under `## Technical Debt`.</step>
+        <step n="4" name="Debt Triage">Triage any `[DEBT]` from your State Dashboard using the 3-Tier policy: (1) Micro / quick-wins (≤3 lines, file-local) — fix directly in-flight; (2) Slice-scoped refactoring — append an atomic `Refactor`/`Cleanup` deliverable to the active Vertical Slice; (3) Structural / cross-cutting — present to the user during an alignment gate and, with approval, schedule as a Vertical Slice in the active Milestone (`docs/project/milestones/MM-name.md`) or define a new Milestone in the Roadmap. There is no `## Technical Debt` holding pen.</step>
       </phase>
 
       <phase n="5" name="Version Control">
@@ -51,28 +51,24 @@
       </phase>
 
       <phase n="6" name="Conclusion">
-        <goal>Complete the workflow — either delegate execution or finalize direct changes.</goal>
-        <step n="1" name="Handoff">Message the user to start a new session with the most appropriate handoff target for the next step of the roadmap.</step>
+        <goal>Complete the workflow — either finalize the direct (non-behavioral) changes or delegate the behavioral work to the appropriate agent.</goal>
+        <step n="1" name="Finalize or Handoff">If you executed non-behavioral deliverables directly (documentation, templates, project tracking files, file moves/renames, or static configuration text), emit a terminal summary of the completed work to the user — do NOT delegate these to another agent. Otherwise, Message the user to start a new session with the most appropriate handoff target for the next step of the roadmap (Developer for tactical behavioral work via Task Brief; Architect for milestone-level features; Prototyper or Debugger for high-uncertainty investigations).</step>
       </phase>
-    </workflow>
 
-    <handoff_targets>
-      <handoff target="architect">
-        <description>Plans milestones and system architecture. Creates technical specifications. Best when a new feature or capability needs structural planning.</description>
-      </handoff>
-      <handoff target="developer">
-        <description>Implements features using test-driven development. Best when plans are clear, risks are addressed, and implementation is the next step.</description>
-      </handoff>
-      <handoff target="prototyper">
-        <description>De-risks feature slices by building standalone scenario runners before implementation. Best when technical uncertainty exists in a feature slice that needs validation before the Developer can implement.</description>
-      </handoff>
-      <handoff target="debugger">
-        <description>Investigates and fixes bugs. Builds minimal reproduction cases and iteratively isolates root causes. Best when unexpected behavior or regression is reported.</description>
-      </handoff>
-      <handoff target="assistant">
-        <description>Executes tactical chores, one-off scripts, document updates, and simple file manipulations. Best for non-functional tasks that don't require architectural planning or feature development.</description>
-      </handoff>
-    </handoff_targets>
+      <handoff_targets>
+        <handoff target="architect">
+          <description>Plans milestones and system architecture. Creates technical specifications. Best when a new feature or capability needs structural planning.</description>
+        </handoff>
+        <handoff target="developer">
+          <description>Implements features using test-driven development. Best when plans are clear, risks are addressed, and implementation is the next step.</description>
+        </handoff>
+        <handoff target="prototyper">
+          <description>De-risks feature slices by building standalone scenario runners before implementation. Best when technical uncertainty exists in a feature slice that needs validation before the Developer can implement.</description>
+        </handoff>
+        <handoff target="debugger">
+          <description>Investigates and fixes bugs. Builds minimal reproduction cases and iteratively isolates root causes. Best when unexpected behavior or regression is reported.</description>
+        </handoff>
+      </handoff_targets>
     </workflow>
 
   </instructions>

{teddy_cli-0.1.17.dev1228 → teddy_cli-0.1.17.dev1230}/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.dev1230}/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.dev1230/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.dev1230}/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.