853ec4cf81
Three coordinated fixes for CI pipeline race conditions:
1. Woodpecker step dependencies: Added depends_on: [deps] to all 6 component
templates (service, worker, cli, app-astro, app-react, app-nextjs) so build
steps wait for go work sync to complete.
2. Idempotent resource provisioning: Modified provisionResources() to check
for existing database/cache before creating, preventing "already exists"
errors on component re-adds.
3. Batch component endpoint: POST /projects/{id}/components/batch enables
atomic multi-component additions in a single git commit. Validates all
components upfront, provisions infra sequentially, commits code components
atomically.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
78 lines
4.2 KiB
Markdown
78 lines
4.2 KiB
Markdown
# 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.
|