Ridu v0.25.0

Ridu 0.25.0

SQLite now counts filtered lists from its indexes and does less work for each write. On the new
Ridu/PocketBase SQLite benchmark in tests/performance/pocketbase, an anonymous list filtered by an
access rule fell from 5.1 ms to 0.73 ms of server CPU per request with 900 matching posts, and from
14 ms to 1.1 ms with 2,700. Deletes run about twice as fast as in 0.24.0, creates 22% faster and
updates 14% faster. These are measurements from one machine.

This release changes SQLite's index layout and migration planner, so SQLite migration histories and
the databases they migrated must be recreated. PostgreSQL and MongoDB are unchanged.

Changes

• SQLite filters, sorts, distinct values and field indexes share one typed expression: the stored
  value when its JSON type matches the field, otherwise null. An equality or range filter on an
  indexed field, and its total, is answered from the index without reading documents,
  published-only reads included. A scalar in filter is still checked against each candidate
  document.
• A value stored with a different JSON type from its field, such as an object under a text field,
  still never matches a filter. It now sorts with missing values and reads as null among distinct
  values.
• SQLite indexes the columns through which tasks, edit locks and authentication tokens refer to a
  document. Deleting a document no longer scans those tables: with 50,000 retained tasks, a delete
  fell from 9.5 ms to 0.1 ms.
• Each SQLite connection keeps up to 64 compiled statements, of at most 4 KiB of SQL each and 64 KiB
  in all, so a repeated statement skips SQLite's compile step. Larger statements, such as filters
  with long in lists, compile for each call as before.
• SQLite writes skip unique-value and reference work for collections that have neither, and a delete
  no longer repeats cleanup that foreign keys already perform.
• ridu dev brings an existing SQLite development database's indexes up to date before it checks
  the recorded schema, adding the indexes an earlier Ridu did not create. A changed base index or
  table is still reported as drift.

Upgrade

Update the Go module and all Ridu npm packages to 0.25.0 together, regenerate application contracts,
and rebuild the admin and application binary.

• SQLite's migration planner is now 1.4.0. A migration history written by an earlier Ridu is
  rejected as an unsupported planner version, and a SQLite database it migrated fails readiness
  because its index layout changed. Create a new history, for example by moving migrations/ aside
  and running ridu migrate create --name initial, and recreate deployed SQLite databases from it.
  Back up application data and uploads before recreating a database, and rehearse restoration with
  the new schema before cutover.
• SQLite databases that ridu dev synchronizes, which have no migration history, gain the new
  indexes on the next sync.
• PostgreSQL and MongoDB planners, database layouts and migration histories are unchanged.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.

Ridu v0.24.0

Ridu 0.24.0

A binary built with ridu build now applies its own migrations, so a production container can run
the binary alone, with no Ridu CLI, Go or JavaScript runtime beside the server. The Railway guide
now migrates and starts with the binary.

Hosts such as Railway bill the memory a container holds, including the cache of files its processes
have read. Running ridu migrate up at startup compiled the project with Go under the package
manager before the server started. On one Railway service that left about 120 MB of file cache in
the container for as long as the server ran, beside a server using about 40 MB. A package script as
the start command, such as bun run start, also keeps the package manager running beside the server.

Changes

• <binary> migrate up applies the committed migrations from migrations/ in the working
  directory, or from --directory. It applies them only when they are exactly the history the
  binary was built with, the same history its /readyz check requires, and refuses any other. It
  selects the database like ridu migrate up, from DATABASE_URL or RIDU_SQLITE_PATH or the
  --database-url and --database-path flags, and takes the same --allow-maintenance,
  --allow-insecure-database, --allow-unbounded and timeout flags. plan, status, verify
  and stop boundaries stay in the CLI. See
  Deploy migrations.
• Generated projects register their adapter's migration driver in cmd/server/main.go, for
  example ridu.WithProjectMigrations(postgres.ProjectMigrations()). The binary migrates through
  it, and data transforms are passed to the same call.
• The Railway guide sets the pre-deploy command to
  ./dist/<project> migrate up and the start command to ./dist/<project>, and the SQLite start
  command to ./dist/<project> migrate up && exec ./dist/<project>. The
  Build and run guide lists what a production
  image needs: the binary, migrations/, trusted certificates and its environment.
