# Orchard Studio: The Interactive Foundry

**Vision:** A "Deploy First, Code Later" platform where users build software through conversation with an Architect Agent, watching their application evolve in real-time.

## 1. The Core Philosophy
Current AI coding tools (Cursor, Copilot) operate at the *file level*. Deploying is the *last* step.
**Orchard Studio** flips this:
1.  **Infrastructure is Day 0.** You get a URL and a Database immediately.
2.  **Requirements are Fluid.** You don't write a spec document; you have a conversation.
3.  **Agents are Engineers.** You don't review PRs line-by-line; you review functionality and intent.

## 2. The User Experience (The "Aeries" Flow)

### Phase 1: Genesis (Template Selection)
*   **UI:** A visual catalog of "Seeds" (Templates).
    *   *Option A:* "SaaS Starter" (Auth + Billing + API).
    *   *Option B:* "Social World" (Realtime + Spatial).
    *   *Option C:* "Empty Canvas" (Hello World).
*   **Action:** User clicks "Spawn".
*   **System:** `rdev` immediately provisions K8s namespace, CRDB database, and deploys the Skeleton.
*   **Result:** User sees a green "Live" badge and a URL: `https://cool-project.threesix.ai`.

### Phase 2: The Consultation (The Architect)
*   **UI:** A split screen. Left side is the **Live App Preview**. Right side is the **Architect Chat**.
*   **Interaction:**
    *   *User:* "I want users to be able to post photos of their cats."
    *   *Architect:* "Sounds good. Should these photos be public, or friends-only?" (Clarifying requirements).
    *   *User:* "Public feed, like Instagram."
    *   *Architect:* "Understood. I'll add a `Post` model, image storage, and a public feed endpoint."
*   **The Artifact:** The Architect updates a **"Blueprint"** (a live JSON/Markdown representation of the feature) in the sidebar. The user sees the plan forming.

### Phase 3: Materialization (The Build)
*   **Action:** User clicks "Build It".
*   **System:** The Studio bundles the context and sends it to `rdev`.
    *   `rdev` triggers the SDLC: Spec -> Design -> Implement -> Verify.
    *   **The Magic:** The user sees a "Terminal/Activity" feed in the Studio:
        *   *Check:* "Designing Database Schema..."
        *   *Check:* "Writing Go Handlers..."
        *   *Check:* "Running Tests..."
        *   *Check:* "Deploying..."
*   **Result:** The "Live App Preview" refreshes. The feature is now real.

### Phase 4: Evolution (Day 2+)
*   **UI:** The user sees a bug or wants a change.
*   **Interaction:** "The cat photos are too big. Make them grid style."
*   **System:** `rdev` treats this as a refactor/style update task.

## 3. Technical Architecture

### The Frontend: `orchard-studio`
A Next.js application that acts as the control plane.
*   **Auth:** Integrated with `rdev` auth.
*   **State:** Holds the "Draft" state of features before they are sent to the build engine.
*   **Socket:** Listens to `rdev` events to stream build logs and deployment status.

### The Backend: `rdev-api` Adaptation
We need to expose the "Tree Runner" logic as a managed service.
*   **`POST /projects/{id}/blueprint`**: Updates the desired state.
*   **`POST /projects/{id}/materialize`**: Triggers the Agent to reconcile the difference between *Current Code* and *Blueprint*.

### The Agent: "The Architect"
A specialized persona (system prompt) separate from the "Coder."
*   **Responsibility:** Requirement Elicitation. It doesn't write code; it writes **Specs**.
*   **Skill:** `interview-user`. It knows to ask about edge cases (Auth, Scale, Privacy) before committing to a plan.

## 4. How this enables "Aeries"
If the goal is a social world:
1.  **Genesis:** User spawns "Empty World".
2.  **Consultation:** "I want agents that walk around and talk about philosophy."
3.  **Materialization:** `rdev` deploys the `simulation-service` and `redis`.
4.  **Evolution:** "Add a weather system." `rdev` refactors the simulation loop to include environmental variables.

## 5. Roadmap to Reality

1.  **The Engine (Now):** Finish `slackpath` & `aeries` trees to prove `rdev` *can* build these systems autonomously.
2.  **The API Layer (Next):** Expose `rdev` capabilities so a UI can trigger them (not just CLI).
3.  **The Studio (Future):** Build the Next.js UI that wraps this power in a conversation.