rdev/app-vision.md

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.