• The generated build script runs ridu build --output dist/<project>, so the binary's name no
  longer depends on the directory it's built in. A platform that builds in /app, such as Railway,
  otherwise gets dist/app, which the start script and the guides don't name. On Windows,
  ridu build adds .exe to an --output path without an extension.
• The PostgreSQL and SQLite guides for switching adapters now swap the migration driver too, and the
  MongoDB guide's example of converting cmd/server/main.go, which highlighted the wrong two
  readiness lines since 0.23.0, matches the generated file.

Upgrade

Update the Go module and all Ridu npm packages to 0.24.0 together, and rebuild the admin and
application binary.

cmd/server/main.go belongs to your project, so the migration driver isn't added for you. A
project that already passes data transforms to ridu.WithProjectMigrations has it. Otherwise, to
migrate with the binary, register it outside the len(os.Args) == 1 branch, using the sqlite or
mongodb package for those databases:

options := []ridu.ExecuteOption{
	ridu.WithProjectMigrations(postgres.ProjectMigrations()),
}
if len(os.Args) == 1 {
	options = append(options, runtimeOptions(applicationConfig)...)
}

Then deploy migrations/ with the binary, run ./dist/<project> migrate up where you ran
ridu migrate up, and start ./dist/<project> itself rather than through a package script. If
your build script is plain ridu build, add --output dist/<project> so the binary has the name
your commands use. ridu migrate up keeps working unchanged.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.

Ridu v0.23.0

Ridu 0.23.0

Ridu gzips its JSON and HTML responses, can see each visitor's address behind proxies it can't
list, such as Railway's, and adds Fit: "inside" for image sizes that show a whole photo. WebP
uploads now work.

Fixes

• WebP uploads were refused. Ridu recognised WebP files but had no decoder for them, so a
  collection that allowed image/webp failed every WebP upload with "decode image metadata: image:
  unknown format". Ridu now decodes WebP and keeps the original as uploaded. Go can't write WebP, so
  image sizes made from a lossy WebP without transparency are JPEG, and those made from a lossless
  or transparent WebP are PNG. "contain" sizes stay PNG for their transparent padding.
• A trusted proxy's Forwarded header without a proto parameter made Ridu treat the request as
  plain HTTP, ignoring X-Forwarded-Proto. Some proxies, reportedly including Railway's, pass a
  visitor's own Forwarded header on, so a visitor who sent one couldn't sign in once those proxies
  were trusted. Ridu now falls back to X-Forwarded-Proto.
• The Go comment on UploadConfig.Private suggested files without it were public. Every download is
  already checked against the collection's read access and sent as private, no-store; Private
  also requires a signed-in caller. The comment and the uploads guide now say so. See
  Uploads.

Changes

• Ridu gzips GET responses of 1 KiB or more that are JSON, HTML, CSS, JavaScript, SVG or other
  text, for clients that accept gzip, and sends Vary: Accept-Encoding. Compressed responses get a
  weak ETag and no Content-Length or Accept-Ranges. Responses under /api/auth/ and responses
  to other methods stay uncompressed, because they can carry session or preview tokens, which
  compression could reveal through the response's length (BREACH). Custom and plugin endpoints
  follow the same rules, so return secrets from POST endpoints. On a Railway deployment,
  /api/schema went from 60 KB to about 9 KB. See
  Production.
• HandlerOptions.TrustedProxyHops, read from RIDU_TRUSTED_PROXY_HOPS in generated projects,
  counts the proxies a request passes through when only the one that connects to Ridu can be listed
  in TrustedProxyCIDRs. Ridu then takes the client address from before them in
  X-Forwarded-For, so sign-in rate limits apply to each visitor instead of the whole proxy. The
  Railway guide now sets
  RIDU_TRUSTED_PROXY_CIDRS=100.64.0.0/10 and RIDU_TRUSTED_PROXY_HOPS=2. Account lockout
  (MaxLoginAttempts) still limits guesses at one account from any number of addresses.
• Fit: "inside" fits an image size within its Width × Height at the picture's own shape,
  without padding, and never enlarges it. The size's stored width and height are the picture's,
  so they can be smaller than the box. "contain" still pads to the full box, as sharp and Payload
  do, and its padding is now documented. See Uploads.
• RequestObservation.ResponseBytes documents that it counts the bytes the handler wrote, before
  compression.

