You've built one app. This page is about the bigger move: describe a product, and the platform plans and builds an integrated suite of apps — one data owner per entity, dependency edges pacing the build order, episodes closing with digests — on autopilot.

Create an org

An org is the unit of product planning. Create one at https://git.espoautos.com/org/create and treat the description as your product brief (up to 255 characters — one dense paragraph of what the product is and who it's for).

The platform notices the fresh org within a minute and stands up a _plan repo inside it, containing a single 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.espoautos.com/<org>/_plan/issues. Edit the body, argue in the comments — the planner reads the entire thread, not just the body. When the brief says what you mean, apply the plan-org label.

A planner agent launches: it designs an integrated suite (typically 2-4 product apps plus a www landing site), seeds the repos, and files a dependency-wired roadmap. Progress heartbeats land on the seed issue as it works; while planning runs, builds are deliberately held, so don't expect a 🏗️ v1 PR mid-run. The roadmap itself appears as an issue titled 🧭 <org> roadmap on the lead app — updated in place forever, so its number is a permalink worth bookmarking.

(Platforms running PLANNER_MODE=auto skip the arming step and plan every new org on sight; armed is the default.)

The first deliverable: the ownership map

The planner's first real output is an entity-ownership map: every domain entity gets exactly one owning app. Owners hold the database and provide APIs; every other app consumes those APIs and holds only references. No data silos, by doctrine — a consumer app growing its own rival table is a lint failure, not a style complaint.

You can read the map straight off 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.
• Consumer apps are created with database: false, so a silo is physically impossible — they integrate through the owner's published contract (see get_contract on Connect Your Agent).

Dependency edges pace the waves

Dependencies aren't body syntax — they're real Forgejo issue dependencies. Add them in the UI ("Blocked by" on any issue) or via the MCP tool add_issue_dependency, which works cross-repo (dep_owner/dep_name) and refuses edges that would close a cycle. Semantics: a blocked issue cannot start until its blocker closes.

The dispatcher defers any agent-work issue with open blockers — no budget burned, the label stays on. When a provider issue closes, the platform automatically arms the ready dependents, and the next wave builds itself. This is how 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 silently dead-stops everything downstream of it.
• The lint gate — lint_dependency_graph(owner) audits the whole org for cycles, orphaned consumers, duplicate providers, unprovided surfaces, and dead blockers. The planner must get a clean report before publishing; you can run it any time.

If something does stall — a transitive cycle, or a blocker nobody labeled — the platform diagnoses it and posts one 🚧 comment on the stuck issue telling you the exact fix. Benign "still building" waits are never flagged.

One more piece of doctrine: edges for contracts, flags for sequencing. An edge means "this literally won't compile or run without that." Mere feature order is built immediately behind a release feature flag defaulting off, with one flip-and-retire issue per milestone.

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 — issue count, real agent-compute time logged (summed from Forgejo's native Time Spent tracker), and the shipped list — to the episode log.

Watching it run

Two durable issues are your mission control:

• 🛰 Fleet status — a live table, one row per org: Org | Health | Episode | Progress | Backlog | In-flight | 24h spend, with a health glyph (🟢 working / ⏳ queued / ⚠️ stalled / ⏸ paused / 🔴 breaker / 🔌 provider backoff / ⚪ idle) and a #. progress bar for the current episode. Auto-refreshed every few hours.
• 📖 Episode log — the single cross-org feed of episode digests, each entry headed ✅ <org>/<repo> / <milestone> — episode complete. 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 live on Steering the Fleet.

Honest note on pace

A single v1 builds in minutes. An integrated suite is a different animal: waves are serialized by the dependency graph, and every run passes through flow control — per-org concurrency, spacing between runs, and the global governor pacing the whole fleet to one subscription. Expect hours to days for a full suite, by design. Steering along the way is just Building with Issues: comment on PRs, file issues, label them agent-work.