feat(builder): conversational AI intent builder shell

[delchev]

A new standalone Harmonia shell — a conversational AI intent builder. You describe the application you want; an app.intent is created and evolved underneath; a canvas visualises the entities, processes and glue live; one button turns the conversation into a running application, ending on a success state that links you to the shells where you can try it.

Served at /services/web/builder/ (shell id builder), .access-gated to ADMINISTRATOR / DEVELOPER like the intent endpoints it drives.

Almost no new backend

The feature is a frontend orchestration over endpoints that already ship — the intent engine's agent / parse / generate, the workspace, the publisher, and the health + problems feeds — reusing the shared application-core runtime (theme, notifications, branding, i18n) by absolute URL, with no per-shell copies. It is one screen, so there is deliberately no Pinecone router.

The single addition is GET /services/ide/intent/agent/status → {configured} (configuration-only, never an upstream call). The shell probes it on load so an instance with no API key says so before the user types, instead of letting the first message fail with 412. The plan proposed firing a throwaway /agent turn for this, which would have burned a real Anthropic round-trip on every page load of a working instance; the endpoint is the cheap way to get the banner up front.

The conversation loop

chat → POST /services/ide/intent/agent → re-validate the proposal client-side through /parse → auto-apply → redraw.

The re-validation is load-bearing, not belt-and-braces: the agent returns 200 even when its proposal still fails validation (the server's two repair rounds were exhausted), signalling it only as trailing prose in reply. An invalid proposal is rendered as issues and never reaches the buffer. There is no diff/Accept step — a valid proposal auto-applies and the assistant's own text is the change narration; the raw YAML stays available read-only in a drawer, and the Intent Editor in the IDE remains the authoring surface.

Hidden persistence

The project id is a slug of the intent's name, created lazily on the first accepted proposal and never renamed (a rename would mean delete + recreate + republish). Every accepted proposal is auto-saved, so reloading restores the app from disk, not from browser memory. An app switcher lists the workspace projects carrying a root app.intent; chat history is per-project localStorage (the agent endpoint is stateless).

The one button

save → Problems baseline → generate models → replay codeGenerations → publish → healthcheck poll + Problems diff, each step ticking green.

The Problems diff is the only honest "published clean" signal: publishing is synchronous but reports nothing about what the synchronizers then made of the artefacts, so a client-Java compile error or a failed CSVIM seed surfaces there and nowhere else. Without it a broken app would be reported as a success. The success panel's "try it here" links are discovered (platform-shells + the app's own perspective path from application-perspectives) rather than assembled from a guessed gen/<model> convention that would 404 the moment a template changed its layout.

Shared diagram renderer (the only change to shipped code)

The Intent Editor's ~310 lines of mxGraph rendering are extracted from its AngularJS controller into a framework-free window.IntentDiagrams.render(model, host) / .dispose(host) (editor-intent/js/intent-diagrams.js). Mechanical extraction only — the editor renders through it unchanged (editor.js drops from 824 to 491 lines) and the shell loads the same file by URL. IntentEditorLoadsIT guards it.

Gotchas this paid for

Each of these was found by the integration test, not by review:

• Never put an Alpine binding on <i x-h-lucide>. The plugin replaces the <i> with the rendered svg, so a binding would be lost — it throws instead, and the uncaught throw aborts Alpine's walk over everything below it (the toolbar rendered; the entire split pane did not). Use an <svg x-h-lucide> placeholder.
• The idempotent creates answer 304, and response.ok is 2xx-only — so a naive !response.ok throw made the second save fail while the first succeeded.
• The workspace itself may not exist on an instance where the user never opened the IDE; creating a project inside a missing workspace answers 404.
• The agent endpoint can make three upstream calls at 120 s each, so the client timeout is 7 minutes with a staged typing indicator.

Tests

IntentBuilderShellIT drives the journey against a local HTTP stub of the Anthropic upstream (DIRIGIBLE_INTENT_AI_BASE_URL, the same override IntentAgentServiceTest uses in-process), so it needs no API key and no network:

• @Tag("smoke") — the shell bootstraps (stores + renderer registered, first-run surface renders). Runs on every PR; this is the regression class services-level tests cannot catch, where every endpoint stays green while the page is dead.
• Unconfigured assistant — with no key the banner is announced before the user types; with the stub configured it stays away.
• Full journey — one sentence becomes a validated intent, the canvas draws it, the intent is saved with nothing asked of the user, and Publish reaches the success state. Backed by assertions on what the pipeline actually produced (the generated .model in the workspace, the project in the registry), so it stays honest if the success panel is ever reworked.

Verified locally: IntentBuilderShellIT (both) green, IntentEditorLoadsIT green, formatter:validate BUILD SUCCESS, full reactor build SUCCESS, unit suite 1483 tests / 0 failures (the 5 errors are FtpRepositoryTest + DirigibleApplicationTest BindException: Address already in use from another local instance holding the ports).

Deliberately not in v1

No raw YAML editing (read-only drawer), no diff/Accept, no server-side conversation persistence, and no multi-model (uses:) orchestration.

🤖 Generated with Claude Code