# BW AI Schema Pro — Roadmap

**Last Updated:** 2026-05-20

## Current Version: 2.1.4

## Done (2026-05-06)

- ✅ **Update-server flip release (2.1.4).** Plugin update-checker URL flipped from the legacy `bwgeo.demoing.info` endpoint to `https://plugins.bowden.works/wp-json/bw/v1/update-check?slug=bw-ai-schema-pro`. The 2.1.4 zip was published to **both** plugins.bowden.works (the new home) and the legacy bwgeo distribution (so existing sites pulling from bwgeo would pick up the URL flip on their next poll). The bw-update-server has the plugin registered. The transitional bwgeo zip can stay in place indefinitely as a safety net for any laggard site; retire it whenever convenient.
- ✅ **BW tooling compatibility (2.1.4).** Added `BW_AI_SCHEMA_PRO_VERSION` compat constant as a literal next to `BW_SCHEMA_VERSION`. `tools/bump-version.sh` updates it alongside the plugin header. `BW_SCHEMA_VERSION` reads from the plugin header at runtime so it auto-follows. Sunsets at 3.0.0.
- ✅ **BW scans clean (2.1.4).** `cleanup-scan`, `security-scan`, `test-plugin` all pass.
- ✅ **Security audit (2026-05-06).** 140 advisory warnings audited, 0 HIGH, 1 LOW fixed (`?skip_setup=1` cap check on `maybe_redirect_to_setup()` — in `[Unreleased]` for the next release).

## Open

### Next patch release
- Ship the `?skip_setup=1` cap-check fix currently in `CHANGELOG.md [Unreleased]`. Patch bump per umbrella versioning rule.

## Future — 3.0.0: bundled slug rename + prefix conformance + data migration

**Status:** intent recorded; no schedule.
**Likely version:** 3.0.0 (breaking — slug + prefix + DB key changes).
**Why bundled:** doing the slug rename and the prefix conformance as separate releases would force customer data to be renamed twice. Bundling them into a single 3.0.0 release lets the data-migration code run once. This is the **only reason** the prefix didn't conform at the 2026-05-06 import.
**Why deferred:** the migration is real work and not blocking anything today. Real production sites depend on the grandfathered keys.

### What needs to happen

1. **Pick a new slug.** Current `bw-ai-schema-pro` will be replaced. Name TBD — rian wants to rename but doesn't have a good one yet. Constraints:
   - Must match `bw-[a-z0-9-]+` (BW slug standard).
   - Should describe what the plugin actually does (AI-optimized schema markup); "schema" alone is too generic, "ai-schema" is closer; consider "bw-schema", "bw-aischema", "bw-schema-ai", "bw-schemax", or something less literal that won't age out as "AI" loses its trendiness.

2. **Internal prefix conformance.** Once slug is picked (call it `bw-NEWSLUG`):
   - Function/hook/option/transient/post-meta prefix: `bw_schema_*` → `bw_NEWSLUG_*` (underscored).
   - Constants: `BW_SCHEMA_*` → `BW_NEWSLUG_*` (upper).
   - Class names: `BW_Schema_*` → `BW_Newslug_*`.
   - Class file names: `class-bw-schema-*.php` → `class-bw-NEWSLUG-*.php`.
   - Text domain: `bw-ai-schema-pro` → `bw-NEWSLUG`.
   - Plugin directory: rename to `bw-NEWSLUG`.

3. **Data migration.** Customer sites have data keyed under `bw_schema_*`. The 3.0.0 release must:
   - On activation, copy all `bw_schema_*` options/post_meta/transients to `bw_NEWSLUG_*` keys.
   - Delete the old keys after successful copy.
   - Hook the WP plugin upgrader to handle the directory rename gracefully (or document a manual deactivate-old-install-new procedure if WP can't handle it cleanly across renames).
   - Settings, cached schemas, author/team data — all need an inventory in `docs/ARCHITECTURE.md` "Data Storage" section before the migration is written.

4. **Update the BW tooling test.** `test-plugin.sh` checks for `Update URI: https://plugins.bowden.works/${SLUG}/`. After rename, this becomes `https://plugins.bowden.works/bw-NEWSLUG/`. The plugin's main-file header and the bw-update-server registration both need updating.

5. **Plugin product page** at `plugins.bowden.works/bw-NEWSLUG/` (currently `plugins.bowden.works/bw-ai-schema-pro/` — to be created as part of the URL flip release; may need a redirect from the old product page after rename).

### Scope explicitly NOT in 3.0.0
- Adding new features. The rename is a maintenance release, not a feature release. Pile features into 2.x or 4.x.
- Breaking the schema markup output. End-user behavior must be byte-identical pre/post-3.0.0; only internals change.

## Open questions for the rename
- Should the rename happen in one release (3.0.0 rename + migrate) or two (2.x preparing + 3.0.0 finalizing)? One release is cleaner but riskier; two is safer but longer.
- Backwards-compat shims — should `BW_SCHEMA_VERSION` remain as an alias of `BW_NEWSLUG_VERSION` for one major version, or hard-cut at 3.0.0? Customer sites may have third-party code referencing the old constants (unlikely but not zero).