Glossary · Delivery

OpenSpec plan

An OpenSpec plan is the change a KERNSTACK topic asks @agent to write in Plan mode: a proposal, requirements with scenarios, and a task list, shown as a card in the thread. Product files and deploys stay closed until someone on the topic approves that card.

Collaboration BoardAgent SandboxesHosted Git
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

Definition: OpenSpec plan

An OpenSpec plan is the change a KERNSTACK topic asks @agent to write in Plan mode: a proposal, requirements with scenarios, and a task list, shown as a card in the thread. Product files and deploys stay closed until someone on the topic approves that card.

What Plan mode writes

Turn Plan mode on from the topic menu when Agents are enabled. With hosted git available, an @agent mention writes one OpenSpec change on the conversation’s branch: a proposal, a spec delta whose requirements are marked ADDED, MODIFIED, REMOVED, or RENAMED, at least one scenario on each requirement, and a task checklist. The thread renders that change as a card — change id, title, proposal, requirements, scenarios, and tasks — and the composer stays on “Plan mode · no changes”.

What approval does

A proposed card says no changes are made until approved. Approve records who approved and asks @agent to apply that change and deploy the conversation’s stack. Plan mode stays on. Request changes, or a reply on the card, marks the proposal as changes requested. A newer proposal replaces older ones still waiting.

The card describes the behavior the topic agreed. When the approved change is applied, kernstack plan names the infrastructure effect: new routes, changed functions, and anything listed for deletion. The topic reads the behavior first; the plan diff reads the platform consequences of making it.

FAQ

Frequently asked questions

On an existing topic, with Agents enabled: the topic menu has Plan mode. The composer then reads “Plan mode · no changes”, and an @agent mention proposes an OpenSpec plan. Hosted git is what lets that plan land as a change on the conversation’s branch.

The change id, a title, a short proposal, requirements tagged ADDED, MODIFIED, REMOVED, or RENAMED, at least one scenario each, and a task checklist. The same files sit on the conversation’s branch under openspec/changes/<id>/.

Approving asks @agent to apply that change and deploy the conversation’s stack. Plan mode stays on. Moving the work onto a production target remains the separate, confirmed promotion the project already requires.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudHow KERNSTACK unifies infrastructure, code, intelligence, and collaboration.Platform · AgentsAgent sandboxesIsolated sandboxes for coding agentsPlatform · PeopleCollaborationBoards and conversations on the projectPlatform · SourceHosted GitRepository hosting inside the projectGlossary · AgentsAgent sandboxAn agent sandbox is where a coding agent’s work lives on KERNSTACK: a dedicated agent/<id> branch in hosted git, deployed to its own agent-<id> environment. Your main branch is never touched, and nothing leaves the sandbox without a reviewed plan.Glossary · WorkflowHuman approvalHuman approval is a workflow step — { "human": { "title": "..." } } — that pauses a run until a named person decides. The decision, the decider, and the record as shown are stored in the run, and the workflow resumes with the outcome as data.Glossary · DeliveryPlan diffA plan diff is the preview kernstack plan produces before any deploy: the creates, updates, and deletes the new stack.json would cause — with deletes listed under “Will delete” and refused until a person passes --confirm-destructive. It is also available as kernstack plan --json.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →