Docs · IDE rails

IDE rails

Closure doesn’t replace your IDE. It gives your IDE a product model.

The Quickstart is enough for most teams: one npx command, Connect in Cursor, build. This page is the deeper reference — what that command installs, the tool catalog, and how auth works.

The authoring contract

Every AI coding tool can generate code. Connected to Closure, your IDE authors a governed product instead — and the runtime holds up its side of a real contract:

The runtime teaches. Your agent doesn't guess at the paradigm — it asks. platform_docs_search grounds answers in the docs, the book, and the whitepaper; platform_taxonomy serves the live vocabulary: every schema, component kind, workflow node type, and composition rule, straight from the runtime that will execute them.
The runtime checks before you write. platform_validate dry-runs any DataObject, Experience graph, or workflow graph and returns structured, teachable errors — authoring mistakes die in the editor, not in your product.
The runtime gates what ships. Agent creativity is welcome — novel layouts, custom tools, original brand systems. But the ship bar (design system, framing, taxonomy-pure components, i18n, discoverability, accessibility) is verified server-side by the same gates a governed build runs. platform_experience_verify gives your agent that verdict on demand; no client can mark its own work as passing.
The runtime delegates back. Governed workflows can pause at an agent step and hand the task to your IDE (platform_agent_task → work → platform_agent_submit). The programmer's workshop becomes a callable instrument of the application's own processes — reasoning stays local, the graph, vault, and audit stay with the platform.
The runtime learns from friction. Anonymous signals — a search with no good answer, a gate that keeps failing — automatically become Issues in the platform's own healing loop (see telemetry below). The integration gets better because people use it.

That's the division of labor: the best authoring surfaces in the world, one governed runtime underneath. Your editor reasons; Closure stays the product.

Install

Run in a normal terminal (Cursor’s Terminal panel or your OS terminal) — not via the Agent’s Shell tool:

npx @closurenetwork/ide@latest init

Public package on npmjs.org (closurenetwork scope). Default path: fetch the public Agent Pack from Closure Knowledge, write IDE rails, register remote MCP + OAuth (Cursor Connect). Fallback for CI / locked-down hosts: npx @closurenetwork/ide init --stdio plus an API key from Account → IDE.

Why a real terminal: Cursor sandboxes Agent Shell (network allowlist) and *hard-blocks agent writes to `.cursor/.json** — including mcp.json. First-time install is intentionally a human step, like cloning a repo. After that, Connect + platform_* tools are the agent path; npx @closurenetwork/ide sync` can refresh rules/skills.

On-prem: point at your console before init:

STUDIO_URL=https://<your-host>/console npx @closurenetwork/ide init

What gets written (IDE rails)

init is a thin installer. Doctrine and skills are pulled from Closure (platform org Knowledge via GET /api/public/ide/pack) — not hardcoded in the npm package. Local files are adapters only; the product graph stays the source of truth.

Path	Role
`.closure/pack.json`	Pack version + hashes for `sync`
`.cursor/mcp.json`	Registers the `closure` MCP server
`.cursor/rules/` · `.cursor/skills/closure-platform/`	Cursor rules + Closure-way skills
`.claude/skills/closure-platform/` · `CLAUDE.md`	Claude Code adapters
`AGENTS.md`	Generic agent host constitution
`.github/copilot-instructions.md`	Short Copilot extract

After Connect, org skills refresh via MCP (platform_knowledge_skills_pull). Re-fetch rails with npx @closurenetwork/ide sync; check with npx @closurenetwork/ide status.

Auth

Mode	How
Connect (default)	`https://mcp.closureapps.com` → Cursor Connect → browser consent
API key	Mint `csk_…` under Account → IDE; use `--stdio` and set `STUDIO_API_KEY`

Never paste secrets into chat. Use platform_collect_start → browser form → vault.

Tool catalog

Tool	What it does
`platform_status`	Confirm session / org
`platform_knowledge_skills_pull`	Refresh Closure-way skills into the rails dirs
`platform_docs_search`	Semantic search over the docs, the book, and the whitepaper — grounds paradigm answers
`platform_taxonomy`	Machine-readable DataObject vocabulary — schemas, component kinds, composition rules, workflow node kinds, custom tools
`platform_validate`	Dry-run a DataObject, Experience graph, or workflow graph before writing
`platform_experience_scaffold`	Scaffold an Experience on the graph
`platform_experience_verify`	Run the governed build's craft gates (page craft, brand, discoverability, a11y) against one Experience
`platform_build_start`	Start a governed build on SaaS
`platform_tools_create` / `platform_tools_list`	Register and discover custom serverless-function tools (sandboxed code or HTTPS)
`platform_workflows_list`	List org workflows
`platform_agent_task` / `platform_agent_submit`	IDE-as-executor loop when a run is `waiting_ide`
`platform_collect_start`	Open a governed form for secrets
`platform_run_start` / `platform_run_status`	Start and poll workflow runs
`platform_experiences_health`	Pin state per environment — what's on Test/Prod, whether Dev is ahead
`platform_experiences_promote`	Snapshot live Dev and promote one Experience to Test or Prod
`platform_release_snapshot` / `platform_release_promote`	Org-wide release: capture every pillar, then pin it to an environment
`platform_feedback`	Anonymously report a docs gap or build friction — feeds the platform's self-improvement loop

Promote from your IDE

Environments are part of the authoring loop, not a console detour. Dev is the live editable graph; Test and Prod serve pinned versions. When the user says "promote to test" or "ship it to prod":

platform_experiences_health — check pin state and whether Dev moved past the last snapshot.
platform_experiences_promote — snapshots live Dev (if needed) and pins the version to test or prod for one Experience.
For an org-wide cut across every pillar, use platform_release_snapshot then platform_release_promote.

Promotes run the same server-side gates as the console: role and promote-policy checks, the open-Issue quality gate, and optional dual-control approval. A denied promote returns the reason — surface it to the user instead of retrying.

Anonymous telemetry

The MCP kit reports friction signals so the platform can fix what breaks in the field: failed tool calls, docs searches with no good answer, validation and craft-gate failures. Reports carry only the signal — a tool name, an error message, or a normalized query. No prompts, no code, no secrets, and no account identity are ever sent; organization ids are one-way hashed before storage. Recurring patterns automatically open Issues for the platform team, each with a recommended fix.

Opt out any time by setting CLOSURE_TELEMETRY=0 in the environment that runs the MCP server.

What the IDE must not do

Treat chat as a secrets channel
Invent a second source of truth on disk for Experiences
Call an app done before platform_experience_verify passes — the craft gates (design system, framing, taxonomy-pure components, i18n, discoverability, accessibility) are the same ones a governed build enforces
Assume a local Closure process — default is SaaS (Self-hosting when you must)
Confuse L1 gateway MCP (closure.*) with Platform MCP (platform_*)

Ops — Runs · Events · Issues · Goals · Versions
Build paths — IDE, external app, or console
Self-hosting