spec-editor Autonomic is in early access. Request access

spec-editor Autonomic

spec-editor Autonomic is a plugin for the open core. The open core holds the requirements model. Autonomic adds the team that turns a requirement into reviewed, tested, released code. Autonomic is in early access: purchase is not open yet.

Element ids and file names in the examples on this page are invented.

Early access

To ask for it, see pricing and use “Request early access”, or write through the contact page. Prices on the pricing page are early and may change. Autonomic is licensed separately from the open core, under the plugin license; the open core is Apache-2.0. Self-service purchase and license keys are coming soon. Until then the plugin is delivered to early-access users directly.

The steps of activation, as they will work once purchase opens, are on the activation page.

What Autonomic adds

Area What you get
Delivery team Analysts, an analysis manager, a project manager, a coder, a tester and devops.
Analysis Independent analysts per source, a reconciling second pass, a check of the result against the source.
Review Stages decided by evidence, with risk classes A to D.
Test stands A blue/green stand for every plan, acceptance criteria run there before promotion, rollback.
Cost control Difficulty classifier, a ladder of models, cost attribution, budget guards, a pool of subscription accounts.
Breakpoints A small JavaScript snippet that turns a click in your running product into a source.
Reengineer Restores a model from existing code.
Coverage spec-editor coverage: requirements covered by code and code covered by requirements.
Code search Local semantic search over code, without an external service.
In the interface Report a bug; chat with an agent in the context of an element.

The delivery roles and who decides what

Roles mirror a small human organisation. Managers own queues of work. A deterministic engine only moves events between them and does not decide anything.

Role Does
Analysts Each reads a source on its own and proposes elements: modules, scenarios, screens, data, qualities.
Analysis manager Owns the analysis queue; reconciles the analysts’ results in a second pass and sends the agreed result for checking against the source.
Project manager Plans the work of a requirement, splits it into tasks and owns the delivery queue.
Coder Implements a task in the repository on the machine where your subscription is logged in.
Tester Runs the acceptance criteria and records the evidence.
Devops Builds, deploys to a test stand, promotes or rolls back.

The requirement is the item that flows through this team: from a source, to analysis, to a plan, to code, to a check, to release. Because the criteria live in the requirement, the tester and the analyst read the same definition of done.

A model never receives what its source did not say. After the analysts agree, their result is checked against the source, and an element that has no support there does not enter the model.

Review stages and risk classes

Each stage of delivery has a gate. A gate is decided by evidence: what was changed, what the checks returned, how much the change can break. Changes are sorted into risk classes A to D. A low-risk change with passing evidence goes through by itself. A human is asked only where the evidence is missing.

The gate commands are under spec-editor gate: list shows pending requests, approve and reject answer one, risk computes the risk assessment without changing anything. See the CLI reference.

Test stands

Every plan is deployed to a test stand before it reaches your users. Stands are blue/green: the new version runs next to the current one. The acceptance criteria of the requirements in the plan run against the stand, and the plan is promoted only if they pass. A rollback exists. Builds and stands can run on a remote host; coders stay on the machine where the subscription is logged in.

Cost control on your own subscriptions

Autonomic runs on your own subscriptions or tokens. We do not sell tokens and your code is not sent to us. Model access goes through the local Claude Code CLI on your subscription (no API key), through API keys with LiteLLM, or through local models with Ollama.

What keeps the cost in check:

  • A classifier rates the difficulty of a task; easy tasks go to cheap models.
  • A ladder of models climbs from cheap to strong when a result fails its checks.
  • Cost is attributed to the source and to the role that spent it.
  • Budget guards limit what a run may spend.
  • A pool of subscription accounts fails over to the next account when one hits its limit.

Breakpoints

A breakpoint lets the owner of a running product point at a part of the screen and say “this”. You add a small JavaScript snippet to the product. After that, a click on an element of the page creates a source in spec-editor, bound to the requirement of that element, together with the screen, the element path and the state of the page.

The page is marked once with data-spec-id, the same idea as @implements for code. A screen root gets the id of its screen element, a widget the id of its widget:

<div data-spec-id="SCR-012">
  <table data-spec-id="WID-007">...</table>
  <button data-spec-id="CTL-003">Export</button>
</div>

The snippet is initialised with the address of your spec-editor server, an owner token and the name of the application. This is an illustration; the endpoint, token and file name are placeholders:

<script src="/assets/spec-editor-sdk.js"></script>
<script>
  const sdk = SpecEditorSDK.init({
    endpoint: "http://127.0.0.1:8088",
    token: "OWNER_TOKEN",
    app: "orders-web"
  });
</script>

Press Alt+Shift+B or the floating button, hover to see which element is selected, click one, optionally type a note and press Enter. Cancel with Esc and nothing is sent.

The script ships with Autonomic. It is delivered with the plugin, not from a public registry. Its options are described in the SDK document that comes with it.

Where to go next