Upgrade

Update the Go module and all Ridu npm packages to 0.23.0 together, and rebuild the admin and
application binary.

cmd/server/main.go belongs to your project, so the new setting isn't added for you. To use it,
add TrustedProxyHops: envInt("RIDU_TRUSTED_PROXY_HOPS"), after TrustedProxyCIDRs in
HandlerOptions, and copy the envInt helper from a project made with ridu new. On Railway, set
the two variables from the Railway guide.

Changing an image size's Fit affects new uploads; files uploaded earlier keep the sizes they were
made with.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.

Ridu v0.22.0

Ridu 0.22.0

Collection lists read only the fields they show, so a long rich-text body no longer travels with
every row. select no longer changes what field read rules and read hooks see, which closes a way
around rules that check another field. Lists read per-row permissions in batches.

Security

• A field read rule that checks another field of the same document, like the membersOnly example
  in the access-control guide, could be bypassed with select. Ridu removed the unselected fields
  before it ran read rules and read hooks, so select={"url":true} hid membersOnly from the
  rule. A rule that treats a missing value as allowed then returned the field. Related documents
  loaded with a target select in populate had the same gap. When a collection has read hooks or
  field read rules, Ridu now reads the whole stored document, runs them, and only then keeps the
  selected fields.

Breaking changes

• Custom list cells (listCellRenderers) and list layouts (listResultsRenderers) receive
  documents holding only the ID, timestamps, title field, visible columns and the fields they
  declare. A cell or layout that reads any other field must name it in the new fields option,
  for example fields: ['status']. Ridu checks the names when it builds the admin. See
  Custom table cells and
  Show collection results as cards.

Changes

• The admin collection list reads only what it shows: each document's ID, timestamps, title field
  and visible columns, the parent field in a hierarchy, and the fields that custom cells or a list
  layout declare. Search, filters and sorting still run in the database on any field. See
  Browse content.
• Relationship and upload fields named in fields arrive as the related document's ID and title,
  like a relationship column, whether or not their column is visible. A custom cell's own value
  is always the saved value.
• A list page records the columns and fields it was read for. When a navigation brings a page read
  for another column layout, for example after another tab saved its own, the list reads it again
  instead of showing empty cells.
• Lists with includeAccess and the admin's select-all read per-row permissions in batches: one
  read for the page's documents, and one for each distinct predicate a filtered access rule
  returns, instead of reads for every row. A 10-row page whose update and delete rules return
  filters makes 3 reads instead of about 30. readVersions on a versioned collection is still
  counted for each row.

Upgrade

Update the Go module and all Ridu npm packages to 0.22.0 together, and rebuild the admin and
application binary.

If a custom list cell reads document fields other than its own column, or a list layout reads
anything besides the title, add those field names to the registration's fields. Reads that
select fields from a collection with read hooks or field read rules now read whole documents
internally; responses change only where a rule now sees the fields it checks.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.

Ridu v0.21.1

Ridu 0.21.1

The admin stops waiting for Svelte updates that have already reached the page. Editing, focus,
scrolling and navigation behave as before.

Changes

• The admin removes twelve tick() waits that ran after the change they waited for was already in
  the DOM. They followed saves, uploads and bulk edits that had finished updating the page, came
  before scroll restoration and the navigation progress bar, which already wait for the next
  frame, delayed the document lock request behind the form, deferred returning focus to list
  column and filter controls after a navigation, and preceded opening the command menu.

Upgrade

Update the Go module and all Ridu npm packages to 0.21.1 together, and rebuild the admin and
application binary. No contract changes.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.

Ridu v0.21.0

Ridu 0.21.0

Image uploads take photos from current phones: Ridu reserves the memory image processing actually
uses, so 24- and 40-megapixel photos are no longer refused. MaxImageDimension stores a smaller
original, and remote image imports refuse IPv4-compatible IPv6 addresses.

Security

• Importing an image with uploadFromURL refused private and special-use addresses, but accepted
  IPv4-compatible IPv6 addresses such as ::127.0.0.1 and ::169.254.169.254, which reach the
  same hosts. Remote fetches now accept IPv6 only inside the global unicast block, 2000::/3,
  without its special-purpose ranges.

Changes

