OS 3.5.0

One name, everywhere

OS used to be called Core Index, and half the code still said so. Menus,
stylesheets, log messages, and the licence file now all say OS. Nothing you
click changes, but the plugin finally has one name instead of two.

Your blocks moved, and moved themselves

Five blocks changed name: task, wiki, csv, checklist, and the site editor
embed. A block name is stored inside every post that uses it, so renaming
one usually breaks those posts and shows a "this block contains unexpected
content" notice.

OS updates them for you on the first load after updating. Your posts keep
their content, their attributes, and their last-modified dates, and no
revisions are created. If a post merely mentions an old block name in its
text, that text is left exactly as written.

There is nothing to do and nothing to click.

Still broken, and honest about it

The Ask AI panel still does not load on WordPress 7.1, unchanged from 3.4.1.
It was built for an older way of loading code and needs rebuilding rather
than patching. Every other screen works.

OS 3.4.1

The admin screens work again on WordPress 7.1

Every OS screen showed a loading spinner and never finished, on WordPress
7.1. Nothing loaded: not Content Types, not Wiki, not Calendar.

The cause was four missing lines. OS hands WordPress's own components to its
screens through a small bridge file, and that bridge listed most components
but not DropZone, FormFileUpload, ResizableBox, or the confirm dialog.
Asking for a component the bridge does not list is not a small failure. It
stops the entire screen from starting, which is why one unlisted component in
the Ask AI panel took down everything.

If you are on WordPress 7.1, update. Earlier versions of OS have the same
problem.

Still broken, and honest about it

The Ask AI panel does not load on WordPress 7.1. It was built for an older
way of loading code and needs rebuilding, not patching. Every other screen
works. This is the next thing being fixed.

OS 3.4.0

Content types can be declared in a file

Put a types.json beside your content and OS builds the type from it. One
declaration gives you the record type, its fields, its REST API, and the tools
your agent sees. There is nothing to click, and the file is the truth: copy it to
another site and you get the same model.

docs/types.example.json is a working example to start from.

Fields have real types now

A field can say what it accepts: a number with a floor, a date, a list of allowed
values, a list of strings, or a link to another record. WordPress enforces it when
anything writes, so a bad value is rejected at the door instead of stored and
found later.

Layout moved out of the field list. Fields describe data, display describes how
it looks, and deleting the whole display block leaves every value readable.

Your agent knows what it will get back

Every content type publishes five tools: list, read, create, update, and delete.
They now describe both what they accept and what they return, so an agent can plan
against a real answer rather than guess. The API and the agent tools are generated
from the same declaration and run the same code, so they can never drift apart or
let one do something the other cannot.

A problem in a declaration tells you

A field with a layout type, an unknown type, a name that is too long, a duplicate,
a layout referencing a field that does not exist, or a link with no target: each
one is reported on screen, by name. Nothing is skipped quietly.

Releases are reproducible

tools/build-zip.sh builds the plugin zip from a tagged commit, refuses a dirty
tree or a version that disagrees with itself, and runs every test first. Verified
against 3.3.0, which it rebuilds byte for byte.

Known limits

• Filtering a list still reads through post meta. The index that makes it fast is
  designed, not built, so only fields marked for indexing can be filtered on.
• The rules block in a declaration is accepted and kept, but not yet enforced.
  Permissions are still ordinary WordPress capabilities. Do not treat a rules
  block as protection.
• Changing a declaration takes effect immediately. The migration file that would
  hold a destructive change back is specified but not built.

OS 3.3.0

Menus & icons is now a full app page: search 417 icons as you type, Font Awesome and Dashicons together, with live previews.

🤖 Generated with Claude Code

OS 3.2.0

Pick any icon for any type: the Menus & icons screen now has a dropdown with the bundled Font Awesome set and every dashicon your WordPress ships, with a live preview.

🤖 Generated with Claude Code

OS 3.1.2

Split menus per type with the Menus & icons manager (3.1.0), on a delivery path that can't go stale: the update manifest now ships with each release.

🤖 Generated with Claude Code

OS 3.1.1

Split menus (3.1.0) plus a sturdier updater: forced checks are always fresh, and a stale CDN edge can no longer delay an update past a few minutes.

Every type has its own menu item and icon, arranged under Content type → Menus & icons.

🤖 Generated with Claude Code

OS 3.1.0

Every type now has its own menu item and icon. Events, Reminders, and Automations stand on their own, and so do Skills, Wiki, and Memory.

Arrange them your way under Content type → Menus & icons: label, icon, and sidebar position for every type, one screen, no code.

Sites on 3.0.1 receive this update on the Plugins screen.

🤖 Generated with Claude Code

OS 3.0.1

Auto-updates. WordPress now checks this repo's releases and offers new versions on the Plugins screen, no manual downloads after this one.

Install: upload os.zip through Plugins → Add New Plugin → Upload Plugin. Requires WordPress 6.9+ and PHP 8.1+.

🤖 Generated with Claude Code

OS 3.0.0

One plugin, nine modules: wiki, calendar, content types, code, filesystem, graph, activity, notifications, wizard.

• Module toggle under Settings → OS Modules. A module that is off does not boot. Per site on multisite.
• Circuit breaker: a module that fails to load is switched off with the reason shown, and the site carries on.
• Agent-ready: every module registers WordPress Abilities and REST routes; pair with the MCP Adapter for one MCP endpoint over the whole system.
• Migrations included for sites coming from the earlier Core Index / os-* plugin family: wp ci migrate-options and wp ci migrate-types, with compatibility shims so legacy callers keep working either side of the move.

Install: upload os.zip through Plugins → Add New → Upload.

Requires WordPress 6.9+ and PHP 8.1+.

🤖 Generated with Claude Code