Local AI Search readiness
Review robots.txt, sitemap, llms.txt, and eligible public content without turning the plugin into mandatory cloud onboarding.
Prepare WordPress and WooCommerce for AI Search with a local-first workflow: analyze public signals, select content, generate deterministic llms.txt, and publish only when the administrator chooses to.
The current version is 0.5.0-dev. The code is public and verifiable, but it is not yet presented as a stable release or as available on WordPress.org.
Accepted local capabilities remain available without a Kairoseth account. External support is optional, explicit, and separate from the Free product.
Review robots.txt, sitemap, llms.txt, and eligible public content without turning the plugin into mandatory cloud onboarding.
Generate a deterministic proposal from selected public content and inspect exactly what will be published before any write occurs.
Include public WordPress content and supported public WooCommerce product awareness in the accepted local workflow.
Compare before writing, avoid unnecessary changes, and verify the public result and its SHA-256 after publication.
Keep state and operations scoped per site so a Multisite installation does not mix context across tenants.
The Free product works locally. Kairoseth receives bounded context only after an administrator explicitly starts a request.
The workflow prioritizes human control, determinism, compare-before-write behavior, and idempotence.
Check public readiness signals and eligible site content.
Choose which public content belongs in the proposal.
Review deterministic llms.txt output and its hash before publishing.
Write only after an explicit administrator action.
Read the public result back and confirm it matches the expected content.
Loading the support surface does not contact Kairoseth. An external request starts only after an explicit click, automatic context is limited to bounded technical metadata, and the user chooses what additional information to send.
Kairoseth separates identity, organization scope, product roles and product capabilities. A login route, browser state or AI response never becomes an authorization boundary by itself.
Customer resources and access are resolved inside an active organization context rather than treated as global account state.
Owner, Admin and Member authority is assigned per product. Organization membership alone does not automatically grant every product.
Sensitive access, policy and capability decisions remain authoritative on the server instead of trusting client UI state or model output.
Capabilities that can act are introduced behind explicit grants, staged gates and audit rather than implied autonomy.
Review the customer-facing policies that define privacy, security reporting, acceptable use and the current legal operating framework.
Extensions catalog integration does not change distribution status: 0.5.0-dev remains in development until release and WordPress.org gates are complete.