• UploadConfig.MaxImageDimension scales a JPEG or PNG original wider or taller than that many
  pixels down to fit before Ridu stores it, keeping its shape and never enlarging it. The scaled
  image replaces the stored file with its width, height, and filesize, the private source
  that crops start from, and the image sizes made from it. It is stored upright, without the
  camera's EXIF metadata. GIFs and smaller images keep their uploaded bytes. The value must be at
  least the width and height of every image size. See
  Limit large images.

Fixes

• Ridu reserved about twice the memory resizing an image used, so a photo over about 21
  megapixels needed more than the whole 512 MiB budget and was refused. The reservation now
  follows the work: for a JPEG, its chroma sampling, progressive coding and EXIF orientation. Image
  sizes are resampled through an intermediate of four bytes a pixel instead of 32. With sizes of
  800 and 1,600 pixels, a 24.5-megapixel photo reserves about 205 MiB instead of about 600 MB, and
  photos up to the 40-megapixel limit are accepted.
• The image budget is half of GOMEMLIMIT when you set it, and 512 MiB otherwise.
• An image over the budget fails with a message that tells the person uploading the most the
  server takes, ending, for example, upload an image of at most about 18.3 megapixels. An image
  over the 20,000-pixel or 40-megapixel limit says which.

Upgrade

Update the Go module and all Ridu npm packages to 0.21.0 together, and rebuild the admin and
application binary. No contract changes.

Generated image sizes are resampled by a different library, so their pixels can differ slightly
from earlier versions'; their dimensions and crops are unchanged. Set GOMEMLIMIT a little below
your service's memory, for example GOMEMLIMIT=900MiB for 1 GB.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.

Ridu v0.20.1

Ridu 0.20.1

The embedded admin signs in behind a hosting platform's TLS proxy, such as Railway's, without
listing its own origin in RIDU_ALLOWED_ORIGINS.

Fixes

• Behind a proxy that terminates HTTPS and forwards plain HTTP from addresses outside
  RIDU_TRUSTED_PROXY_CIDRS, Ridu saw every request as http. The browser sent the page's
  https origin, so Ridu refused the admin's own sign-in and every other write with
  origin_denied. When a request arrives as plain HTTP from an address Ridu doesn't trust, Ridu
  now accepts the HTTPS origin of the host the request names: only a page served over HTTPS from
  that host sends it. Ridu still follows the scheme a trusted proxy reports, refuses an HTTP origin
  on an HTTPS request, and accepts no other host or port this way. See
  Proxies and HTTPS.
• Ridu refused browser writes from unlisted origins without logging anything. It now logs the
  first refusal of each origin, with request_origin, the origin it computed for the request, for
  up to 32 origins.

Upgrade

Update the Go module and all Ridu npm packages to 0.20.1 together, and rebuild the admin and
application binary. No contract changes.

On Railway and similar platforms, you can remove your application's own HTTPS origin from
RIDU_ALLOWED_ORIGINS if you added it to work around this. Keep the origins of other browser
applications that call the API.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.

Ridu v0.20.0

Ridu 0.20.0

Ridu now requires Go 1.26.9, which fixes standard-library vulnerabilities that Ridu's servers
reach. S3 upload storage works with Railway buckets, the Railway guide's configuration passes
Railway's healthcheck, and date-time queries match stored values however they were written.

Security

Go 1.26.9 and 1.27.2 fix eleven standard-library vulnerabilities that Ridu's code reaches: in
HTTP/2 and HTTP/1 serving and proxying, Range and MIME header parsing, TLS Encrypted Client Hello
and, on Windows, os.Root (GO-2026-6603,
6604, 6605,
6607, 6608,
6609, 6610,
6611, 6612,
6613 and 6617). No
Go 1.25 release fixes them. Ridu's minimum Go version and its release builder move from 1.25.13 to
1.26.9. The ridu binaries of 0.19.0 and earlier were built with Go 1.25.13 and are affected, and
so is any application built with a Go release before 1.26.9, or with Go 1.27.0 or 1.27.1.

Fixes

• The S3 storage adapter addressed every bucket path style, https://<endpoint>/<bucket>/<key>.
  Railway buckets (Tigris) refuse that style, so the readiness check failed with 403 Forbidden
  and the deploy never became ready. Buckets are now addressed virtual-hosted style by default,
  https://<bucket>.<endpoint host>/<key>, which AWS S3, Railway buckets and Cloudflare R2
  accept. s3.Config.PathStyle keeps the path form. See
  S3-compatible storage.
