What the app called a Product is now a Project, and what it called a Project is now a Scope. Two levels, one name each, the same everywhere: Project › Scope › Modules › Features › Tasks. Nothing about your data changed.
What changed
The hierarchy had two levels and three names. The codebase-level container was a Product, the blueprint inside it was a Project, and the same blueprint was also called a Scope in URLs, buttons, and pricing. Those are now:
- Project — the thing you're building: one codebase, with its GitHub repo, project-wide Context, and memory. This was "Product".
- Scope — one planned piece of work inside a project: a blueprint of modules, features, and tasks. This was "Project".
A project holds as many scopes as it needs, and each scope inherits the project's repo and Context unless it overrides them. That was always how it worked; only the words moved.
Where you'll see it
- The header switcher reads Project / Scope. "New project" creates the container; "New scope" creates a blueprint inside it.
- Project settings live at
/project/<id>/settings; the Project board is/scopes?project=<id>. The old/product/...routes are gone, so update any bookmarks. - Pricing says 1 project on the free entry and unlimited projects & scopes on paid plans, and the plan comparison, FAQ, and docs match.
- Settings pages, the dashboard, usage, and cloud runs say "scope" wherever they used to say "project" for a blueprint.
For agents
MCP tool names are a public contract — installed skills and configured agents call them by name — so list_projects, get_project, create_project, and project_id are unchanged and still operate on a scope. The parent project is product_id. Every tool description and the session playbook now say so, and list_projects labels the parent list Projects, so an agent told to "add this to the Billing project" lands in the right place. A clean rename of the tool names will come with a versioned MCP release and a deprecation window, not a silent swap.
Nothing in your data or API keys changed.