Migrate to Harmonia version 3

.claude/docs/shells.md

@@ -13,7 +13,7 @@ The loop: chat → `POST /services/ide/intent/agent` → **re-validate the propo
 **The one button** (`js/services/pipeline.js`, the `publish` store) runs save → **Problems baseline** → `/intent/generate` (which generates the models AND the code from them in that one call, reporting each recipe's outcome in `codeGenerations`) → publisher → healthcheck poll + **Problems diff filtered to `/<project>`**. That diff is the only honest "published clean" signal — publishing is synchronous but reports nothing about what the synchronizers made of the artefacts, so a client-Java compile error or a failed CSVIM seed surfaces there and nowhere else. The success panel's "try it here" links are **discovered** (`platform-shells`, plus the app's own perspective path from `application-perspectives`) — never assembled from a guessed `gen/<model>` convention, which would 404 the moment a template changed its layout.
 
 Gotchas this shell paid for (all confirmed by `IntentBuilderShellIT`):
-- **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 whole split pane did not). Use an `<svg x-h-lucide>` placeholder for any `:data-lucide` / `:class` / `x-show`.
+- **Every icon is an `<svg x-h-lucide>` placeholder.** The Lucide plugin renders an svg in place, so an Alpine binding (`:data-lucide` / `:class` / `x-show`) stays live; a replaced placeholder such as `<i>` throws instead, and the uncaught throw **aborts Alpine's walk over everything below it** (the toolbar rendered, the whole split pane did not). `HarmoniaContractIT` refuses any `<i x-h-lucide>`; for everything else Harmonia the upstream skill is the rule set (see `.claude/docs/harmonia-ui.md`).
 - **The idempotent creates answer `304`, and `response.ok` is 2xx-only.** `POST /workspaces/{ws}` and `.../{ws}/{project}` return 201 the first time and **304 NOT MODIFIED** afterwards, so a naive `!response.ok` throw makes the *second* save fail while the first succeeded. The fetch helper takes an `alsoOk: [304]`.
 - **The workspace may not exist at all** on an instance where the user never opened the IDE; creating a project inside a missing workspace answers 404, so `ensureProject` creates the workspace first.
 - The agent endpoint can make three upstream calls, each **streamed** with adaptive thinking (so there is no fixed per-call ceiling to multiply; the server's outer bound is 10 minutes per call) — the client timeout is **20 minutes**, with a staged typing indicator.

DATABASE_SHELL_PLAN.md

@@ -12,11 +12,11 @@ this plan clones.
 
 ### Corrections to this plan, found while building it
 
-- **The bump is to 2.9.0, not 2.10.0.** 2.10.0 is published on npm but has no webjar on Maven
-  Central, and 2.9.0 carries every breaking change that mattered (the tree rewrite included). The
-  2.10.0 delta — a cross-origin iframe crash fix and an inverted `getBreakpointListener` third
-  argument — is a follow-up; when its webjar lands, the six shells calling that listener must pass
-  `true`.
+- **The bump was to 2.9.0 at the time (2.10.0 had no webjar yet); the platform has since moved on to
+  3.1.2.** The `getBreakpointListener` third argument is deliberately left at its default
+  (`topFrame = false`): the listener then measures the frame it runs in, which is what the CSS
+  breakpoint variants resolve against, so the shells calling it pass nothing. (An earlier note here
+  asked them to pass `true`; Harmonia's own docs argue the opposite, and the docs win.)
 - **The `data-disabled` sweep was a bug fix, not a rename.** `data-disabled` on a root `x-h-select`
   never did anything, even on 2.6.0: it was always a per-*option* attribute, and the whole control
   is disabled through native `disabled` on `x-h-select-input`. Preview-mode and read-only dropdowns