• S3 requests were signed for a path without its leading slash when the endpoint had no path, so
  the service computed a different signature. Requests are now signed for the path they are sent
  to.
• The Railway guide set RIDU_ALLOWED_HOSTS to the public domain alone. Railway's healthcheck
  sends Host: healthcheck.railway.app, and Ridu checks the host before it routes /readyz, so
  every deploy failed its healthcheck. The guide now sets
  RIDU_ALLOWED_HOSTS=${{RAILWAY_PUBLIC_DOMAIN}},healthcheck.railway.app. See
  Set production variables.
• Ridu refused unlisted hosts without logging anything. It now logs the first refusal of each
  host the allowed hosts omit, naming the host and RIDU_ALLOWED_HOSTS, for up to 32 hosts.
• Date-time fields stored values as written. query.DateTime sends UTC with milliseconds, so it
  missed values saved without milliseconds or with an offset, and range filters and sorting could
  put values out of time order. Ridu now stores every date-time value in one form, UTC with
  milliseconds such as 2026-09-08T10:00:00.000Z, on SQLite, PostgreSQL and MongoDB. See
  Defaults, timezones, and sorting.
• Custom field examples and the text editor that ridu new scaffolds bind with a Svelte function
  binding, bind:value={() => field.value ?? "", (next) => field.set(next)}.

Breaking changes and upgrade

Update the Go module and all Ridu npm packages to 0.20.0 together, regenerate application contracts,
and rebuild the admin and application binary.

• Ridu requires Go 1.26.9 or newer. go get github.com/riducms/ridu@v0.20.0 raises an existing
  project's go line to 1.26.9, and new projects start there. Go 1.27.0 and 1.27.1 meet that
  minimum but still have the vulnerabilities, so build and deploy with Go 1.26.9 or a later 1.26
  release, or with Go 1.27.2 or later.
• S3 storage addresses buckets virtual-hosted style by default. Set PathStyle: true in
  s3.Config for MinIO and other emulators addressed by IP address or a single host name, and for
  a bucket whose name contains a dot. Without it, s3.New refuses an IP-address endpoint, or a
  dotted bucket over HTTPS. Endpoint never includes the bucket.
• REST, the local API and the SDK return date-time values in the stored form: a value written as
  2026-09-08T11:00:00+01:00 reads back as 2026-09-08T10:00:00.000Z. Values stored before
  0.20.0 keep their text until their document is saved again, so save documents again if you
  filter or sort on their date-time fields.
• On Railway, add healthcheck.railway.app to RIDU_ALLOWED_HOSTS.

This is a pre-1 release with breaking contracts; keep the coordinated packages aligned. Production
still runs as a Go binary with its static admin embedded, without a JavaScript server.

Ridu v0.19.0

Ridu 0.19.0

Collections and globals that already store documents can now turn on versions. On Windows, SQLite
projects start, the admin loads, ridu migrate create succeeds, and Ctrl+C stops every process
ridu dev started.

Changes

• Setting Versions: true on an existing collection or global no longer fails with
  RIDU_VERSIONS_ENABLE_UNSUPPORTED. A migration records what the documents it already stores
  become:

  • published: each document is published with a first version and a matching draft, so readers
    keep seeing it.
  • draft: each document stays an unpublished draft with a first version, and public reads stop
    returning it until it is published. This needs drafts.
  • require-empty: ridu migrate up stops while the collection stores any document.

  ridu migrate create takes the choice from --versions-existing or asks in a terminal.
  ridu dev enables versions without asking while the collection stores nothing. Otherwise it asks
  published, draft or cancel, then writes and applies the migration like an accepted rename. SQLite,
  PostgreSQL and MongoDB apply the choice in the migration's transaction, and ridu migrate verify
  replays it. See Enabling versions.

Fixes

• On Windows, every command that opened a SQLite file by path failed with
  parse SQLite path: … invalid port, including ridu dev, ridu migrate plan, up and verify,
  and the server. Paths now become file:///C:/… URIs, and UNC shares work too.
• On Windows, the admin never loaded under ridu dev: no @admin/ import resolved, because Vite's
  module IDs start with a drive. A Windows ridu build also split @riducms/ui into many small
  chunks.
