Cortext as a standalone app

[priethor]

Cortext is today a WordPress plugin, so trying it means setting up WordPress first. Many people won't go through that added friction, and that's the ceiling on who actually gets to use it.

We think Cortext is its own product. It's based on a WordPress plugin, but the thing people would value, the workspace, the collections, the way pages and rows link together, doesn't depend on knowing or caring about WordPress. This issue is the start of figuring out how to ship Cortext as a standalone app: something you install and open like any other app on your machine, with WordPress hidden underneath. The plugin stays the plugin; the app is just the box it lives in.

Why?

The people who'd reach for Cortext aren't comparing it to WordPress. They're comparing it to Obsidian, Notion, Anytype, Bear, Apple Notes, etc.. None of those ask you to provision a CMS first. As long as Cortext is plugin-only, we don't show up in that comparison at all.

What we'd want to figure out

Runtime

• How to run WordPress inside an app that a user installs once. Options span PHP-WASM (WordPress Playground), bundled native PHP, or a partial rewrite. Each carries very different trade-offs in speed, bundle size, complexity, and maintenance.
• How well does that runtime cope with Cortext's actual REST surface and the block editor, not just hello-world WordPress?

First-launch setup

• Where the workspace lives across app updates (the natural spot on macOS is something like ~/Library/Application Support/Cortext/sites/default/).
• How the local admin user is provisioned, with what credentials, with what cookies.
• How salts and keys are generated and stored.

Plugin-side UI changes

In standalone mode, Cortext is the entire product surface. wp-admin shouldn't be reachable:

• Hide all wp-admin chrome except the Cortext top-level page. Settings, Plugins, Themes, Users, Comments, default Posts/Pages, Tools, Site Health, the admin top bar, dashboard widgets. None should be reachable or visible.
• Inside Cortext's own UI, public-web affordances go away for now: "Publish" probably becomes "Save", "Preview" / "View Post" / "Visit site" disappear.
• Audit core Gutenberg blocks for ones that don't make sense for a knowledge base (Latest Posts, RSS, anything pulling external content). Tracked under Fix Cortext editor integration gaps #85.

These get gated through a runtime constant (something like CORTEXT_DESKTOP) that drives per-feature filter defaults. The standalone app sets the constant in wp-config.php; the plugin code reads it once to flip the defaults on a set of cortext_* filters, each of which a site owner can still override on a regular WordPress install if they want to.

Updates and lifecycle

• How does updating the app update the embedded WordPress, the plugin code, and any data migrations on the persisted workspace?
• Reset/recovery for a broken workspace.

Packaging and distribution

• Signing and notarization on macOS.
• DMG, and equivalents for Windows/Linux later.
• Auto-update.

Repo and process

• Whether the standalone app lives next to the plugin in this repo, or in a separate cortext-desktop repo that takes the plugin as a versioned dependency.
• Whether a "try Cortext in your browser" channel built on Playground stays alive as a separate distribution path. Gut feeling: yes!

Out of scope for a v1

These don't change whether Cortext can ship as a standalone app, so they shouldn't drag this conversation off-topic:

• Sync, multi-device, collaboration.
• Multi-user local accounts.
• Publishing to a remote WordPress site. Probably for a v2, but it depends on other WP projects.
• Mobile.
• Public rendering of Cortext pages outside WordPress. This is a no-go unless we implement remote syncing.