What we shipped.
Engineering notes from each release. We commit publicly; the canonical log lives on GitHub, this page is the human-readable summary.
2026-05-06 — Visual editor + field-schema unification
Ten commits. One big feature, a long-overdue schema cleanup, and a production bug fix in the MCP deploy toolchain.
feat — visual-editor extension
Adds a Sanity-style overlay editor that activates on the public site for logged-in admins. A floating Edit page button appears on every page; clicking it switches into edit mode with per-block hover outlines and a resizable side drawer.
- Full field editing for all 20 canonical kernel field types (string, richtext via Tiptap, number, boolean, select, radio, checkbox, date, link, image, gallery, file, object, array, reference, term picker)
- Live preview: typing re-renders the block via
/admin/api/block-types/previewand swaps its DOM range without a reload - Insert blocks inline (gap buttons between blocks), delete, duplicate — all visible on the page before saving
- Drag-reorder via dnd-kit
- Save: a single
PATCH /admin/api/nodes/{id}commits all pending changes — no new write endpoints - Overlay is skipped entirely for unauthenticated requests; no editor code reaches anonymous visitors
refactor — field-schema vocabulary unified
The kernel, MCP, admin UI, in-repo themes and blocks all previously used a mix of legacy aliases (key, label, help, default, sub_fields, types text / repeater / group / node) and the canonical vocabulary (name, title, description, initialValue, fields, types string / array / object / reference). This sprint consolidates everything to the canonical form:
- Go core + MCP read/write only canonical keys; legacy aliases remain accepted by the back-compat reader but are no longer emitted
- DB migration normalises stored block and node-type schemas to canonical shape
- Admin UI drops legacy type names; all block editors use canonical field types
- In-repo theme and extension
block.jsonfiles rewritten to canonical vocabulary - Theme settings + public-site hydration updated to accept canonical vocabulary
- Node-type updates now persist correctly and propagate to the live admin and render pipeline end-to-end
fix — MCP extension deploy tools
core.extension.deploy, core.extension.deploy_finalize, and core.extension.delete were returning “extension handler not wired” on production. The handler is wired after MCP server construction (because it depends on PluginManager, which depends on infrastructure set up later), but the tool closures were capturing the handler into a local variable at construction time — seeing nil forever. Tools now read s.deps.ExtensionHandler lazily inside each closure. The presigned upload pair (deploy_init / deploy_finalize) was unusable since shipping; only the smaller inline core.extension.deploy worked, and that forced base64-inflated payloads through the JSON envelope.
2026-04-29 — 2026-05-02 — Admin redesign, kernel boundary, presigned uploads
~30 commits. Admin UI overhauled from scratch, kernel/extensions boundary hardened, MCP gets large-binary upload support.
refactor — kernel/extensions boundary enforced
A long-planned architectural sweep moved every feature-specific component out of internal/ and into the correct extension:
- Email dispatcher (rule matching, template rendering, recipient resolution, delivery log) — moved to email-manager
/robots.txt+<head>OG / Twitter meta tags — moved to seo-extension- Media files, optimisation pipeline, WebP conversion — moved to media-manager
CoreAPI surface (SendEmail, UploadMedia, GetMedia, …) is unchanged; calls now route to the active plugin that declares the matching provides tag. “no provider for X” errors mean the relevant extension is inactive.
redesign — admin UI
Full visual overhaul of the admin shell: new design-token system (replacing the old indigo/slate palette), updated SDUI shell, login page, shared listing/editor primitives, PublishActions sidebar component, AJAX pagination and sorting across all listing views, consistent 1200 px max-width, updated Titlebar across all editors.
feat — presigned uploads for MCP large binaries
core.media.upload_init / .upload_finalize (and theme/extension counterparts) bypass the JSON-RPC envelope for files above ~5 MB: init returns a presigned URL, the client PUTs raw bytes there (the token in the URL is the auth — no Authorization header needed), finalize runs the same install pipeline as the legacy base64 tool. Tokens are 64 chars, single-use, ~15 min TTL. Cap configurable via SQUILLA_{MEDIA,THEME,EXTENSION}_MAX_MB env (defaults 50 / 200 / 200 MB).
feat — theme settings (squilla theme)
The Squilla marketing theme gained a full settings surface: branding (logo, favicon, site tagline), appearance (accent colour, density, motif), header (CTA label/URL, GitHub star count, pill text), and footer columns. Settings are rendered into public pages via {{.theme_settings.*}} and into MCP/admin preview via the wired ThemeSettings context.
fix — 404 rendering handed to themes
The kernel no longer owns the 404 page. The public catch-all now looks up a layout with the reserved slug 404 (or the legacy alias error) from the active theme. If absent, a minimal hardcoded fallback renders. Themes opt in by declaring the layout in theme.json and creating the corresponding HTML file.
fix — theme settings on public site
Non-translatable theme settings were invisible on the public site because the render path was reading per-locale rows and finding nothing for the default language sentinel. The settings store now reads non-translatable fields from language_code='' directly, with a correct fallback chain.
v0.1.0 — Public preview
2026-04 · first tagged release of the Squilla theme + marketing site.
- Kernel + extensions split finalised — no feature-specific code remains in
internal/ - MCP server with ~50 tools across 15 domains, plus the
core.guidemeta-tool - Hot theme + extension activation — no server restart, no downtime
core.theme.deployandcore.extension.deployaccept a base64-encoded zip and unpack via atomic directory swap (50 MB cap)- VDUS admin shell wired up; every feature page is now an extension micro-frontend
- Seven reference extensions: media-manager, forms, email-manager, sitemap-generator, content-blocks (40 blocks + 10 templates), resend-provider, smtp-provider
- The Squilla theme — marketing, docs, marketplace shells — ships in the repo as the activated default
The road ahead
The full GitHub roadmap is the source of truth; treat what’s below as direction rather than commitments.
- S3 file storage extension (design + plan landed in May; implementation in progress)
- Per-node language fallbacks and richer i18n primitives in core
- More themes, more blocks, more example extensions
For the commit-by-commit log, see github.com/erikkubica/squilla/commits/main.