• On Windows, ridu migrate create wrote the migration and then exited with "Access is denied", and
  the local storage adapter's health check, uploads and deletes failed the same way. Ridu no longer
  syncs directories on Windows, where the file system already makes those changes durable.
• On Windows, Ctrl+C on ridu dev left the admin's Vite processes running and holding port 5173.
  Each process ridu dev starts now runs in a job object that ends its whole tree when Ridu stops,
  even if Ridu itself is killed. Through the npm launcher, the first Ctrl+C lets Ridu shut down
  cleanly and a second ends it at once.

Windows remains a source-build target without release qualification.

Breaking changes and upgrade

Update the Go module and all Ridu npm packages to 0.19.0 together, regenerate application contracts,
and rebuild the admin and application binary.

• sqlite.CreateArtifact, postgres.CreateArtifact and postgres.BuildArtifact take an
  ArtifactOptions value in place of positional renames, destructive approval and transforms, as
  mongodb.CreateArtifact already did. sqlite.CreateArtifactWithRenames is removed; pass
  ArtifactOptions{Renames: …}. The CLI commands are unchanged.
• Migration artifacts gain the enable_versions step kind. Planner versions are unchanged, so
  existing histories replay as before.
• On PostgreSQL and MongoDB, a migration that enables versions needs
  ridu migrate up --allow-maintenance.
• The generated SQLite server now accepts Windows file: URIs in RIDU_SQLITE_PATH. To use them
  in an existing project, copy sqliteDatabasePath from cmd/server/main.go in a new project.

This is a pre-1 release with breaking contracts; keep the coordinated packages aligned. Production
still runs as a Go binary with its static admin embedded, without a JavaScript server.

Ridu v0.18.0

Ridu 0.18.0

Rich text gains plain-text and Markdown converters, the editor works as a form field, and two
editor bugs from 0.17.0 are fixed.

Changes

• Typing a list with * or +, a checklist with * [ ], a tab in a code block, a line break
  written as two trailing spaces or a backslash, or a code fence of four backticks made a document
  the editor couldn't save: the admin couldn't save the entry, and in an application the bound
  value kept the previous document. The editor now saves them. Lexical 0.49 records the Markdown it
  read on each node, which the stored document doesn't accept, so the editor now leaves it out.
• In an application, CSS outside a cascade layer, such as a reset like UnoCSS's preflight, no longer
  restyles RichTextEditor or its menus and dialogs: lists keep their bullets, headings their
  sizes and buttons their colors, and focus draws one outline.
• convertLexicalToPlaintext from @riducms/sdk/richtext returns a document's text, for previews,
  search, notifications or a language model. Custom blocks, uploads and relationships take
  converters, as with renderRichTextHTML.
• @riducms/plugin-richtext/markdown exports convertMarkdownToLexical, which turns Markdown, such
  as a language model's answer, into the document the editor's Markdown shortcuts make. It runs on
  a server without a browser. Pass the Go field's features; Markdown for anything else stays
  text.
• RichTextEditor with a name submits its document with a form, as JSON in a hidden field,
  including without JavaScript.
• The editor guide shows saving with a form action,
  converting Markdown, and restyling the editor through Ridu's app layer. The
  display guide shows plain text.

Breaking changes and upgrade

Update the Go module and all Ridu npm packages to 0.18.0 together, regenerate application contracts,
and rebuild the admin and application binary. This release changes no Go APIs, authoring config,
manifest or protocol versions, REST behavior, migration planners, or database layouts, so existing
databases and migration histories need no changes.

• In an application, CSS outside a cascade layer no longer restyles the editor's inner elements or
  its popups unless its selector is more specific than two classes. Move such overrides into Ridu's
  app layer, and declare Ridu's layers after a framework's own, such as Tailwind's:
  @layer ridu, ridu-plugins, app;. Custom properties and a class passed to the editor work as
  before.
• RichTextEditor's name now also adds a form field. Remove a hidden input you added with the
  same name.
• @riducms/plugin-richtext adds @lexical/code-core and @lexical/extension 0.49.0 as
  dependencies.

This is a pre-1 release with breaking contracts; keep the coordinated packages aligned. Production
still runs as a Go binary with its static admin embedded, without a JavaScript server.