Architecture Discovery

# Setup: Architecture Discovery

**Purpose:** Scan an existing project and populate `.smiddy/context/architecture.md` with the actual system architecture.
**When to run:** Once, for existing projects, immediately after running `stack-discovery.md` and before starting Phase 02.
**Output:** A filled-in `.smiddy/context/architecture.md`.

> **New projects:** Do not run this prompt. The Architect agent in Phase 02 will create the architecture from scratch.

---

## Instructions

Your job is to discover the system's architecture by reading the source code — not by asking the user to describe it. Infer what you can; ask only what you cannot determine from the code itself.

### Step 1 — Map the top-level structure

Read the project root and identify the top-level folders. Determine whether the project is:

- A **monolith** — single deployable unit, all logic in one codebase
- A **modular monolith** — single deployment but code divided into explicit domain modules
- A **monorepo** — multiple packages or services in one repository
- A **microservices system** — multiple independently deployable services

Look for signals:
- `apps/`, `services/`, `packages/` folders → monorepo or microservices
- `src/` with domain-named subfolders → modular monolith
- Flat `src/` or single-layer structure → monolith

Record the architecture style and its rationale (as inferred from the code).

### Step 2 — Identify entry points

Find where the system starts:

| Signal | What it reveals |
|---|---|
| `main.ts`, `index.ts`, `app.ts`, `server.ts` | Application entry point |
| `cmd/`, `bin/`, `cli.py` | CLI entry points |
| `handler.ts`, `lambda.ts`, `functions/` | Serverless entry points |
| Route files (`routes/`, `pages/`, `app/` in Next.js) | HTTP surface area |
| Worker or queue consumer files | Background processing |

For each entry point, note what it exposes (HTTP, CLI, event, etc.) and to whom (public internet, internal services, scheduled jobs).

### Step 3 — Map components and responsibilities

Read the top-level source folders and identify distinct components. A component is a folder or module with a clear, bounded responsibility. For each component, describe:

- What it is responsible for
- What it depends on (other components, external services)
- Whether it has a public interface (exported functions, HTTP endpoints, events)

Do not list every file. Identify the boundaries, not the contents.

### Step 4 — Trace key data flows

Find the two or three most important user-facing or system-level flows. For each:

1. Start from the entry point (HTTP request, CLI command, event, scheduled job)
2. Follow the call chain through components
3. Identify where data is read from or written to

Use the format: