You have built one app. This page shows the next step: give the platform a product, not a feature. The planner designs an integrated suite of apps from one description. Dependency edges pace the build order. Milestones close as episodes with digests. You write one brief; the platform does the rest.

Create an org

An org is the unit of product planning. Create one at https://git.open-platform.sh/org/create. Treat the description as your product brief. It holds up to 255 characters. Write one dense paragraph: what the product is, and who it is for.

The platform detects the new org within a minute. It creates a _plan repo inside the org. The repo holds one issue titled 🌱 Plan this org: <org> with a pre-drafted brief. Nothing builds yet. This is your moment to shape the product.

Arm the planner

Open the seed issue at https://git.open-platform.sh/<org>/_plan/issues. Edit the body. Add comments to refine the brief. The planner reads the entire thread, not only the body. When the brief says what you mean, apply the plan-org label.

A planner agent starts. It designs an integrated suite — typically 2-4 product apps plus a www landing site. It seeds the repos and files a dependency-wired roadmap. Progress heartbeats land on the seed issue while it works.

Note: the platform holds builds while planning runs. Do not expect a 🏗️ v1 PR during the run.

The roadmap appears as an issue titled 🧭 <org> roadmap on the lead app. The planner updates this one issue in place forever. Its number is a stable permalink. Bookmark it.

Platforms with PLANNER_MODE=auto skip the arming step and plan every new org on sight. The default mode is armed.

The first deliverable: the ownership map

The planner's first output is an entity-ownership map. Every domain entity gets exactly one owning app. The owner holds the database and provides the APIs. Every other app consumes those APIs and holds only references. A consumer app that grows its own rival table fails the lint gate, by doctrine.

Read the map from the issues:

• The provider issue carries a provides: <slug> line in its body. One provider per slug, ever.
• Each consumer issue carries a consumes: <slug> line plus a real dependency edge to the provider issue.
• The planner creates consumer apps with database: false, so a data silo is impossible. Consumers integrate through the owner's published contract. See get_contract on Connect Your Agent.

Dependency edges pace the waves

Dependencies are real Forgejo issue dependencies, not body syntax. Add one in the UI with "Blocked by" on any issue. Or use the MCP tool add_issue_dependency. The tool works cross-repo (dep_owner/dep_name) and refuses any edge that would close a cycle. The semantics are strict: a blocked issue cannot start until its blocker closes.

The dispatcher defers any agent-work issue with open blockers. No budget burns; the label stays on. When a provider issue closes, the platform arms the ready dependents. The next wave builds itself. A suite converges in the right order without anyone clicking anything:

graph BT
  HB["homebase#2 — contract skeleton<br/>provides: property"]
  LI["listings<br/>consumes: property"]
  LE["leasing#2<br/>consumes: property"]
  MA["maintenance<br/>consumes: property"]
  LI -- "blocked by" --> HB
  LE -- "blocked by" --> HB
  MA -- "blocked by" --> HB

Two rules keep the graph honest:

• The apex rule. Every provides: issue must carry the agent-work label. An unlabeled apex dead-stops everything downstream of it.
• The root. Every app's 🏗️ v1: <app> issue is the root of its tree; the planner's roadmap issues descend from it automatically and the cross-repo contract edges join the trees. See Dependency Trees.
• The lint gate. lint_dependency_graph(owner) audits the whole org: cycles, orphaned consumers, duplicate providers, unprovided surfaces, dead blockers. The planner must get a clean report before it publishes. Run it yourself at any time.

When the graph stalls — a transitive cycle, or an unlabeled blocker — the platform diagnoses the cause. It posts one 🚧 comment on the stuck issue with the exact fix. It never flags a benign "still building" wait.

One rule of doctrine: edges for contracts, flags for sequencing. An edge means the work cannot compile or run without its blocker. Mere feature order builds immediately behind a release feature flag that defaults to off. Each milestone gets one flip-and-retire issue for its flags.

Episodes: milestones with an ending

The planner groups post-v1 work into milestones — v1.1 — <theme> style, 3-6 issues each. A milestone is an episode. When its last issue closes, the platform closes the milestone and posts a digest to the episode log. The digest holds the issue count, the shipped list, and the real agent-compute time. The time is summed from Forgejo's native Time Spent tracker.

Watch it run

Two durable issues are your mission control:

• 🛰 Fleet status — a live table with one row per org: Org | Health | Episode | Progress | Backlog | In-flight | 24h spend. Each row shows a health glyph (🟢 working / ⏳ queued / ⚠️ stalled / ⏸ paused / 🔴 breaker / 🔌 provider backoff / ⚪ idle) and a #. progress bar for the current episode. The platform refreshes the table every few hours.
• 📖 Episode log — the single cross-org feed of episode digests. Each entry is headed ✅ <org>/<repo> / <milestone> — episode complete. It is the platform's narrative history, one comment per finished episode.

By default these live in the first two issues of plat/fleet. Operators typically point them at their own <login>/fleet repo. Dashboards and spend levers are on Steering the Fleet.

A note on pace

A single v1 builds in minutes. An integrated suite takes longer, by design. The dependency graph serializes the waves. Every run passes through flow control: per-org concurrency, spacing between runs, and the global governor that paces the fleet to one subscription. Expect hours to days for a full suite. Steer along the way with Building with Issues: comment on PRs, file issues, label them agent-work.