diff --git a/CHANGELOG-legacy.md b/CHANGELOG-legacy.md
new file mode 100644
index 0000000..527b27b
--- /dev/null
+++ b/CHANGELOG-legacy.md
@@ -0,0 +1,1293 @@
+# Changelog
+
+All notable changes to Aurora Admin are documented here, one entry per
+version bump. Starts at 2.1.0 — earlier history (the theming rebuild,
+window chrome/taskbar, Site Editor support, etc.) lives in `git log` and
+`PROJECT_STATUS.md`, not reconstructed here.
+
+## [3.6.1] - 2026-07-11
+
+### Fixed
+- **Second round of misplaced `phpcs:ignore` fixes**, found via another fresh Plugin Check report after 3.5.1's fix. Turns out `WordPress.DB.DirectDatabaseQuery.DirectQuery`/`NoCaching` and `WordPress.DB.PreparedSQL.NotPrepared`/`InterpolatedNotPrepared` are attributed by PHPCS to *different* lines within the same multi-line `$wpdb->get_results()`/`get_row()` call — `DirectQuery`/`NoCaching` to the outer call's opening line, `NotPrepared` to whichever inner line the interpolated table name physically appears on. 3.5.1's fix moved every ignore comment down to cover the inner line (fixing `NotPrepared`) but broke coverage of the outer line (`DirectQuery`/`NoCaching` came back) for four calls in `MenuCreatorData.php` and `Notices.php`/`NoticesData.php` that hadn't already been collapsed to a single line. Fixed by collapsing those four remaining multi-line calls too — consistent with the single-line-call pattern used everywhere else in the 3.5.1 fix, which a single ignore comment reliably covers regardless of which sniff PHPCS attributes to that line. Re-verified with the automated scan plus live REST-dispatch functional round-trips.
+
+## [3.6.0] - 2026-07-11
+
+### Changed
+- **Site Backup extracted into a standalone companion plugin,** at the
+  user's explicit request, following the same pattern as File Manager
+  (3.4.0) and Database Explorer (3.5.0) — proactive risk reduction, not a
+  WP.org rejection: restoring a backup means writing arbitrary files back
+  into the site, the same class of thing that's kept file-management
+  functionality out of Aurora Admin proper.
+  - The entire `admin/src/Backup/` tree (job/schedule storage, DB dumper,
+    file archiver, the state-machine engine, wp_cron safety net, and all
+    four storage providers — local, S3-compatible, Google Drive, plus the
+    provider interface/factory) and all four Backup REST controllers
+    moved, unmodified in behavior, into a brand-new sibling plugin:
+    **Aurora Site Backup** (`aurora-site-backup.php`, own bootstrap, own
+    REST namespace `aurora-site-backup/v1`, own Vite build). Since this
+    plugin needs its own settings storage independent of Aurora Admin
+    (S3 credentials, Google Drive OAuth tokens), a small standalone
+    `Options\Settings` class was added, backed by its own
+    `aurora_site_backup_settings` option — same minimal shape as Aurora
+    Admin's own Settings class, just a separate store.
+  - `CompanionPluginData.php`'s `PLUGINS` config array (already
+    generalized in 3.5.0) gained a `site-backup` entry — no new PHP
+    needed beyond the config line. The Settings → Add-ons screen now
+    lists all three companion plugins.
+  - Verified live via a full `rest_do_request()` dispatch: created a real
+    backup job, stepped it through the DB-dump phase, and canceled it —
+    end-to-end confirmation the extracted code still works, not just that
+    it loads without fatals.
+  - **Deployment gap, same as the other two companion plugins**: the
+    `aurora-site-backup.zip` is not yet hosted at
+    `https://aurora.auroradragon.studio/aurora-site-backup.zip` — the
+    Add-ons "Install & Activate" button for it will fail with a fetch
+    error until that's deployed (needs explicit go-ahead).
+
+## [3.5.1] - 2026-07-11
+
+### Fixed
+- **Misplaced `phpcs:ignore` comments from the 3.3.2 compliance pass, found via a fresh Plugin Check report.** WPCS's `phpcs:ignore` suppresses violations reported on the exact next physical line — but several annotations added in 3.3.2 sat above the *opening* line of a multi-line `$wpdb->get_results()`/`get_row()`/`get_var()` call (e.g. `$rows = $wpdb->get_results(`), while PHPCS actually attributes the violation to whichever line further down inside that call contains the interpolated table-name/column tokens. Those suppressions were silently never taking effect. Fixed across `MenuCreatorData.php`, `NoticesData.php`, `Notices.php`, `BackupSchedules.php`, `BackupJobs.php`, `MediaFolders.php` (the largest cluster — collapsed most multi-line query calls to a single physical line so one ignore comment reliably covers every sniff PHPCS reports on that line, added a `MediaFolders::name_taken()` helper to replace an inline `while()` condition that couldn't otherwise be annotated), `DbDumper.php`, `AnalyticsData.php`, and `MediaData.php`'s `post__not_in` VIP-advisory comment. Also added a genuinely missing annotation on `Analytics::record()`'s `$wpdb->insert()` call. Verified with an automated scan confirming every `$wpdb->` call with dynamic table/query construction is now immediately preceded by its ignore comment.
+- **Real bug found during verification, unrelated to Plugin Check**: `MenuCreatorData::create()` built its internal follow-up "fetch the row I just inserted" request as `new \WP_REST_Request("GET", "", ["id" => $wpdb->insert_id])` — but `WP_REST_Request`'s third constructor argument doesn't populate what `get_param()` reads, so `get_one()` always received a null id and returned "Menu not found" instead of the newly created menu. Confirmed via a full `rest_do_request()` dispatch (not just a direct function call) that this reproduced through the real REST route. Fixed by building the request with `set_url_params()`, WP core's own documented pattern for this.
+- Confirmed the `compressed_files`/`hidden_files`/`unexpected_markdown_file` findings in the Plugin Check report (build zips, `.gitignore`, `.claude/`, `PROJECT_STATUS.md`) are scanner noise from scanning the whole development repository, not the actual submission zip — verified via `unzip -l` that none of those paths exist in `wporg-submission/aurora-admin.zip`.
+
+## [3.5.0] - 2026-07-11
+
+### Changed
+- **Database Explorer extracted into a standalone companion plugin,** for
+  the same reason and following the exact same pattern as File Manager
+  in 3.4.0: direct database-query tooling (browsing tables, running
+  free-form SELECT/SHOW/DESCRIBE/EXPLAIN queries from wp-admin) is
+  treated by WordPress.org's Plugin Directory review the same way as
+  file-management functionality — outside what it accepts in a
+  directory-listed plugin. Rather than wait for a rejection to confirm
+  it or delete the feature outright:
+  - `admin/src/DatabaseExplorer/DatabaseExplorerData.php` and its Vue
+    UI (plus the shared `AppListShell`/`AppListItem` list-detail layout
+    it's built on) moved, unmodified in behavior, into a brand-new
+    sibling plugin: **Aurora Database Explorer**
+    (`aurora-database-explorer.php`, own bootstrap, own REST namespace
+    `aurora-database-explorer/v1`, own Vite build). Works completely
+    standalone, verified live via direct HTTP request with a
+    server-generated auth cookie — the admin page renders its mount
+    div and enqueued script correctly, and the REST namespace is
+    registered and reachable.
+  - `CompanionPluginData.php` was generalized from a single
+    file-manager-only class into a small `PLUGINS` config array keyed
+    by slug, so both File Manager and Database Explorer (and any future
+    companion plugin) share the same install/activate/status REST
+    routes and `Plugin_Upgrader`-based installer logic — adding a new
+    companion plugin going forward is a config entry, not new PHP.
+  - The **Settings → Add-ons** screen now lists both companion plugins.
+  - **Deployment gap, same as File Manager**: the Database Explorer zip
+    is not yet hosted at
+    `https://aurora.auroradragon.studio/aurora-database-explorer.zip` —
+    the Add-ons "Install & Activate" button for it will fail with a
+    fetch error until that's deployed (needs explicit go-ahead, same as
+    any other production deploy).
+
+## [3.4.0] - 2026-07-11
+
+### Changed
+- **File Manager extracted into a standalone companion plugin.** WordPress.org's
+  second review response was unambiguous: the entire category of
+  file-management/code-editing functionality isn't accepted into the
+  Plugin Directory, regardless of the restrictions added in v3.2.1 —
+  the feature had to come out of Aurora Admin entirely for the
+  submission to be reconsidered. Rather than delete the functionality:
+  - `admin/src/FileManager/FileManagerData.php` and its three Vue
+    components moved, unmodified in behavior, into a brand-new sibling
+    plugin: **Aurora File Manager** (`aurora-file-manager.php`, own
+    bootstrap, own REST namespace `aurora-file-manager/v1`, own Vite
+    build). It works completely standalone — verified live with Aurora
+    Admin fully deactivated.
+  - The Theme Editor → File Manager redirect (`AppearancePages.php`) is
+    gone; visits to `theme-editor.php` now fall through to WordPress
+    core's own Theme Editor unmodified, which already respects
+    `DISALLOW_FILE_EDIT` itself.
+  - A new **Settings → Add-ons** screen offers one-click installation of
+    Aurora File Manager, wrapping `Plugin_Upgrader::install()` — the
+    same core API the native Plugins → Add New "Install Now" button
+    uses — pointed at a fixed, non-client-supplied HTTPS zip URL. No
+    settings/data are shared between the two plugins; Aurora Admin has
+    zero remaining code that touches the filesystem beyond its own
+    Site Backup archives.
+
+## [3.3.2] - 2026-07-11
+
+### Fixed
+- **WordPress.org Plugin Check compliance pass** — a full re-run of the
+  official Plugin Check tool against the whole codebase (279 findings
+  across 26 files) surfaced several real gaps beyond the earlier v3.0.1/
+  v3.0.2/v3.2.1 passes, all now fixed:
+  - `readme.txt`'s `Stable tag` had drifted to 3.2.1 while the plugin
+    itself moved through 3.3.0/3.3.1 — a real mismatch that can prevent
+    WordPress.org from serving the correct download to users. Now kept
+    in lockstep with every version bump.
+  - `Analytics::country()` read `$_SERVER[$h]` directly for an
+    `empty()`/`strlen()` check before the existing sanitized copy was
+    computed — fixed by sanitizing once up front and using that
+    everywhere, rather than touching the raw superglobal at all.
+  - `AuroraAdmin.php`'s `defined("ABSPATH") || exit()` guard sat after
+    49 `use` import statements — functionally fine, but far enough into
+    the file that at least one automated file-access-protection scanner
+    didn't detect it. Moved to immediately after the `namespace`
+    declaration, this file's one deliberate departure from the rest of
+    the codebase's "guard after imports" convention.
+  - Roughly 230 `WordPress.DB.DirectDatabaseQuery`/`PreparedSQL`/
+    `UnescapedDBParameter` findings across every custom-table feature
+    (Site Backup, Media Folders, Activity Log, Analytics, Menu Creator,
+    Notices, Database Explorer) — verified each one is safe (internal
+    `$wpdb->prefix`-based table names or already-validated/escaped
+    identifiers, never raw user input) and annotated with the justified
+    `phpcs:ignore` the review process expects, matching the standard
+    already established for Database Explorer's query runner.
+  - A handful of `fread()`/`fwrite()`/`fclose()` calls adjacent to an
+    already-annotated `fopen()` were still individually flagged — WPCS
+    suppression is strictly per-line, so each sibling call in Site
+    Backup's file/S3/Google Drive streaming code now has its own
+    annotation too.
+  - Several `RuntimeException` messages interpolating internal (never
+    user-supplied) values were flagged as unescaped output — annotated
+    as exception messages, not HTML/browser output, the same
+    false-positive class WPCS is known to flag on exception
+    constructors.
+
+## [3.3.1] - 2026-07-11
+
+### Fixed
+- **Settings page: nav and content now scroll independently.** Previously
+  the left category list and the right content panel scrolled together
+  as one long page — scrolling down the nav to reach a category near the
+  bottom (e.g. "Modern Image Formats") and clicking it left the content
+  panel's top scrolled out of view above the fold, requiring an extra
+  scroll back up to actually see it. Both panels now have their own
+  fixed-height scroll region, and switching categories resets the
+  content panel's scroll position to the top regardless of the nav's own
+  scroll position.
+
+## [3.3.0] - 2026-07-11
+
+### Added
+- **Modern Image Formats** — a new Settings section that automatically
+  generates a WebP or AVIF sibling for every size WordPress produces from
+  a newly uploaded JPEG/PNG, and (optionally) rewrites `<img>` markup
+  into a `<picture>` element offering the modern format with the original
+  as a fallback source. "Automatic" output format prefers AVIF, falling
+  back to WebP, based on what the server's image editor actually
+  supports (`wp_image_editor_supports()`) — gracefully generates nothing
+  on a host that supports neither, rather than erroring. Purely additive:
+  original JPEG/PNG files are always kept, nothing about the attachment's
+  own metadata or file is changed, and generated files are cleaned up
+  automatically when the attachment is deleted. Only affects new
+  uploads — existing library images need a regenerate-thumbnails-style
+  tool to pick up the feature.
+  - Built entirely on documented WordPress core hooks
+    (`wp_generate_attachment_metadata`, `delete_attachment`,
+    `wp_editor_set_quality`, `wp_content_img_tag`,
+    `wp_get_attachment_image_html`) and `WP_Image_Editor::save()`'s
+    documented mime-type-conversion parameter — no third-party plugin
+    code, no Composer dependency.
+  - Verified live end-to-end: uploaded a real JPEG, confirmed a smaller
+    AVIF sibling was generated and recorded in attachment metadata,
+    confirmed a post embedding the image rendered a correct
+    `<picture><source type="image/avif" srcset="...">` wrapper, and
+    confirmed both the original and generated files were removed with no
+    orphans left behind after deleting the attachment.
+
+## [3.2.1] - 2026-07-11
+
+### Changed
+- **File Manager: PHP/executable editing removed.** Rejected from the
+  WordPress.org Plugin Directory because File Manager let a
+  `manage_options` user open and overwrite *existing* `.php` files
+  in-place with immediate execution effect — no different in risk from
+  WordPress core's own Theme/Plugin editor, which core lets hosts disable
+  via `DISALLOW_FILE_EDIT` specifically because of that risk. File Manager
+  previously blocked creating/uploading/renaming-to executable file
+  types, but that same list wasn't enforced on *editing an existing* file
+  of that type — closed now: opening or saving any file matching
+  `BLOCKED_EXTENSIONS` (php, phtml, cgi, py, sh, and others) is refused.
+  File Manager also now honors `DISALLOW_FILE_EDIT` (blocks all editing)
+  and `DISALLOW_FILE_MODS` (blocks all create/upload/rename/delete/copy/
+  move/write operations), the same host-level lockdown constants
+  WordPress core's own file-modification flows already respect. Browsing,
+  downloading, and viewing file info are unaffected.
+
+## [3.2.0] - 2026-07-11
+
+### Added
+- **Google Drive remote storage** for Site Backup — a second remote
+  storage option alongside S3-compatible, via OAuth 2.0. Each site
+  connects its own Google Cloud OAuth client (Client ID + Secret, pasted
+  into Settings) since a free, publicly-distributed plugin can't ship a
+  shared client secret; scope is the narrow `drive.file` (only
+  files/folders Aurora itself creates). Resumable upload and
+  `Range`-header chunked download against Drive API v3 mirror the
+  bounded-per-step design S3's multipart upload already established — no
+  changes to the job engine itself were needed, confirming the
+  storage-provider abstraction's original design goal. Shipped
+  code-complete and protocol-verified (request shapes checked against
+  Google's published API reference, and live-tested against Google's real
+  OAuth endpoints with placeholder credentials to confirm genuine API
+  errors come back); a full live "Connect" round-trip is left for the
+  user to verify once they have a real Google Cloud OAuth client and
+  HTTPS on the target site.
+
+## [3.1.0] - 2026-07-11
+
+### Added
+- **Site Backup** — a new free sub-app: full site backup (database +
+  wp-content) and restore-in-place, on-demand or on a recurring daily/
+  weekly/monthly schedule, storing archives locally or on any
+  S3-compatible remote (AWS S3, Backblaze B2, Cloudflare R2, DigitalOcean
+  Spaces — one implementation via a configurable endpoint, no vendor
+  SDK, SigV4 signing implemented directly and verified against AWS's own
+  published test vectors).
+  - Built on a new resumable job-processing engine (`BackupEngine` +
+    `BackupJobs`) — the first background-job infrastructure in this
+    codebase. Every backup/restore step is bounded (row/file/byte count
+    and a wall-clock budget) so a multi-GB site never risks a single
+    request's timeout or memory limit. Two trigger paths converge on the
+    same step function: foreground polling from the Vue UI (fast
+    feedback while a tab is open) and a `wp_cron` safety net
+    (`BackupCron`) that keeps a job moving with no browser involved —
+    closing the tab mid-backup, or a scheduled backup with nobody
+    watching, both still reach completion.
+  - Database export/import (`DbDumper`) — paginated dump with schema
+    captured per-table (`DROP TABLE IF EXISTS` + `CREATE TABLE`, so
+    restore is deterministic and re-runnable from scratch), chunked
+    restore via a byte-cursor into the dump file. Aurora's own
+    backup-tracking tables are excluded from what gets backed up — a real
+    bug caught during testing, where restoring a snapshot of those tables
+    was overwriting the very job row driving the restore mid-flight.
+  - File archiving (`FileArchiver`) — a manifest of every file under
+    `wp-content/` (excluding the backup storage directory itself and,
+    structurally, `wp-config.php`, which lives outside `wp-content/`
+    entirely), zipped/extracted in bounded batches via `ZipArchive`,
+    reopened and appended to across isolated requests. Every extracted
+    entry is containment-checked (zip-slip protection) before anything is
+    written — verified live with a deliberately crafted malicious archive
+    entry, confirmed rejected.
+  - Local storage hardening — `wp-content/uploads/aurora-backups/` gets
+    WordPress core's own `index.php`/`.htaccess` stub pair; the real
+    protection is that every archive read goes through a
+    `manage_options`-gated REST route streaming the file through PHP,
+    never a guessable direct URL.
+  - Recurring schedules with count-based retention — a scheduled backup
+    prunes older ones (both the job row and its stored archive, local or
+    remote) down to the schedule's configured retention count.
+  - v1 deliberately does not include cross-domain migration (Duplicator's
+    own headline feature — generating an `installer.php` for a totally
+    different host) or restoring from an arbitrary uploaded archive
+    (restore only ever sources from Aurora's own backup history) — both
+    are real scope/risk decisions, not oversights.
+- Live-verified end-to-end on the dev site, including catching and fixing
+  two real bugs along the way: a job's `phase` column wasn't updated to
+  a clean terminal value on completion (stale "Archiving files…" label
+  after a backup had actually finished), and a data-corruption bug where
+  manually pre-escaping newlines before `$wpdb->_real_escape()` (which
+  already does this) caused restored text fields to contain literal
+  backslash-n characters instead of real line breaks.
+
+## [3.0.2] - 2026-07-11
+
+### Fixed
+- Plugin header validation error from the WordPress.org submission checker:
+  `Plugin URI` and `Author URI` were both `https://auroradragon.studio`,
+  and WP.org requires them to be distinct (one identifies the plugin, the
+  other the author). `Plugin URI` now points to
+  `https://aurora.auroradragon.studio` (the plugin's own marketing site);
+  `Author URI` stays on the studio's root site.
+
+## [3.0.1] - 2026-07-11
+
+### Fixed
+- **WordPress.org Plugin Check compliance pass.** Ran the official Plugin
+  Check tool ahead of submission and fixed every real issue it surfaced
+  (257 flagged items, several dozen real):
+  - `WidgetsData.php`: replaced the forbidden `wp_get_sidebars_widgets()`
+    (internal-only core function) with a local helper reading the
+    `sidebars_widgets` option directly.
+  - `FileManagerData.php`: converted every raw filesystem call
+    (`move_uploaded_file()`, `mkdir()`, `rename()`, `unlink()`, `rmdir()`,
+    `is_writable()`, `readfile()`) to the `WP_Filesystem` API, which works
+    across hosting setups that don't allow direct filesystem access.
+    `move_uploaded_file()`'s upload-tampering check is preserved via an
+    explicit `is_uploaded_file()` call before handing off to
+    `WP_Filesystem::move()`.
+  - `BugReportData.php`: `parse_url()` → `wp_parse_url()`.
+  - `SubApps.php`: fixed a translation-function rule violation (page
+    titles now wrapped in `__()` at definition instead of being passed as
+    a variable to `__()` at the call site) and added justified
+    nonce-check suppressions on two read-only routing checks.
+  - Fixed missing `wp_unslash()`/sanitization on a handful of superglobal
+    reads (`Analytics.php`, `Shell.php`, `AnalyticsData.php`) and added
+    missing translator comments for two placeholder strings.
+  - Annotated dynamic-table-name SQL queries across `MediaFolders.php`,
+    `AnalyticsData.php`, `DatabaseExplorerData.php`, `NoticesData.php`,
+    `MenuCreatorData.php`, and `ActivityLogData.php` with justified
+    `phpcs:ignore` comments — every flagged table name comes from an
+    internal `$wpdb->prefix`-based helper, never user input, and table
+    identifiers can't go through `$wpdb->prepare()`'s value placeholders
+    (WordPress core has no API for arbitrary custom tables).
+  - Removed the stale `Domain Path: /languages/` plugin header (pointed
+    at a folder that's never existed — see 2.x-era removal of the fake
+    "13 languages" marketing claim).
+  - All changes live-verified against the LocalWP install: File Manager's
+    full create/rename/delete cycle exercised directly against the REST
+    routes (folder create, file create, rename, soft-delete, empty
+    trash), Widgets' sidebar-read endpoint, Database Explorer's table
+    browsing, and Media Folders' filtered listing all confirmed working
+    with zero console/PHP errors.
+
+## [3.0.0] - 2026-07-06
+
+### Removed
+- **The entire licensing/monetization system.** Aurora Admin is being given
+  away free on the WordPress.org plugin repository — every feature
+  previously gated behind a paid license (Role Editor, Activity Log,
+  Database Explorer, File Manager, Analytics, White Label, Full Admin
+  Takeover, Media Folders) is now simply available to everyone, no key
+  required.
+  - Deleted `admin/src/Licensing/` entirely (`License.php`, `Integrity.php`,
+    the file-tamper-detection system that only existed to protect license
+    gating from bypass) and `bin/build-integrity-manifest.php`.
+  - Deleted the "Pro feature" upgrade-prompt UI (`UpgradeNotice.vue`,
+    `locked-feature.js`) and every lock badge in the sidebar.
+  - Removed the License key field and the dev-only "Simulate active
+    license" toggle from Settings — there's nothing left to license or
+    simulate.
+  - `license_key` and `dev_license_override` are actively purged from any
+    site's stored settings on upgrade (same cleanup pattern used for the
+    earlier Remote Site Switcher removal), not just hidden from the UI.
+  - Report a Bug still works, now via a direct call to the feedback
+    endpoint instead of going through the license-status layer.
+  - This is a clean split from the commercial `auroraplugins.com` service
+    (beta licenses, Pro purchases) — that server-side system is untouched
+    and unaffected by this change, it's simply no longer wired into this
+    codebase.
+
+## [2.27.0] - 2026-07-06
+
+### Added
+- Restored the dev-only license override (`AURORA_ADMIN_DEV_MODE` wp-config.php
+  constant + Settings > Developer > "Simulate active license" toggle),
+  reversing the 2.25.0 removal. Requested explicitly for local testing on
+  admin.local — lets Pro features be exercised without a real license key.
+  **This must be stripped again before the next release/beta build** — same
+  standing rule as before, now re-documented in `PROJECT_STATUS.md`. Only
+  has any effect when `AURORA_ADMIN_DEV_MODE` is defined truthy in a given
+  install's own `wp-config.php`, never set in the repo or any built zip.
+
+## [2.26.0] - 2026-07-05
+
+### Added
+- "Report a Bug" page (Aurora sidebar section), a real WordPress admin page
+  (`aurora-admin-bug-report`, registered via `SubApps.php` like Menu
+  Creator/Admin Notices) with a single free-text field plus auto-filled,
+  read-only diagnostics (plugin version, WordPress version, PHP version,
+  active theme, last 4 characters of the license key — not the full key).
+  Submits to a new `POST aurora-admin/v1/bug-report` REST route
+  (`admin/src/Rest/BugReportData.php`), which forwards to a new
+  `License::submit_bug_report()` method that calls the license server.
+  - **License server** (`aurora-licensing` plugin, not this repo): added a
+    `wp_aurora_bug_reports` table (DB version 3 → 4, same version-gated
+    migration idiom) and a new public `POST /report-bug` REST route,
+    storing the description plus whatever license key/domain/diagnostics
+    fields were sent. Deliberately a plain `wpdb->insert` with no admin UI
+    yet — reports are reviewable via `wp db query` for now; a dashboard can
+    come later if report volume justifies it.
+  - Verified live end-to-end (not mocked): submitted a real report through
+    the actual Report a Bug page, confirmed it landed correctly in
+    `wp_aurora_bug_reports` on the production server, then deleted the two
+    test rows (one from an earlier curl smoke test) by exact ID.
+
+## [2.25.0] - 2026-07-05
+
+### Removed
+- Dev-mode license override (`AURORA_ADMIN_DEV_MODE` wp-config.php constant,
+  Settings > Developer category's toggle, and every call-site in
+  `License::is_active()`/`is_feature_available()`) — this was a
+  build-time-only escape hatch for testing paid features without a live
+  license, marked in `PROJECT_STATUS.md` as "MUST BE REMOVED BEFORE A
+  RELEASE BUILD" since it shipped in the plugin zip. Real beta testers are
+  about to install real builds, so it had to go before that zip goes out.
+  Paid features now gate purely on `License::is_active()` for everyone,
+  no exceptions.
+
+## [2.24.0] - 2026-07-05
+
+### Added
+- Beta tester license support, end to end. User asked for 10 new 30-day
+  beta licenses plus a way to flag/display beta status in the plugin.
+  - **License server** (`aurora-licensing` plugin on the live
+    `auroraplugins.com` box, not this repo): added an `is_beta` column to
+    `wp_aurora_licenses` (migrated in place via a `plugins_loaded`-hooked
+    check, since the file was updated without re-activation — same
+    version-gated migration idiom this plugin's own `ActivityLog.php`
+    etc. use), a `wp aurora-lic generate-beta <count> [--days=<n>]
+    [--max-sites=<n>]` WP-CLI command (not a public REST route —
+    generating free licenses has to stay admin/shell-only), and `is_beta`
+    added to `/validate` and `/activate`'s response payloads. Generated
+    the 10 requested keys (30-day expiry, 1 site each) — see the
+    conversation for the actual key list; not duplicated here since this
+    file ships to customers.
+  - **Client** (this plugin): `License::is_beta_tester()` reads the
+    server's `is_beta` flag (already flowing through the existing
+    `status()` cache — no new caching logic needed). Settings > General's
+    license status line now shows "Beta Tester license active — expires
+    in N days (date)" instead of the normal "License active (plan)" text
+    when a beta key is active. A beta license is a real, fully-functional
+    `is_active()` license like any other — this is a display flag only,
+    not a separate gating path.
+  - Verified against the real production license server, not a mock:
+    generated a real key via the new CLI command, activated it from the
+    dev site's actual Settings page, confirmed the badge and expiry
+    countdown render correctly, then cleared the key (deactivating it
+    server-side via the existing `on_settings_updated` flow).
+
+## [2.23.0] - 2026-07-05
+
+### Added
+- Full field-set parity for Writing/Reading/Discussion native Settings
+  screens, closing the gap flagged in 2.22.0's audit.
+  - **Writing**: `Default Post Category` and `Default Post Format` are now
+    real dropdowns (populated from `get_categories()`/
+    `get_post_format_strings()`) instead of raw numeric IDs. Added
+    `use_smilies` — registered in core's own REST settings schema but
+    never actually added to this screen.
+  - **Reading**: `Homepage`/`Posts Page` are now page-title dropdowns
+    (via `get_pages()`) instead of raw page IDs, and only appear once
+    "Homepage Displays" is set to "A static page" — matching native
+    WordPress's own conditional reveal. New generic `showIf` field
+    property in `NativeSettings.vue` (`{key, equals}`) drives this,
+    reusable by any future field.
+  - **Discussion**: went from 2 fields to full native parity (~24 fields:
+    pingback/comment defaults, moderation rules, threaded-comment
+    settings, pagination, three notification-email toggles, comment
+    moderation/disallowed-keys blocklists, and avatar settings). Core's
+    REST settings schema (`register_initial_settings()`) only ever
+    exposed 2 of Discussion's real options — everything else needed a new
+    dedicated controller, `DiscussionData.php`, doing raw `get_option()`/
+    `update_option()` reads/writes against an explicit key allowlist (same
+    pattern as `PermalinksData.php`, generalized to many keys instead of
+    one).
+  - New `textarea` field type in `SettingsField.vue` for the two
+    moderation-keys blocklist fields (multi-line plain text — nothing
+    else on any settings screen needed one until now).
+  - Verified live: dropdowns populate with real data, conditional fields
+    show/hide correctly, and a real save-then-reload round trip on
+    Discussion (toggled a setting off, saved, reloaded fresh, confirmed
+    the change persisted) — not just an optimistic-UI check.
+
+## [2.22.0] - 2026-07-05
+
+Full plugin audit, requested after the plugin-delete crash raised the
+question of what else might be broken or incomplete. Checked every
+sidebar screen live (console + PHP error log at each stop), re-verified
+the license-activation claim from last session against the actual code,
+and closed the one remaining documented security gap.
+
+### Fixed
+- **REST-bypass gap closed for Role Editor, Activity Log, and Database
+  Explorer** — their REST controllers only checked
+  `current_user_can('manage_options')`, not the license, so a direct REST
+  call could reach paid functionality (including Database Explorer's raw
+  SQL runner) with no license at all. Same fix already applied to File
+  Manager/Media Folders earlier this session, just never circled back for
+  these three. Verified every other paid-feature REST controller (Themes,
+  Nav Menus, Widgets, Permalinks, Analytics, White Label) already had the
+  check — this was the last of them.
+- **Permalinks screen was missing the standard structure presets** (Plain,
+  Day and name, Month and name, Numeric, Post name) — only the raw
+  "Custom Structure" text field existed, which is the one part of that
+  screen almost nobody actually uses by hand. Added the five presets as
+  radio options with live example URLs, auto-detecting which preset (or
+  "Custom") matches the currently-saved structure.
+
+### Verified (no changes needed)
+- Clicked through Dashboard, Posts, Pages, Media, Users, Comments,
+  Plugins, all Aurora sub-apps (Menu Creator, Admin Notices, Role Editor,
+  Activity Log, Database Explorer, File Manager), Media Upload, Add New
+  User, Profile, all 5 native Settings screens, and several Aurora
+  Settings categories (General, White Label, Analytics) — no fatals, no
+  new console errors anywhere in the pass.
+- Confirmed License.php's activation/validation flow is real (calls
+  `auroraplugins.com`'s REST API, caches with TTL, tamper-checks) —
+  corrected a stale "still a placeholder" claim from earlier this session
+  and removed the outdated doc line that caused it.
+
+### Known gaps (not fixed — flagged for a decision, not silently patched)
+- Writing/Reading/Discussion native Settings screens expose only a
+  handful of fields each, several as raw text/numeric-ID inputs where
+  native WordPress has dropdowns (post category, post format, homepage
+  page picker) — functional but poor UX, and Discussion in particular is
+  missing most of its native moderation options. Larger effort than the
+  Permalinks fix; needs new endpoints (categories list, post formats) and
+  new field types, not just a values tweak.
+- Comments list's pagination footer shows "0 to 0 of 0" despite the "All"
+  tab correctly showing a count — cosmetic, not investigated further.
+
+## [2.21.2] - 2026-07-05
+
+### Fixed
+- Deleting a plugin from Aurora's Plugins page ("major issue" per user
+  report) fataled the whole site with WordPress's generic "There has been
+  a critical error" page instead of actually deleting anything. Root
+  cause, found in the PHP error log: `PluginsData::delete_plugin()` called
+  core's `delete_plugins()`, which internally calls
+  `request_filesystem_credentials()` (WP_Filesystem setup) — that function
+  lives in `wp-admin/includes/file.php`, which a REST API request doesn't
+  load the way a normal wp-admin page load does, and `delete_plugin()`
+  only required `plugin.php`. `update_plugin()` right below it already
+  required `file.php` for the same underlying reason; `delete_plugin()`
+  just never got the same fix. Verified live: deleted a real plugin
+  (WP File Manager) end to end with no fatal, "Plugin deleted." message
+  shown correctly, confirmed no new error logged.
+
+## [2.21.1] - 2026-07-05
+
+### Fixed
+- Sidebar section accordion closed the wrong section on "hidden child"
+  native screens (theme-install.php, media-new.php, user-new.php, ...).
+  User: expand Appearance, click "Add New Theme", and the Appearance
+  section collapsed while the "AURORA" section at the bottom opened
+  instead — this was a different bug than the overlay-covers-the-sidebar
+  issue fixed in 2.21.0, this was specifically about which section stays
+  expanded. Root cause: `Sidebar.vue`'s accordion decides the open section
+  by matching the current URL against each menu item's own submenu array
+  (`MenuSerializer::serialize()`, scraped from WP's `$submenu` global) —
+  but these screens are deliberately absent from `$submenu` (WP's own
+  native left menu doesn't list "Add New Theme" as a link either, only
+  "Themes"/"Customize"/"Editor"), so no section ever matched and the
+  accordion fell through to its Aurora-expanded default.
+  - WP core itself solves this exact problem for its own native menu
+    highlighting via a `$parent_file` global, set directly in each of
+    these pages' own PHP (`theme-install.php` sets
+    `$parent_file = 'themes.php'`, `media-new.php` sets `'upload.php'`,
+    `user-new.php` sets `'users.php'`) — reused that instead of
+    hardcoding a list of "hidden child screen" mappings ourselves.
+    `Shell::print_mount()` now reads it and passes it through as
+    `activeParentFile`; `Sidebar.vue`'s `isSectionActive()` treats a menu
+    item as active when its id matches, alongside the existing exact-URL
+    checks. General fix — covers any current or future WP core (or
+    third-party plugin) screen using this same convention, not just the
+    three confirmed here.
+
+## [2.21.0] - 2026-07-05
+
+### Changed
+- The theme-install.php "Preview & Install" overlay (clicking a theme card
+  under Appearance > Themes > Add New Theme) is now framed like the block
+  editor window instead of covering Aurora's sidebar/toolbar entirely.
+  User reported "it closes the menu" — confirmed this is WP core's own
+  native behavior (the fullscreen overlay covers the native admin menu
+  too, on a totally vanilla install), not a regression, but agreed a
+  framed treatment was worth the risk for visual consistency with how the
+  block editor is already handled.
+  - `.wp-full-overlay` (WP core's overlay component, shared with the
+    Customizer — only `.theme-install-overlay` specifically is touched,
+    not `.wp-full-overlay` generally) is reframed to Aurora's standard
+    inset box: the overlay itself plus its two independently
+    `position: fixed` children (`.wp-full-overlay-sidebar`,
+    `.wp-full-overlay-main`) each need the same left/top/bottom math
+    applied directly, since fixed descendants don't inherit an ancestor's
+    padding-box positioning the way absolutely-positioned ones do.
+    `margin-left` on `.expanded`/`.collapsed` mirrors WP core's own three
+    responsive breakpoints with Aurora's frame offset added on top, so the
+    sidebar collapse/expand slide animation keeps working unmodified.
+  - Root-caused and fixed two real bugs found while building this: (1)
+    opening the overlay adds `body.full-overlay-active`, and WP core's own
+    CSS sets `body.full-overlay-active { visibility: hidden }` with only
+    the overlay itself set back to visible — Aurora's entire shell
+    inherited that hidden visibility too (nested in body), which is what
+    silently erased the sidebar/toolbar instead of just having them
+    covered. Fixed with one override re-enabling visibility for Aurora's
+    own root specifically. (2) The overlay's own `height: 100%` (WP core)
+    combined with our `top`+`bottom` insets was the exact same
+    over-constrained-box bug already known from the block editor's
+    `.interface-interface-skeleton` — same `height: auto !important` fix.
+  - The traffic-light winbar needed a permanently-running `MutationObserver`
+    rather than a one-shot check: the overlay doesn't exist in the initial
+    DOM (WP core creates it lazily on first click), and every subsequent
+    theme selection fully re-renders the overlay's contents, wiping out
+    anything inserted into it — confirmed live (bar present after the
+    first click, gone after picking a second theme) before switching to an
+    idempotent "ensure inserted" observer callback.
+  - Verified live end-to-end: opening via natural clicks (not just direct
+    URL navigation), switching between themes with the prev/next arrows
+    (triggers the content-destroying re-render), closing and confirming
+    the sidebar/toolbar return correctly, no console errors at any step.
+
+## [2.20.2] - 2026-07-05
+
+### Fixed
+- Appearance > Themes was missing two capabilities the native Themes
+  screen has: browsing/installing themes from the WordPress.org directory,
+  and uploading a theme zip. `AppearancePages.php`'s `load-themes.php`
+  hijack never passed a link to `theme-install.php` (only `customizeUrl`),
+  so there was no way to reach either from Aurora's Themes page.
+  `Themes.vue` gains an "Add New Theme" button (next to Customize) linking
+  to native `theme-install.php`, gated on `current_user_can('install_themes')`
+  — that native screen already has both the WordPress.org browser (Popular/
+  Latest/Block Themes/Favorites/Feature Filter tabs, search) and an
+  "Upload Theme" button built in, so neither needed rebuilding. Same
+  reuse-native-flow-for-add pattern already used for Plugins' `addUrl`
+  (`plugin-install.php`) and Media's `newMediaUrl` (`media-new.php`).
+
+## [2.20.1] - 2026-07-05
+
+### Fixed
+- Font Library (`font-library.php`) rendered with a jarring mix of Aurora's
+  dark frame around a completely white, near-unreadable content area (light
+  text on a white card). WP 6.5+ built this screen on `@wordpress/
+  components`' newer "boot-layout" primitives instead of classic postbox
+  markup, so `native-dark.css`'s existing postbox/card rules never matched
+  its DOM. Added targeted dark-theme coverage for the screen's stable,
+  hand-authored class names (`.boot-layout-container`, `.boot-layout__stage`,
+  `.admin-ui-page`, `.admin-ui-navigable-region`, `.admin-ui-page__header`,
+  `.font-library-page__tab-panel`, `.font-library__tabpanel-layout`,
+  `.font-library__footer`, `.font-library__fonts-list-item`,
+  `.font-library__font-card`) — deliberately not touching this screen's
+  Emotion-generated hash classes (e.g. `css-qi2azi`), which aren't stable
+  across WP builds.
+- Regenerated `admin/src/Licensing/integrity-manifest.json` and rebuilt
+  `dist/aurora-admin-v2.zip` from a fresh staging copy — the protected
+  files' checksums (`Integrity::is_tampered()`'s manifest) had gone stale
+  after this session's edits to `aurora-admin.php`, `Shell.php`, and others.
+  Also excluded `.claude/` from the staged copy — the internal tooling
+  config had been getting bundled into the distributable zip.
+
+## [2.20.0] - 2026-07-05
+
+### Added
+- Media Folders (paid — `License::PAID_FEATURES["media-folders"]`): a
+  folder tree for the Media Library, duplicating the organizing capability
+  of the FileBird Pro plugin at the user's request, with its own
+  independent schema (`wp_aurora_media_folders` /
+  `wp_aurora_media_folder_items`, distinct from FileBird's own `wp_fbv*`
+  tables so both can coexist) rather than importing FileBird's data.
+  - New `MediaFolders.php` model (create/rename/delete/reparent, one folder
+    per attachment) + `MediaFolderData.php` REST routes
+    (`/media-folders`, `/media-folders/assign`), every route double-gated
+    (`current_user_can` + `License::is_feature_available`) per this
+    project's established REST-bypass-hardening pattern.
+  - `Media.vue` gains a folder sidebar (`MediaFolderTree.vue`): create,
+    rename, delete, right-click context menu, drag-and-drop reparenting,
+    and drag-and-drop (or a "Move to folder" fallback) to file media into
+    folders. "All Media" and "Uncategorized" are pinned pseudo-folders.
+  - The Media Library page itself stays free/ungated either way — only the
+    folder capability is paid. Unlicensed users keep today's flat grid
+    unchanged; the sidebar shows an inline `UpgradeNotice` instead of
+    disappearing or locking the whole page — a new gating shape for this
+    codebase (previously: whole sub-app free or whole sub-app paid).
+
+### Fixed
+- `Shell::is_own_page()` didn't recognize `ScreenHijack`-based pages
+  (Posts, Pages, Media, Users, Comments — they keep their native URL, no
+  `?page=aurora-admin` to key off), so it misclassified them as native
+  pages and loaded `native-dark.css`'s own-page exclusion incorrectly,
+  letting that stylesheet's generic `a` color rule leak into the real
+  Aurora UI. Invisible until now because no earlier hijacked page rendered
+  a link relying on accent/contrast coloring — Media Folders' new
+  "Enter a license key" CTA in the unlicensed sidebar was the first.
+  `ScreenHijack::register()` now flags `is_hijack_active()` the moment any
+  registered hijack activates for the current request, and
+  `is_own_page()` checks it.
+
+## [2.19.0] - 2026-07-05
+
+### Removed
+- Remote Site Switcher: the Settings > General "Remote Sites" repeater and
+  "Remote Site Switcher Capability" field, and the toolbar dropdown they
+  fed. User asked what it did; investigation found it was inert scaffolding
+  — it collected and stored a remote site's URL/username/application
+  password, but nothing anywhere in the codebase ever used the credentials
+  (no REST calls, no proxying, no SSO). The toolbar "switcher" was just a
+  plain link opening the remote site's own `/wp-admin/` in a new tab. User's
+  call: "doesn't really do much for the software" — removed rather than
+  built out, since a real cross-site integration wasn't the ask.
+- `License::PAID_FEATURES["remote-site-switcher"]` — the feature's paid gate,
+  now dead code since the feature itself is gone.
+
+### Added
+- `Settings::remove_retired_keys()` — actively deletes now-unused settings
+  keys from the database on `init`, rather than leaving them inertly
+  stored. Added specifically because `remote_sites` held a real secret
+  (WordPress application passwords); once the field stopped being read or
+  written, the safer move was to purge it, not just stop touching it.
+
+## [2.18.0] - 2026-07-05
+
+### Added
+- Role Editor: an info icon next to every capability checkbox, with a
+  hover tooltip explaining what it actually does — user asked directly,
+  pointing at `level_0`/`level_1` as an example of capabilities with no
+  explanation anywhere in the UI. New `capabilityDescriptions.js` covers
+  all ~55 WordPress core capabilities (`edit_posts`, `manage_options`,
+  `unfiltered_html`, etc.) plus the legacy `level_0`–`level_10` "user
+  level" system specifically — a pre-2.0 permissions scheme WordPress
+  still assigns to every default role purely for backward compatibility
+  with old themes/plugins that check `current_user_can('level_N')`
+  directly instead of a named capability; core itself hasn't checked a
+  level in years. Any capability not in the dictionary (e.g. one added by
+  another plugin) gets a generic "custom capability" fallback rather than
+  showing nothing. Verified live: hovering `level_0`'s info icon on the
+  Subscriber role shows the explanation described above.
+
+## [2.17.2] - 2026-07-05
+
+### Fixed
+- `AppListShell.vue` (the shared master/detail layout used by Database
+  Explorer, Role Editor, Activity Log, Admin Notices, and Menu Creator):
+  the list pane and detail pane shared one page-level scroll instead of
+  scrolling independently. Selecting an item near the bottom of a long
+  list (e.g. Database Explorer's 40 tables) left the detail panel's
+  newly-loaded content rendered off-screen above the current scroll
+  position — looked like nothing happened until you scrolled all the way
+  back up. Root cause: the shell only set a `min-height` on the outer
+  flex container, so it just grew with content instead of giving each
+  pane a capped height + its own scrollbar. Fixed by giving the container
+  a real `height` and both panes `height: 100%; overflow-y: auto`, with a
+  separate mobile-breakpoint treatment (stacked panes get natural height
+  with their own `max-height` instead of squashing to 50/50). Verified
+  live: scrolled Database Explorer's table list to the bottom, selected
+  `wp_users`, confirmed its data appeared immediately without scrolling.
+
+## [2.17.1] - 2026-07-05
+
+### Fixed
+- File Manager's right-click context menu never appeared for real users
+  (it worked in earlier automated testing, which turned out to be
+  triggering the bug's absence rather than confirming its fix). Root
+  cause: right-clicking — especially via a trackpad's two-finger tap or
+  Ctrl-click on macOS — can fire a trailing synthetic `click` event
+  immediately after `contextmenu` on the same target. The menu's
+  "click anywhere else closes it" listener was attached synchronously the
+  moment the menu opened, so that trailing click closed it in the same
+  tick it appeared — a real race condition, not a rendering bug. Fixed by
+  deferring the outside-click listener's registration by one tick
+  (`setTimeout(..., 0)`) so it only starts listening after the opening
+  event has fully finished. Verified by simulating the exact race
+  (`contextmenu` immediately followed by `click` on the same element,
+  same tick) and confirming the menu stays open; also confirmed a genuine
+  later click still closes it.
+
+## [2.17.0] - 2026-07-05
+
+### Added
+- File Manager: **right-click context menu**, mirroring the toolbar exactly
+  (same functions, just a different trigger) so the two can't drift out of
+  sync. Right-clicking an item outside the current selection selects just
+  that item first (standard file-manager behavior); right-clicking within
+  an existing multi-selection leaves it intact so bulk actions still work
+  from the menu. Right-clicking empty space shows folder-level actions
+  (New Folder/File, Upload, Paste) instead. Closes on Escape or a click
+  anywhere else.
+- File Manager: the plain `<textarea>` editor is now a real code editor
+  (CodeMirror 6 — `codemirror` + per-language packages for JS/TS, CSS,
+  HTML, JSON, PHP, Markdown, XML, SQL), with syntax highlighting, line
+  numbers, code folding, and active-line highlighting. Language is chosen
+  by file extension; unrecognized extensions fall back to plain text
+  rather than guessing wrong. Themed directly off Aurora's own CSS
+  variables (not a hardcoded palette) so it matches whatever theme preset
+  is active instead of looking like a foreign widget. Adds real bundle
+  weight (~250KB gzipped) — only loaded when the File Manager page itself
+  is opened, not part of the main admin bundle.
+- Verified live: context menu appears correctly for both selection and
+  empty-space cases with the right actions enabled/disabled, Escape closes
+  it; PHP syntax highlighting confirmed rendering correctly on a real file
+  (index.php — comments, strings, keywords all colored, doc-block folding
+  visible).
+
+## [2.16.0] - 2026-07-05
+
+### Changed
+- File Manager's actions consolidated into a single elFinder-style toolbar
+  (back/forward/up navigation history, new folder/file, upload,
+  copy/cut/paste, rename, trash, download/edit/info, list/grid view toggle,
+  fullscreen, search) matching the layout of the "WP File Manager" reference
+  plugin, replacing the previous split of header buttons + a per-row Actions
+  column. Selection is now click-to-select (checkbox) + toolbar action,
+  double-click to open a folder or editable file — the toolbar's buttons
+  enable/disable based on what's currently selected (e.g. Rename/Info only
+  with exactly one item selected, Download only for a single file).
+- **Move/copy switched from a destination-picker modal to clipboard-style
+  copy/cut/paste** — select item(s), click Copy or Cut, navigate anywhere
+  (tree sidebar, breadcrumb, double-click into a folder), click Paste. A
+  copy clipboard survives repeated pastes; a cut clipboard clears itself
+  after the first successful paste. Same `/file-manager/bulk` endpoint
+  underneath, just a different frontend trigger.
+- Added a **grid view** (thumbnails/icons in a card layout) as an
+  alternative to the list view, and a **fullscreen toggle** for the File
+  Manager panel itself.
+- Verified live: copy → navigate into a folder → paste (file appeared in
+  the new location) → select → trash → confirmed removed; back-navigation
+  and grid view toggle both confirmed working.
+
+## [2.15.0] - 2026-07-05
+
+### Added
+- File Manager closed most of the feature gap against the reference "WP
+  File Manager" plugin, adding everything that didn't carry the security
+  risk of the already-excluded zip/unzip and chmod features:
+  - **Move & copy** between folders (`copy_item`/`move_item`), with
+    same-containment checks as everything else plus a specific guard
+    against moving/copying a folder into its own descendant. Name
+    collisions at the destination get " (2)", " (3)", etc. appended rather
+    than silently overwriting.
+  - **Multi-select + bulk actions** — one `/file-manager/bulk` endpoint
+    drives trash/move/copy across any number of selected items, reusing
+    the exact same per-item logic as the single-item buttons so bulk
+    behavior can't drift from what those do. Partial failures don't abort
+    the rest — every path gets its own attempt, failures are reported back.
+  - **Trash instead of permanent delete** — deleting now moves the item
+    into a flat UUID-named folder under `wp-content/uploads/aurora-admin-trash/`
+    plus a JSON manifest (original path, name, type, deleted-at), rather
+    than encoding the original path into the filename (nesting/special
+    characters/length limits make that fragile). Trash view offers
+    restore (recreates parent folders as needed, blocks if something's
+    since taken the original spot), permanent delete, and empty-trash.
+  - **Folder tree sidebar** — lazy-loaded (only fetches a folder's children
+    when expanded) via the existing list endpoint filtered to directories,
+    no new backend route needed. Reused as the destination picker for
+    move/copy.
+  - **File info panel** — read-only permissions/owner/size/dates/mime type
+    via a new `/file-manager/info` endpoint; directory size is computed
+    on-demand for this one-off request rather than for every row in the
+    main list (would slow down browsing large folders for no benefit).
+  - **Image thumbnails** — a new `/file-manager/preview` endpoint serves
+    image files inline (not as an attachment) for use as an `<img>` src;
+    no server-side resizing, just the extension allowlist + size cap every
+    other endpoint here already uses.
+  - **Drag-and-drop upload** (multiple files at once) and **sortable
+    columns** (Name/Size/Modified, folders always first regardless of
+    sort) — both frontend-only, no new backend surface.
+  - Aurora's own trash folder is hidden from the normal browser view when
+    listing `wp-content/uploads` — it's an implementation detail, not a
+    real user-created folder.
+  - Verified live: multi-select, info panel, and the full create → trash →
+    restore round trip through the UI; copy/bulk-trash/empty-trash verified
+    directly against the REST endpoints.
+- Still deliberately not built (unchanged from the original scope decision):
+  zip/unzip (zip-slip risk) and chmod/permissions editing (too easy to lock
+  yourself out).
+
+## [2.14.0] - 2026-07-05
+
+### Added
+- **Developer-only** license override for local testing — lets Pro
+  features be tested without buying a license against the developer's own
+  software. Settings > Developer's "Simulate active license" toggle treats
+  every paid feature as fully licensed, bypassing both the real license
+  check and the file-integrity tamper check. Two gates keep this from ever
+  doing anything on a real install even if this code ships by accident:
+  (1) it only has any effect at all when `AURORA_ADMIN_DEV_MODE` is
+  defined truthy in `wp-config.php` — never set anywhere in this repo or
+  the release zip, only in a local dev environment's own config — and (2)
+  the Settings > Developer category itself only renders in the UI when
+  that constant is present. **This entire feature (the `DEV_MODE_CONSTANT`
+  checks in `License.php`, the `devModeAvailable` flag in
+  `SettingsPage.php`, and the "Developer" category in
+  `settingsConfig.js`/`Settings.vue`) must be removed before packaging a
+  release build** — every touch point is marked `DEV ONLY` in comments.
+  Verified live: toggling it on/off correctly unlocks/re-locks a Pro
+  feature (Role Editor) end-to-end, including the sidebar's lock badge.
+
+## [2.13.1] - 2026-07-05
+
+### Fixed
+- Every `ScreenHijack`-mounted page (Posts, Pages, Media, Users, Comments,
+  the 5 native Settings screens, Media Upload, Add New User, Nav Menus,
+  Themes, Widgets, Profile) was missing the traffic-light title bar and
+  rendering outside the normal card frame — the DOM structure didn't match
+  native/other Aurora pages. Root cause: WordPress prints
+  `<div id="wpbody"><div id="wpbody-content">` *after* the
+  `in_admin_header` hook fires (confirmed directly in core's
+  `admin-header.php`), but `ScreenHijack.php` started its output buffer
+  *on* `in_admin_header` — so those wrapper divs' opening tags, and later
+  their closing tags (printed before `admin_footer` fires), both ended up
+  inside the buffer and got discarded along with the native content they
+  were meant to replace. The mount div ended up a level too high in the
+  DOM (a direct child of `#wpcontent`), which broke `windowChrome.js`'s
+  `#wpbody-content`-based traffic-light insertion and the shell's card
+  framing CSS. Fixed by having `ScreenHijack.php` re-print the `#wpbody`/
+  `#wpbody-content` wrapper divs itself around the mount point, so the DOM
+  matches what WordPress would have produced. Verified live on Posts,
+  Media, Users, and Profile.
+
+## [2.13.0] - 2026-07-05
+
+### Added
+- Sixth and final phase of the "full admin takeover" initiative: the block
+  editor (`post.php`/`post-new.php`). Deliberately a reskin, not a rebuild
+  — Gutenberg stays completely native, extending the framing
+  `windowChrome.js`/`shell-frame.css` already had working (traffic-light
+  dots overlaid on the editor). Added a "← Posts"/"← Pages" breadcrumb next
+  to the dots, resolved from the `post-type-{slug}` body class WP core
+  already adds to every post edit screen (needed since Posts/Pages moved
+  off a fixed `admin.php?page=...` URL onto their native URLs earlier this
+  phase, so there's no single URL to hardcode).
+  - Caught and fixed a real bug while testing: the Site Editor
+    (`site-editor.php`) shares the same `block-editor-page` body class the
+    breadcrumb logic keyed off, but has no `post-type-*` class (it edits
+    templates, not a post) — the original version defaulted to guessing
+    "Posts" there, which was wrong. Now returns no breadcrumb at all when
+    no `post-type-*` class is present, verified live on both the post
+    editor (crumb shows, correct link) and the Site Editor (no crumb,
+    nested-skeleton framing unaffected).
+  - This is the last screen in the "full admin takeover" initiative's
+    original 9-item build order. All 9 phases are now shipped.
+
+## [2.12.0] - 2026-07-05
+
+### Added
+- Fifth phase of the "full admin takeover" initiative: Profile
+  (`profile.php`), reskinning WordPress's own fields (name, contact info,
+  bio) via core's `/wp/v2/users/me` REST route, plus a small new
+  `ProfileData.php` route for password changes (core deliberately excludes
+  password from its own REST schema). Free, gated by `modern_users`.
+  - Deliberately does not attempt to host third-party plugin fields (2FA
+    setup, WooCommerce customer fields, etc., added via the
+    `show_user_profile`/`personal_options` hooks) — a Vue reskin has no
+    safe way to render another plugin's raw HTML/JS. Instead, the hijack
+    checks `has_action('show_user_profile')`/`has_action('personal_options')`
+    at hijack time and falls through to the real native screen whenever
+    either has a callback registered, rather than silently hiding those
+    plugins' fields. Verified live both ways: installed a test mu-plugin
+    hooking `show_user_profile` and confirmed the native screen renders
+    instead of the reskin; removed it and confirmed the reskin returns.
+  - Password changes re-issue the auth cookie immediately after
+    `wp_set_password()` (which invalidates the current session, since it's
+    derived in part from the password hash) — same as core's own
+    user-edit.php does when you change your own password.
+
+## [2.11.0] - 2026-07-05
+
+### Added
+- Fourth phase of the "full admin takeover" initiative: the Appearance
+  batch. Nav Menus (`nav-menus.php`) and Widgets (`widgets.php`) are real,
+  purpose-built replacements — not wired into the existing Menu Creator,
+  which manages Aurora's own admin sidebar and turned out to be an unrelated
+  feature despite the similar name. Themes (`themes.php`) is a real
+  list/activate/delete replacement (`ThemesData.php` + `Themes.vue`). Theme
+  Editor (`theme-editor.php`) redirects to the existing File Manager instead
+  of getting a second in-browser file editor — building one would duplicate
+  File Manager's exact RCE risk surface for no benefit. Tools, Import/Export,
+  and Site Health are deliberately left un-hijacked; Shell's existing
+  native-page framing already covers them and a full rebuild has no real
+  value-add over core's own screens.
+  - Widgets is deliberately simplified to reordering/moving/deactivating
+    existing widget instances between sidebars — adding a brand-new
+    instance of an arbitrary widget type still uses WordPress's own
+    block-based widgets screen (each widget type owns its own default
+    settings and form; genericizing that is a full editor's worth of scope
+    on its own, same reasoning as not rebuilding the block editor).
+  - Nav Menus supports the common paths: create/delete menus, add
+    pages/posts/categories/custom links, reorder and indent/outdent
+    (sub-menu) items, assign menus to theme locations.
+  - All three (plus Native Settings, previously shipped) are gated by the
+    `full_admin_takeover` master toggle and the `"admin-takeover"` paid
+    feature; every new REST controller checks the license directly in its
+    own `permission_callback`, not just at the page level.
+- Fixed a real frontend bug caught while testing these against a 403 (no
+  license): `Themes.vue`, `Widgets.vue`, and `NavMenus.vue`'s fetch calls
+  didn't check `res.ok` before treating the response body as the expected
+  data shape — a REST error object (`{code, message, data}`) got rendered
+  as if it were the actual list, producing bogus placeholder rows instead
+  of a clear error message. All three now surface the real error.
+- Verified live: Themes' activate/list/screenshot rendering confirmed
+  working end-to-end (switched between all 3 installed themes); Nav Menus
+  and Widgets' REST layer verified directly (create/add-item/list/delete
+  round trip, real sidebar data) — the pages themselves couldn't be
+  rendered in this dev environment since none of the 3 installed themes
+  register classic nav-menu/widget support (all are block/FSE themes,
+  which core itself refuses these screens for too — not a defect in the
+  hijack).
+
+## [2.10.0] - 2026-07-05
+
+### Added
+- Third phase of the "full admin takeover" initiative: Media Upload
+  (`media-new.php`) and Add New User (`user-new.php`) are now hijacked in
+  place. Both are Vue-only — no new PHP REST controllers — talking directly
+  to core's own `/wp/v2/media` and `/wp/v2/users` REST routes, which already
+  cover file upload and user creation. Free, gated by the same
+  `modern_media`/`modern_users` toggles as their already-free list-view
+  companions (no reason to paywall mid-workflow between "browse" and "add").
+  Verified live end-to-end: created a real user and confirmed it appears in
+  the Users list.
+
+## [2.9.0] - 2026-07-05
+
+### Added
+- Second phase of the "full admin takeover" initiative: the 5 native
+  Settings screens (General, Writing, Reading, Discussion, Permalinks) are
+  now hijacked in place (`NativeSettingsPages.php`), sharing one generic
+  Vue page (`NativeSettings.vue`) driven by a per-screen field schema.
+  Most fields read/write through core's own `/wp/v2/settings` REST route;
+  Permalinks has no core REST route for rewrite rules, so it gets its own
+  small `PermalinksData.php` controller instead (calls
+  `$wp_rewrite->set_permalink_structure()` + `flush_rules()`, same as core's
+  own settings page does).
+- New master toggle, Settings > Admin Takeover > "Full admin takeover"
+  (default **off** — these new areas cover more ground and carry more risk
+  than the already-migrated Posts/Pages/Media/Users/Comments, so opt-in
+  rather than on by default), plus a new `"admin-takeover"` paid feature key.
+  Every new REST controller in this phase checks
+  `License::is_feature_available("admin-takeover")` directly in its own
+  `permission_callback`, not just at the page level — the same defense the
+  File Manager REST controller already has, verified live by confirming a
+  direct REST call still 403s with the setting on but no license.
+- `SettingsField.vue` (shared by the main Settings page and the new native
+  Settings screens) gained two small additions: `readonly` support on text
+  fields (Site Address shouldn't be editable inline) and a `select` field
+  type (a plain dropdown, distinct from the existing multiselect checkbox
+  list) — both minimal, generically useful additions, not one-offs.
+
+## [2.8.0] - 2026-07-05
+
+### Added
+- First phase of the "full admin takeover" initiative: Posts, Pages, Media
+  Library, Users, and Comments no longer redirect to a separate
+  `admin.php?page=...` URL — they now hijack their native screens in place
+  (`ScreenHijack.php`, registered via `HijackedNativePages.php`), the same
+  approach the original uixpress reference plugin used. WordPress's
+  `load-{page}.php` hook fires before the native screen prints anything, so
+  Aurora buffers and discards the native output and mounts its own Vue page
+  in its place — the URL never changes, so there's no separate slug that can
+  fall out of sync with a plugin's own redirect, a bookmark, or any other
+  direct visit. This is exactly the bug class already hit and fixed once for
+  Plugins; the other five pages are now structurally immune to it. Plugins
+  itself stays on the redirect mechanism — `plugins.php` prints output in a
+  way that can't be cleanly buffered, confirmed by the reference plugin's own
+  abandoned attempt at hijacking it.
+- Existing REST controllers and Vue pages for all five are unchanged — only
+  the mounting mechanism moved.
+
+## [2.7.2] - 2026-07-05
+
+### Fixed
+- Installing/activating a plugin dropped back to the native WordPress
+  Plugins page instead of staying in Aurora's UI, until the sidebar's
+  "Plugins" link was clicked again. Unlike Posts/Pages/Media/Users/
+  Comments, Plugins only ever had its sidebar *link* rewritten
+  (`MenuSerializer.php`) — there was no `redirect_native_pages()` case
+  for direct visits to `plugins.php`, which is exactly what WordPress's
+  own post-activate/post-install redirect does
+  (`wp_redirect(self_admin_url('plugins.php?activate=true'))`, no
+  `?page=` param). Added the missing case, matching the pattern already
+  used for the other four pages.
+
+## [2.7.1] - 2026-07-05
+
+### Fixed
+- Native form fields (text inputs, textareas, selects) on several
+  classic/non-block-editor screens — most visibly the title field on the
+  Edit Media screen, but the same fix applies wherever it occurred — were
+  showing stark white, breaking the dark theme. Root cause: some native
+  WP screens style specific fields via a 2-ID selector (e.g. core's
+  `#titlediv #title { background: #fff }`), which beats our existing
+  rule's single `#wpbody-content` id no matter how many classes are
+  stacked on it — the exact same CSS-specificity trap as an earlier
+  block-editor background bug. Added `!important` to the form-field rule
+  block, since there's no legitimate case where a native admin form field
+  should stay white.
+
+## [2.7.0] - 2026-07-05
+
+### Added
+- New File Manager (`aurora-admin-file-manager`), browsing/editing the
+  WordPress install's own files — built fresh (not embedding elFinder),
+  in the spirit of the "WP File Manager" plugin already on this site
+  (same root, same `manage_options`-only gate). Create/upload/download/
+  rename/delete files and folders, plus a plain-text editor for
+  code/config files. A **Pro feature** — the riskiest surface in the
+  whole plugin (arbitrary read/write access to the site's own PHP files),
+  so it's gated the same way as Database Explorer.
+  - Every path a client sends is resolved to a real, `ABSPATH`-contained
+    path via `realpath()` before any filesystem operation — containment
+    is checked against the resolved path, not string-matched against the
+    raw input, so symlink tricks and encoded traversal can't slip past.
+  - Uploads/new files/renames all reject a blocklist of server-executable
+    extensions (`.php`, `.phtml`, `.cgi`, `.sh`, etc.) — the single most
+    important control here, since uploading a webshell is the whole ballgame.
+  - Deliberately not built: zip/unzip (zip-slip extraction vulnerability),
+    chmod/permissions editing, and cross-directory move/copy — each is a
+    meaningfully larger, riskier scope than a first pass warrants.
+
+### Fixed
+- File Manager's REST endpoints now also check
+  `License::is_feature_available('file-manager')`, not just
+  `manage_options` — found while wiring it up that the page-level lock
+  alone doesn't stop a direct REST call from bypassing it entirely.
+  **The same gap exists in Database Explorer, Role Editor, and Activity
+  Log's REST controllers and is not yet fixed** — flagged as a follow-up.
+
+## [2.6.0] - 2026-07-05
+
+### Added
+- Real replacement pages for Pages, Media Library, and Users — the
+  remaining native admin screens that were only dark-themed skinning,
+  now built the same way as Posts/Comments/Plugins (own REST controller,
+  own Vue page, native screen redirected away):
+  - **Pages** (`PagesData.php` + `Pages.vue`): same as Posts, but shows
+    the parent page instead of categories. `edit.php?post_type=page`
+    redirects; other post types are untouched.
+  - **Media Library** (`MediaData.php` + `Media.vue`): a thumbnail grid
+    (not a rebuilt drag-drop uploader) with type filters (Images/Audio/
+    Video/Documents/Unattached), search, and delete. `upload.php`
+    (both grid and list mode) redirects; `media-new.php` (the actual
+    upload screen) is untouched, same reasoning as leaving the block
+    editor alone for Posts/Pages.
+  - **Users** (`UsersData.php` + `Users.vue`): filterable by role, with
+    edit/delete actions. Deleting a user always reassigns their content
+    to whoever performs the deletion, rather than exposing WP core's
+    reassign-or-delete-everything choice as a one-click REST action —
+    deliberately simplified to avoid a surprising, highly destructive
+    default. `users.php` redirects; `user-new.php` (account creation)
+    is untouched.
+  - All four gated by their own Settings toggle (`modern_pages`,
+    `modern_media`, `modern_users` — `modern_posts` already existed),
+    each defaulting to on.
+
+## [2.5.0] - 2026-07-05
+
+### Added
+- Real replacement Posts management page (`aurora-admin-posts`), the same
+  kind of full custom page as Comments/Plugins rather than dark-themed
+  skinning over the native `edit.php` list table. New `PostsData.php` REST
+  controller (list with status/search filters, trash, restore, permanent
+  delete) and a new Vue page matching the Comments layout (status filter
+  pills, search, table with title/author/categories/comments/date/status,
+  inline row actions, pagination). The native Posts screen (`edit.php`,
+  default post type only — Pages and other post types are untouched)
+  redirects to it, gated by Settings > Posts' restored "Modern posts
+  table" toggle (removed a few commits ago when it had no implementation
+  behind it — now it does).
+
+### Fixed
+- The `modern_plugins`/`modern_comments` settings toggles now default to
+  visually "on" in the Settings UI to match their actual PHP default
+  (previously they defaulted true server-side but showed off in the UI
+  until explicitly saved) — same fix applied to the new `modern_posts`.
+
+## [2.4.2] - 2026-07-04
+
+### Fixed
+- Admin Notices only ever showed on the Aurora Dashboard — everywhere
+  else, `admin_notices` fired normally, but on the Dashboard specifically
+  the notice was invisible: `DashboardTakeover` hides `#wpbody` entirely
+  there (to hide the *native* dashboard, not our own), and that's exactly
+  where WordPress prints `admin_notices` output. Notices now render
+  directly inside the Aurora dashboard frame instead on that one page.
+  Along the way, also worked around a separate WordPress core behavior
+  (`common.js` unconditionally relocates every `.notice` element to right
+  after the page's `<h1>`) using core's own documented `below-h2` opt-out
+  class, since without it the notice would've just been silently moved
+  back into the hidden `#wpbody` by that script regardless of where it
+  was placed server-side.
+
+## [2.4.1] - 2026-07-04
+
+### Fixed
+- Dashboard scrolling was broken — content below the first ~1500px
+  (Server Health, Media Analytics, etc.) was completely unreachable.
+  `.aurora-dashboard-frame` never got the height cap + internal scroll
+  treatment `#wpbody-content` got in an earlier fix; combined with
+  `html`/`body` being locked to `overflow: hidden` (to fix a phantom
+  scrollbar on a different page), there was no scroll mechanism left at
+  all for the dashboard specifically. Mirrored the same
+  max-height/overflow-y treatment onto `.aurora-dashboard-frame`.
+
+## [2.4.0] - 2026-07-04
+
+### Added
+- Settings > Menu's "Menu search" toggle now actually does something —
+  previously had no implementation at all. Shows a real search box at the
+  top of the sidebar that filters both the WP-native menu list and the
+  Aurora nav section by title, auto-expanding every section with a match.
+
+### Fixed
+- Settings > Dashboard's "Custom dashboard" toggle now actually gates the
+  dashboard takeover — previously the Aurora dashboard always replaced the
+  native one regardless of this setting, with no way to turn it back off.
+- Settings > Plugins' "Modern plugins page" and Settings > Comments'
+  "Modern comments page" toggles now actually gate their respective
+  takeovers/redirects the same way — previously both ran unconditionally
+  regardless of these settings.
+
+### Removed
+- Settings > Posts' "Modern posts table" and Settings > Users' "Modern
+  users page" toggles — both described a custom management interface that
+  was never built. Shipping a checkbox with nothing behind it is worse
+  than not having the checkbox; removed rather than left as dead UI. Their
+  categories are removed too, since they had no other fields.
+
+## [2.3.1] - 2026-07-04
+
+### Fixed
+- Sidebar accordion now treats the "Aurora" branded nav section as part of
+  the same single-open accordion as the WP-native menu list, instead of
+  being the one exception that stayed open regardless of what else was
+  expanded. Expanding any native section now collapses Aurora too, and
+  vice versa.
+
+## [2.3.0] - 2026-07-04
+
+### Added
+- Settings > Media's "Allow SVG uploads" toggle now actually does
+  something — previously existed in the UI with no implementation behind
+  it, so every SVG upload was rejected. Fixes both of WordPress's default
+  blocks (the `upload_mimes` allowlist and the real-mime sniff that nulls
+  out the file type for SVGs specifically), plus a PHP warning
+  (`wp_get_missing_image_subsizes()` reading undefined `width`/`height`
+  metadata keys that SVGs never had) that could otherwise corrupt the
+  upload response on environments with warnings displayed inline. Also
+  does basic sanitization on upload (strips `<script>` tags, inline event
+  handler attributes, `javascript:` URIs) since SVG can carry executable
+  content.
+
+## [2.2.0] - 2026-07-04
+
+### Added
+- Settings > Login's "Style login page" and "Login logo" fields now
+  actually do something — previously they existed in the UI with no
+  implementation behind them at all. Styles `wp-login.php` with a dark
+  theme (background, card, inputs, button) and swaps in the configured
+  logo image in place of the WordPress logo, linked to the site's home
+  URL instead of wordpress.org.
+
+## [2.1.1] - 2026-07-04
+
+### Fixed
+- Image fields (Logo, Dark mode logo, Login logo, Admin favicon) now open
+  the real WordPress media library picker. `wp_enqueue_media()` was never
+  called, so `wp.media` was undefined client-side and every image field
+  silently fell back to a plain URL prompt instead.
+
+## [2.1.0] - 2026-07-04
+
+### Added
+- Free/paid feature gating: Role Editor, Activity Log, Database Explorer,
+  Analytics, White Label, and the remote site switcher are now Pro
+  features. Menu Creator, Admin Notices, Comments, Plugins, and the core
+  shell/theming stay free. Locked pages show an upgrade prompt instead of
+  the real feature; the sidebar shows a lock badge on locked items.
+- Real license validation against the `auroraplugins.com` license server
+  (validate/activate/deactivate), replacing the earlier placeholder that
+  treated any non-empty key as active. Status is cached for 12 hours and
+  re-checked immediately on a license-key change. The Settings page shows
+  a live status line (active/invalid/unreachable) under the License key
+  field.
+- File-integrity tamper protection: if the code implementing the license
+  gate has been modified, every paid feature re-locks regardless of an
+  otherwise-valid license — makes stripping the check out of a
+  redistributed copy not actually unlock anything.
+
+### Fixed
+- Role Editor's REST endpoint 500'd when hit via the REST API — it called
+  `get_editable_roles()`, which WordPress only auto-loads for normal
+  wp-admin page requests, not REST requests.
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 527b27b..c2b1a45 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,1293 +1,126 @@
 # Changelog
 
-All notable changes to Aurora Admin are documented here, one entry per
-version bump. Starts at 2.1.0 — earlier history (the theming rebuild,
-window chrome/taskbar, Site Editor support, etc.) lives in `git log` and
-`PROJECT_STATUS.md`, not reconstructed here.
+All notable changes to Aurora Admin, newest first — one entry per version
+bump. Versioning restarted at **1.0** on 2026-07-25 for the first public
+release; the earlier internal 3.x history is preserved in
+[`CHANGELOG-legacy.md`](CHANGELOG-legacy.md).
 
-## [3.6.1] - 2026-07-11
+## [1.12] — 2026-07-26
+
+### Added
+- **Disable Gutenberg** toggle (Settings > Screens > Editor, `admin/src/Editor/DisableGutenberg.php`): opt-in, off by default. Filters `use_block_editor_for_post_type` to fall back to WordPress core's own classic (meta-box/TinyMCE) post editor — the same core-supported mechanism the official Classic Editor plugin uses — rather than framing or rebuilding the block editor. The block editor remains one of the two deliberate "still native" exceptions in the admin takeover; this is an escape hatch around it, not a conversion of it.
+
+## [1.11] — 2026-07-26
 
 ### Fixed
-- **Second round of misplaced `phpcs:ignore` fixes**, found via another fresh Plugin Check report after 3.5.1's fix. Turns out `WordPress.DB.DirectDatabaseQuery.DirectQuery`/`NoCaching` and `WordPress.DB.PreparedSQL.NotPrepared`/`InterpolatedNotPrepared` are attributed by PHPCS to *different* lines within the same multi-line `$wpdb->get_results()`/`get_row()` call — `DirectQuery`/`NoCaching` to the outer call's opening line, `NotPrepared` to whichever inner line the interpolated table name physically appears on. 3.5.1's fix moved every ignore comment down to cover the inner line (fixing `NotPrepared`) but broke coverage of the outer line (`DirectQuery`/`NoCaching` came back) for four calls in `MenuCreatorData.php` and `Notices.php`/`NoticesData.php` that hadn't already been collapsed to a single line. Fixed by collapsing those four remaining multi-line calls too — consistent with the single-line-call pattern used everywhere else in the 3.5.1 fix, which a single ignore comment reliably covers regardless of which sniff PHPCS attributes to that line. Re-verified with the automated scan plus live REST-dispatch functional round-trips.
+- **Updates** (`update-core.php`) rendered available plugin/theme updates with unreadable white table rows in dark mode. Two stacked gaps: (1) this table is `class="widefat updates-table"`, not `.wp-list-table` — `native-dark.css` had zero coverage for `.widefat`, so it's now covered by the same generic table/td/th rules added for Export/Erase Personal Data in 1.10. (2) Even after that, the `<tr>` itself stayed white — traced to WP core's `list-tables.css`, which sets `.plugins tr { background: #fff; }` for the real native Plugins screen; both the plugin-update and theme-update tables reuse `<tbody class="plugins">`, so the plain class name collides and wins over the dark background. Fixed with a scoped `.plugins tr { background: transparent; }` override in `native-dark.css`. Verified live via an injected mock table matching update-core.php's real markup shape — both rows render fully dark and readable. Visual-only; update checking/installation stay entirely native.
 
-## [3.6.0] - 2026-07-11
+## [1.10] — 2026-07-26
+
+### Fixed
+- **Export Personal Data** and **Erase Personal Data** (the privacy/GDPR tools) rendered with unreadable white table rows — WordPress core sets an explicit white background directly on `<td>` elements (not just `<tr>`), which silently wins over `.wp-list-table`'s own dark background. This is a generic `WP_List_Table` gap, not specific to these two screens, so the fix (`native-dark.css`) applies broadly to any native list-table screen, not just these.
+- Per an explicit decision: these two screens' request queue, bulk actions, and the AJAX-driven export/erase processing (which runs every plugin's own registered `wp_privacy_personal_data_exporters`/`erasers` callbacks) stay entirely native — a subtly-wrong rebuild here has real compliance consequences, not just cosmetic ones, unlike Tools/Export/Import. Same "frame native content" treatment as Site Health.
+
+## [1.9] — 2026-07-26
 
 ### Changed
-- **Site Backup extracted into a standalone companion plugin,** at the
-  user's explicit request, following the same pattern as File Manager
-  (3.4.0) and Database Explorer (3.5.0) — proactive risk reduction, not a
-  WP.org rejection: restoring a backup means writing arbitrary files back
-  into the site, the same class of thing that's kept file-management
-  functionality out of Aurora Admin proper.
-  - The entire `admin/src/Backup/` tree (job/schedule storage, DB dumper,
-    file archiver, the state-machine engine, wp_cron safety net, and all
-    four storage providers — local, S3-compatible, Google Drive, plus the
-    provider interface/factory) and all four Backup REST controllers
-    moved, unmodified in behavior, into a brand-new sibling plugin:
-    **Aurora Site Backup** (`aurora-site-backup.php`, own bootstrap, own
-    REST namespace `aurora-site-backup/v1`, own Vite build). Since this
-    plugin needs its own settings storage independent of Aurora Admin
-    (S3 credentials, Google Drive OAuth tokens), a small standalone
-    `Options\Settings` class was added, backed by its own
-    `aurora_site_backup_settings` option — same minimal shape as Aurora
-    Admin's own Settings class, just a separate store.
-  - `CompanionPluginData.php`'s `PLUGINS` config array (already
-    generalized in 3.5.0) gained a `site-backup` entry — no new PHP
-    needed beyond the config line. The Settings → Add-ons screen now
-    lists all three companion plugins.
-  - Verified live via a full `rest_do_request()` dispatch: created a real
-    backup job, stepped it through the DB-dump phase, and canceled it —
-    end-to-end confirmation the extracted code still works, not just that
-    it loads without fatals.
-  - **Deployment gap, same as the other two companion plugins**: the
-    `aurora-site-backup.zip` is not yet hosted at
-    `https://aurora.auroradragon.studio/aurora-site-backup.zip` — the
-    Add-ons "Install & Activate" button for it will fail with a fetch
-    error until that's deployed (needs explicit go-ahead).
+- **Activity Log rebuilt** from a master-detail sidebar list into a full data table (Date, Author, IP Address, Type, Action, Description), matching a reference design. Two tabs — **Admin** (site/content activity) and **User** (account activity: login/logout/registration/profile updates) — filter via a new `scope` REST param (`object_type = 'user'` vs `!= 'user'`).
+- The Author column now shows the user's avatar, role, and a link to their profile, plus email — batch-fetched at query time from `user_id` rather than duplicated into every log row, so it always reflects the account's current role/email.
+- `object_type` for content events is now the post's real type (`post`/`page`/a custom post type) instead of a hardcoded `"post"` — Page edits now correctly show as "Page", not "Post".
+- `action_type` values unified to generic verbs (`created`/`updated`/`deleted`/etc.) reused across content types, instead of type-prefixed strings (`post_deleted`, `plugin_activated`, ...) — Type and Action are now cleanly orthogonal filterable columns. Pre-existing log rows keep their original values (no backfill).
 
-## [3.5.1] - 2026-07-11
+### Added
+- IP address capture (`REMOTE_ADDR` only — deliberately not trusting `X-Forwarded-For`, which is spoofable and this plugin has no way to know if a given host's proxy is trustworthy).
+- Logout tracking (`wp_logout`) and media upload/delete tracking (`add_attachment`/`delete_attachment`), both absent before.
 
 ### Fixed
-- **Misplaced `phpcs:ignore` comments from the 3.3.2 compliance pass, found via a fresh Plugin Check report.** WPCS's `phpcs:ignore` suppresses violations reported on the exact next physical line — but several annotations added in 3.3.2 sat above the *opening* line of a multi-line `$wpdb->get_results()`/`get_row()`/`get_var()` call (e.g. `$rows = $wpdb->get_results(`), while PHPCS actually attributes the violation to whichever line further down inside that call contains the interpolated table-name/column tokens. Those suppressions were silently never taking effect. Fixed across `MenuCreatorData.php`, `NoticesData.php`, `Notices.php`, `BackupSchedules.php`, `BackupJobs.php`, `MediaFolders.php` (the largest cluster — collapsed most multi-line query calls to a single physical line so one ignore comment reliably covers every sniff PHPCS reports on that line, added a `MediaFolders::name_taken()` helper to replace an inline `while()` condition that couldn't otherwise be annotated), `DbDumper.php`, `AnalyticsData.php`, and `MediaData.php`'s `post__not_in` VIP-advisory comment. Also added a genuinely missing annotation on `Analytics::record()`'s `$wpdb->insert()` call. Verified with an automated scan confirming every `$wpdb->` call with dynamic table/query construction is now immediately preceded by its ignore comment.
-- **Real bug found during verification, unrelated to Plugin Check**: `MenuCreatorData::create()` built its internal follow-up "fetch the row I just inserted" request as `new \WP_REST_Request("GET", "", ["id" => $wpdb->insert_id])` — but `WP_REST_Request`'s third constructor argument doesn't populate what `get_param()` reads, so `get_one()` always received a null id and returned "Menu not found" instead of the newly created menu. Confirmed via a full `rest_do_request()` dispatch (not just a direct function call) that this reproduced through the real REST route. Fixed by building the request with `set_url_params()`, WP core's own documented pattern for this.
-- Confirmed the `compressed_files`/`hidden_files`/`unexpected_markdown_file` findings in the Plugin Check report (build zips, `.gitignore`, `.claude/`, `PROJECT_STATUS.md`) are scanner noise from scanning the whole development repository, not the actual submission zip — verified via `unzip -l` that none of those paths exist in `wporg-submission/aurora-admin.zip`.
+- Login and self-registration events were recorded as done by "System" instead of the actual user. Root cause: `wp_get_current_user()` isn't reliable at the moment either hook fires — `wp_login` fires from inside `wp_signon()`, before the caller sets the current user, and a self-registering visitor isn't authenticated yet at `user_register` time (confirmed via WP core source, not a guess). Both hooks already receive the right user identity as a parameter for exactly this reason; `record()` now accepts an explicit actor override, used by both.
 
-## [3.5.0] - 2026-07-11
+## [1.8] — 2026-07-25
+
+### Added
+- **Full admin takeover**: the Import screen (`import.php`) is now a real Aurora-built replacement via `ScreenHijack`, gated behind `full_admin_takeover`. Only the listing/install page is rebuilt — running an already-active importer still opens `admin.php?import={id}`, a screen entirely owned and rendered by whichever third-party importer plugin registered that id, which is unpredictable, arbitrary UI outside this hijack's scope and stays native (same category as the block editor).
+- Install/activate reuses two already-proven mechanisms instead of new logic: WordPress core's own `admin-ajax.php?action=install-plugin` (the exact request native's "Install Now" button triggers) for installing, and Aurora's own `aurora-admin/v1/plugins/activate` route for activation. Any third-party output hooked to `import_filters` is captured and re-rendered, same as Tools' `tool_box` handling.
+
+### Fixed
+- `get_importers()` returns `null` (not an empty array) until something has actually called `register_importer()` — true on any site with no active importer plugins, including this dev site. Native `import.php` never hits this directly (it only reads the result via `isset()`, and by the time it ever `foreach`es, PHP has already auto-vivified the variable into an array via an earlier assignment) — but this code `foreach`es the raw result directly and needed its own explicit `is_array()` guard. Reproduced live, fixed, verified clean.
+
+## [1.7] — 2026-07-25
+
+### Added
+- **Full admin takeover**: the Export screen (`export.php`) is now a real Aurora-built form via `ScreenHijack`, gated behind `full_admin_takeover`. Safe to fully rebuild (unlike Tools/Site Health): the actual `?download=true` file-generation request calls `export_wp()` and `die()`s before ever reaching `in_admin_header`/`admin_footer` (the hooks the hijack's buffering relies on), so it's never touched by the hijack — Aurora's form submits via a real browser navigation to that same URL, and the resulting WXR file is byte-for-byte what core would have produced.
+
+### Fixed
+- The form initially only sent non-empty filter params, but native `export.php` reads `$_GET['cat']` etc. directly with no `isset()` guard — omitting a param when "All" was selected triggered PHP "Undefined array key" warnings that get echoed straight into the downloaded file (verified: with `display_errors` on, this corrupted the XML with warning HTML before the `<?xml` declaration). Fixed by always sending every relevant param for the selected content type, matching native's own `<select>`-based form exactly. Verified live across All content/Posts/Pages/Media — clean output, no warnings, in all four cases.
+
+## [1.6] — 2026-07-25
+
+### Fixed
+- **Site Health** (`site-health.php`) rendered with unreadable text — three of its own elements (`.health-check-header`, `.health-check-accordion-trigger`, `.health-check-accordion-panel`) painted a hardcoded white/off-white background that the generic dark-text cascade didn't reach, leaving light text against a light background (the same pattern already fixed for the block editor's "boot-layout" panels). Fixed in `native-dark.css`.
+- Deliberately did **not** rebuild Site Health's own test logic: its Status tab hits WordPress core's own `/wp-site-health/v1/tests/*` REST routes, and third-party plugins can add their own checks via the `site_status_tests` filter — reproducing that risked both drifting from core and silently dropping other plugins' checks. Frame and theming are Aurora's; the tests themselves stay WordPress core's, same "frame native content" treatment as the Gutenberg editor.
+
+## [1.5] — 2026-07-25
+
+### Added
+- **Full admin takeover**: the Tools screen (Available Tools, `tools.php`) is now a real Aurora-built replacement via `ScreenHijack`, gated behind `full_admin_takeover` like the other takeover screens.
+- Core's "Categories and Tags Converter" card — which turned out to be hardcoded in `tools.php`'s own template rather than produced by the `tool_box` hook — is reproduced with the identical capability gate (`import` + category/tag `manage_terms`) so visibility exactly matches native behavior.
+- Any card another active plugin adds via the genuine `tool_box` hook is still captured and displayed, styled to match — Aurora owns the page shell, not third-party hook content, so nothing another plugin adds to this screen silently disappears.
+
+## [1.4] — 2026-07-25
+
+### Added
+- **Login Redirect** (Settings > Appearance > Login Redirect): two opt-in, off-by-default redirects — send logged-out wp-admin visitors to a custom URL instead of the login screen (`init`-time guard, correctly scoped around admin-ajax.php/admin-post.php/REST/cron/network-admin so nothing else breaks), and send specific roles to a custom URL after logging in instead of the dashboard (standard `login_redirect` filter). Deliberately does not touch wp-login.php itself — hiding/changing the login URL is a separate, higher-risk feature not implemented here.
+- Verified live: a logged-out request to `/wp-admin/` correctly lands on the configured URL when enabled, and falls back to normal WordPress behavior when disabled. The after-login role redirect was verified by code review (the standard `login_redirect` filter pattern) rather than a live browser login, to avoid overwriting the tester's authenticated session cookies.
+
+## [1.3] — 2026-07-25
+
+### Added
+- New **Modules** page (Aurora sidebar): an addon marketplace for Aurora's standalone companion plugins (File Manager, Database Explorer, Site Backup), each installable and activatable with one click. This is now the primary entry point for installing Aurora addons, including future ones as they're released.
 
 ### Changed
-- **Database Explorer extracted into a standalone companion plugin,** for
-  the same reason and following the exact same pattern as File Manager
-  in 3.4.0: direct database-query tooling (browsing tables, running
-  free-form SELECT/SHOW/DESCRIBE/EXPLAIN queries from wp-admin) is
-  treated by WordPress.org's Plugin Directory review the same way as
-  file-management functionality — outside what it accepts in a
-  directory-listed plugin. Rather than wait for a rejection to confirm
-  it or delete the feature outright:
-  - `admin/src/DatabaseExplorer/DatabaseExplorerData.php` and its Vue
-    UI (plus the shared `AppListShell`/`AppListItem` list-detail layout
-    it's built on) moved, unmodified in behavior, into a brand-new
-    sibling plugin: **Aurora Database Explorer**
-    (`aurora-database-explorer.php`, own bootstrap, own REST namespace
-    `aurora-database-explorer/v1`, own Vite build). Works completely
-    standalone, verified live via direct HTTP request with a
-    server-generated auth cookie — the admin page renders its mount
-    div and enqueued script correctly, and the REST namespace is
-    registered and reachable.
-  - `CompanionPluginData.php` was generalized from a single
-    file-manager-only class into a small `PLUGINS` config array keyed
-    by slug, so both File Manager and Database Explorer (and any future
-    companion plugin) share the same install/activate/status REST
-    routes and `Plugin_Upgrader`-based installer logic — adding a new
-    companion plugin going forward is a config entry, not new PHP.
-  - The **Settings → Add-ons** screen now lists both companion plugins.
-  - **Deployment gap, same as File Manager**: the Database Explorer zip
-    is not yet hosted at
-    `https://aurora.auroradragon.studio/aurora-database-explorer.zip` —
-    the Add-ons "Install & Activate" button for it will fail with a
-    fetch error until that's deployed (needs explicit go-ahead, same as
-    any other production deploy).
+- Settings' "Add-ons" category has been removed — its install cards moved to the new Modules page.
 
-## [3.4.0] - 2026-07-11
+## [1.2] — 2026-07-25
+
+### Fixed
+- Menu Creator was effectively non-functional: its item list was **always empty**, because it fetched the menu over REST where WordPress doesn't build the admin `$menu`. The raw top-level menu is now captured at page load and passed via the page's `serverData`, so the editor actually shows the items.
+
+### Added
+- Menu Creator: **reordering now works.** The item list is drag-to-reorder (with up/down buttons as a fallback), and the saved order is applied to Aurora's sidebar by `MenuSerializer`. Items the config doesn't mention — separators and newly installed plugins' menu items — are preserved after the ordered ones, so nothing disappears.
 
 ### Changed
-- **File Manager extracted into a standalone companion plugin.** WordPress.org's
-  second review response was unambiguous: the entire category of
-  file-management/code-editing functionality isn't accepted into the
-  Plugin Directory, regardless of the restrictions added in v3.2.1 —
-  the feature had to come out of Aurora Admin entirely for the
-  submission to be reconsidered. Rather than delete the functionality:
-  - `admin/src/FileManager/FileManagerData.php` and its three Vue
-    components moved, unmodified in behavior, into a brand-new sibling
-    plugin: **Aurora File Manager** (`aurora-file-manager.php`, own
-    bootstrap, own REST namespace `aurora-file-manager/v1`, own Vite
-    build). It works completely standalone — verified live with Aurora
-    Admin fully deactivated.
-  - The Theme Editor → File Manager redirect (`AppearancePages.php`) is
-    gone; visits to `theme-editor.php` now fall through to WordPress
-    core's own Theme Editor unmodified, which already respects
-    `DISALLOW_FILE_EDIT` itself.
-  - A new **Settings → Add-ons** screen offers one-click installation of
-    Aurora File Manager, wrapping `Plugin_Upgrader::install()` — the
-    same core API the native Plugins → Add New "Install Now" button
-    uses — pointed at a fixed, non-client-supplied HTTPS zip URL. No
-    settings/data are shared between the two plugins; Aurora Admin has
-    zero remaining code that touches the filesystem beyond its own
-    Site Backup archives.
+- Menu Creator now edits top-level items only; the previous submenu rows were removed because submenu hide/rename was never actually applied (a clean future addition).
 
-## [3.3.2] - 2026-07-11
+## [1.1] — 2026-07-25
 
 ### Fixed
-- **WordPress.org Plugin Check compliance pass** — a full re-run of the
-  official Plugin Check tool against the whole codebase (279 findings
-  across 26 files) surfaced several real gaps beyond the earlier v3.0.1/
-  v3.0.2/v3.2.1 passes, all now fixed:
-  - `readme.txt`'s `Stable tag` had drifted to 3.2.1 while the plugin
-    itself moved through 3.3.0/3.3.1 — a real mismatch that can prevent
-    WordPress.org from serving the correct download to users. Now kept
-    in lockstep with every version bump.
-  - `Analytics::country()` read `$_SERVER[$h]` directly for an
-    `empty()`/`strlen()` check before the existing sanitized copy was
-    computed — fixed by sanitizing once up front and using that
-    everywhere, rather than touching the raw superglobal at all.
-  - `AuroraAdmin.php`'s `defined("ABSPATH") || exit()` guard sat after
-    49 `use` import statements — functionally fine, but far enough into
-    the file that at least one automated file-access-protection scanner
-    didn't detect it. Moved to immediately after the `namespace`
-    declaration, this file's one deliberate departure from the rest of
-    the codebase's "guard after imports" convention.
-  - Roughly 230 `WordPress.DB.DirectDatabaseQuery`/`PreparedSQL`/
-    `UnescapedDBParameter` findings across every custom-table feature
-    (Site Backup, Media Folders, Activity Log, Analytics, Menu Creator,
-    Notices, Database Explorer) — verified each one is safe (internal
-    `$wpdb->prefix`-based table names or already-validated/escaped
-    identifiers, never raw user input) and annotated with the justified
-    `phpcs:ignore` the review process expects, matching the standard
-    already established for Database Explorer's query runner.
-  - A handful of `fread()`/`fwrite()`/`fclose()` calls adjacent to an
-    already-annotated `fopen()` were still individually flagged — WPCS
-    suppression is strictly per-line, so each sibling call in Site
-    Backup's file/S3/Google Drive streaming code now has its own
-    annotation too.
-  - Several `RuntimeException` messages interpolating internal (never
-    user-supplied) values were flagged as unescaped output — annotated
-    as exception messages, not HTML/browser output, the same
-    false-positive class WPCS is known to flag on exception
-    constructors.
-
-## [3.3.1] - 2026-07-11
-
-### Fixed
-- **Settings page: nav and content now scroll independently.** Previously
-  the left category list and the right content panel scrolled together
-  as one long page — scrolling down the nav to reach a category near the
-  bottom (e.g. "Modern Image Formats") and clicking it left the content
-  panel's top scrolled out of view above the fold, requiring an extra
-  scroll back up to actually see it. Both panels now have their own
-  fixed-height scroll region, and switching categories resets the
-  content panel's scroll position to the top regardless of the nav's own
-  scroll position.
-
-## [3.3.0] - 2026-07-11
-
-### Added
-- **Modern Image Formats** — a new Settings section that automatically
-  generates a WebP or AVIF sibling for every size WordPress produces from
-  a newly uploaded JPEG/PNG, and (optionally) rewrites `<img>` markup
-  into a `<picture>` element offering the modern format with the original
-  as a fallback source. "Automatic" output format prefers AVIF, falling
-  back to WebP, based on what the server's image editor actually
-  supports (`wp_image_editor_supports()`) — gracefully generates nothing
-  on a host that supports neither, rather than erroring. Purely additive:
-  original JPEG/PNG files are always kept, nothing about the attachment's
-  own metadata or file is changed, and generated files are cleaned up
-  automatically when the attachment is deleted. Only affects new
-  uploads — existing library images need a regenerate-thumbnails-style
-  tool to pick up the feature.
-  - Built entirely on documented WordPress core hooks
-    (`wp_generate_attachment_metadata`, `delete_attachment`,
-    `wp_editor_set_quality`, `wp_content_img_tag`,
-    `wp_get_attachment_image_html`) and `WP_Image_Editor::save()`'s
-    documented mime-type-conversion parameter — no third-party plugin
-    code, no Composer dependency.
-  - Verified live end-to-end: uploaded a real JPEG, confirmed a smaller
-    AVIF sibling was generated and recorded in attachment metadata,
-    confirmed a post embedding the image rendered a correct
-    `<picture><source type="image/avif" srcset="...">` wrapper, and
-    confirmed both the original and generated files were removed with no
-    orphans left behind after deleting the attachment.
-
-## [3.2.1] - 2026-07-11
+- Plugins screen now re-syncs with the real backend state after activate/deactivate/delete, so a plugin no longer keeps showing "deactivated" when WordPress's `activate_plugin()` returns a benign "unexpected output" error even though the plugin did activate.
 
 ### Changed
-- **File Manager: PHP/executable editing removed.** Rejected from the
-  WordPress.org Plugin Directory because File Manager let a
-  `manage_options` user open and overwrite *existing* `.php` files
-  in-place with immediate execution effect — no different in risk from
-  WordPress core's own Theme/Plugin editor, which core lets hosts disable
-  via `DISALLOW_FILE_EDIT` specifically because of that risk. File Manager
-  previously blocked creating/uploading/renaming-to executable file
-  types, but that same list wasn't enforced on *editing an existing* file
-  of that type — closed now: opening or saving any file matching
-  `BLOCKED_EXTENSIONS` (php, phtml, cgi, py, sh, and others) is refused.
-  File Manager also now honors `DISALLOW_FILE_EDIT` (blocks all editing)
-  and `DISALLOW_FILE_MODS` (blocks all create/upload/rename/delete/copy/
-  move/write operations), the same host-level lockdown constants
-  WordPress core's own file-modification flows already respect. Browsing,
-  downloading, and viewing file info are unaffected.
-
-## [3.2.0] - 2026-07-11
-
-### Added
-- **Google Drive remote storage** for Site Backup — a second remote
-  storage option alongside S3-compatible, via OAuth 2.0. Each site
-  connects its own Google Cloud OAuth client (Client ID + Secret, pasted
-  into Settings) since a free, publicly-distributed plugin can't ship a
-  shared client secret; scope is the narrow `drive.file` (only
-  files/folders Aurora itself creates). Resumable upload and
-  `Range`-header chunked download against Drive API v3 mirror the
-  bounded-per-step design S3's multipart upload already established — no
-  changes to the job engine itself were needed, confirming the
-  storage-provider abstraction's original design goal. Shipped
-  code-complete and protocol-verified (request shapes checked against
-  Google's published API reference, and live-tested against Google's real
-  OAuth endpoints with placeholder credentials to confirm genuine API
-  errors come back); a full live "Connect" round-trip is left for the
-  user to verify once they have a real Google Cloud OAuth client and
-  HTTPS on the target site.
-
-## [3.1.0] - 2026-07-11
-
-### Added
-- **Site Backup** — a new free sub-app: full site backup (database +
-  wp-content) and restore-in-place, on-demand or on a recurring daily/
-  weekly/monthly schedule, storing archives locally or on any
-  S3-compatible remote (AWS S3, Backblaze B2, Cloudflare R2, DigitalOcean
-  Spaces — one implementation via a configurable endpoint, no vendor
-  SDK, SigV4 signing implemented directly and verified against AWS's own
-  published test vectors).
-  - Built on a new resumable job-processing engine (`BackupEngine` +
-    `BackupJobs`) — the first background-job infrastructure in this
-    codebase. Every backup/restore step is bounded (row/file/byte count
-    and a wall-clock budget) so a multi-GB site never risks a single
-    request's timeout or memory limit. Two trigger paths converge on the
-    same step function: foreground polling from the Vue UI (fast
-    feedback while a tab is open) and a `wp_cron` safety net
-    (`BackupCron`) that keeps a job moving with no browser involved —
-    closing the tab mid-backup, or a scheduled backup with nobody
-    watching, both still reach completion.
-  - Database export/import (`DbDumper`) — paginated dump with schema
-    captured per-table (`DROP TABLE IF EXISTS` + `CREATE TABLE`, so
-    restore is deterministic and re-runnable from scratch), chunked
-    restore via a byte-cursor into the dump file. Aurora's own
-    backup-tracking tables are excluded from what gets backed up — a real
-    bug caught during testing, where restoring a snapshot of those tables
-    was overwriting the very job row driving the restore mid-flight.
-  - File archiving (`FileArchiver`) — a manifest of every file under
-    `wp-content/` (excluding the backup storage directory itself and,
-    structurally, `wp-config.php`, which lives outside `wp-content/`
-    entirely), zipped/extracted in bounded batches via `ZipArchive`,
-    reopened and appended to across isolated requests. Every extracted
-    entry is containment-checked (zip-slip protection) before anything is
-    written — verified live with a deliberately crafted malicious archive
-    entry, confirmed rejected.
-  - Local storage hardening — `wp-content/uploads/aurora-backups/` gets
-    WordPress core's own `index.php`/`.htaccess` stub pair; the real
-    protection is that every archive read goes through a
-    `manage_options`-gated REST route streaming the file through PHP,
-    never a guessable direct URL.
-  - Recurring schedules with count-based retention — a scheduled backup
-    prunes older ones (both the job row and its stored archive, local or
-    remote) down to the schedule's configured retention count.
-  - v1 deliberately does not include cross-domain migration (Duplicator's
-    own headline feature — generating an `installer.php` for a totally
-    different host) or restoring from an arbitrary uploaded archive
-    (restore only ever sources from Aurora's own backup history) — both
-    are real scope/risk decisions, not oversights.
-- Live-verified end-to-end on the dev site, including catching and fixing
-  two real bugs along the way: a job's `phase` column wasn't updated to
-  a clean terminal value on completion (stale "Archiving files…" label
-  after a backup had actually finished), and a data-corruption bug where
-  manually pre-escaping newlines before `$wpdb->_real_escape()` (which
-  already does this) caused restored text fields to contain literal
-  backslash-n characters instead of real line breaks.
-
-## [3.0.2] - 2026-07-11
-
-### Fixed
-- Plugin header validation error from the WordPress.org submission checker:
-  `Plugin URI` and `Author URI` were both `https://auroradragon.studio`,
-  and WP.org requires them to be distinct (one identifies the plugin, the
-  other the author). `Plugin URI` now points to
-  `https://aurora.auroradragon.studio` (the plugin's own marketing site);
-  `Author URI` stays on the studio's root site.
-
-## [3.0.1] - 2026-07-11
-
-### Fixed
-- **WordPress.org Plugin Check compliance pass.** Ran the official Plugin
-  Check tool ahead of submission and fixed every real issue it surfaced
-  (257 flagged items, several dozen real):
-  - `WidgetsData.php`: replaced the forbidden `wp_get_sidebars_widgets()`
-    (internal-only core function) with a local helper reading the
-    `sidebars_widgets` option directly.
-  - `FileManagerData.php`: converted every raw filesystem call
-    (`move_uploaded_file()`, `mkdir()`, `rename()`, `unlink()`, `rmdir()`,
-    `is_writable()`, `readfile()`) to the `WP_Filesystem` API, which works
-    across hosting setups that don't allow direct filesystem access.
-    `move_uploaded_file()`'s upload-tampering check is preserved via an
-    explicit `is_uploaded_file()` call before handing off to
-    `WP_Filesystem::move()`.
-  - `BugReportData.php`: `parse_url()` → `wp_parse_url()`.
-  - `SubApps.php`: fixed a translation-function rule violation (page
-    titles now wrapped in `__()` at definition instead of being passed as
-    a variable to `__()` at the call site) and added justified
-    nonce-check suppressions on two read-only routing checks.
-  - Fixed missing `wp_unslash()`/sanitization on a handful of superglobal
-    reads (`Analytics.php`, `Shell.php`, `AnalyticsData.php`) and added
-    missing translator comments for two placeholder strings.
-  - Annotated dynamic-table-name SQL queries across `MediaFolders.php`,
-    `AnalyticsData.php`, `DatabaseExplorerData.php`, `NoticesData.php`,
-    `MenuCreatorData.php`, and `ActivityLogData.php` with justified
-    `phpcs:ignore` comments — every flagged table name comes from an
-    internal `$wpdb->prefix`-based helper, never user input, and table
-    identifiers can't go through `$wpdb->prepare()`'s value placeholders
-    (WordPress core has no API for arbitrary custom tables).
-  - Removed the stale `Domain Path: /languages/` plugin header (pointed
-    at a folder that's never existed — see 2.x-era removal of the fake
-    "13 languages" marketing claim).
-  - All changes live-verified against the LocalWP install: File Manager's
-    full create/rename/delete cycle exercised directly against the REST
-    routes (folder create, file create, rename, soft-delete, empty
-    trash), Widgets' sidebar-read endpoint, Database Explorer's table
-    browsing, and Media Folders' filtered listing all confirmed working
-    with zero console/PHP errors.
-
-## [3.0.0] - 2026-07-06
-
-### Removed
-- **The entire licensing/monetization system.** Aurora Admin is being given
-  away free on the WordPress.org plugin repository — every feature
-  previously gated behind a paid license (Role Editor, Activity Log,
-  Database Explorer, File Manager, Analytics, White Label, Full Admin
-  Takeover, Media Folders) is now simply available to everyone, no key
-  required.
-  - Deleted `admin/src/Licensing/` entirely (`License.php`, `Integrity.php`,
-    the file-tamper-detection system that only existed to protect license
-    gating from bypass) and `bin/build-integrity-manifest.php`.
-  - Deleted the "Pro feature" upgrade-prompt UI (`UpgradeNotice.vue`,
-    `locked-feature.js`) and every lock badge in the sidebar.
-  - Removed the License key field and the dev-only "Simulate active
-    license" toggle from Settings — there's nothing left to license or
-    simulate.
-  - `license_key` and `dev_license_override` are actively purged from any
-    site's stored settings on upgrade (same cleanup pattern used for the
-    earlier Remote Site Switcher removal), not just hidden from the UI.
-  - Report a Bug still works, now via a direct call to the feedback
-    endpoint instead of going through the license-status layer.
-  - This is a clean split from the commercial `auroraplugins.com` service
-    (beta licenses, Pro purchases) — that server-side system is untouched
-    and unaffected by this change, it's simply no longer wired into this
-    codebase.
-
-## [2.27.0] - 2026-07-06
-
-### Added
-- Restored the dev-only license override (`AURORA_ADMIN_DEV_MODE` wp-config.php
-  constant + Settings > Developer > "Simulate active license" toggle),
-  reversing the 2.25.0 removal. Requested explicitly for local testing on
-  admin.local — lets Pro features be exercised without a real license key.
-  **This must be stripped again before the next release/beta build** — same
-  standing rule as before, now re-documented in `PROJECT_STATUS.md`. Only
-  has any effect when `AURORA_ADMIN_DEV_MODE` is defined truthy in a given
-  install's own `wp-config.php`, never set in the repo or any built zip.
-
-## [2.26.0] - 2026-07-05
-
-### Added
-- "Report a Bug" page (Aurora sidebar section), a real WordPress admin page
-  (`aurora-admin-bug-report`, registered via `SubApps.php` like Menu
-  Creator/Admin Notices) with a single free-text field plus auto-filled,
-  read-only diagnostics (plugin version, WordPress version, PHP version,
-  active theme, last 4 characters of the license key — not the full key).
-  Submits to a new `POST aurora-admin/v1/bug-report` REST route
-  (`admin/src/Rest/BugReportData.php`), which forwards to a new
-  `License::submit_bug_report()` method that calls the license server.
-  - **License server** (`aurora-licensing` plugin, not this repo): added a
-    `wp_aurora_bug_reports` table (DB version 3 → 4, same version-gated
-    migration idiom) and a new public `POST /report-bug` REST route,
-    storing the description plus whatever license key/domain/diagnostics
-    fields were sent. Deliberately a plain `wpdb->insert` with no admin UI
-    yet — reports are reviewable via `wp db query` for now; a dashboard can
-    come later if report volume justifies it.
-  - Verified live end-to-end (not mocked): submitted a real report through
-    the actual Report a Bug page, confirmed it landed correctly in
-    `wp_aurora_bug_reports` on the production server, then deleted the two
-    test rows (one from an earlier curl smoke test) by exact ID.
-
-## [2.25.0] - 2026-07-05
-
-### Removed
-- Dev-mode license override (`AURORA_ADMIN_DEV_MODE` wp-config.php constant,
-  Settings > Developer category's toggle, and every call-site in
-  `License::is_active()`/`is_feature_available()`) — this was a
-  build-time-only escape hatch for testing paid features without a live
-  license, marked in `PROJECT_STATUS.md` as "MUST BE REMOVED BEFORE A
-  RELEASE BUILD" since it shipped in the plugin zip. Real beta testers are
-  about to install real builds, so it had to go before that zip goes out.
-  Paid features now gate purely on `License::is_active()` for everyone,
-  no exceptions.
-
-## [2.24.0] - 2026-07-05
-
-### Added
-- Beta tester license support, end to end. User asked for 10 new 30-day
-  beta licenses plus a way to flag/display beta status in the plugin.
-  - **License server** (`aurora-licensing` plugin on the live
-    `auroraplugins.com` box, not this repo): added an `is_beta` column to
-    `wp_aurora_licenses` (migrated in place via a `plugins_loaded`-hooked
-    check, since the file was updated without re-activation — same
-    version-gated migration idiom this plugin's own `ActivityLog.php`
-    etc. use), a `wp aurora-lic generate-beta <count> [--days=<n>]
-    [--max-sites=<n>]` WP-CLI command (not a public REST route —
-    generating free licenses has to stay admin/shell-only), and `is_beta`
-    added to `/validate` and `/activate`'s response payloads. Generated
-    the 10 requested keys (30-day expiry, 1 site each) — see the
-    conversation for the actual key list; not duplicated here since this
-    file ships to customers.
-  - **Client** (this plugin): `License::is_beta_tester()` reads the
-    server's `is_beta` flag (already flowing through the existing
-    `status()` cache — no new caching logic needed). Settings > General's
-    license status line now shows "Beta Tester license active — expires
-    in N days (date)" instead of the normal "License active (plan)" text
-    when a beta key is active. A beta license is a real, fully-functional
-    `is_active()` license like any other — this is a display flag only,
-    not a separate gating path.
-  - Verified against the real production license server, not a mock:
-    generated a real key via the new CLI command, activated it from the
-    dev site's actual Settings page, confirmed the badge and expiry
-    countdown render correctly, then cleared the key (deactivating it
-    server-side via the existing `on_settings_updated` flow).
-
-## [2.23.0] - 2026-07-05
-
-### Added
-- Full field-set parity for Writing/Reading/Discussion native Settings
-  screens, closing the gap flagged in 2.22.0's audit.
-  - **Writing**: `Default Post Category` and `Default Post Format` are now
-    real dropdowns (populated from `get_categories()`/
-    `get_post_format_strings()`) instead of raw numeric IDs. Added
-    `use_smilies` — registered in core's own REST settings schema but
-    never actually added to this screen.
-  - **Reading**: `Homepage`/`Posts Page` are now page-title dropdowns
-    (via `get_pages()`) instead of raw page IDs, and only appear once
-    "Homepage Displays" is set to "A static page" — matching native
-    WordPress's own conditional reveal. New generic `showIf` field
-    property in `NativeSettings.vue` (`{key, equals}`) drives this,
-    reusable by any future field.
-  - **Discussion**: went from 2 fields to full native parity (~24 fields:
-    pingback/comment defaults, moderation rules, threaded-comment
-    settings, pagination, three notification-email toggles, comment
-    moderation/disallowed-keys blocklists, and avatar settings). Core's
-    REST settings schema (`register_initial_settings()`) only ever
-    exposed 2 of Discussion's real options — everything else needed a new
-    dedicated controller, `DiscussionData.php`, doing raw `get_option()`/
-    `update_option()` reads/writes against an explicit key allowlist (same
-    pattern as `PermalinksData.php`, generalized to many keys instead of
-    one).
-  - New `textarea` field type in `SettingsField.vue` for the two
-    moderation-keys blocklist fields (multi-line plain text — nothing
-    else on any settings screen needed one until now).
-  - Verified live: dropdowns populate with real data, conditional fields
-    show/hide correctly, and a real save-then-reload round trip on
-    Discussion (toggled a setting off, saved, reloaded fresh, confirmed
-    the change persisted) — not just an optimistic-UI check.
-
-## [2.22.0] - 2026-07-05
-
-Full plugin audit, requested after the plugin-delete crash raised the
-question of what else might be broken or incomplete. Checked every
-sidebar screen live (console + PHP error log at each stop), re-verified
-the license-activation claim from last session against the actual code,
-and closed the one remaining documented security gap.
-
-### Fixed
-- **REST-bypass gap closed for Role Editor, Activity Log, and Database
-  Explorer** — their REST controllers only checked
-  `current_user_can('manage_options')`, not the license, so a direct REST
-  call could reach paid functionality (including Database Explorer's raw
-  SQL runner) with no license at all. Same fix already applied to File
-  Manager/Media Folders earlier this session, just never circled back for
-  these three. Verified every other paid-feature REST controller (Themes,
-  Nav Menus, Widgets, Permalinks, Analytics, White Label) already had the
-  check — this was the last of them.
-- **Permalinks screen was missing the standard structure presets** (Plain,
-  Day and name, Month and name, Numeric, Post name) — only the raw
-  "Custom Structure" text field existed, which is the one part of that
-  screen almost nobody actually uses by hand. Added the five presets as
-  radio options with live example URLs, auto-detecting which preset (or
-  "Custom") matches the currently-saved structure.
-
-### Verified (no changes needed)
-- Clicked through Dashboard, Posts, Pages, Media, Users, Comments,
-  Plugins, all Aurora sub-apps (Menu Creator, Admin Notices, Role Editor,
-  Activity Log, Database Explorer, File Manager), Media Upload, Add New
-  User, Profile, all 5 native Settings screens, and several Aurora
-  Settings categories (General, White Label, Analytics) — no fatals, no
-  new console errors anywhere in the pass.
-- Confirmed License.php's activation/validation flow is real (calls
-  `auroraplugins.com`'s REST API, caches with TTL, tamper-checks) —
-  corrected a stale "still a placeholder" claim from earlier this session
-  and removed the outdated doc line that caused it.
-
-### Known gaps (not fixed — flagged for a decision, not silently patched)
-- Writing/Reading/Discussion native Settings screens expose only a
-  handful of fields each, several as raw text/numeric-ID inputs where
-  native WordPress has dropdowns (post category, post format, homepage
-  page picker) — functional but poor UX, and Discussion in particular is
-  missing most of its native moderation options. Larger effort than the
-  Permalinks fix; needs new endpoints (categories list, post formats) and
-  new field types, not just a values tweak.
-- Comments list's pagination footer shows "0 to 0 of 0" despite the "All"
-  tab correctly showing a count — cosmetic, not investigated further.
-
-## [2.21.2] - 2026-07-05
-
-### Fixed
-- Deleting a plugin from Aurora's Plugins page ("major issue" per user
-  report) fataled the whole site with WordPress's generic "There has been
-  a critical error" page instead of actually deleting anything. Root
-  cause, found in the PHP error log: `PluginsData::delete_plugin()` called
-  core's `delete_plugins()`, which internally calls
-  `request_filesystem_credentials()` (WP_Filesystem setup) — that function
-  lives in `wp-admin/includes/file.php`, which a REST API request doesn't
-  load the way a normal wp-admin page load does, and `delete_plugin()`
-  only required `plugin.php`. `update_plugin()` right below it already
-  required `file.php` for the same underlying reason; `delete_plugin()`
-  just never got the same fix. Verified live: deleted a real plugin
-  (WP File Manager) end to end with no fatal, "Plugin deleted." message
-  shown correctly, confirmed no new error logged.
-
-## [2.21.1] - 2026-07-05
-
-### Fixed
-- Sidebar section accordion closed the wrong section on "hidden child"
-  native screens (theme-install.php, media-new.php, user-new.php, ...).
-  User: expand Appearance, click "Add New Theme", and the Appearance
-  section collapsed while the "AURORA" section at the bottom opened
-  instead — this was a different bug than the overlay-covers-the-sidebar
-  issue fixed in 2.21.0, this was specifically about which section stays
-  expanded. Root cause: `Sidebar.vue`'s accordion decides the open section
-  by matching the current URL against each menu item's own submenu array
-  (`MenuSerializer::serialize()`, scraped from WP's `$submenu` global) —
-  but these screens are deliberately absent from `$submenu` (WP's own
-  native left menu doesn't list "Add New Theme" as a link either, only
-  "Themes"/"Customize"/"Editor"), so no section ever matched and the
-  accordion fell through to its Aurora-expanded default.
-  - WP core itself solves this exact problem for its own native menu
-    highlighting via a `$parent_file` global, set directly in each of
-    these pages' own PHP (`theme-install.php` sets
-    `$parent_file = 'themes.php'`, `media-new.php` sets `'upload.php'`,
-    `user-new.php` sets `'users.php'`) — reused that instead of
-    hardcoding a list of "hidden child screen" mappings ourselves.
-    `Shell::print_mount()` now reads it and passes it through as
-    `activeParentFile`; `Sidebar.vue`'s `isSectionActive()` treats a menu
-    item as active when its id matches, alongside the existing exact-URL
-    checks. General fix — covers any current or future WP core (or
-    third-party plugin) screen using this same convention, not just the
-    three confirmed here.
-
-## [2.21.0] - 2026-07-05
-
-### Changed
-- The theme-install.php "Preview & Install" overlay (clicking a theme card
-  under Appearance > Themes > Add New Theme) is now framed like the block
-  editor window instead of covering Aurora's sidebar/toolbar entirely.
-  User reported "it closes the menu" — confirmed this is WP core's own
-  native behavior (the fullscreen overlay covers the native admin menu
-  too, on a totally vanilla install), not a regression, but agreed a
-  framed treatment was worth the risk for visual consistency with how the
-  block editor is already handled.
-  - `.wp-full-overlay` (WP core's overlay component, shared with the
-    Customizer — only `.theme-install-overlay` specifically is touched,
-    not `.wp-full-overlay` generally) is reframed to Aurora's standard
-    inset box: the overlay itself plus its two independently
-    `position: fixed` children (`.wp-full-overlay-sidebar`,
-    `.wp-full-overlay-main`) each need the same left/top/bottom math
-    applied directly, since fixed descendants don't inherit an ancestor's
-    padding-box positioning the way absolutely-positioned ones do.
-    `margin-left` on `.expanded`/`.collapsed` mirrors WP core's own three
-    responsive breakpoints with Aurora's frame offset added on top, so the
-    sidebar collapse/expand slide animation keeps working unmodified.
-  - Root-caused and fixed two real bugs found while building this: (1)
-    opening the overlay adds `body.full-overlay-active`, and WP core's own
-    CSS sets `body.full-overlay-active { visibility: hidden }` with only
-    the overlay itself set back to visible — Aurora's entire shell
-    inherited that hidden visibility too (nested in body), which is what
-    silently erased the sidebar/toolbar instead of just having them
-    covered. Fixed with one override re-enabling visibility for Aurora's
-    own root specifically. (2) The overlay's own `height: 100%` (WP core)
-    combined with our `top`+`bottom` insets was the exact same
-    over-constrained-box bug already known from the block editor's
-    `.interface-interface-skeleton` — same `height: auto !important` fix.
-  - The traffic-light winbar needed a permanently-running `MutationObserver`
-    rather than a one-shot check: the overlay doesn't exist in the initial
-    DOM (WP core creates it lazily on first click), and every subsequent
-    theme selection fully re-renders the overlay's contents, wiping out
-    anything inserted into it — confirmed live (bar present after the
-    first click, gone after picking a second theme) before switching to an
-    idempotent "ensure inserted" observer callback.
-  - Verified live end-to-end: opening via natural clicks (not just direct
-    URL navigation), switching between themes with the prev/next arrows
-    (triggers the content-destroying re-render), closing and confirming
-    the sidebar/toolbar return correctly, no console errors at any step.
-
-## [2.20.2] - 2026-07-05
-
-### Fixed
-- Appearance > Themes was missing two capabilities the native Themes
-  screen has: browsing/installing themes from the WordPress.org directory,
-  and uploading a theme zip. `AppearancePages.php`'s `load-themes.php`
-  hijack never passed a link to `theme-install.php` (only `customizeUrl`),
-  so there was no way to reach either from Aurora's Themes page.
-  `Themes.vue` gains an "Add New Theme" button (next to Customize) linking
-  to native `theme-install.php`, gated on `current_user_can('install_themes')`
-  — that native screen already has both the WordPress.org browser (Popular/
-  Latest/Block Themes/Favorites/Feature Filter tabs, search) and an
-  "Upload Theme" button built in, so neither needed rebuilding. Same
-  reuse-native-flow-for-add pattern already used for Plugins' `addUrl`
-  (`plugin-install.php`) and Media's `newMediaUrl` (`media-new.php`).
-
-## [2.20.1] - 2026-07-05
-
-### Fixed
-- Font Library (`font-library.php`) rendered with a jarring mix of Aurora's
-  dark frame around a completely white, near-unreadable content area (light
-  text on a white card). WP 6.5+ built this screen on `@wordpress/
-  components`' newer "boot-layout" primitives instead of classic postbox
-  markup, so `native-dark.css`'s existing postbox/card rules never matched
-  its DOM. Added targeted dark-theme coverage for the screen's stable,
-  hand-authored class names (`.boot-layout-container`, `.boot-layout__stage`,
-  `.admin-ui-page`, `.admin-ui-navigable-region`, `.admin-ui-page__header`,
-  `.font-library-page__tab-panel`, `.font-library__tabpanel-layout`,
-  `.font-library__footer`, `.font-library__fonts-list-item`,
-  `.font-library__font-card`) — deliberately not touching this screen's
-  Emotion-generated hash classes (e.g. `css-qi2azi`), which aren't stable
-  across WP builds.
-- Regenerated `admin/src/Licensing/integrity-manifest.json` and rebuilt
-  `dist/aurora-admin-v2.zip` from a fresh staging copy — the protected
-  files' checksums (`Integrity::is_tampered()`'s manifest) had gone stale
-  after this session's edits to `aurora-admin.php`, `Shell.php`, and others.
-  Also excluded `.claude/` from the staged copy — the internal tooling
-  config had been getting bundled into the distributable zip.
-
-## [2.20.0] - 2026-07-05
-
-### Added
-- Media Folders (paid — `License::PAID_FEATURES["media-folders"]`): a
-  folder tree for the Media Library, duplicating the organizing capability
-  of the FileBird Pro plugin at the user's request, with its own
-  independent schema (`wp_aurora_media_folders` /
-  `wp_aurora_media_folder_items`, distinct from FileBird's own `wp_fbv*`
-  tables so both can coexist) rather than importing FileBird's data.
-  - New `MediaFolders.php` model (create/rename/delete/reparent, one folder
-    per attachment) + `MediaFolderData.php` REST routes
-    (`/media-folders`, `/media-folders/assign`), every route double-gated
-    (`current_user_can` + `License::is_feature_available`) per this
-    project's established REST-bypass-hardening pattern.
-  - `Media.vue` gains a folder sidebar (`MediaFolderTree.vue`): create,
-    rename, delete, right-click context menu, drag-and-drop reparenting,
-    and drag-and-drop (or a "Move to folder" fallback) to file media into
-    folders. "All Media" and "Uncategorized" are pinned pseudo-folders.
-  - The Media Library page itself stays free/ungated either way — only the
-    folder capability is paid. Unlicensed users keep today's flat grid
-    unchanged; the sidebar shows an inline `UpgradeNotice` instead of
-    disappearing or locking the whole page — a new gating shape for this
-    codebase (previously: whole sub-app free or whole sub-app paid).
-
-### Fixed
-- `Shell::is_own_page()` didn't recognize `ScreenHijack`-based pages
-  (Posts, Pages, Media, Users, Comments — they keep their native URL, no
-  `?page=aurora-admin` to key off), so it misclassified them as native
-  pages and loaded `native-dark.css`'s own-page exclusion incorrectly,
-  letting that stylesheet's generic `a` color rule leak into the real
-  Aurora UI. Invisible until now because no earlier hijacked page rendered
-  a link relying on accent/contrast coloring — Media Folders' new
-  "Enter a license key" CTA in the unlicensed sidebar was the first.
-  `ScreenHijack::register()` now flags `is_hijack_active()` the moment any
-  registered hijack activates for the current request, and
-  `is_own_page()` checks it.
-
-## [2.19.0] - 2026-07-05
-
-### Removed
-- Remote Site Switcher: the Settings > General "Remote Sites" repeater and
-  "Remote Site Switcher Capability" field, and the toolbar dropdown they
-  fed. User asked what it did; investigation found it was inert scaffolding
-  — it collected and stored a remote site's URL/username/application
-  password, but nothing anywhere in the codebase ever used the credentials
-  (no REST calls, no proxying, no SSO). The toolbar "switcher" was just a
-  plain link opening the remote site's own `/wp-admin/` in a new tab. User's
-  call: "doesn't really do much for the software" — removed rather than
-  built out, since a real cross-site integration wasn't the ask.
-- `License::PAID_FEATURES["remote-site-switcher"]` — the feature's paid gate,
-  now dead code since the feature itself is gone.
-
-### Added
-- `Settings::remove_retired_keys()` — actively deletes now-unused settings
-  keys from the database on `init`, rather than leaving them inertly
-  stored. Added specifically because `remote_sites` held a real secret
-  (WordPress application passwords); once the field stopped being read or
-  written, the safer move was to purge it, not just stop touching it.
-
-## [2.18.0] - 2026-07-05
-
-### Added
-- Role Editor: an info icon next to every capability checkbox, with a
-  hover tooltip explaining what it actually does — user asked directly,
-  pointing at `level_0`/`level_1` as an example of capabilities with no
-  explanation anywhere in the UI. New `capabilityDescriptions.js` covers
-  all ~55 WordPress core capabilities (`edit_posts`, `manage_options`,
-  `unfiltered_html`, etc.) plus the legacy `level_0`–`level_10` "user
-  level" system specifically — a pre-2.0 permissions scheme WordPress
-  still assigns to every default role purely for backward compatibility
-  with old themes/plugins that check `current_user_can('level_N')`
-  directly instead of a named capability; core itself hasn't checked a
-  level in years. Any capability not in the dictionary (e.g. one added by
-  another plugin) gets a generic "custom capability" fallback rather than
-  showing nothing. Verified live: hovering `level_0`'s info icon on the
-  Subscriber role shows the explanation described above.
-
-## [2.17.2] - 2026-07-05
-
-### Fixed
-- `AppListShell.vue` (the shared master/detail layout used by Database
-  Explorer, Role Editor, Activity Log, Admin Notices, and Menu Creator):
-  the list pane and detail pane shared one page-level scroll instead of
-  scrolling independently. Selecting an item near the bottom of a long
-  list (e.g. Database Explorer's 40 tables) left the detail panel's
-  newly-loaded content rendered off-screen above the current scroll
-  position — looked like nothing happened until you scrolled all the way
-  back up. Root cause: the shell only set a `min-height` on the outer
-  flex container, so it just grew with content instead of giving each
-  pane a capped height + its own scrollbar. Fixed by giving the container
-  a real `height` and both panes `height: 100%; overflow-y: auto`, with a
-  separate mobile-breakpoint treatment (stacked panes get natural height
-  with their own `max-height` instead of squashing to 50/50). Verified
-  live: scrolled Database Explorer's table list to the bottom, selected
-  `wp_users`, confirmed its data appeared immediately without scrolling.
-
-## [2.17.1] - 2026-07-05
-
-### Fixed
-- File Manager's right-click context menu never appeared for real users
-  (it worked in earlier automated testing, which turned out to be
-  triggering the bug's absence rather than confirming its fix). Root
-  cause: right-clicking — especially via a trackpad's two-finger tap or
-  Ctrl-click on macOS — can fire a trailing synthetic `click` event
-  immediately after `contextmenu` on the same target. The menu's
-  "click anywhere else closes it" listener was attached synchronously the
-  moment the menu opened, so that trailing click closed it in the same
-  tick it appeared — a real race condition, not a rendering bug. Fixed by
-  deferring the outside-click listener's registration by one tick
-  (`setTimeout(..., 0)`) so it only starts listening after the opening
-  event has fully finished. Verified by simulating the exact race
-  (`contextmenu` immediately followed by `click` on the same element,
-  same tick) and confirming the menu stays open; also confirmed a genuine
-  later click still closes it.
-
-## [2.17.0] - 2026-07-05
-
-### Added
-- File Manager: **right-click context menu**, mirroring the toolbar exactly
-  (same functions, just a different trigger) so the two can't drift out of
-  sync. Right-clicking an item outside the current selection selects just
-  that item first (standard file-manager behavior); right-clicking within
-  an existing multi-selection leaves it intact so bulk actions still work
-  from the menu. Right-clicking empty space shows folder-level actions
-  (New Folder/File, Upload, Paste) instead. Closes on Escape or a click
-  anywhere else.
-- File Manager: the plain `<textarea>` editor is now a real code editor
-  (CodeMirror 6 — `codemirror` + per-language packages for JS/TS, CSS,
-  HTML, JSON, PHP, Markdown, XML, SQL), with syntax highlighting, line
-  numbers, code folding, and active-line highlighting. Language is chosen
-  by file extension; unrecognized extensions fall back to plain text
-  rather than guessing wrong. Themed directly off Aurora's own CSS
-  variables (not a hardcoded palette) so it matches whatever theme preset
-  is active instead of looking like a foreign widget. Adds real bundle
-  weight (~250KB gzipped) — only loaded when the File Manager page itself
-  is opened, not part of the main admin bundle.
-- Verified live: context menu appears correctly for both selection and
-  empty-space cases with the right actions enabled/disabled, Escape closes
-  it; PHP syntax highlighting confirmed rendering correctly on a real file
-  (index.php — comments, strings, keywords all colored, doc-block folding
-  visible).
-
-## [2.16.0] - 2026-07-05
-
-### Changed
-- File Manager's actions consolidated into a single elFinder-style toolbar
-  (back/forward/up navigation history, new folder/file, upload,
-  copy/cut/paste, rename, trash, download/edit/info, list/grid view toggle,
-  fullscreen, search) matching the layout of the "WP File Manager" reference
-  plugin, replacing the previous split of header buttons + a per-row Actions
-  column. Selection is now click-to-select (checkbox) + toolbar action,
-  double-click to open a folder or editable file — the toolbar's buttons
-  enable/disable based on what's currently selected (e.g. Rename/Info only
-  with exactly one item selected, Download only for a single file).
-- **Move/copy switched from a destination-picker modal to clipboard-style
-  copy/cut/paste** — select item(s), click Copy or Cut, navigate anywhere
-  (tree sidebar, breadcrumb, double-click into a folder), click Paste. A
-  copy clipboard survives repeated pastes; a cut clipboard clears itself
-  after the first successful paste. Same `/file-manager/bulk` endpoint
-  underneath, just a different frontend trigger.
-- Added a **grid view** (thumbnails/icons in a card layout) as an
-  alternative to the list view, and a **fullscreen toggle** for the File
-  Manager panel itself.
-- Verified live: copy → navigate into a folder → paste (file appeared in
-  the new location) → select → trash → confirmed removed; back-navigation
-  and grid view toggle both confirmed working.
-
-## [2.15.0] - 2026-07-05
-
-### Added
-- File Manager closed most of the feature gap against the reference "WP
-  File Manager" plugin, adding everything that didn't carry the security
-  risk of the already-excluded zip/unzip and chmod features:
-  - **Move & copy** between folders (`copy_item`/`move_item`), with
-    same-containment checks as everything else plus a specific guard
-    against moving/copying a folder into its own descendant. Name
-    collisions at the destination get " (2)", " (3)", etc. appended rather
-    than silently overwriting.
-  - **Multi-select + bulk actions** — one `/file-manager/bulk` endpoint
-    drives trash/move/copy across any number of selected items, reusing
-    the exact same per-item logic as the single-item buttons so bulk
-    behavior can't drift from what those do. Partial failures don't abort
-    the rest — every path gets its own attempt, failures are reported back.
-  - **Trash instead of permanent delete** — deleting now moves the item
-    into a flat UUID-named folder under `wp-content/uploads/aurora-admin-trash/`
-    plus a JSON manifest (original path, name, type, deleted-at), rather
-    than encoding the original path into the filename (nesting/special
-    characters/length limits make that fragile). Trash view offers
-    restore (recreates parent folders as needed, blocks if something's
-    since taken the original spot), permanent delete, and empty-trash.
-  - **Folder tree sidebar** — lazy-loaded (only fetches a folder's children
-    when expanded) via the existing list endpoint filtered to directories,
-    no new backend route needed. Reused as the destination picker for
-    move/copy.
-  - **File info panel** — read-only permissions/owner/size/dates/mime type
-    via a new `/file-manager/info` endpoint; directory size is computed
-    on-demand for this one-off request rather than for every row in the
-    main list (would slow down browsing large folders for no benefit).
-  - **Image thumbnails** — a new `/file-manager/preview` endpoint serves
-    image files inline (not as an attachment) for use as an `<img>` src;
-    no server-side resizing, just the extension allowlist + size cap every
-    other endpoint here already uses.
-  - **Drag-and-drop upload** (multiple files at once) and **sortable
-    columns** (Name/Size/Modified, folders always first regardless of
-    sort) — both frontend-only, no new backend surface.
-  - Aurora's own trash folder is hidden from the normal browser view when
-    listing `wp-content/uploads` — it's an implementation detail, not a
-    real user-created folder.
-  - Verified live: multi-select, info panel, and the full create → trash →
-    restore round trip through the UI; copy/bulk-trash/empty-trash verified
-    directly against the REST endpoints.
-- Still deliberately not built (unchanged from the original scope decision):
-  zip/unzip (zip-slip risk) and chmod/permissions editing (too easy to lock
-  yourself out).
-
-## [2.14.0] - 2026-07-05
-
-### Added
-- **Developer-only** license override for local testing — lets Pro
-  features be tested without buying a license against the developer's own
-  software. Settings > Developer's "Simulate active license" toggle treats
-  every paid feature as fully licensed, bypassing both the real license
-  check and the file-integrity tamper check. Two gates keep this from ever
-  doing anything on a real install even if this code ships by accident:
-  (1) it only has any effect at all when `AURORA_ADMIN_DEV_MODE` is
-  defined truthy in `wp-config.php` — never set anywhere in this repo or
-  the release zip, only in a local dev environment's own config — and (2)
-  the Settings > Developer category itself only renders in the UI when
-  that constant is present. **This entire feature (the `DEV_MODE_CONSTANT`
-  checks in `License.php`, the `devModeAvailable` flag in
-  `SettingsPage.php`, and the "Developer" category in
-  `settingsConfig.js`/`Settings.vue`) must be removed before packaging a
-  release build** — every touch point is marked `DEV ONLY` in comments.
-  Verified live: toggling it on/off correctly unlocks/re-locks a Pro
-  feature (Role Editor) end-to-end, including the sidebar's lock badge.
-
-## [2.13.1] - 2026-07-05
-
-### Fixed
-- Every `ScreenHijack`-mounted page (Posts, Pages, Media, Users, Comments,
-  the 5 native Settings screens, Media Upload, Add New User, Nav Menus,
-  Themes, Widgets, Profile) was missing the traffic-light title bar and
-  rendering outside the normal card frame — the DOM structure didn't match
-  native/other Aurora pages. Root cause: WordPress prints
-  `<div id="wpbody"><div id="wpbody-content">` *after* the
-  `in_admin_header` hook fires (confirmed directly in core's
-  `admin-header.php`), but `ScreenHijack.php` started its output buffer
-  *on* `in_admin_header` — so those wrapper divs' opening tags, and later
-  their closing tags (printed before `admin_footer` fires), both ended up
-  inside the buffer and got discarded along with the native content they
-  were meant to replace. The mount div ended up a level too high in the
-  DOM (a direct child of `#wpcontent`), which broke `windowChrome.js`'s
-  `#wpbody-content`-based traffic-light insertion and the shell's card
-  framing CSS. Fixed by having `ScreenHijack.php` re-print the `#wpbody`/
-  `#wpbody-content` wrapper divs itself around the mount point, so the DOM
-  matches what WordPress would have produced. Verified live on Posts,
-  Media, Users, and Profile.
-
-## [2.13.0] - 2026-07-05
-
-### Added
-- Sixth and final phase of the "full admin takeover" initiative: the block
-  editor (`post.php`/`post-new.php`). Deliberately a reskin, not a rebuild
-  — Gutenberg stays completely native, extending the framing
-  `windowChrome.js`/`shell-frame.css` already had working (traffic-light
-  dots overlaid on the editor). Added a "← Posts"/"← Pages" breadcrumb next
-  to the dots, resolved from the `post-type-{slug}` body class WP core
-  already adds to every post edit screen (needed since Posts/Pages moved
-  off a fixed `admin.php?page=...` URL onto their native URLs earlier this
-  phase, so there's no single URL to hardcode).
-  - Caught and fixed a real bug while testing: the Site Editor
-    (`site-editor.php`) shares the same `block-editor-page` body class the
-    breadcrumb logic keyed off, but has no `post-type-*` class (it edits
-    templates, not a post) — the original version defaulted to guessing
-    "Posts" there, which was wrong. Now returns no breadcrumb at all when
-    no `post-type-*` class is present, verified live on both the post
-    editor (crumb shows, correct link) and the Site Editor (no crumb,
-    nested-skeleton framing unaffected).
-  - This is the last screen in the "full admin takeover" initiative's
-    original 9-item build order. All 9 phases are now shipped.
-
-## [2.12.0] - 2026-07-05
-
-### Added
-- Fifth phase of the "full admin takeover" initiative: Profile
-  (`profile.php`), reskinning WordPress's own fields (name, contact info,
-  bio) via core's `/wp/v2/users/me` REST route, plus a small new
-  `ProfileData.php` route for password changes (core deliberately excludes
-  password from its own REST schema). Free, gated by `modern_users`.
-  - Deliberately does not attempt to host third-party plugin fields (2FA
-    setup, WooCommerce customer fields, etc., added via the
-    `show_user_profile`/`personal_options` hooks) — a Vue reskin has no
-    safe way to render another plugin's raw HTML/JS. Instead, the hijack
-    checks `has_action('show_user_profile')`/`has_action('personal_options')`
-    at hijack time and falls through to the real native screen whenever
-    either has a callback registered, rather than silently hiding those
-    plugins' fields. Verified live both ways: installed a test mu-plugin
-    hooking `show_user_profile` and confirmed the native screen renders
-    instead of the reskin; removed it and confirmed the reskin returns.
-  - Password changes re-issue the auth cookie immediately after
-    `wp_set_password()` (which invalidates the current session, since it's
-    derived in part from the password hash) — same as core's own
-    user-edit.php does when you change your own password.
-
-## [2.11.0] - 2026-07-05
-
-### Added
-- Fourth phase of the "full admin takeover" initiative: the Appearance
-  batch. Nav Menus (`nav-menus.php`) and Widgets (`widgets.php`) are real,
-  purpose-built replacements — not wired into the existing Menu Creator,
-  which manages Aurora's own admin sidebar and turned out to be an unrelated
-  feature despite the similar name. Themes (`themes.php`) is a real
-  list/activate/delete replacement (`ThemesData.php` + `Themes.vue`). Theme
-  Editor (`theme-editor.php`) redirects to the existing File Manager instead
-  of getting a second in-browser file editor — building one would duplicate
-  File Manager's exact RCE risk surface for no benefit. Tools, Import/Export,
-  and Site Health are deliberately left un-hijacked; Shell's existing
-  native-page framing already covers them and a full rebuild has no real
-  value-add over core's own screens.
-  - Widgets is deliberately simplified to reordering/moving/deactivating
-    existing widget instances between sidebars — adding a brand-new
-    instance of an arbitrary widget type still uses WordPress's own
-    block-based widgets screen (each widget type owns its own default
-    settings and form; genericizing that is a full editor's worth of scope
-    on its own, same reasoning as not rebuilding the block editor).
-  - Nav Menus supports the common paths: create/delete menus, add
-    pages/posts/categories/custom links, reorder and indent/outdent
-    (sub-menu) items, assign menus to theme locations.
-  - All three (plus Native Settings, previously shipped) are gated by the
-    `full_admin_takeover` master toggle and the `"admin-takeover"` paid
-    feature; every new REST controller checks the license directly in its
-    own `permission_callback`, not just at the page level.
-- Fixed a real frontend bug caught while testing these against a 403 (no
-  license): `Themes.vue`, `Widgets.vue`, and `NavMenus.vue`'s fetch calls
-  didn't check `res.ok` before treating the response body as the expected
-  data shape — a REST error object (`{code, message, data}`) got rendered
-  as if it were the actual list, producing bogus placeholder rows instead
-  of a clear error message. All three now surface the real error.
-- Verified live: Themes' activate/list/screenshot rendering confirmed
-  working end-to-end (switched between all 3 installed themes); Nav Menus
-  and Widgets' REST layer verified directly (create/add-item/list/delete
-  round trip, real sidebar data) — the pages themselves couldn't be
-  rendered in this dev environment since none of the 3 installed themes
-  register classic nav-menu/widget support (all are block/FSE themes,
-  which core itself refuses these screens for too — not a defect in the
-  hijack).
-
-## [2.10.0] - 2026-07-05
-
-### Added
-- Third phase of the "full admin takeover" initiative: Media Upload
-  (`media-new.php`) and Add New User (`user-new.php`) are now hijacked in
-  place. Both are Vue-only — no new PHP REST controllers — talking directly
-  to core's own `/wp/v2/media` and `/wp/v2/users` REST routes, which already
-  cover file upload and user creation. Free, gated by the same
-  `modern_media`/`modern_users` toggles as their already-free list-view
-  companions (no reason to paywall mid-workflow between "browse" and "add").
-  Verified live end-to-end: created a real user and confirmed it appears in
-  the Users list.
-
-## [2.9.0] - 2026-07-05
-
-### Added
-- Second phase of the "full admin takeover" initiative: the 5 native
-  Settings screens (General, Writing, Reading, Discussion, Permalinks) are
-  now hijacked in place (`NativeSettingsPages.php`), sharing one generic
-  Vue page (`NativeSettings.vue`) driven by a per-screen field schema.
-  Most fields read/write through core's own `/wp/v2/settings` REST route;
-  Permalinks has no core REST route for rewrite rules, so it gets its own
-  small `PermalinksData.php` controller instead (calls
-  `$wp_rewrite->set_permalink_structure()` + `flush_rules()`, same as core's
-  own settings page does).
-- New master toggle, Settings > Admin Takeover > "Full admin takeover"
-  (default **off** — these new areas cover more ground and carry more risk
-  than the already-migrated Posts/Pages/Media/Users/Comments, so opt-in
-  rather than on by default), plus a new `"admin-takeover"` paid feature key.
-  Every new REST controller in this phase checks
-  `License::is_feature_available("admin-takeover")` directly in its own
-  `permission_callback`, not just at the page level — the same defense the
-  File Manager REST controller already has, verified live by confirming a
-  direct REST call still 403s with the setting on but no license.
-- `SettingsField.vue` (shared by the main Settings page and the new native
-  Settings screens) gained two small additions: `readonly` support on text
-  fields (Site Address shouldn't be editable inline) and a `select` field
-  type (a plain dropdown, distinct from the existing multiselect checkbox
-  list) — both minimal, generically useful additions, not one-offs.
-
-## [2.8.0] - 2026-07-05
-
-### Added
-- First phase of the "full admin takeover" initiative: Posts, Pages, Media
-  Library, Users, and Comments no longer redirect to a separate
-  `admin.php?page=...` URL — they now hijack their native screens in place
-  (`ScreenHijack.php`, registered via `HijackedNativePages.php`), the same
-  approach the original uixpress reference plugin used. WordPress's
-  `load-{page}.php` hook fires before the native screen prints anything, so
-  Aurora buffers and discards the native output and mounts its own Vue page
-  in its place — the URL never changes, so there's no separate slug that can
-  fall out of sync with a plugin's own redirect, a bookmark, or any other
-  direct visit. This is exactly the bug class already hit and fixed once for
-  Plugins; the other five pages are now structurally immune to it. Plugins
-  itself stays on the redirect mechanism — `plugins.php` prints output in a
-  way that can't be cleanly buffered, confirmed by the reference plugin's own
-  abandoned attempt at hijacking it.
-- Existing REST controllers and Vue pages for all five are unchanged — only
-  the mounting mechanism moved.
-
-## [2.7.2] - 2026-07-05
-
-### Fixed
-- Installing/activating a plugin dropped back to the native WordPress
-  Plugins page instead of staying in Aurora's UI, until the sidebar's
-  "Plugins" link was clicked again. Unlike Posts/Pages/Media/Users/
-  Comments, Plugins only ever had its sidebar *link* rewritten
-  (`MenuSerializer.php`) — there was no `redirect_native_pages()` case
-  for direct visits to `plugins.php`, which is exactly what WordPress's
-  own post-activate/post-install redirect does
-  (`wp_redirect(self_admin_url('plugins.php?activate=true'))`, no
-  `?page=` param). Added the missing case, matching the pattern already
-  used for the other four pages.
-
-## [2.7.1] - 2026-07-05
-
-### Fixed
-- Native form fields (text inputs, textareas, selects) on several
-  classic/non-block-editor screens — most visibly the title field on the
-  Edit Media screen, but the same fix applies wherever it occurred — were
-  showing stark white, breaking the dark theme. Root cause: some native
-  WP screens style specific fields via a 2-ID selector (e.g. core's
-  `#titlediv #title { background: #fff }`), which beats our existing
-  rule's single `#wpbody-content` id no matter how many classes are
-  stacked on it — the exact same CSS-specificity trap as an earlier
-  block-editor background bug. Added `!important` to the form-field rule
-  block, since there's no legitimate case where a native admin form field
-  should stay white.
-
-## [2.7.0] - 2026-07-05
-
-### Added
-- New File Manager (`aurora-admin-file-manager`), browsing/editing the
-  WordPress install's own files — built fresh (not embedding elFinder),
-  in the spirit of the "WP File Manager" plugin already on this site
-  (same root, same `manage_options`-only gate). Create/upload/download/
-  rename/delete files and folders, plus a plain-text editor for
-  code/config files. A **Pro feature** — the riskiest surface in the
-  whole plugin (arbitrary read/write access to the site's own PHP files),
-  so it's gated the same way as Database Explorer.
-  - Every path a client sends is resolved to a real, `ABSPATH`-contained
-    path via `realpath()` before any filesystem operation — containment
-    is checked against the resolved path, not string-matched against the
-    raw input, so symlink tricks and encoded traversal can't slip past.
-  - Uploads/new files/renames all reject a blocklist of server-executable
-    extensions (`.php`, `.phtml`, `.cgi`, `.sh`, etc.) — the single most
-    important control here, since uploading a webshell is the whole ballgame.
-  - Deliberately not built: zip/unzip (zip-slip extraction vulnerability),
-    chmod/permissions editing, and cross-directory move/copy — each is a
-    meaningfully larger, riskier scope than a first pass warrants.
-
-### Fixed
-- File Manager's REST endpoints now also check
-  `License::is_feature_available('file-manager')`, not just
-  `manage_options` — found while wiring it up that the page-level lock
-  alone doesn't stop a direct REST call from bypassing it entirely.
-  **The same gap exists in Database Explorer, Role Editor, and Activity
-  Log's REST controllers and is not yet fixed** — flagged as a follow-up.
-
-## [2.6.0] - 2026-07-05
-
-### Added
-- Real replacement pages for Pages, Media Library, and Users — the
-  remaining native admin screens that were only dark-themed skinning,
-  now built the same way as Posts/Comments/Plugins (own REST controller,
-  own Vue page, native screen redirected away):
-  - **Pages** (`PagesData.php` + `Pages.vue`): same as Posts, but shows
-    the parent page instead of categories. `edit.php?post_type=page`
-    redirects; other post types are untouched.
-  - **Media Library** (`MediaData.php` + `Media.vue`): a thumbnail grid
-    (not a rebuilt drag-drop uploader) with type filters (Images/Audio/
-    Video/Documents/Unattached), search, and delete. `upload.php`
-    (both grid and list mode) redirects; `media-new.php` (the actual
-    upload screen) is untouched, same reasoning as leaving the block
-    editor alone for Posts/Pages.
-  - **Users** (`UsersData.php` + `Users.vue`): filterable by role, with
-    edit/delete actions. Deleting a user always reassigns their content
-    to whoever performs the deletion, rather than exposing WP core's
-    reassign-or-delete-everything choice as a one-click REST action —
-    deliberately simplified to avoid a surprising, highly destructive
-    default. `users.php` redirects; `user-new.php` (account creation)
-    is untouched.
-  - All four gated by their own Settings toggle (`modern_pages`,
-    `modern_media`, `modern_users` — `modern_posts` already existed),
-    each defaulting to on.
-
-## [2.5.0] - 2026-07-05
-
-### Added
-- Real replacement Posts management page (`aurora-admin-posts`), the same
-  kind of full custom page as Comments/Plugins rather than dark-themed
-  skinning over the native `edit.php` list table. New `PostsData.php` REST
-  controller (list with status/search filters, trash, restore, permanent
-  delete) and a new Vue page matching the Comments layout (status filter
-  pills, search, table with title/author/categories/comments/date/status,
-  inline row actions, pagination). The native Posts screen (`edit.php`,
-  default post type only — Pages and other post types are untouched)
-  redirects to it, gated by Settings > Posts' restored "Modern posts
-  table" toggle (removed a few commits ago when it had no implementation
-  behind it — now it does).
-
-### Fixed
-- The `modern_plugins`/`modern_comments` settings toggles now default to
-  visually "on" in the Settings UI to match their actual PHP default
-  (previously they defaulted true server-side but showed off in the UI
-  until explicitly saved) — same fix applied to the new `modern_posts`.
-
-## [2.4.2] - 2026-07-04
-
-### Fixed
-- Admin Notices only ever showed on the Aurora Dashboard — everywhere
-  else, `admin_notices` fired normally, but on the Dashboard specifically
-  the notice was invisible: `DashboardTakeover` hides `#wpbody` entirely
-  there (to hide the *native* dashboard, not our own), and that's exactly
-  where WordPress prints `admin_notices` output. Notices now render
-  directly inside the Aurora dashboard frame instead on that one page.
-  Along the way, also worked around a separate WordPress core behavior
-  (`common.js` unconditionally relocates every `.notice` element to right
-  after the page's `<h1>`) using core's own documented `below-h2` opt-out
-  class, since without it the notice would've just been silently moved
-  back into the hidden `#wpbody` by that script regardless of where it
-  was placed server-side.
-
-## [2.4.1] - 2026-07-04
-
-### Fixed
-- Dashboard scrolling was broken — content below the first ~1500px
-  (Server Health, Media Analytics, etc.) was completely unreachable.
-  `.aurora-dashboard-frame` never got the height cap + internal scroll
-  treatment `#wpbody-content` got in an earlier fix; combined with
-  `html`/`body` being locked to `overflow: hidden` (to fix a phantom
-  scrollbar on a different page), there was no scroll mechanism left at
-  all for the dashboard specifically. Mirrored the same
-  max-height/overflow-y treatment onto `.aurora-dashboard-frame`.
-
-## [2.4.0] - 2026-07-04
-
-### Added
-- Settings > Menu's "Menu search" toggle now actually does something —
-  previously had no implementation at all. Shows a real search box at the
-  top of the sidebar that filters both the WP-native menu list and the
-  Aurora nav section by title, auto-expanding every section with a match.
-
-### Fixed
-- Settings > Dashboard's "Custom dashboard" toggle now actually gates the
-  dashboard takeover — previously the Aurora dashboard always replaced the
-  native one regardless of this setting, with no way to turn it back off.
-- Settings > Plugins' "Modern plugins page" and Settings > Comments'
-  "Modern comments page" toggles now actually gate their respective
-  takeovers/redirects the same way — previously both ran unconditionally
-  regardless of these settings.
-
-### Removed
-- Settings > Posts' "Modern posts table" and Settings > Users' "Modern
-  users page" toggles — both described a custom management interface that
-  was never built. Shipping a checkbox with nothing behind it is worse
-  than not having the checkbox; removed rather than left as dead UI. Their
-  categories are removed too, since they had no other fields.
-
-## [2.3.1] - 2026-07-04
-
-### Fixed
-- Sidebar accordion now treats the "Aurora" branded nav section as part of
-  the same single-open accordion as the WP-native menu list, instead of
-  being the one exception that stayed open regardless of what else was
-  expanded. Expanding any native section now collapses Aurora too, and
-  vice versa.
-
-## [2.3.0] - 2026-07-04
-
-### Added
-- Settings > Media's "Allow SVG uploads" toggle now actually does
-  something — previously existed in the UI with no implementation behind
-  it, so every SVG upload was rejected. Fixes both of WordPress's default
-  blocks (the `upload_mimes` allowlist and the real-mime sniff that nulls
-  out the file type for SVGs specifically), plus a PHP warning
-  (`wp_get_missing_image_subsizes()` reading undefined `width`/`height`
-  metadata keys that SVGs never had) that could otherwise corrupt the
-  upload response on environments with warnings displayed inline. Also
-  does basic sanitization on upload (strips `<script>` tags, inline event
-  handler attributes, `javascript:` URIs) since SVG can carry executable
-  content.
-
-## [2.2.0] - 2026-07-04
-
-### Added
-- Settings > Login's "Style login page" and "Login logo" fields now
-  actually do something — previously they existed in the UI with no
-  implementation behind them at all. Styles `wp-login.php` with a dark
-  theme (background, card, inputs, button) and swaps in the configured
-  logo image in place of the WordPress logo, linked to the site's home
-  URL instead of wordpress.org.
-
-## [2.1.1] - 2026-07-04
-
-### Fixed
-- Image fields (Logo, Dark mode logo, Login logo, Admin favicon) now open
-  the real WordPress media library picker. `wp_enqueue_media()` was never
-  called, so `wp.media` was undefined client-side and every image field
-  silently fell back to a plain URL prompt instead.
-
-## [2.1.0] - 2026-07-04
-
-### Added
-- Free/paid feature gating: Role Editor, Activity Log, Database Explorer,
-  Analytics, White Label, and the remote site switcher are now Pro
-  features. Menu Creator, Admin Notices, Comments, Plugins, and the core
-  shell/theming stay free. Locked pages show an upgrade prompt instead of
-  the real feature; the sidebar shows a lock badge on locked items.
-- Real license validation against the `auroraplugins.com` license server
-  (validate/activate/deactivate), replacing the earlier placeholder that
-  treated any non-empty key as active. Status is cached for 12 hours and
-  re-checked immediately on a license-key change. The Settings page shows
-  a live status line (active/invalid/unreachable) under the License key
-  field.
-- File-integrity tamper protection: if the code implementing the license
-  gate has been modified, every paid feature re-locks regardless of an
-  otherwise-valid license — makes stripping the check out of a
-  redistributed copy not actually unlock anything.
-
-### Fixed
-- Role Editor's REST endpoint 500'd when hit via the REST API — it called
-  `get_editable_roles()`, which WordPress only auto-loads for normal
-  wp-admin page requests, not REST requests.
+- Documented a Plugin Check `phpcs:ignore` for the `emoji_svg_url` WordPress core filter used by the Security module's emoji-disable feature.
+
+## [1.0] — 2026-07-25
+
+First public release.
+
+### Admin experience
+- Full modern admin shell — fixed sidebar, toolbar, and global search —
+  in place of the standard WordPress admin chrome.
+- Custom takeover screens for Dashboard, Posts, Pages, Media, Users, and
+  Comments, plus Add User, Media Upload, and Profile.
+- Sub-apps: Settings, Setup Wizard, Menu Creator, Role Editor, Admin
+  Notices, Activity Log, and Report a Bug.
+
+### Theming
+- Live theme presets with an accent-driven palette applied across the whole
+  admin, plus a Google Font picker for the interface typeface.
+- Rounded content cards with a soft shadow so each page reads as a framed
+  surface.
+- Scroll areas sit **inside** the rounded frame — the scrollbar no longer
+  squares off the right corners — and scrollbars are tinted with the active
+  theme accent.
+
+### Under the hood
+- REST API namespace `aurora-admin/v1` backing every takeover screen.
+- Security & performance hardening module, custom admin CSS/JS injection,
+  and a login-screen customizer.
diff --git a/admin/assets/native-dark.css b/admin/assets/native-dark.css
index 774b75b..1c83cd8 100644
--- a/admin/assets/native-dark.css
+++ b/admin/assets/native-dark.css
@@ -51,6 +51,11 @@ html.aurora-dark.aurora-ready #wpbody-content .postbox,
 html.aurora-dark.aurora-ready #wpbody-content .card,
 html.aurora-dark.aurora-ready #wpbody-content .welcome-panel,
 html.aurora-dark.aurora-ready #wpbody-content .wp-list-table,
+/* .widefat: WP's general "wide flat table" utility class, used beyond just
+   WP_List_Table screens — e.g. update-core.php's plugin/theme update
+   tables (class="widefat updates-table", no .wp-list-table and no
+   .striped either), which were completely uncovered without this. */
+html.aurora-dark.aurora-ready #wpbody-content .widefat,
 html.aurora-dark.aurora-ready #wpbody-content .stuffbox {
   background: var(--aurora-card-bg);
   border-color: var(--aurora-card-border);
@@ -79,17 +84,41 @@ html.aurora-dark.aurora-ready #wpbody-content .postbox .handle-order-lower {
 
 /* Tables ---------------------------------------------------------------- */
 html.aurora-dark.aurora-ready #wpbody-content .wp-list-table th,
-html.aurora-dark.aurora-ready #wpbody-content .wp-list-table td {
+html.aurora-dark.aurora-ready #wpbody-content .wp-list-table td,
+html.aurora-dark.aurora-ready #wpbody-content .widefat th,
+html.aurora-dark.aurora-ready #wpbody-content .widefat td {
   border-color: var(--aurora-border);
+  /* Core sets an explicit white background directly on <td> (not just the
+     row), which otherwise wins over .wp-list-table/.widefat's own dark
+     background above — transparent lets the row's actual background
+     (plain dark, or the striped-odd shade below) show through instead of a
+     white cell sitting on an otherwise-dark row. Seen first on Export/
+     Erase Personal Data's request-queue table, but this is a generic
+     WP_List_Table/.widefat gap, not specific to any one screen. */
+  background: transparent;
 }
 
 html.aurora-dark.aurora-ready #wpbody-content .wp-list-table thead th,
 html.aurora-dark.aurora-ready #wpbody-content .wp-list-table tfoot th,
 html.aurora-dark.aurora-ready #wpbody-content .wp-list-table thead th a,
-html.aurora-dark.aurora-ready #wpbody-content .wp-list-table tfoot th a {
+html.aurora-dark.aurora-ready #wpbody-content .wp-list-table tfoot th a,
+html.aurora-dark.aurora-ready #wpbody-content .widefat thead th,
+html.aurora-dark.aurora-ready #wpbody-content .widefat tfoot th,
+html.aurora-dark.aurora-ready #wpbody-content .widefat thead th a,
+html.aurora-dark.aurora-ready #wpbody-content .widefat tfoot th a {
   color: var(--aurora-text);
 }
 
+/* core's list-tables.css sets `.plugins tr { background: #fff; }` for the
+   native Plugins screen's list table — .plugins is a plain class name, not
+   scoped to that screen, so it also matches update-core.php's plugin-update
+   table (its <tbody> reuses the same class). Aurora's own Plugins screen is
+   a full custom rebuild that never hits this native markup, which is why
+   this collision hadn't surfaced before update-core.php. */
+html.aurora-dark.aurora-ready #wpbody-content .plugins tr {
+  background: transparent;
+}
+
 html.aurora-dark.aurora-ready #wpbody-content .wp-list-table.striped > tbody > :nth-child(odd),
 html.aurora-dark.aurora-ready #wpbody-content .striped > tbody > :nth-child(odd) {
   background: var(--aurora-bg-subtle);
@@ -492,3 +521,31 @@ html.aurora-dark.aurora-ready #wpbody-content .font-library__font-card {
   border-color: var(--aurora-card-border);
   color: var(--aurora-text);
 }
+
+/* Site Health (site-health.php) is left running WordPress core's own test
+ * logic rather than reimplemented — its Status tab async checks hit core's
+ * own /wp-site-health/v1/tests/* REST routes, and third-party plugins can
+ * add their own checks via the site_status_tests filter, so reproducing it
+ * risks both drifting from core and silently dropping other plugins'
+ * checks. Only the framing/theming is Aurora's, same "frame native content"
+ * treatment as the block editor above.
+ *
+ * Three of its own elements paint a hardcoded white/off-white background
+ * that the generic #wpbody-content light-text cascade doesn't reach,
+ * leaving light text unreadable against it — the same "boot-layout" pattern
+ * fixed above, just a different screen. */
+html.aurora-dark.aurora-ready #wpbody-content .health-check-header,
+html.aurora-dark.aurora-ready #wpbody-content .health-check-accordion-panel {
+  background: var(--aurora-card-bg);
+}
+html.aurora-dark.aurora-ready #wpbody-content .health-check-accordion-trigger {
+  background: var(--aurora-bg-subtle);
+  color: var(--aurora-text);
+}
+/* The Security/Performance category pill inside each trigger row keeps its
+ * own dark text color (readable against the trigger's original near-white
+ * background) — needs to flip to light along with the trigger's background
+ * above, or it becomes unreadable in the other direction. */
+html.aurora-dark.aurora-ready #wpbody-content .health-check-accordion-trigger .badge {
+  color: var(--aurora-text);
+}
diff --git a/admin/src/ActivityLog/ActivityLog.php b/admin/src/ActivityLog/ActivityLog.php
index dac01fb..07881e8 100644
--- a/admin/src/ActivityLog/ActivityLog.php
+++ b/admin/src/ActivityLog/ActivityLog.php
@@ -10,7 +10,7 @@ defined("ABSPATH") || exit();
 class ActivityLog
 {
   const TABLE = "aurora_admin_activity_log";
-  const DB_VERSION = "1";
+  const DB_VERSION = "2";
   const DB_OPTION = "aurora_admin_activity_log_db_version";
 
   public function __construct()
@@ -19,9 +19,12 @@ class ActivityLog
 
     add_action("save_post", [self::class, "on_save_post"], 10, 3);
     add_action("before_delete_post", [self::class, "on_delete_post"]);
+    add_action("add_attachment", [self::class, "on_add_attachment"]);
+    add_action("delete_attachment", [self::class, "on_delete_attachment"]);
     add_action("user_register", [self::class, "on_user_register"]);
     add_action("profile_update", [self::class, "on_profile_update"]);
     add_action("wp_login", [self::class, "on_login"], 10, 2);
+    add_action("wp_logout", [self::class, "on_logout"]);
     add_action("activated_plugin", [self::class, "on_plugin_activated"]);
     add_action("deactivated_plugin", [self::class, "on_plugin_deactivated"]);
     add_action("switch_theme", [self::class, "on_theme_switch"]);
@@ -52,6 +55,7 @@ class ActivityLog
       object_label VARCHAR(191) NOT NULL DEFAULT '',
       user_id BIGINT UNSIGNED NULL,
       user_name VARCHAR(191) NOT NULL DEFAULT '',
+      ip_address VARCHAR(45) NULL,
       details LONGTEXT NULL,
       created_at DATETIME NOT NULL,
       PRIMARY KEY (id),
@@ -66,10 +70,23 @@ class ActivityLog
     update_option(self::DB_OPTION, self::DB_VERSION);
   }
 
-  private static function record($action_type, $object_type, $object_id, $object_label, $details = [])
+  /**
+   * @param array|null $actor Overrides the "current user" attribution with
+   *   an explicit ["id" => int, "name" => string] — needed for wp_logout,
+   *   where wp_get_current_user() has already been reset to the logged-out
+   *   (id 0) user by the time this hook fires, which would otherwise record
+   *   every logout as done by nobody.
+   */
+  private static function record($action_type, $object_type, $object_id, $object_label, $details = [], $actor = null)
   {
     global $wpdb;
-    $user = wp_get_current_user();
+    if ($actor === null) {
+      $current = wp_get_current_user();
+      $actor = [
+        "id" => $current && $current->exists() ? $current->ID : null,
+        "name" => $current && $current->exists() ? $current->display_name : "",
+      ];
+    }
 
     // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery -- $wpdb->insert() is WordPress's own escaping-safe API for writing to a custom table (not raw SQL); there's no core post/postmeta abstraction for Aurora's own activity-log table, so any access to it is necessarily "direct" by this sniff's definition.
     $wpdb->insert(self::table_name(), [
@@ -77,69 +94,133 @@ class ActivityLog
       "object_type" => $object_type,
       "object_id" => $object_id,
       "object_label" => substr((string) $object_label, 0, 191),
-      "user_id" => $user && $user->exists() ? $user->ID : null,
-      "user_name" => $user && $user->exists() ? $user->display_name : "",
+      "user_id" => $actor["id"],
+      "user_name" => $actor["name"],
+      "ip_address" => self::client_ip(),
       "details" => $details ? wp_json_encode($details) : null,
       "created_at" => current_time("mysql"),
     ]);
   }
 
+  /**
+   * REMOTE_ADDR only — the actual TCP peer, not spoofable by a request
+   * header. Behind a reverse proxy/load balancer this will read as the
+   * proxy's own address rather than the original visitor; deliberately not
+   * trusting X-Forwarded-For or similar instead, since blindly trusting a
+   * client-supplied header for anything (even just display, as here) is the
+   * standard IP-spoofing footgun, and this plugin has no reliable way to
+   * know whether a given host's proxy is trusted.
+   */
+  private static function client_ip()
+  {
+    $ip = isset($_SERVER["REMOTE_ADDR"]) ? sanitize_text_field(wp_unslash($_SERVER["REMOTE_ADDR"])) : "";
+    return filter_var($ip, FILTER_VALIDATE_IP) ? $ip : null;
+  }
+
   public static function on_save_post($post_id, $post, $update)
   {
-    // save_post fires on autosaves and revisions too — neither represents a
-    // real user-visible change, so both are skipped here.
-    if (wp_is_post_autosave($post_id) || wp_is_post_revision($post_id)) {
+    // save_post fires on autosaves, revisions, and attachments too — none
+    // represent a real user-visible content change (attachments get their
+    // own add_attachment/delete_attachment hooks below), so all three are
+    // skipped here.
+    if (wp_is_post_autosave($post_id) || wp_is_post_revision($post_id) || $post->post_type === "attachment") {
       return;
     }
     if (!in_array($post->post_status, ["publish", "draft", "pending", "future", "private"], true)) {
       return;
     }
-    self::record($update ? "post_updated" : "post_created", "post", $post_id, $post->post_title ?: "(no title)");
+    // object_type is the post's real type (post/page/a custom post type),
+    // not a hardcoded "post" — the Activity Log's Type column needs this to
+    // read correctly for anything that isn't the built-in Posts type.
+    self::record($update ? "updated" : "created", $post->post_type, $post_id, $post->post_title ?: "(no title)");
   }
 
   public static function on_delete_post($post_id)
   {
     $post = get_post($post_id);
-    if (!$post || $post->post_type === "revision") {
+    if (!$post || $post->post_type === "revision" || $post->post_type === "attachment") {
       return;
     }
-    self::record("post_deleted", "post", $post_id, $post->post_title ?: "(no title)");
+    self::record("deleted", $post->post_type, $post_id, $post->post_title ?: "(no title)");
+  }
+
+  public static function on_add_attachment($post_id)
+  {
+    $post = get_post($post_id);
+    self::record("created", "attachment", $post_id, $post ? $post->post_title : "(no title)");
+  }
+
+  public static function on_delete_attachment($post_id)
+  {
+    $post = get_post($post_id);
+    self::record("deleted", "attachment", $post_id, $post ? $post->post_title : "(no title)");
   }
 
   public static function on_user_register($user_id)
   {
     $user = get_userdata($user_id);
-    self::record("user_registered", "user", $user_id, $user ? $user->user_login : "");
+    // Self-registration means the visitor isn't authenticated yet at this
+    // point, so wp_get_current_user() would show "not logged in" rather
+    // than the account that was just created. Attributing explicitly to the
+    // new account instead — including when an admin creates the account —
+    // is a deliberate choice for this specific event: unlike profile edits
+    // (where the acting admin, shown via the default wp_get_current_user()
+    // attribution, is the more useful "who did this"), a registration event
+    // is overwhelmingly self-service, so "who this account belongs to" is
+    // the more useful read here, and treating both origins the same way
+    // keeps this one event type's Author column consistent regardless of
+    // which flow created the account.
+    self::record("registered", "user", $user_id, $user ? $user->user_login : "", [], [
+      "id" => $user_id,
+      "name" => $user ? $user->display_name : "",
+    ]);
   }
 
   public static function on_profile_update($user_id)
   {
     $user = get_userdata($user_id);
-    self::record("user_updated", "user", $user_id, $user ? $user->user_login : "");
+    self::record("profile_updated", "user", $user_id, $user ? $user->user_login : "");
   }
 
   public static function on_login($user_login, $user)
   {
-    self::record("login", "user", $user->ID, $user_login);
+    // Not wp_get_current_user(): wp_login fires from inside wp_signon(),
+    // before wp-login.php's own form handler calls wp_set_current_user() —
+    // the same ordering issue on_logout() has, just in the other direction.
+    // $user is passed in for exactly this reason; use it directly instead.
+    self::record("login", "user", $user->ID, $user_login, [], [
+      "id" => $user->ID,
+      "name" => $user->display_name,
+    ]);
+  }
+
+  public static function on_logout($user_id)
+  {
+    $user = $user_id ? get_userdata($user_id) : false;
+    $login = $user ? $user->user_login : "";
+    self::record("logout", "user", $user_id ?: null, $login, [], [
+      "id" => $user_id ?: null,
+      "name" => $user ? $user->display_name : "",
+    ]);
   }
 
   public static function on_plugin_activated($plugin)
   {
-    self::record("plugin_activated", "plugin", null, $plugin);
+    self::record("activated", "plugin", null, $plugin);
   }
 
   public static function on_plugin_deactivated($plugin)
   {
-    self::record("plugin_deactivated", "plugin", null, $plugin);
+    self::record("deactivated", "plugin", null, $plugin);
   }
 
   public static function on_theme_switch($new_name)
   {
-    self::record("theme_switched", "theme", null, $new_name);
+    self::record("switched", "theme", null, $new_name);
   }
 
   public static function on_settings_updated()
   {
-    self::record("settings_updated", "settings", null, "Aurora Admin settings");
+    self::record("updated", "settings", null, "Aurora Admin settings");
   }
 }
diff --git a/admin/src/ActivityLog/ActivityLogData.php b/admin/src/ActivityLog/ActivityLogData.php
index da79f65..98feb58 100644
--- a/admin/src/ActivityLog/ActivityLogData.php
+++ b/admin/src/ActivityLog/ActivityLogData.php
@@ -23,6 +23,11 @@ class ActivityLogData
         return current_user_can("manage_options");
       },
       "args" => [
+        // "admin" = site/content activity (everything except user-account
+        // events), "user" = account activity (login/logout/registration/
+        // profile updates) — the Activity Log page's two tabs. Omit for
+        // unfiltered (both).
+        "scope" => ["type" => "string", "required" => false, "enum" => ["admin", "user"]],
         "action_type" => ["type" => "string", "required" => false],
         "object_type" => ["type" => "string", "required" => false],
         "search" => ["type" => "string", "required" => false],
@@ -40,6 +45,13 @@ class ActivityLogData
     $where = ["1=1"];
     $params = [];
 
+    $scope = $request->get_param("scope");
+    if ($scope === "user") {
+      $where[] = "object_type = 'user'";
+    } elseif ($scope === "admin") {
+      $where[] = "object_type != 'user'";
+    }
+
     if ($request->get_param("action_type")) {
       $where[] = "action_type = %s";
       $params[] = sanitize_text_field($request->get_param("action_type"));
@@ -73,15 +85,50 @@ class ActivityLogData
     // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery, WordPress.DB.DirectDatabaseQuery.NoCaching, WordPress.DB.PreparedSQL.NotPrepared, PluginCheck.Security.DirectDB.UnescapedDBParameter -- reading Aurora's own custom activity-log table; always passed through $wpdb->prepare() with $params plus the trailing $per_page/$offset bound via %d/%d.
     $rows = $wpdb->get_results($wpdb->prepare($sql, array_merge($params, [$per_page, $offset])));
 
-    $items = array_map(function ($row) {
+    // Live user info (avatar/role/email) rather than freezing it into each
+    // log row at record time — reflects the account's CURRENT role/email
+    // (correct if either changes later) and avoids duplicating PII into
+    // every single event row when user_id is already a foreign key back to
+    // it. Batch-fetched once for every distinct user_id on this page,
+    // rather than one get_userdata() call per row.
+    $user_ids = array_values(array_unique(array_filter(array_map(function ($row) {
+      return $row->user_id ? (int) $row->user_id : 0;
+    }, $rows))));
+    $users_by_id = [];
+    if ($user_ids) {
+      // $roles[0] is a role SLUG (e.g. "shop_manager") — its translated
+      // display name has to come from wp_roles()'s own registered name for
+      // that slug, not a guess like ucfirst($slug); that only happens to
+      // work for the single-word built-in roles.
+      $all_roles = wp_roles()->roles;
+      foreach (get_users(["include" => $user_ids, "fields" => "all_with_meta"]) as $u) {
+        $slug = $u->roles ? $u->roles[0] : "";
+        $role_name = $slug && isset($all_roles[$slug]) ? translate_user_role($all_roles[$slug]["name"]) : "";
+        $users_by_id[$u->ID] = [
+          "avatar" => get_avatar_url($u->ID, ["size" => 64]),
+          "role" => $role_name,
+          "email" => $u->user_email,
+          "editUrl" => esc_url_raw(admin_url("user-edit.php?user_id=" . $u->ID)),
+        ];
+      }
+    }
+
+    $items = array_map(function ($row) use ($users_by_id) {
+      $uid = $row->user_id ? (int) $row->user_id : null;
+      $u = $uid && isset($users_by_id[$uid]) ? $users_by_id[$uid] : null;
       return [
         "id" => (int) $row->id,
         "actionType" => $row->action_type,
         "objectType" => $row->object_type,
         "objectId" => $row->object_id ? (int) $row->object_id : null,
         "objectLabel" => $row->object_label,
-        "userId" => $row->user_id ? (int) $row->user_id : null,
+        "userId" => $uid,
         "userName" => $row->user_name,
+        "userAvatar" => $u ? $u["avatar"] : null,
+        "userRole" => $u ? $u["role"] : "",
+        "userEmail" => $u ? $u["email"] : "",
+        "userEditUrl" => $u ? $u["editUrl"] : "",
+        "ipAddress" => $row->ip_address,
         "details" => $row->details ? json_decode($row->details, true) : null,
         "createdAt" => $row->created_at,
       ];
diff --git a/admin/src/App/AuroraAdmin.php b/admin/src/App/AuroraAdmin.php
index 15b0ff5..4df40ed 100644
--- a/admin/src/App/AuroraAdmin.php
+++ b/admin/src/App/AuroraAdmin.php
@@ -31,6 +31,9 @@ use AuroraAdmin\Pages\NativeSettingsPages;
 use AuroraAdmin\Rest\PermalinksData;
 use AuroraAdmin\Rest\DiscussionData;
 use AuroraAdmin\Pages\AppearancePages;
+use AuroraAdmin\Pages\ToolsPage;
+use AuroraAdmin\Pages\ExportPage;
+use AuroraAdmin\Pages\ImportPage;
 use AuroraAdmin\Rest\NavMenusData;
 use AuroraAdmin\Rest\ThemesData;
 use AuroraAdmin\Rest\WidgetsData;
@@ -43,6 +46,8 @@ use AuroraAdmin\Roles\RolesData;
 use AuroraAdmin\ActivityLog\ActivityLog;
 use AuroraAdmin\ActivityLog\ActivityLogData;
 use AuroraAdmin\Login\LoginStyle;
+use AuroraAdmin\Login\LoginRedirect;
+use AuroraAdmin\Editor\DisableGutenberg;
 use AuroraAdmin\Media\SvgUploads;
 use AuroraAdmin\Media\MediaFolders;
 use AuroraAdmin\ImageFormats\ImageFormats;
@@ -84,6 +89,9 @@ class AuroraAdmin
     new PermalinksData();
     new DiscussionData();
     new AppearancePages();
+    new ToolsPage();
+    new ExportPage();
+    new ImportPage();
     new NavMenusData();
     new ThemesData();
     new WidgetsData();
@@ -96,6 +104,8 @@ class AuroraAdmin
     new ActivityLog();
     new ActivityLogData();
     new LoginStyle();
+    new LoginRedirect();
+    new DisableGutenberg();
     new SvgUploads();
     new MediaFolders();
     new ImageFormats();
diff --git a/admin/src/Editor/DisableGutenberg.php b/admin/src/Editor/DisableGutenberg.php
new file mode 100644
index 0000000..8ccc7d5
--- /dev/null
+++ b/admin/src/Editor/DisableGutenberg.php
@@ -0,0 +1,31 @@
+<?php
+namespace AuroraAdmin\Editor;
+
+use AuroraAdmin\Options\Settings;
+
+defined("ABSPATH") || exit();
+
+/**
+ * Settings > Screens > Editor: "Disable Gutenberg" — opt-in, off by default.
+ * Falls back to WordPress core's own classic (meta-box/TinyMCE) post editor
+ * via the same core-supported filter the official Classic Editor plugin
+ * uses, rather than framing or rebuilding the block editor itself — the
+ * block editor stays one of the two deliberate "still native" screens in
+ * the admin takeover (alongside the Theme/Plugin File Editor), so this is
+ * an escape hatch around it, not a takeover of it.
+ */
+class DisableGutenberg
+{
+  public function __construct()
+  {
+    add_filter("use_block_editor_for_post_type", [self::class, "maybe_disable"], 100);
+  }
+
+  public static function maybe_disable($use_block_editor)
+  {
+    if ((bool) Settings::get("disable_gutenberg", false)) {
+      return false;
+    }
+    return $use_block_editor;
+  }
+}
diff --git a/admin/src/Login/LoginRedirect.php b/admin/src/Login/LoginRedirect.php
new file mode 100644
index 0000000..8eee4cd
--- /dev/null
+++ b/admin/src/Login/LoginRedirect.php
@@ -0,0 +1,110 @@
+<?php
+namespace AuroraAdmin\Login;
+
+use AuroraAdmin\Options\Settings;
+
+defined("ABSPATH") || exit();
+
+/**
+ * Settings > Login > "Login Redirect": optionally sends logged-out wp-admin
+ * visitors to a custom URL instead of the login screen, and/or sends
+ * specific roles to a custom URL after logging in instead of the dashboard.
+ * Both are opt-in and empty by default (normal WordPress behavior).
+ *
+ * Deliberately does NOT touch wp-login.php itself — it is never hidden,
+ * blocked, or moved, so this can only change where someone lands
+ * before/after that point, never whether they can reach the login form.
+ * Changing/hiding the login URL itself is a separate, higher-risk feature
+ * not implemented here.
+ */
+class LoginRedirect
+{
+  public function __construct()
+  {
+    add_filter("login_redirect", [self::class, "after_login"], 10, 3);
+    add_filter("allowed_redirect_hosts", [self::class, "allow_configured_hosts"]);
+    // wp_loaded, not admin_init: WordPress's own auth_redirect() (called
+    // from wp-admin/admin.php, before admin_init fires) already redirects
+    // an unauthenticated visitor to wp-login.php and exits — admin_init
+    // would never run for the case this needs to catch. wp_loaded fires
+    // from inside wp-settings.php, which wp-admin/admin.php requires and
+    // waits on BEFORE calling auth_redirect(), so it reliably runs first.
+    add_action("wp_loaded", [self::class, "guard_admin"]);
+  }
+
+  private static function enabled()
+  {
+    return (bool) Settings::get("login_redirect_enabled", false);
+  }
+
+  /** Destination after a successful login, for the configured roles. */
+  public static function after_login($redirect_to, $requested_redirect_to, $user)
+  {
+    if (!self::enabled() || !($user instanceof \WP_User) || !$user->exists()) {
+      return $redirect_to;
+    }
+
+    $roles = (array) Settings::get("redirect_roles", []);
+    if (!$roles || !array_intersect((array) $user->roles, $roles)) {
+      return $redirect_to;
+    }
+
+    $target = trim((string) Settings::get("redirect_after_login_url", ""));
+    return $target !== "" ? esc_url_raw($target) : $redirect_to;
+  }
+
+  /**
+   * Sends logged-out visitors to a custom URL instead of the default
+   * wp-login.php screen when they try to open wp-admin. Scoped tightly to
+   * real browser page loads under wp-admin — admin-ajax.php and
+   * admin-post.php (both used by logged-out requests via the *_nopriv_*
+   * hooks other plugins rely on for public form handling), async uploads,
+   * REST, and multisite's network admin are all left untouched, so nothing
+   * outside the login screen itself is affected.
+   */
+  public static function guard_admin()
+  {
+    if (!self::enabled() || is_user_logged_in()) {
+      return;
+    }
+    if (!is_admin() || is_network_admin() || wp_doing_ajax()) {
+      return;
+    }
+    if (defined("REST_REQUEST") && REST_REQUEST) {
+      return;
+    }
+    $excluded_scripts = ["admin-post.php", "admin-ajax.php", "async-upload.php"];
+    if (in_array($GLOBALS["pagenow"] ?? "", $excluded_scripts, true)) {
+      return;
+    }
+
+    $target = trim((string) Settings::get("redirect_unauthenticated_url", ""));
+    // Empty, or would send a logged-out visitor straight back into
+    // wp-admin — the latter is almost certainly a misconfiguration and
+    // would otherwise create a redirect loop.
+    if ($target === "" || stripos($target, "wp-admin") !== false) {
+      return;
+    }
+
+    wp_safe_redirect(esc_url_raw($target));
+    exit();
+  }
+
+  /**
+   * Lets wp_safe_redirect() honor an external target the admin configured
+   * for either redirect above, instead of silently falling back to the site
+   * home URL — both settings come from manage_options-gated Settings, never
+   * from request input, so there's no open-redirect exposure in trusting
+   * their host.
+   */
+  public static function allow_configured_hosts($hosts)
+  {
+    foreach (["redirect_unauthenticated_url", "redirect_after_login_url"] as $key) {
+      $host = wp_parse_url(trim((string) Settings::get($key, "")), PHP_URL_HOST);
+      if ($host) {
+        $hosts[] = $host;
+      }
+    }
+    return $hosts;
+  }
+}
diff --git a/admin/src/MenuCreator/MenuCreator.php b/admin/src/MenuCreator/MenuCreator.php
index 581552d..8d35984 100644
--- a/admin/src/MenuCreator/MenuCreator.php
+++ b/admin/src/MenuCreator/MenuCreator.php
@@ -14,14 +14,38 @@ class MenuCreator
   const DB_VERSION = "1";
   const DB_OPTION = "aurora_admin_menus_db_version";
 
+  /** Cached merged item list for the current user (per request). */
+  private static $items_cache = null;
+
+  /** Raw top-level menu snapshot, captured before apply() hides anything. */
+  private static $native_snapshot = null;
+
   public function __construct()
   {
     add_action("init", [self::class, "maybe_install"]);
-    // Late priority so it runs after all other plugins have registered
-    // their own menu items — there's nothing left to reorder/hide otherwise.
+    // Snapshot the full native menu just before apply() runs, so the editor
+    // can list (and re-enable) items this config hides. Both run after every
+    // other plugin has registered its menu items.
+    add_action("admin_menu", [self::class, "capture_native"], PHP_INT_MAX - 1);
     add_action("admin_menu", [self::class, "apply"], PHP_INT_MAX);
   }
 
+  /** Captures the raw top-level menu for the editor (see native_snapshot()). */
+  public static function capture_native()
+  {
+    self::$native_snapshot = \AuroraAdmin\Shell\MenuSerializer::top_level_items();
+  }
+
+  /**
+   * The raw top-level menu items for the current admin page load. The Menu
+   * Creator page feeds this into its serverData (SubApps.php) because the
+   * REST route can't build the admin menu.
+   */
+  public static function native_snapshot()
+  {
+    return is_array(self::$native_snapshot) ? self::$native_snapshot : [];
+  }
+
   public static function table_name()
   {
     global $wpdb;
@@ -57,64 +81,112 @@ class MenuCreator
   }
 
   /**
-   * Applies every published config whose target roles match the current
-   * user: hides items marked hidden and relabels items with a custom label.
+   * Merged item list from every published config whose target roles match
+   * the current user. Cached for the request (read by both apply() and
+   * ordered_slugs() on every admin page load).
    */
-  public static function apply()
+  private static function current_user_items()
   {
-    global $menu, $wpdb;
+    if (self::$items_cache !== null) {
+      return self::$items_cache;
+    }
+    self::$items_cache = [];
 
+    global $wpdb;
     if (!is_admin() || !function_exists("wp_get_current_user")) {
-      return;
+      return self::$items_cache;
     }
 
     $user = wp_get_current_user();
     if (!$user || !$user->exists()) {
-      return;
+      return self::$items_cache;
     }
 
     $table = self::table_name();
     // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery, WordPress.DB.DirectDatabaseQuery.NoCaching, WordPress.DB.PreparedSQL.InterpolatedNotPrepared -- {$table} is an internal, hardcoded {$wpdb->prefix}-based table name, not user input; no user-supplied values in this query. Runs on every admin page load to build the sidebar menu, so a per-request cache wouldn't help; a persistent cache would need its own invalidation on every config save, more complexity than this read is worth.
     $configs = $wpdb->get_results("SELECT roles, items FROM {$table} WHERE status = 'published'");
     if (!$configs) {
+      return self::$items_cache;
+    }
+
+    $items = [];
+    foreach ($configs as $config) {
+      $roles = json_decode($config->roles ?: "[]", true);
+      if (!is_array($roles) || !$roles || !array_intersect((array) $user->roles, $roles)) {
+        continue;
+      }
+      $decoded = json_decode($config->items ?: "[]", true);
+      if (is_array($decoded)) {
+        $items = array_merge($items, $decoded);
+      }
+    }
+
+    self::$items_cache = $items;
+    return $items;
+  }
+
+  /**
+   * Hides items marked hidden and relabels items with a custom label, on the
+   * native top-level $menu (which Aurora's MenuSerializer then reads).
+   */
+  public static function apply()
+  {
+    global $menu;
+    if (!is_array($menu)) {
       return;
     }
 
-    foreach ($configs as $config) {
-      $roles = json_decode($config->roles ?: "[]", true);
-      if (!is_array($roles) || !$roles) {
-        continue;
-      }
-      if (!array_intersect((array) $user->roles, $roles)) {
+    foreach (self::current_user_items() as $item) {
+      $native_id = isset($item["native_id"]) ? $item["native_id"] : "";
+      if ($native_id === "") {
         continue;
       }
 
-      $items = json_decode($config->items ?: "[]", true);
-      if (!is_array($items)) {
-        continue;
-      }
-
-      foreach ($items as $item) {
-        $native_id = isset($item["native_id"]) ? $item["native_id"] : "";
-        if ($native_id === "") {
+      foreach ($menu as $key => $entry) {
+        if (!isset($entry[2]) || $entry[2] !== $native_id) {
           continue;
         }
 
-        foreach ($menu as $key => $entry) {
-          if (!isset($entry[2]) || $entry[2] !== $native_id) {
-            continue;
-          }
+        if (!empty($item["hidden"])) {
+          unset($menu[$key]);
+          continue 2;
+        }
 
-          if (!empty($item["hidden"])) {
-            unset($menu[$key]);
-            continue 2;
-          }
-
-          if (!empty($item["label"])) {
-            $menu[$key][0] = sanitize_text_field($item["label"]);
-          }
+        if (!empty($item["label"])) {
+          $menu[$key][0] = sanitize_text_field($item["label"]);
         }
       }
     }
   }
+
+  /**
+   * Desired top-level slug order for the current user, from the saved config
+   * (items sorted by their 'order' field). Empty when no config applies.
+   *
+   * Consumed by MenuSerializer so Aurora's own sidebar reflects the order —
+   * WordPress's native `menu_order` filter only reorders the core admin menu,
+   * which Aurora hides, so it can't be used here.
+   */
+  public static function ordered_slugs()
+  {
+    $items = self::current_user_items();
+    if (!$items) {
+      return [];
+    }
+
+    usort($items, function ($a, $b) {
+      $ao = isset($a["order"]) ? (int) $a["order"] : 0;
+      $bo = isset($b["order"]) ? (int) $b["order"] : 0;
+      return $ao <=> $bo;
+    });
+
+    $slugs = [];
+    foreach ($items as $item) {
+      $slug = isset($item["native_id"]) ? $item["native_id"] : "";
+      if ($slug !== "" && !in_array($slug, $slugs, true)) {
+        $slugs[] = $slug;
+      }
+    }
+    return $slugs;
+  }
 }
diff --git a/admin/src/MenuCreator/MenuCreatorData.php b/admin/src/MenuCreator/MenuCreatorData.php
index b6e0324..6835648 100644
--- a/admin/src/MenuCreator/MenuCreatorData.php
+++ b/admin/src/MenuCreator/MenuCreatorData.php
@@ -82,17 +82,15 @@ class MenuCreatorData
   {
     $menu = \AuroraAdmin\Shell\MenuSerializer::serialize();
     $flat = [];
+    // Top-level items only. These are what the Menu Creator can reorder,
+    // hide, and rename today; submenu editing isn't applied yet, so it isn't
+    // offered (showing controls that do nothing is worse than not showing
+    // them).
     foreach ($menu as $item) {
       if (!empty($item["separator"]) || empty($item["id"])) {
         continue;
       }
       $flat[] = ["native_id" => $item["id"], "title" => $item["title"], "icon" => $item["icon"]];
-      foreach ($item["submenu"] ?? [] as $sub) {
-        if (empty($sub["id"])) {
-          continue;
-        }
-        $flat[] = ["native_id" => $sub["id"], "title" => $item["title"] . " › " . $sub["title"], "icon" => null];
-      }
     }
     return new \WP_REST_Response($flat, 200);
   }
diff --git a/admin/src/Pages/ExportPage.php b/admin/src/Pages/ExportPage.php
new file mode 100644
index 0000000..f884564
--- /dev/null
+++ b/admin/src/Pages/ExportPage.php
@@ -0,0 +1,39 @@
+<?php
+namespace AuroraAdmin\Pages;
+
+defined("ABSPATH") || exit();
+
+/**
+ * Registers the Export screen (export.php) for the "full admin takeover"
+ * initiative — a real Aurora-built form, not a reframed native page.
+ *
+ * Safe to fully rebuild (unlike Tools/Site Health): export.php's actual file
+ * generation (the `?download=true` request) calls export_wp() and die()s
+ * before ever reaching in_admin_header/admin_footer — the two hooks
+ * ScreenHijack's buffering relies on — so that request is never touched by
+ * the hijack at all and runs completely native, unmodified. Only the HTML
+ * form (the plain GET view with no `download` param) is replaced; Aurora's
+ * form submits via a real browser navigation to the same
+ * export.php?download=true&... URL, so the download itself is byte-for-byte
+ * what core would have produced.
+ */
+class ExportPage
+{
+  public function __construct()
+  {
+    ScreenHijack::register(
+      "load-export.php",
+      "export", // Matches core's own capability for this screen.
+      "full_admin_takeover",
+      "export",
+      "aurora-admin-export-root",
+      null,
+      null,
+      function () {
+        return [
+          "exportUrl" => esc_url_raw(admin_url("export.php")),
+        ];
+      }
+    );
+  }
+}
diff --git a/admin/src/Pages/ImportPage.php b/admin/src/Pages/ImportPage.php
new file mode 100644
index 0000000..14f3726
--- /dev/null
+++ b/admin/src/Pages/ImportPage.php
@@ -0,0 +1,137 @@
+<?php
+namespace AuroraAdmin\Pages;
+
+defined("ABSPATH") || exit();
+
+/**
+ * Registers the Import screen (import.php) for the "full admin takeover"
+ * initiative — a real Aurora-built listing, not a reframed native page.
+ *
+ * Only the LISTING page is rebuilt. Running an already-active importer
+ * (native "Run Importer" link) still goes to admin.php?import={id} — a
+ * screen registered and entirely rendered by whatever third-party importer
+ * plugin owns that id (register_importer()'s own callback). That page is
+ * arbitrary, unpredictable third-party UI outside this hijack's scope
+ * (a different load-{hook}), and stays native, same as e.g. the block
+ * editor stays native beyond its frame.
+ *
+ * Install/activate reuses existing, already-proven mechanisms instead of
+ * new logic: WordPress core's own admin-ajax "install-plugin" action (same
+ * one native's "Install Now" button triggers) for installing, and Aurora's
+ * own aurora-admin/v1/plugins/activate route (see PluginsData.php) for
+ * activation.
+ */
+class ImportPage
+{
+  public function __construct()
+  {
+    ScreenHijack::register(
+      "load-import.php",
+      "import", // Matches core's own capability for this screen.
+      "full_admin_takeover",
+      "import",
+      "aurora-admin-import-root",
+      null,
+      null,
+      function () {
+        return self::build_data();
+      }
+    );
+  }
+
+  private static function build_data()
+  {
+    if (!function_exists("get_importers")) {
+      require_once ABSPATH . "wp-admin/includes/import.php";
+    }
+
+    // Real, already-active importers (registered via register_importer() by
+    // an active importer plugin) — global $wp_importers. get_importers()
+    // returns that global as-is, which is null (not an empty array) until
+    // something actually calls register_importer() — true whenever no
+    // importer plugin is active, e.g. a fresh install. Native import.php
+    // never hits this directly: it only ever reads $importers via isset(),
+    // and PHP auto-vivifies null into an array the moment popular_importers
+    // gets merged in via `$importers[$id] = [...]`, so by the time IT
+    // foreach()es, an assignment has always already happened. This code
+    // foreach()es the raw result directly, so it needs its own guard.
+    $active = get_importers();
+    if (!is_array($active)) {
+      $active = [];
+    }
+
+    $can_install = current_user_can("install_plugins");
+    $popular = $can_install ? wp_get_popular_importers() : [];
+
+    $merged = [];
+
+    foreach ($active as $id => $data) {
+      $merged[] = [
+        "id" => $id,
+        "name" => $data[0],
+        "description" => $data[1],
+        "status" => "active",
+        "runUrl" => esc_url_raw(self_admin_url("admin.php?import=" . $id)),
+      ];
+    }
+
+    // Same de-dup + dummy-registration logic as native import.php: a
+    // popular importer already covered by an active one is skipped.
+    foreach ($popular as $pop_key => $pop) {
+      $importer_id = isset($pop["importer-id"]) ? $pop["importer-id"] : $pop_key;
+      if (isset($active[$pop_key]) || isset($active[$importer_id])) {
+        continue;
+      }
+
+      $plugin_slug = isset($pop["plugin-slug"]) ? $pop["plugin-slug"] : "";
+      $entry = [
+        "id" => $importer_id,
+        "name" => $pop["name"],
+        "description" => $pop["description"],
+        "slug" => $plugin_slug,
+        // Deterministic regardless of current status — provided for every
+        // entry so the front end never has to construct an admin URL
+        // itself (this respects any custom/network admin path).
+        "runUrl" => esc_url_raw(self_admin_url("admin.php?import=" . $importer_id)),
+      ];
+
+      if ($plugin_slug !== "" && file_exists(WP_PLUGIN_DIR . "/" . $plugin_slug)) {
+        if (!function_exists("get_plugins")) {
+          require_once ABSPATH . "wp-admin/includes/plugin.php";
+        }
+        $plugins = get_plugins("/" . $plugin_slug);
+        if ($plugins) {
+          $keys = array_keys($plugins);
+          $entry["status"] = "installed_inactive";
+          $entry["pluginFile"] = $plugin_slug . "/" . $keys[0];
+        } else {
+          $entry["status"] = "not_installed";
+        }
+      } else {
+        $entry["status"] = "not_installed";
+      }
+
+      $merged[] = $entry;
+    }
+
+    usort($merged, function ($a, $b) {
+      return strcasecmp($a["name"], $b["name"]);
+    });
+
+    // Any third-party output hooked to import_filters (a genuine, if rarely
+    // used, extension point) — same capture-and-relay approach as Tools'
+    // tool_box. Empty on a site with nothing hooked to it.
+    ob_start();
+    do_action("import_filters");
+    $native_filters_html = trim((string) ob_get_clean());
+
+    return [
+      "importers" => $merged,
+      "canInstallPlugins" => $can_install,
+      "installNonce" => wp_create_nonce("updates"),
+      "ajaxUrl" => esc_url_raw(admin_url("admin-ajax.php")),
+      "pluginSearchUrl" => esc_url_raw(network_admin_url("plugin-install.php?tab=search&type=tag&s=importer")),
+      "nativeFiltersHtml" => $native_filters_html,
+    ];
+  }
+}
diff --git a/admin/src/Pages/SubApps.php b/admin/src/Pages/SubApps.php
index f8ec6ab..53d51ed 100644
--- a/admin/src/Pages/SubApps.php
+++ b/admin/src/Pages/SubApps.php
@@ -35,6 +35,7 @@ class SubApps
   public static function pages()
   {
     return [
+      "aurora-admin-modules" => ["title" => __("Modules", "aurora-admin"), "entry" => "modules"],
       "aurora-admin-menu-creator" => ["title" => __("Menu Creator", "aurora-admin"), "entry" => "menu-creator"],
       "aurora-admin-notices" => ["title" => __("Admin Notices", "aurora-admin"), "entry" => "admin-notices"],
       "aurora-admin-roles" => ["title" => __("Role Editor", "aurora-admin"), "entry" => "role-editor"],
@@ -164,6 +165,13 @@ class SubApps
       $data["theme"] = wp_get_theme()->get("Name");
     }
 
+    // The Menu Creator editor needs the raw top-level menu, which can't be
+    // read over REST (the admin $menu isn't built there). Pass the snapshot
+    // captured during this admin page load instead.
+    if ($page === "aurora-admin-menu-creator") {
+      $data["nativeItems"] = \AuroraAdmin\MenuCreator\MenuCreator::native_snapshot();
+    }
+
     $root_id = "aurora-admin-" . $pages[$page]["entry"] . "-root";
     ?>
     <div
diff --git a/admin/src/Pages/ToolsPage.php b/admin/src/Pages/ToolsPage.php
new file mode 100644
index 0000000..a45fa37
--- /dev/null
+++ b/admin/src/Pages/ToolsPage.php
@@ -0,0 +1,72 @@
+<?php
+namespace AuroraAdmin\Pages;
+
+defined("ABSPATH") || exit();
+
+/**
+ * Registers the "Available Tools" screen (tools.php) for the "full admin
+ * takeover" initiative — a real hijacked replacement, not just a reframed
+ * native page.
+ *
+ * tools.php's whole purpose is being an extension point: other plugins add
+ * their own cards to it via the `tool_box` action (WooCommerce, migration
+ * tools, etc. have historically used it). A pure from-scratch rebuild would
+ * silently drop that content the moment Aurora takes over the screen, so
+ * this still captures and re-renders whatever `tool_box` produces — Aurora
+ * owns the page shell (header, card styling, layout) but not the content of
+ * hooks it doesn't control.
+ *
+ * Import, Export, Site Health, Export/Erase Personal Data, and the Theme/
+ * Plugin File Editors are separate screens (their own load-{file} hooks) and
+ * are not covered by this — Available Tools only.
+ *
+ * Native tools.php's "Categories and Tags Converter" card is NOT produced by
+ * the tool_box hook — it's hardcoded directly in core's own template, gated
+ * on the `import` capability plus category/tag manage_terms. Replicated here
+ * with the identical gate so visibility exactly matches what core itself
+ * would have shown.
+ */
+class ToolsPage
+{
+  public function __construct()
+  {
+    ScreenHijack::register(
+      "load-tools.php",
+      "edit_posts", // Matches core's own capability for this screen.
+      "full_admin_takeover",
+      "tools",
+      "aurora-admin-tools-root",
+      null,
+      null,
+      function () {
+        // Same gate core's own tools.php applies before showing the
+        // Categories and Tags Converter card.
+        $show_converter = false;
+        if (current_user_can("import")) {
+          $cats = get_taxonomy("category");
+          $tags = get_taxonomy("post_tag");
+          $show_converter =
+            ($cats && current_user_can($cats->cap->manage_terms)) ||
+            ($tags && current_user_can($tags->cap->manage_terms));
+        }
+
+        // The native call to do_action('tool_box') already happened during
+        // this same request (inside the buffer ScreenHijack discards) — this
+        // is a second, independent invocation solely to capture its output
+        // for Aurora's own page, so any OTHER plugin's tool_box card still
+        // shows up here. Standard "buffer a hook to capture its markup"
+        // pattern; safe for the well-behaved, output-only callbacks this
+        // hook is meant for.
+        ob_start();
+        do_action("tool_box");
+        $native_tools_html = trim((string) ob_get_clean());
+
+        return [
+          "showCategoriesConverter" => $show_converter,
+          "importUrl" => esc_url_raw(admin_url("import.php")),
+          "nativeToolsHtml" => $native_tools_html,
+        ];
+      }
+    );
+  }
+}
diff --git a/admin/src/Security/Security.php b/admin/src/Security/Security.php
index 519e427..debc516 100644
--- a/admin/src/Security/Security.php
+++ b/admin/src/Security/Security.php
@@ -111,6 +111,7 @@ class Security
     // Drop the s.w.org DNS-prefetch the emoji script adds.
     add_filter("wp_resource_hints", function ($hints, $relation_type) {
       if ($relation_type === "dns-prefetch") {
+        // phpcs:ignore WordPress.NamingConventions.PrefixAllGlobals.NonPrefixedHooknameFound -- "emoji_svg_url" is a WordPress core filter (wp-includes/formatting.php), not a hook this plugin owns; it is applied here only to read core's own emoji SVG base URL so the matching s.w.org dns-prefetch hint can be identified and removed.
         $emoji_svg = apply_filters("emoji_svg_url", "https://s.w.org/images/core/emoji/");
         $hints = array_filter($hints, function ($h) use ($emoji_svg) {
           return strpos((string) $h, $emoji_svg) === false && strpos((string) $h, "s.w.org") === false;
diff --git a/admin/src/Shell/MenuSerializer.php b/admin/src/Shell/MenuSerializer.php
index 43dae02..e3f728f 100644
--- a/admin/src/Shell/MenuSerializer.php
+++ b/admin/src/Shell/MenuSerializer.php
@@ -102,6 +102,62 @@ class MenuSerializer
       $items[] = $entry;
     }
 
+    // Apply the Menu Creator's saved order (if any) for the current user.
+    // Configured items come first in their saved order; anything not in the
+    // config — separators, and newly installed plugins' menu items — keeps
+    // its original position after them, so new menu items never disappear.
+    $order = \AuroraAdmin\MenuCreator\MenuCreator::ordered_slugs();
+    if ($order) {
+      $rank = array_flip($order);
+      $tail = count($order);
+      $decorated = [];
+      foreach ($items as $i => $entry) {
+        $slug = isset($entry["id"]) ? $entry["id"] : "";
+        $r = $slug !== "" && isset($rank[$slug]) ? $rank[$slug] : $tail + $i;
+        $decorated[] = ["r" => $r, "i" => $i, "entry" => $entry];
+      }
+      usort($decorated, function ($a, $b) {
+        return $a["r"] <=> $b["r"] ?: $a["i"] <=> $b["i"];
+      });
+      $items = array_map(function ($d) {
+        return $d["entry"];
+      }, $decorated);
+    }
+
+    return $items;
+  }
+
+  /**
+   * Raw top-level menu items ({native_id,title,icon}) for the Menu Creator
+   * editor. Unlike serialize() this must be captured BEFORE MenuCreator hides
+   * anything (so hidden items still appear and can be toggled back on) — and
+   * it can't run over REST, where the admin $menu isn't built. See
+   * MenuCreator::capture_native().
+   */
+  public static function top_level_items()
+  {
+    global $menu;
+    if (!is_array($menu)) {
+      return [];
+    }
+    $items = [];
+    foreach ($menu as $item) {
+      $classes = isset($item[4]) ? $item[4] : "";
+      if (strpos($classes, "wp-menu-separator") !== false) {
+        continue;
+      }
+      $cap = isset($item[1]) ? $item[1] : "";
+      $slug = isset($item[2]) ? $item[2] : "";
+      if ($slug === "" || $slug === "aurora-admin" || empty($cap) || !current_user_can($cap)) {
+        continue;
+      }
+      $title = self::clean_title(isset($item[0]) ? $item[0] : "");
+      $items[] = [
+        "native_id" => $slug,
+        "title" => $title["title"],
+        "icon" => self::resolve_icon(isset($item[6]) ? $item[6] : ""),
+      ];
+    }
     return $items;
   }
 
diff --git a/admin/src/Shell/Shell.php b/admin/src/Shell/Shell.php
index eccc63d..7518b0c 100644
--- a/admin/src/Shell/Shell.php
+++ b/admin/src/Shell/Shell.php
@@ -250,6 +250,7 @@ class Shell
   {
     $items = [
       ["id" => "aurora-admin", "title" => __("Settings", "aurora-admin"), "icon" => "dashicons-admin-generic"],
+      ["id" => "aurora-admin-modules", "title" => __("Modules", "aurora-admin"), "icon" => "dashicons-screenoptions"],
       ["id" => "aurora-admin-menu-creator", "title" => __("Menu Creator", "aurora-admin"), "icon" => "dashicons-menu-alt"],
       ["id" => "aurora-admin-notices", "title" => __("Admin Notices", "aurora-admin"), "icon" => "dashicons-megaphone"],
       ["id" => "aurora-admin-roles", "title" => __("Role Editor", "aurora-admin"), "icon" => "dashicons-groups"],
diff --git a/app/src/entries/export.js b/app/src/entries/export.js
new file mode 100644
index 0000000..c2d3067
--- /dev/null
+++ b/app/src/entries/export.js
@@ -0,0 +1,10 @@
+import { createApp } from 'vue';
+import '@/shell/shell-frame.css';
+import Export from '@/pages/export/Export.vue';
+
+const mountEl = document.getElementById('aurora-admin-export-root');
+
+if (mountEl) {
+  const data = JSON.parse(mountEl.dataset.auroraAdmin || '{}');
+  createApp(Export, { serverData: data }).mount(mountEl);
+}
diff --git a/app/src/entries/import.js b/app/src/entries/import.js
new file mode 100644
index 0000000..ef492b5
--- /dev/null
+++ b/app/src/entries/import.js
@@ -0,0 +1,10 @@
+import { createApp } from 'vue';
+import '@/shell/shell-frame.css';
+import Import from '@/pages/import/Import.vue';
+
+const mountEl = document.getElementById('aurora-admin-import-root');
+
+if (mountEl) {
+  const data = JSON.parse(mountEl.dataset.auroraAdmin || '{}');
+  createApp(Import, { serverData: data }).mount(mountEl);
+}
diff --git a/app/src/entries/modules.js b/app/src/entries/modules.js
new file mode 100644
index 0000000..fa5db7a
--- /dev/null
+++ b/app/src/entries/modules.js
@@ -0,0 +1,10 @@
+import { createApp } from 'vue';
+import '@/shell/shell-frame.css';
+import Modules from '@/pages/modules/Modules.vue';
+
+const mountEl = document.getElementById('aurora-admin-modules-root');
+
+if (mountEl) {
+  const data = JSON.parse(mountEl.dataset.auroraAdmin || '{}');
+  createApp(Modules, { serverData: data }).mount(mountEl);
+}
diff --git a/app/src/entries/tools.js b/app/src/entries/tools.js
new file mode 100644
index 0000000..3d5d03e
--- /dev/null
+++ b/app/src/entries/tools.js
@@ -0,0 +1,10 @@
+import { createApp } from 'vue';
+import '@/shell/shell-frame.css';
+import Tools from '@/pages/tools/Tools.vue';
+
+const mountEl = document.getElementById('aurora-admin-tools-root');
+
+if (mountEl) {
+  const data = JSON.parse(mountEl.dataset.auroraAdmin || '{}');
+  createApp(Tools, { serverData: data }).mount(mountEl);
+}
diff --git a/app/src/pages/_shared/AppListShell.vue b/app/src/pages/_shared/AppListShell.vue
index 811173e..1a28273 100644
--- a/app/src/pages/_shared/AppListShell.vue
+++ b/app/src/pages/_shared/AppListShell.vue
@@ -80,7 +80,10 @@ const search = defineModel('search', { type: String, default: '' });
      current scroll position, looking like nothing happened until you
      scrolled all the way back up. */
   height: calc(100vh - var(--aurora-toolbar-h) - 60px);
-  margin: -32px;
+  /* -20px cancels the scroller's 20px padding (shell-frame.css's two-layer
+     scroll rule) so the shell still bleeds to the rounded frame's inner
+     edge. Was -32px back when #wpbody-content padded the content directly. */
+  margin: -20px;
   padding: 22px;
   box-sizing: border-box;
   /* No background — html/body already paint the page gradient; this was
diff --git a/app/src/pages/activity-log/ActivityLog.vue b/app/src/pages/activity-log/ActivityLog.vue
index 8fc6746..e6d789e 100644
--- a/app/src/pages/activity-log/ActivityLog.vue
+++ b/app/src/pages/activity-log/ActivityLog.vue
@@ -1,7 +1,5 @@
 <script setup>
 import { ref, computed, watch, onMounted } from 'vue';
-import AppListShell from '../_shared/AppListShell.vue';
-import AppListItem from '../_shared/AppListItem.vue';
 
 const props = defineProps({
   serverData: { type: Object, required: true },
@@ -15,28 +13,67 @@ const api = (path) =>
     return r.json();
   });
 
-const ACTION_TYPES = [
+// Two tabs: "Admin" = site/content activity, "User" = account activity
+// (login/logout/registration/profile updates) — object_type 'user' is the
+// dividing line the REST route's `scope` param filters on.
+const TABS = [
+  { key: 'admin', label: 'Admin' },
+  { key: 'user', label: 'User' },
+];
+
+const ADMIN_ACTIONS = [
   ['', 'All Actions'],
-  ['post_created', 'Post created'],
-  ['post_updated', 'Post updated'],
-  ['post_deleted', 'Post deleted'],
-  ['user_registered', 'User registered'],
-  ['user_updated', 'User updated'],
-  ['login', 'Login'],
-  ['plugin_activated', 'Plugin activated'],
-  ['plugin_deactivated', 'Plugin deactivated'],
-  ['theme_switched', 'Theme switched'],
-  ['settings_updated', 'Settings updated'],
+  ['created', 'Created'],
+  ['updated', 'Updated'],
+  ['deleted', 'Deleted'],
+  ['activated', 'Activated'],
+  ['deactivated', 'Deactivated'],
+  ['switched', 'Switched'],
+];
+const USER_ACTIONS = [
+  ['', 'All Actions'],
+  ['registered', 'Registered'],
+  ['profile_updated', 'Profile updated'],
+  ['login', 'Logged in'],
+  ['logout', 'Logged out'],
 ];
 const OBJECT_TYPES = [
   ['', 'All Types'],
   ['post', 'Post'],
-  ['user', 'User'],
+  ['page', 'Page'],
+  ['attachment', 'Attachment'],
   ['plugin', 'Plugin'],
   ['theme', 'Theme'],
   ['settings', 'Settings'],
 ];
 
+const TYPE_LABELS = {
+  post: 'Post',
+  page: 'Page',
+  attachment: 'Attachment',
+  user: 'User',
+  plugin: 'Plugin',
+  theme: 'Theme',
+  settings: 'Settings',
+};
+const ACTION_LABELS = {
+  created: 'Created',
+  updated: 'Updated',
+  deleted: 'Deleted',
+  registered: 'Registered',
+  profile_updated: 'Profile updated',
+  login: 'Logged in',
+  logout: 'Logged out',
+  activated: 'Activated',
+  deactivated: 'Deactivated',
+  switched: 'Switched',
+};
+const typeLabel = (t) => TYPE_LABELS[t] || (t ? t.charAt(0).toUpperCase() + t.slice(1) : '—');
+const actionLabel = (a) => ACTION_LABELS[a] || a;
+
+const scope = ref('admin');
+const actionOptions = computed(() => (scope.value === 'user' ? USER_ACTIONS : ADMIN_ACTIONS));
+
 const items = ref([]);
 const loading = ref(true);
 const total = ref(0);
@@ -45,14 +82,13 @@ const totalPages = ref(1);
 const actionFilter = ref('');
 const objectFilter = ref('');
 const search = ref('');
-const selectedId = ref(null);
 
 const load = async () => {
   loading.value = true;
   try {
-    const params = new URLSearchParams();
+    const params = new URLSearchParams({ scope: scope.value });
     if (actionFilter.value) params.set('action_type', actionFilter.value);
-    if (objectFilter.value) params.set('object_type', objectFilter.value);
+    if (scope.value === 'admin' && objectFilter.value) params.set('object_type', objectFilter.value);
     if (search.value.trim()) params.set('search', search.value.trim());
     params.set('page', page.value);
     const data = await api(`/activity-log?${params.toString()}`);
@@ -71,83 +107,218 @@ watch([actionFilter, objectFilter, search], () => {
 });
 watch(page, load);
 
-const selected = computed(() => items.value.find((i) => i.id === selectedId.value) || null);
+const setScope = (key) => {
+  if (scope.value === key) return;
+  scope.value = key;
+  actionFilter.value = '';
+  objectFilter.value = '';
+  page.value = 1;
+  load();
+};
 
 const formatDate = (s) => (s ? new Date(s.replace(' ', 'T')).toLocaleString() : '');
+
+const rowRange = computed(() => {
+  if (!total.value) return '0';
+  const start = (page.value - 1) * 20 + 1;
+  const end = Math.min(page.value * 20, total.value);
+  return `${start}–${end}`;
+});
+const goPage = (p) => {
+  page.value = Math.min(Math.max(1, p), totalPages.value);
+};
 </script>
 
 <template>
-  <AppListShell
-    v-model:search="search"
-    title="Activity Log"
-    search-placeholder="Search activities…"
-    :count-label="`${total} ITEMS`"
-    :page="page"
-    :has-prev="page > 1"
-    :has-next="page < totalPages"
-    detail-icon="dashicons-clock"
-    detail-title="Activity Details"
-    detail-text="Select an activity from the list to view detailed information."
-    :has-selection="!!selected"
-    @prev-page="page--"
-    @next-page="page++"
-  >
-    <template #header-actions>
-      <button type="button" @click="load">
+  <main class="activity-page">
+    <header class="activity-page__header">
+      <div>
+        <p class="activity-page__eyebrow">Aurora Admin</p>
+        <h1>Activity Log</h1>
+      </div>
+      <button type="button" class="icon-button" title="Refresh" :disabled="loading" @click="load">
         <span class="dashicons dashicons-update" />
       </button>
-    </template>
+    </header>
 
-    <template #filters>
-      <select v-model="actionFilter" class="activity-log__select">
-        <option v-for="[v, l] in ACTION_TYPES" :key="v" :value="v">{{ l }}</option>
-      </select>
-      <select v-model="objectFilter" class="activity-log__select">
-        <option v-for="[v, l] in OBJECT_TYPES" :key="v" :value="v">{{ l }}</option>
-      </select>
-    </template>
+    <div class="activity-page__tabs">
+      <button
+        v-for="tab in TABS"
+        :key="tab.key"
+        type="button"
+        class="filter-pill"
+        :class="{ 'is-active': scope === tab.key }"
+        @click="setScope(tab.key)"
+      >
+        {{ tab.label }}
+      </button>
+    </div>
 
-    <template #list>
-      <p v-if="!loading && !items.length" style="font-size: 0.8125rem; color: var(--aurora-text-muted); padding: 20px 4px; text-align: center;">
-        No activities found
-      </p>
-      <AppListItem
-        v-for="i in items"
-        :key="i.id"
-        icon="dashicons-clock"
-        :title="i.objectLabel || i.actionType"
-        :subtitle="`${i.userName || 'System'} · ${formatDate(i.createdAt)}`"
-        :active="i.id === selectedId"
-        @click="selectedId = i.id"
-      />
-    </template>
-
-    <template #detail>
-      <div v-if="selected" class="activity-detail">
-        <h2>{{ selected.objectLabel || selected.actionType }}</h2>
-        <dl>
-          <dt>Action</dt><dd>{{ selected.actionType }}</dd>
-          <dt>Object type</dt><dd>{{ selected.objectType }}</dd>
-          <dt>User</dt><dd>{{ selected.userName || 'System' }}</dd>
-          <dt>Date</dt><dd>{{ formatDate(selected.createdAt) }}</dd>
-        </dl>
-        <pre v-if="selected.details">{{ JSON.stringify(selected.details, null, 2) }}</pre>
+    <section class="activity-page__toolbar" aria-label="Activity filters and search">
+      <div class="activity-page__filters">
+        <select v-model="actionFilter" class="activity-page__select">
+          <option v-for="[v, l] in actionOptions" :key="v" :value="v">{{ l }}</option>
+        </select>
+        <select v-if="scope === 'admin'" v-model="objectFilter" class="activity-page__select">
+          <option v-for="[v, l] in OBJECT_TYPES" :key="v" :value="v">{{ l }}</option>
+        </select>
       </div>
-    </template>
-  </AppListShell>
+      <label class="activity-page__search">
+        <span class="dashicons dashicons-search" />
+        <input v-model="search" type="search" placeholder="Search activity…" />
+      </label>
+    </section>
+
+    <section class="activity-table" aria-label="Activity Log">
+      <div class="activity-table__head">
+        <div>Date</div>
+        <div>Author</div>
+        <div>IP Address</div>
+        <div>Type</div>
+        <div>Action</div>
+        <div>Description</div>
+      </div>
+
+      <div v-if="loading" class="activity-table__empty">Loading activity...</div>
+      <div v-else-if="!items.length" class="activity-table__empty">No activity found.</div>
+
+      <article v-for="i in items" v-else :key="i.id" class="activity-row">
+        <div class="activity-row__cell" data-label="Date">{{ formatDate(i.createdAt) }}</div>
+        <div class="activity-row__cell activity-row__author" data-label="Author">
+          <template v-if="i.userId">
+            <img class="activity-row__avatar" :src="i.userAvatar" :alt="i.userName" width="32" height="32" />
+            <div class="activity-row__author-info">
+              <a :href="i.userEditUrl">{{ i.userName }}</a>
+              <span v-if="i.userRole" class="activity-row__role">{{ i.userRole }}</span>
+              <span v-if="i.userEmail" class="activity-row__email">{{ i.userEmail }}</span>
+            </div>
+          </template>
+          <span v-else>System</span>
+        </div>
+        <div class="activity-row__cell" data-label="IP Address">{{ i.ipAddress || '—' }}</div>
+        <div class="activity-row__cell" data-label="Type">
+          <span class="type-badge">{{ typeLabel(i.objectType) }}</span>
+        </div>
+        <div class="activity-row__cell" data-label="Action">{{ actionLabel(i.actionType) }}</div>
+        <div class="activity-row__cell activity-row__desc" data-label="Description">{{ i.objectLabel || '—' }}</div>
+      </article>
+
+      <footer v-if="!loading && items.length" class="activity-table__footer">
+        <div>{{ rowRange }} of {{ total }}</div>
+        <div class="activity-table__pager">
+          <button type="button" :disabled="page <= 1" @click="goPage(1)">
+            <span class="dashicons dashicons-controls-skipback" />
+          </button>
+          <button type="button" :disabled="page <= 1" @click="goPage(page - 1)">
+            <span class="dashicons dashicons-arrow-left-alt2" />
+          </button>
+          <span>Page {{ page }} of {{ totalPages }}</span>
+          <button type="button" :disabled="page >= totalPages" @click="goPage(page + 1)">
+            <span class="dashicons dashicons-arrow-right-alt2" />
+          </button>
+          <button type="button" :disabled="page >= totalPages" @click="goPage(totalPages)">
+            <span class="dashicons dashicons-controls-skipforward" />
+          </button>
+        </div>
+      </footer>
+    </section>
+  </main>
 </template>
 
 <style scoped>
-.activity-log__select {
-  padding: 5px 10px; border-radius: var(--aurora-radius-sm); border: 1px solid var(--aurora-border);
-  background: var(--aurora-bg-subtle); color: var(--aurora-text); font-size: 0.75rem;
+.activity-page { min-height: calc(100vh - 112px); padding: 0; color: var(--aurora-text); background: transparent; }
+.activity-page__header {
+  display: flex; align-items: flex-end; justify-content: space-between; gap: 18px; margin-bottom: 18px;
 }
-.activity-detail h2 { margin: 0 0 16px; font-size: 1.1rem; color: var(--aurora-text); }
-.activity-detail dl { display: grid; grid-template-columns: 120px 1fr; gap: 8px 12px; font-size: 0.8125rem; margin: 0; }
-.activity-detail dt { color: var(--aurora-text-muted); }
-.activity-detail dd { margin: 0; color: var(--aurora-text); }
-.activity-detail pre {
-  margin-top: 18px; padding: 12px; background: var(--aurora-bg-subtle);
-  border-radius: var(--aurora-radius-sm); font-size: 0.75rem; overflow-x: auto; color: var(--aurora-text);
+.activity-page__eyebrow {
+  margin: 0 0 7px; color: var(--aurora-text-muted); font-size: 0.72rem;
+  font-weight: 800; letter-spacing: 0; text-transform: uppercase;
+}
+.activity-page h1 { margin: 0; color: var(--aurora-text); font-size: 1.45rem; line-height: 1.15; }
+
+.icon-button {
+  width: 42px; min-height: 42px; border: 1px solid var(--aurora-border); border-radius: var(--aurora-radius-sm);
+  color: var(--aurora-text); background: var(--aurora-bg-subtle); display: inline-flex;
+  align-items: center; justify-content: center; cursor: pointer;
+}
+.icon-button:hover:not(:disabled) { border-color: var(--aurora-text-muted); }
+.icon-button:disabled { opacity: 0.45; cursor: not-allowed; }
+
+.activity-page__tabs { display: flex; gap: 8px; margin-bottom: 14px; }
+.filter-pill {
+  display: inline-flex; align-items: center; gap: 8px; min-height: 34px;
+  border: 1px solid var(--aurora-border); border-radius: 999px; background: var(--aurora-bg-subtle);
+  color: var(--aurora-text-muted); padding: 0 16px; font-size: 0.78rem; font-weight: 800; cursor: pointer;
+}
+.filter-pill.is-active { border-color: var(--aurora-text-muted); background: var(--aurora-frame-bg); color: var(--aurora-text); }
+
+.activity-page__toolbar { display: flex; align-items: center; justify-content: space-between; gap: 18px; margin-bottom: 12px; }
+.activity-page__filters { display: flex; align-items: center; gap: 8px; flex-wrap: wrap; }
+.activity-page__select {
+  padding: 7px 10px; border-radius: var(--aurora-radius-sm); border: 1px solid var(--aurora-border);
+  background: var(--aurora-bg-subtle); color: var(--aurora-text); font-size: 0.78rem;
+}
+.activity-page__search {
+  width: min(280px, 100%); min-height: 38px; border: 1px solid var(--aurora-border); border-radius: var(--aurora-radius-sm);
+  background: var(--aurora-bg-subtle); display: flex; align-items: center; gap: 8px; padding: 0 12px; color: var(--aurora-text-muted);
+}
+.activity-page__search input {
+  width: 100%; min-width: 0; border: 0; outline: 0; box-shadow: none; background: transparent;
+  color: var(--aurora-text); font-size: 0.84rem;
+}
+.activity-page__search input::placeholder { color: var(--aurora-text-muted); }
+
+.activity-table { overflow: hidden; border: 1px solid var(--aurora-frame-border); border-radius: var(--aurora-radius-sm); background: var(--aurora-frame-bg); }
+.activity-table__head, .activity-row {
+  display: grid;
+  grid-template-columns: 190px minmax(160px, 0.8fr) 130px 110px 140px minmax(180px, 1.6fr);
+  align-items: center;
+}
+.activity-table__head {
+  min-height: 44px; border-bottom: 1px solid var(--aurora-border); color: var(--aurora-text);
+  font-size: 0.79rem; font-weight: 850;
+}
+.activity-table__head > div { min-height: 44px; padding: 0 16px; display: flex; align-items: center; }
+.activity-row { min-height: 76px; border-bottom: 1px solid var(--aurora-border); }
+.activity-row:hover { background: var(--aurora-bg-subtle); }
+.activity-row__cell {
+  min-width: 0; padding: 12px 16px; color: var(--aurora-text-muted); font-size: 0.8rem;
+  line-height: 1.4; overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
+}
+.activity-row__desc { color: var(--aurora-text); white-space: normal; }
+
+.activity-row__author { display: flex; align-items: center; gap: 10px; white-space: normal; }
+.activity-row__avatar { border-radius: 50%; flex-shrink: 0; display: block; }
+.activity-row__author-info { min-width: 0; display: flex; flex-direction: column; gap: 1px; }
+.activity-row__author-info a {
+  color: var(--aurora-accent); font-weight: 700; font-size: 0.8125rem; text-decoration: none;
+  overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
+}
+.activity-row__author-info a:hover { text-decoration: underline; }
+.activity-row__role, .activity-row__email {
+  font-size: 0.71rem; color: var(--aurora-text-muted); overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
+}
+.type-badge {
+  display: inline-block; border-radius: 999px; background: var(--aurora-bg-subtle); color: var(--aurora-text-muted);
+  padding: 2px 10px; font-size: 0.68rem; font-weight: 850; box-shadow: inset 0 0 0 1px var(--aurora-border);
+}
+.activity-table__empty { padding: 38px 18px; color: var(--aurora-text-muted); font-size: 0.85rem; text-align: center; }
+.activity-table__footer {
+  min-height: 50px; border-top: 1px solid var(--aurora-border); display: flex; align-items: center;
+  justify-content: flex-end; gap: 26px; padding: 0 16px; color: var(--aurora-text-muted); font-size: 0.8rem;
+}
+.activity-table__pager { display: flex; align-items: center; gap: 8px; }
+.activity-table__pager button {
+  width: 28px; height: 28px; border: 0; border-radius: var(--aurora-radius-sm);
+  background: transparent; color: var(--aurora-text-muted); cursor: pointer;
+}
+.activity-table__pager button:not(:disabled):hover { background: var(--aurora-bg-subtle); color: var(--aurora-text); }
+.activity-table__pager button:disabled { opacity: 0.4; cursor: not-allowed; }
+
+@media (max-width: 1100px) {
+  .activity-table__head { display: none; }
+  .activity-row { grid-template-columns: 1fr; padding: 10px 0; }
+  .activity-row__cell { white-space: normal; }
+  .activity-row__cell::before { content: attr(data-label) ': '; font-weight: 700; color: var(--aurora-text); }
 }
 </style>
diff --git a/app/src/pages/export/Export.vue b/app/src/pages/export/Export.vue
new file mode 100644
index 0000000..4d112c9
--- /dev/null
+++ b/app/src/pages/export/Export.vue
@@ -0,0 +1,222 @@
+<script setup>
+import { reactive, ref, onMounted } from 'vue';
+
+const props = defineProps({
+  serverData: { type: Object, required: true },
+});
+
+const contentType = ref('all');
+
+const filters = reactive({
+  category: '',
+  post_author: '',
+  post_start_date: '',
+  post_end_date: '',
+  post_status: '',
+  page_author: '',
+  page_start_date: '',
+  page_end_date: '',
+  page_status: '',
+  attachment_start_date: '',
+  attachment_end_date: '',
+});
+
+// Standard WP post statuses (matches core's own get_post_stati({internal: false})).
+const STATUSES = [
+  { value: '', label: 'All' },
+  { value: 'publish', label: 'Published' },
+  { value: 'future', label: 'Scheduled' },
+  { value: 'draft', label: 'Draft' },
+  { value: 'pending', label: 'Pending Review' },
+  { value: 'private', label: 'Private' },
+  { value: 'trash', label: 'Trash' },
+];
+
+const categories = ref([]);
+const authors = ref([]);
+const loadingOptions = ref(true);
+
+onMounted(async () => {
+  try {
+    const headers = { 'X-WP-Nonce': props.serverData.restNonce };
+    const [catsRes, usersRes] = await Promise.all([
+      fetch(`${props.serverData.restUrl}wp/v2/categories?per_page=100`, { headers }),
+      fetch(`${props.serverData.restUrl}wp/v2/users?per_page=100`, { headers }),
+    ]);
+    categories.value = catsRes.ok ? await catsRes.json() : [];
+    authors.value = usersRes.ok ? await usersRes.json() : [];
+  } finally {
+    loadingOptions.value = false;
+  }
+});
+
+// Building and navigating to a real export.php?download=true&... URL (not a
+// fetch) so the browser's normal file-download flow handles the response —
+// this is the exact same request native WordPress's own form would submit,
+// so the file it returns is unmodified.
+//
+// Every relevant param is always sent, even when blank. Native's own HTML
+// <select> elements always submit a name=value pair regardless of which
+// option is picked, and export.php's own PHP reads $_GET['cat'] etc.
+// directly with no isset() guard — omitting a param when "All" is selected
+// (as this used to) triggers PHP "Undefined array key" warnings that, with
+// display_errors on (any site with debugging enabled), get echoed straight
+// into the downloaded file before the XML, corrupting it.
+const download = () => {
+  const params = new URLSearchParams({ download: 'true', content: contentType.value });
+
+  if (contentType.value === 'posts') {
+    params.set('cat', filters.category);
+    params.set('post_author', filters.post_author);
+    params.set('post_start_date', filters.post_start_date);
+    params.set('post_end_date', filters.post_end_date);
+    params.set('post_status', filters.post_status);
+  } else if (contentType.value === 'pages') {
+    params.set('page_author', filters.page_author);
+    params.set('page_start_date', filters.page_start_date);
+    params.set('page_end_date', filters.page_end_date);
+    params.set('page_status', filters.page_status);
+  } else if (contentType.value === 'attachment') {
+    params.set('attachment_start_date', filters.attachment_start_date);
+    params.set('attachment_end_date', filters.attachment_end_date);
+  }
+
+  window.location.href = `${props.serverData.exportUrl}?${params.toString()}`;
+};
+</script>
+
+<template>
+  <main class="export-page">
+    <header class="export-page__header">
+      <p class="export-page__eyebrow">Aurora Admin</p>
+      <h1>Export</h1>
+      <p class="export-page__lead">
+        Create an XML file (WordPress eXtended RSS, or WXR) containing your posts, pages, comments,
+        custom fields, categories, and tags. Import it into another WordPress site to bring this
+        content over.
+      </p>
+    </header>
+
+    <section class="export-page__card">
+      <h2>Choose what to export</h2>
+
+      <div class="export-page__options">
+        <label class="export-page__radio">
+          <input type="radio" value="all" v-model="contentType" />
+          <div>
+            <strong>All content</strong>
+            <p>All of your posts, pages, comments, custom fields, terms, navigation menus, and custom posts.</p>
+          </div>
+        </label>
+
+        <label class="export-page__radio">
+          <input type="radio" value="posts" v-model="contentType" />
+          <strong>Posts</strong>
+        </label>
+        <div v-if="contentType === 'posts'" class="export-page__filters">
+          <label>
+            Category
+            <select v-model="filters.category" :disabled="loadingOptions">
+              <option value="">All</option>
+              <option v-for="c in categories" :key="c.id" :value="c.id">{{ c.name }}</option>
+            </select>
+          </label>
+          <label>
+            Author
+            <select v-model="filters.post_author" :disabled="loadingOptions">
+              <option value="">All</option>
+              <option v-for="a in authors" :key="a.id" :value="a.id">{{ a.name }}</option>
+            </select>
+          </label>
+          <label>Start date <input type="date" v-model="filters.post_start_date" /></label>
+          <label>End date <input type="date" v-model="filters.post_end_date" /></label>
+          <label>
+            Status
+            <select v-model="filters.post_status">
+              <option v-for="s in STATUSES" :key="s.value" :value="s.value">{{ s.label }}</option>
+            </select>
+          </label>
+        </div>
+
+        <label class="export-page__radio">
+          <input type="radio" value="pages" v-model="contentType" />
+          <strong>Pages</strong>
+        </label>
+        <div v-if="contentType === 'pages'" class="export-page__filters">
+          <label>
+            Author
+            <select v-model="filters.page_author" :disabled="loadingOptions">
+              <option value="">All</option>
+              <option v-for="a in authors" :key="a.id" :value="a.id">{{ a.name }}</option>
+            </select>
+          </label>
+          <label>Start date <input type="date" v-model="filters.page_start_date" /></label>
+          <label>End date <input type="date" v-model="filters.page_end_date" /></label>
+          <label>
+            Status
+            <select v-model="filters.page_status">
+              <option v-for="s in STATUSES" :key="s.value" :value="s.value">{{ s.label }}</option>
+            </select>
+          </label>
+        </div>
+
+        <label class="export-page__radio">
+          <input type="radio" value="attachment" v-model="contentType" />
+          <strong>Media</strong>
+        </label>
+        <div v-if="contentType === 'attachment'" class="export-page__filters">
+          <label>Start date <input type="date" v-model="filters.attachment_start_date" /></label>
+          <label>End date <input type="date" v-model="filters.attachment_end_date" /></label>
+        </div>
+      </div>
+
+      <button type="button" class="export-page__submit" @click="download">Download Export File</button>
+    </section>
+  </main>
+</template>
+
+<style scoped>
+.export-page { min-height: calc(100vh - 112px); color: var(--aurora-text); background: transparent; }
+.export-page__eyebrow {
+  margin: 0 0 7px; color: var(--aurora-text-muted); font-size: 0.72rem;
+  font-weight: 800; text-transform: uppercase;
+}
+.export-page__header h1 { margin: 0; font-size: 1.45rem; line-height: 1.15; }
+.export-page__lead {
+  margin: 12px 0 0; max-width: 640px; color: var(--aurora-text-muted);
+  font-size: 0.875rem; line-height: 1.6;
+}
+
+.export-page__card {
+  margin-top: 24px; background: var(--aurora-card-bg); border: 1px solid var(--aurora-card-border);
+  border-radius: var(--aurora-radius-lg); padding: 22px 24px; max-width: 560px;
+}
+.export-page__card h2 { margin: 0 0 16px; font-size: 1rem; font-weight: 700; }
+
+.export-page__options { display: flex; flex-direction: column; gap: 4px; }
+.export-page__radio {
+  display: flex; align-items: flex-start; gap: 10px; padding: 8px 4px;
+  cursor: pointer; font-size: 0.875rem;
+}
+.export-page__radio input { margin-top: 3px; accent-color: var(--aurora-accent); }
+.export-page__radio p { margin: 4px 0 0; font-size: 0.8125rem; color: var(--aurora-text-muted); font-weight: 400; }
+
+.export-page__filters {
+  display: grid; grid-template-columns: 1fr 1fr; gap: 10px;
+  margin: 0 0 8px 30px; padding: 12px; background: var(--aurora-bg-subtle);
+  border-radius: var(--aurora-radius-md);
+}
+.export-page__filters label {
+  display: flex; flex-direction: column; gap: 4px; font-size: 0.75rem;
+  color: var(--aurora-text-muted); font-weight: 600;
+}
+.export-page__filters select, .export-page__filters input[type='date'] {
+  padding: 6px 8px; border-radius: var(--aurora-radius-sm); border: 1px solid var(--aurora-border);
+  background: var(--aurora-card-bg); color: var(--aurora-text); font-size: 0.8125rem; font-weight: 400;
+}
+
+.export-page__submit {
+  margin-top: 20px; border: none; border-radius: var(--aurora-radius-sm); padding: 10px 20px;
+  font-size: 0.875rem; font-weight: 600; cursor: pointer; background: var(--aurora-accent); color: #fff;
+}
+</style>
diff --git a/app/src/pages/import/Import.vue b/app/src/pages/import/Import.vue
new file mode 100644
index 0000000..13c9bbb
--- /dev/null
+++ b/app/src/pages/import/Import.vue
@@ -0,0 +1,178 @@
+<script setup>
+import { reactive } from 'vue';
+
+const props = defineProps({
+  serverData: { type: Object, required: true },
+});
+
+const api = (path, options = {}) =>
+  fetch(`${props.serverData.restUrl}aurora-admin/v1${path}`, {
+    ...options,
+    headers: {
+      'Content-Type': 'application/json',
+      'X-WP-Nonce': props.serverData.restNonce,
+      ...(options.headers || {}),
+    },
+  }).then(async (r) => {
+    const data = await r.json().catch(() => ({}));
+    if (!r.ok) throw new Error(data.message || 'Request failed');
+    return data;
+  });
+
+// Local, mutable copy so a row's status/action can update in place once
+// installed/activated, without needing a full page reload.
+const importers = reactive(props.serverData.importers.map((i) => ({ ...i, busy: false, error: '' })));
+
+const goToImporter = (importer) => {
+  window.location.href = importer.runUrl;
+};
+
+const activate = async (importer) => {
+  importer.busy = true;
+  importer.error = '';
+  try {
+    await api('/plugins/activate', {
+      method: 'POST',
+      body: JSON.stringify({ file: importer.pluginFile }),
+    });
+    goToImporter(importer);
+  } catch (e) {
+    importer.error = e.message || 'Could not activate the importer.';
+  } finally {
+    importer.busy = false;
+  }
+};
+
+const installAndActivate = async (importer) => {
+  importer.busy = true;
+  importer.error = '';
+  try {
+    // Reuses WordPress core's own admin-ajax "install-plugin" action — the
+    // exact same request native's "Install Now" button triggers — rather
+    // than reimplementing plugin installation.
+    const body = new URLSearchParams({
+      action: 'install-plugin',
+      slug: importer.slug,
+      _ajax_nonce: props.serverData.installNonce,
+    });
+    const res = await fetch(props.serverData.ajaxUrl, { method: 'POST', body });
+    const data = await res.json().catch(() => ({}));
+    if (!data.success) {
+      throw new Error(data.data?.errorMessage || 'Installation failed.');
+    }
+
+    // Find the freshly-installed plugin's file path (rather than assuming a
+    // naming convention) via Aurora's own plugins list, then activate it
+    // through the same route the Plugins screen uses.
+    const list = await api('/plugins');
+    const installed = (Array.isArray(list) ? list : []).find((p) => p.slug === importer.slug);
+    if (!installed) {
+      throw new Error('Installed, but the plugin could not be found afterward.');
+    }
+    await api('/plugins/activate', {
+      method: 'POST',
+      body: JSON.stringify({ file: installed.file }),
+    });
+    goToImporter(importer);
+  } catch (e) {
+    importer.error = e.message || 'Could not install the importer.';
+  } finally {
+    importer.busy = false;
+  }
+};
+</script>
+
+<template>
+  <main class="import-page">
+    <header class="import-page__header">
+      <p class="import-page__eyebrow">Aurora Admin</p>
+      <h1>Import</h1>
+      <p class="import-page__lead">
+        If you have posts or comments in another system, WordPress can import those into this
+        site. Choose a system to import from below.
+      </p>
+    </header>
+
+    <div class="import-page__list">
+      <article v-for="imp in importers" :key="imp.id" class="import-card">
+        <div class="import-card__info">
+          <h3>{{ imp.name }}</h3>
+          <p>{{ imp.description }}</p>
+          <p v-if="imp.error" class="import-card__error">{{ imp.error }}</p>
+        </div>
+        <div class="import-card__action">
+          <a v-if="imp.status === 'active'" class="import-card__btn" @click.prevent="goToImporter(imp)" href="#">
+            Run Importer
+          </a>
+          <button
+            v-else-if="imp.status === 'installed_inactive'"
+            type="button"
+            class="import-card__btn"
+            :disabled="imp.busy"
+            @click="activate(imp)"
+          >
+            {{ imp.busy ? 'Activating…' : 'Run Importer' }}
+          </button>
+          <button
+            v-else
+            type="button"
+            class="import-card__btn"
+            :disabled="imp.busy"
+            @click="installAndActivate(imp)"
+          >
+            {{ imp.busy ? 'Installing…' : 'Install Now' }}
+          </button>
+        </div>
+      </article>
+
+      <p v-if="!importers.length" class="import-page__empty">No importers are available.</p>
+    </div>
+
+    <p v-if="serverData.canInstallPlugins" class="import-page__more">
+      If the importer you need is not listed,
+      <a :href="serverData.pluginSearchUrl">search the plugin directory</a>
+      to see if an importer is available.
+    </p>
+
+    <!-- Rendered from WordPress's own `import_filters` hook — whatever other
+         active plugins add there. Not Aurora-authored content, only
+         Aurora-styled, so nothing another plugin adds here disappears. -->
+    <div v-if="serverData.nativeFiltersHtml" class="import-page__native" v-html="serverData.nativeFiltersHtml" />
+  </main>
+</template>
+
+<style scoped>
+.import-page { min-height: calc(100vh - 112px); color: var(--aurora-text); background: transparent; }
+.import-page__eyebrow {
+  margin: 0 0 7px; color: var(--aurora-text-muted); font-size: 0.72rem;
+  font-weight: 800; text-transform: uppercase;
+}
+.import-page__header h1 { margin: 0; font-size: 1.45rem; line-height: 1.15; }
+.import-page__lead {
+  margin: 12px 0 0; max-width: 640px; color: var(--aurora-text-muted);
+  font-size: 0.875rem; line-height: 1.6;
+}
+
+.import-page__list { margin-top: 24px; display: flex; flex-direction: column; gap: 10px; max-width: 720px; }
+.import-card {
+  display: flex; align-items: center; justify-content: space-between; gap: 20px;
+  background: var(--aurora-card-bg); border: 1px solid var(--aurora-card-border);
+  border-radius: var(--aurora-radius-lg); padding: 16px 20px;
+}
+.import-card__info h3 { margin: 0 0 4px; font-size: 0.9375rem; font-weight: 700; }
+.import-card__info p { margin: 0; font-size: 0.8125rem; color: var(--aurora-text-muted); line-height: 1.5; }
+.import-card__error { color: #e5484d !important; margin-top: 6px !important; }
+.import-card__action { flex-shrink: 0; }
+.import-card__btn {
+  display: inline-block; border: none; border-radius: var(--aurora-radius-sm); padding: 8px 16px;
+  font-size: 0.8125rem; font-weight: 600; cursor: pointer; background: var(--aurora-accent);
+  color: #fff; text-decoration: none; white-space: nowrap;
+}
+.import-card__btn:disabled { opacity: 0.6; cursor: default; }
+
+.import-page__empty { color: var(--aurora-text-muted); font-size: 0.875rem; }
+.import-page__more { margin-top: 18px; font-size: 0.8125rem; color: var(--aurora-text-muted); }
+.import-page__more a { color: var(--aurora-accent); }
+
+.import-page__native { margin-top: 18px; }
+</style>
diff --git a/app/src/pages/menu-creator/MenuCreator.vue b/app/src/pages/menu-creator/MenuCreator.vue
index 0f5da8b..2c95077 100644
--- a/app/src/pages/menu-creator/MenuCreator.vue
+++ b/app/src/pages/menu-creator/MenuCreator.vue
@@ -37,10 +37,12 @@ const load = async () => {
   }
 };
 
-onMounted(async () => {
+onMounted(() => {
   load();
-  api('/menus/native-items').then((items) => (nativeItems.value = items));
   roleOptions.value = props.serverData.roles || [];
+  // The native top-level menu is provided in serverData (captured server-side
+  // at page load); the REST route can't build the admin menu.
+  nativeItems.value = props.serverData.nativeItems || [];
 });
 
 const filteredMenus = computed(() => {
@@ -55,48 +57,84 @@ const filteredMenus = computed(() => {
 
 const selected = computed(() => menus.value.find((m) => m.id === selectedId.value) || null);
 
-const draft = reactive({ name: '', status: 'draft', roles: [], items: [] });
+const draft = reactive({ name: '', status: 'draft', roles: [] });
+
+// The full ordered list of top-level items being edited. Row order IS the
+// menu order (saved as each item's `order` index). Each row carries its
+// native title/icon plus the per-item overrides (custom label, hidden).
+const orderedItems = ref([]);
+
+// Merge a config's saved items with the live native top-level list: saved
+// items first, in their saved order, then any native items the config
+// doesn't mention yet (e.g. a newly installed plugin) appended at the end,
+// so new menu items are never silently dropped.
+const buildOrdered = (savedItems = []) => {
+  const byId = Object.fromEntries(nativeItems.value.map((n) => [n.native_id, n]));
+  const saved = [...savedItems].sort((a, b) => (a.order || 0) - (b.order || 0));
+  const seen = new Set();
+  const result = [];
+  for (const s of saved) {
+    const n = byId[s.native_id];
+    if (!n) continue; // saved item no longer exists in the admin menu
+    result.push({ native_id: n.native_id, title: n.title, icon: n.icon, label: s.label || '', hidden: !!s.hidden });
+    seen.add(s.native_id);
+  }
+  for (const n of nativeItems.value) {
+    if (seen.has(n.native_id)) continue;
+    result.push({ native_id: n.native_id, title: n.title, icon: n.icon, label: '', hidden: false });
+  }
+  orderedItems.value = result;
+};
 
 const selectMenu = (menu) => {
   selectedId.value = menu.id;
-  Object.assign(draft, {
-    name: menu.name,
-    status: menu.status,
-    roles: [...menu.roles],
-    items: menu.items.map((i) => ({ ...i })),
-  });
+  Object.assign(draft, { name: menu.name, status: menu.status, roles: [...menu.roles] });
+  buildOrdered(menu.items);
 };
 
 const isCreating = ref(false);
 const newMenu = () => {
   selectedId.value = null;
   isCreating.value = true;
-  Object.assign(draft, { name: 'New menu', status: 'draft', roles: [], items: [] });
+  Object.assign(draft, { name: 'New menu', status: 'draft', roles: [] });
+  buildOrdered([]);
 };
 
-const itemState = (nativeId) => draft.items.find((i) => i.native_id === nativeId);
-const toggleHidden = (nativeId) => {
-  let item = itemState(nativeId);
-  if (!item) {
-    item = { native_id: nativeId, label: '', hidden: false, order: 0 };
-    draft.items.push(item);
-  }
-  item.hidden = !item.hidden;
+// Reorder controls: drag-and-drop plus keyboard-friendly up/down buttons.
+const dragIndex = ref(-1);
+const onDragStart = (i) => { dragIndex.value = i; };
+const onDrop = (i) => {
+  const from = dragIndex.value;
+  dragIndex.value = -1;
+  if (from < 0 || from === i) return;
+  const arr = orderedItems.value;
+  const [moved] = arr.splice(from, 1);
+  arr.splice(i, 0, moved);
 };
-const setLabel = (nativeId, label) => {
-  let item = itemState(nativeId);
-  if (!item) {
-    item = { native_id: nativeId, label: '', hidden: false, order: 0 };
-    draft.items.push(item);
-  }
-  item.label = label;
+const move = (i, dir) => {
+  const j = i + dir;
+  const arr = orderedItems.value;
+  if (j < 0 || j >= arr.length) return;
+  [arr[i], arr[j]] = [arr[j], arr[i]];
 };
 
 const saving = ref(false);
 const save = async () => {
   saving.value = true;
   try {
-    const payload = { name: draft.name, status: draft.status, roles: draft.roles, items: draft.items };
+    const payload = {
+      name: draft.name,
+      status: draft.status,
+      roles: draft.roles,
+      // Row order becomes each item's `order`; only send items that actually
+      // override something (renamed or hidden) or that need an explicit order.
+      items: orderedItems.value.map((it, index) => ({
+        native_id: it.native_id,
+        label: it.label || '',
+        hidden: !!it.hidden,
+        order: index,
+      })),
+    };
     if (isCreating.value) {
       const created = await api('/menus', { method: 'POST', body: JSON.stringify(payload) });
       await load();
@@ -188,23 +226,29 @@ const toggleRole = (slug) => {
         </div>
 
         <div class="menu-editor__section">
-          <h3>Menu items</h3>
+          <h3>Menu items — drag to reorder</h3>
           <div class="menu-editor__items">
-            <div v-for="ni in nativeItems" :key="ni.native_id" class="menu-editor__item">
-              <span class="dashicons" :class="ni.icon?.value || 'dashicons-admin-generic'" />
-              <input
-                type="text"
-                :value="itemState(ni.native_id)?.label || ni.title"
-                @input="setLabel(ni.native_id, $event.target.value)"
-              />
+            <div
+              v-for="(it, i) in orderedItems"
+              :key="it.native_id"
+              class="menu-editor__item"
+              :class="{ 'is-hidden': it.hidden }"
+              draggable="true"
+              @dragstart="onDragStart(i)"
+              @dragover.prevent
+              @drop="onDrop(i)"
+            >
+              <span class="menu-editor__drag dashicons dashicons-move" title="Drag to reorder" />
+              <span class="dashicons" :class="it.icon?.value || 'dashicons-admin-generic'" />
+              <input type="text" v-model="it.label" :placeholder="it.title" />
               <label class="menu-editor__hide">
-                <input
-                  type="checkbox"
-                  :checked="!!itemState(ni.native_id)?.hidden"
-                  @change="toggleHidden(ni.native_id)"
-                />
+                <input type="checkbox" v-model="it.hidden" />
                 Hide
               </label>
+              <div class="menu-editor__move">
+                <button type="button" :disabled="i === 0" title="Move up" @click="move(i, -1)">▲</button>
+                <button type="button" :disabled="i === orderedItems.length - 1" title="Move down" @click="move(i, 1)">▼</button>
+              </div>
             </div>
           </div>
         </div>
@@ -243,11 +287,21 @@ const toggleRole = (slug) => {
   display: flex; align-items: center; gap: 10px; padding: 6px 4px;
   border-bottom: 1px solid var(--aurora-frame-border);
 }
+.menu-editor__item.is-hidden { opacity: 0.5; }
+.menu-editor__drag { cursor: grab; color: var(--aurora-text-muted); flex-shrink: 0; }
+.menu-editor__drag:active { cursor: grabbing; }
 .menu-editor__item input[type='text'] {
   flex: 1; padding: 6px 8px; border-radius: var(--aurora-radius-sm); border: 1px solid var(--aurora-border);
   background: var(--aurora-bg-subtle); color: var(--aurora-text); font-size: 0.8125rem;
 }
-.menu-editor__hide { display: flex; align-items: center; gap: 4px; font-size: 0.75rem; color: var(--aurora-text-muted); }
+.menu-editor__hide { display: flex; align-items: center; gap: 4px; font-size: 0.75rem; color: var(--aurora-text-muted); flex-shrink: 0; }
+.menu-editor__move { display: flex; flex-direction: column; gap: 2px; flex-shrink: 0; }
+.menu-editor__move button {
+  border: none; background: var(--aurora-bg-subtle); color: var(--aurora-text-muted);
+  border-radius: 4px; width: 20px; height: 15px; line-height: 1; font-size: 9px; cursor: pointer; padding: 0;
+}
+.menu-editor__move button:disabled { opacity: 0.35; cursor: default; }
+.menu-editor__move button:not(:disabled):hover { color: var(--aurora-accent); }
 .menu-editor__actions { display: flex; justify-content: flex-end; gap: 8px; }
 .menu-editor__actions button {
   border: none; border-radius: var(--aurora-radius-sm); padding: 9px 18px; font-size: 0.875rem; cursor: pointer;
diff --git a/app/src/pages/modules/Modules.vue b/app/src/pages/modules/Modules.vue
new file mode 100644
index 0000000..2494b24
--- /dev/null
+++ b/app/src/pages/modules/Modules.vue
@@ -0,0 +1,144 @@
+<script setup>
+import { reactive, onMounted } from 'vue';
+import { companionPlugins } from './companionPlugins.js';
+
+const props = defineProps({
+  serverData: { type: Object, required: true },
+});
+
+const api = (path, options = {}) =>
+  fetch(`${props.serverData.restUrl}aurora-admin/v1${path}`, {
+    ...options,
+    headers: {
+      'Content-Type': 'application/json',
+      'X-WP-Nonce': props.serverData.restNonce,
+      ...(options.headers || {}),
+    },
+  }).then(async (r) => {
+    const data = await r.json().catch(() => ({}));
+    if (!r.ok) throw new Error(data.message || 'Request failed');
+    return data;
+  });
+
+// Per-plugin UI state, keyed by slug: { status: {installed,active}|null, busy, error }
+const state = reactive(
+  Object.fromEntries(companionPlugins.map((p) => [p.slug, { status: null, busy: false, error: '' }]))
+);
+
+const loadStatus = async (plugin) => {
+  try {
+    state[plugin.slug].status = await api(plugin.statusEndpoint);
+  } catch {
+    state[plugin.slug].status = { installed: false, active: false };
+  }
+};
+
+onMounted(() => {
+  companionPlugins.forEach(loadStatus);
+});
+
+const install = async (plugin) => {
+  const s = state[plugin.slug];
+  if (s.busy) return;
+  s.busy = true;
+  s.error = '';
+  try {
+    const result = await api(plugin.installEndpoint, { method: 'POST' });
+    if (!result.success) {
+      s.error = result.message || 'Installation failed.';
+    }
+    await loadStatus(plugin);
+  } catch (e) {
+    s.error = e.message || 'Installation failed.';
+  } finally {
+    s.busy = false;
+  }
+};
+</script>
+
+<template>
+  <main class="modules">
+    <header class="modules__head">
+      <p class="modules__eyebrow">Aurora Admin</p>
+      <h1>Modules</h1>
+      <p class="modules__lead">
+        Install additional modules to extend Aurora Admin. Each is a separate, standalone plugin —
+        install and activate it here with one click.
+      </p>
+    </header>
+
+    <div class="modules__grid">
+      <article v-for="p in companionPlugins" :key="p.slug" class="module-card">
+        <div class="module-card__top">
+          <span class="module-card__icon dashicons" :class="p.icon" />
+          <span
+            v-if="state[p.slug].status"
+            class="module-card__badge"
+            :class="{ 'is-active': state[p.slug].status.active }"
+          >
+            {{ state[p.slug].status.active ? 'Active' : state[p.slug].status.installed ? 'Installed' : 'Not installed' }}
+          </span>
+        </div>
+        <h3 class="module-card__title">{{ p.label }}</h3>
+        <p class="module-card__desc">{{ p.description }}</p>
+
+        <div class="module-card__action">
+          <div v-if="!state[p.slug].status" class="module-card__checking">Checking…</div>
+          <a v-else-if="state[p.slug].status.active" class="module-card__manage" :href="p.manageUrl">
+            Open {{ p.label }} →
+          </a>
+          <template v-else>
+            <button
+              type="button"
+              class="module-card__install"
+              :disabled="state[p.slug].busy"
+              @click="install(p)"
+            >
+              {{ state[p.slug].busy ? 'Installing…' : state[p.slug].status.installed ? 'Activate' : 'Install & Activate' }}
+            </button>
+            <p v-if="state[p.slug].error" class="module-card__error">{{ state[p.slug].error }}</p>
+          </template>
+        </div>
+      </article>
+    </div>
+  </main>
+</template>
+
+<style scoped>
+.modules { min-height: calc(100vh - 112px); color: var(--aurora-text); background: transparent; }
+.modules__eyebrow {
+  margin: 0 0 7px; color: var(--aurora-text-muted); font-size: 0.72rem;
+  font-weight: 800; text-transform: uppercase;
+}
+.modules__head h1 { margin: 0; font-size: 1.45rem; line-height: 1.15; }
+.modules__lead { margin: 8px 0 0; color: var(--aurora-text-muted); font-size: 0.9rem; max-width: 640px; line-height: 1.6; }
+.modules__grid {
+  margin-top: 24px; display: grid; gap: 16px;
+  grid-template-columns: repeat(auto-fill, minmax(300px, 1fr));
+}
+.module-card {
+  background: var(--aurora-card-bg); border: 1px solid var(--aurora-card-border);
+  border-radius: var(--aurora-radius-lg); padding: 20px 22px;
+  display: flex; flex-direction: column; gap: 8px;
+}
+.module-card__top { display: flex; align-items: center; justify-content: space-between; }
+.module-card__icon { font-size: 26px; width: 26px; height: 26px; color: var(--aurora-accent); }
+.module-card__badge {
+  font-size: 0.6875rem; font-weight: 700; text-transform: uppercase; letter-spacing: 0.03em;
+  color: var(--aurora-text-muted); background: var(--aurora-bg-subtle);
+  border-radius: 999px; padding: 3px 10px;
+}
+.module-card__badge.is-active { color: var(--aurora-accent); }
+.module-card__title { margin: 4px 0 0; font-size: 1rem; font-weight: 700; }
+.module-card__desc { margin: 0; font-size: 0.8125rem; color: var(--aurora-text-muted); line-height: 1.55; flex: 1; }
+.module-card__action { margin-top: 6px; }
+.module-card__checking { font-size: 0.8125rem; color: var(--aurora-text-muted); }
+.module-card__manage { font-size: 0.8125rem; font-weight: 600; color: var(--aurora-accent); text-decoration: none; }
+.module-card__manage:hover { text-decoration: underline; }
+.module-card__install {
+  border: none; border-radius: var(--aurora-radius-sm); padding: 9px 16px; font-size: 0.8125rem;
+  font-weight: 600; cursor: pointer; background: var(--aurora-accent); color: #fff;
+}
+.module-card__install:disabled { opacity: 0.6; cursor: default; }
+.module-card__error { margin: 8px 0 0; font-size: 0.8125rem; color: #e5484d; }
+</style>
diff --git a/app/src/pages/modules/companionPlugins.js b/app/src/pages/modules/companionPlugins.js
new file mode 100644
index 0000000..b058a84
--- /dev/null
+++ b/app/src/pages/modules/companionPlugins.js
@@ -0,0 +1,39 @@
+/**
+ * Aurora's standalone companion plugins, installable from the Modules page.
+ * Single source of truth for both the card metadata and the REST endpoints
+ * that back them (admin/src/Rest/CompanionPluginData.php) — a new companion
+ * plugin only needs an entry here plus a matching PHP-side entry, no other
+ * wiring.
+ */
+export const companionPlugins = [
+  {
+    slug: 'file-manager',
+    icon: 'dashicons-portfolio',
+    label: 'Aurora File Manager',
+    description:
+      'Browse, edit, and manage your site’s files (themes, plugins, uploads, and more) directly from wp-admin.',
+    statusEndpoint: '/companion-plugins/file-manager/status',
+    installEndpoint: '/companion-plugins/file-manager/install',
+    manageUrl: 'admin.php?page=aurora-file-manager',
+  },
+  {
+    slug: 'database-explorer',
+    icon: 'dashicons-editor-table',
+    label: 'Aurora Database Explorer',
+    description:
+      'A Supabase-style database browser inside wp-admin — see every table with row counts and sizes, browse paginated data, and run your own read-only queries.',
+    statusEndpoint: '/companion-plugins/database-explorer/status',
+    installEndpoint: '/companion-plugins/database-explorer/install',
+    manageUrl: 'admin.php?page=aurora-database-explorer',
+  },
+  {
+    slug: 'site-backup',
+    icon: 'dashicons-migrate',
+    label: 'Aurora Site Backup',
+    description:
+      'Full site backup (database + files) and restore-in-place, on demand or on a recurring schedule, stored locally or on your own S3-compatible or Google Drive remote storage.',
+    statusEndpoint: '/companion-plugins/site-backup/status',
+    installEndpoint: '/companion-plugins/site-backup/install',
+    manageUrl: 'admin.php?page=aurora-site-backup',
+  },
+];
diff --git a/app/src/pages/plugins/Plugins.vue b/app/src/pages/plugins/Plugins.vue
index 56ab35f..a605e5f 100644
--- a/app/src/pages/plugins/Plugins.vue
+++ b/app/src/pages/plugins/Plugins.vue
@@ -81,6 +81,7 @@ const runAction = async (action, plugin) => {
   busyFile.value = plugin.file;
   error.value = '';
   notice.value = '';
+  let redirecting = false;
   try {
     const data = await request(`/plugins/${action}`, {
       method: action === 'delete' ? 'DELETE' : 'POST',
@@ -88,14 +89,21 @@ const runAction = async (action, plugin) => {
     });
     notice.value = data.message || 'Done';
     if (data.redirect) {
+      redirecting = true;
       window.location.href = data.redirect;
       return;
     }
-    await load();
   } catch (err) {
     error.value = err.message || 'Action failed';
   } finally {
     busyFile.value = '';
+    // Always re-sync the list with the real backend state, even after an
+    // error: activate_plugin() can return a WP_Error for benign "unexpected
+    // output" from a plugin's own activation while still leaving the plugin
+    // active, which previously left the row showing its stale pre-click
+    // state (you clicked Activate but it still read "deactivated"). Skipped
+    // only when navigating away (deactivating Aurora itself redirects).
+    if (!redirecting) await load();
   }
 };
 
diff --git a/app/src/pages/settings/Settings.vue b/app/src/pages/settings/Settings.vue
index 67b2719..2251ba2 100644
--- a/app/src/pages/settings/Settings.vue
+++ b/app/src/pages/settings/Settings.vue
@@ -10,22 +10,6 @@ const props = defineProps({
 
 const visibleCategories = settingsCategories;
 
-// Shared REST fetcher for field types that need their own API calls beyond
-// the generic wp/v2/settings save flow (currently just 'companion-plugin').
-const api = (path, options = {}) =>
-  fetch(`${props.serverData.restUrl}aurora-admin/v1${path}`, {
-    ...options,
-    headers: {
-      'X-WP-Nonce': props.serverData.restNonce,
-      'Content-Type': 'application/json',
-      ...(options.headers || {}),
-    },
-  }).then(async (r) => {
-    const body = await r.json().catch(() => ({}));
-    if (!r.ok) throw new Error(body.message || 'Request failed');
-    return body;
-  });
-
 // Working copy of the settings, seeded from the server + field defaults.
 const settings = reactive({ ...(props.serverData.settings || {}) });
 visibleCategories.forEach((cat) =>
@@ -264,7 +248,6 @@ const importSettings = (e) => {
           :field="f"
           :options="optionsFor(f)"
           :disabled="!!f.dependsOn && !settings[f.dependsOn]"
-          :api="api"
           v-model="settings[f.key]"
         />
       </div>
diff --git a/app/src/pages/settings/components/SettingsField.vue b/app/src/pages/settings/components/SettingsField.vue
index 537523a..313d152 100644
--- a/app/src/pages/settings/components/SettingsField.vue
+++ b/app/src/pages/settings/components/SettingsField.vue
@@ -14,9 +14,6 @@ const props = defineProps({
   // True when this field's `dependsOn` key is falsy — greys out the
   // control without hiding it, so the relationship stays visible.
   disabled: { type: Boolean, default: false },
-  // Shared REST fetcher, only used by field types that need their own API
-  // calls beyond the generic wp/v2/settings save flow (companion-plugin).
-  api: { type: Function, default: null },
 });
 const emit = defineEmits(['update:modelValue']);
 
@@ -76,43 +73,14 @@ const pickFont = (name) => {
   fontOpen.value = false;
 };
 const openFontList = () => {
-  fontQuery.value = props.modelValue || '';
+  // Start with an empty query so the whole font list is shown on focus.
+  // Seeding it with the current font filtered the list down to just that
+  // one font, making it impossible to pick a different one without first
+  // clearing the box. The active font stays highlighted via `val === name`.
+  fontQuery.value = '';
   fontOpen.value = true;
 };
 
-// Companion plugin (Aurora File Manager) install card -----------------------
-const companionStatus = ref(null); // { installed, active } | null while loading
-const companionBusy = ref(false);
-const companionError = ref('');
-
-const loadCompanionStatus = async () => {
-  if (props.field.type !== 'companion-plugin' || !props.api) return;
-  try {
-    companionStatus.value = await props.api(props.field.statusEndpoint);
-  } catch {
-    companionStatus.value = { installed: false, active: false };
-  }
-};
-if (props.field.type === 'companion-plugin') {
-  loadCompanionStatus();
-}
-
-const installCompanion = async () => {
-  if (!props.api) return;
-  companionBusy.value = true;
-  companionError.value = '';
-  try {
-    const result = await props.api(props.field.installEndpoint, { method: 'POST' });
-    if (!result.success) {
-      companionError.value = result.message || 'Installation failed.';
-    }
-    await loadCompanionStatus();
-  } catch (e) {
-    companionError.value = e.message || 'Installation failed.';
-  } finally {
-    companionBusy.value = false;
-  }
-};
 </script>
 
 <template>
@@ -273,31 +241,6 @@ const installCompanion = async () => {
         </div>
       </div>
 
-      <!-- Companion plugin install card -->
-      <div v-else-if="field.type === 'companion-plugin'" class="field__companion">
-        <div v-if="!companionStatus" class="field__companion-status">Checking…</div>
-        <template v-else>
-          <a
-            v-if="companionStatus.active"
-            class="field__companion-manage"
-            :href="field.manageUrl"
-          >
-            Installed &amp; active — open File Manager →
-          </a>
-          <template v-else>
-            <button
-              type="button"
-              class="field__companion-install"
-              :disabled="companionBusy"
-              @click="installCompanion"
-            >
-              {{ companionBusy ? 'Installing…' : (companionStatus.installed ? 'Activate' : 'Install & Activate') }}
-            </button>
-            <p v-if="companionError" class="field__companion-error">{{ companionError }}</p>
-          </template>
-        </template>
-      </div>
-
       <!-- Repeater -->
       <div v-else-if="field.type === 'repeater'" class="field__repeater">
         <div v-for="(row, i) in rows" :key="i" class="field__repeater-row">
@@ -460,20 +403,6 @@ const installCompanion = async () => {
 .field__font-item:hover { background: var(--aurora-bg-subtle); }
 .field__font-item--active { color: var(--aurora-accent); }
 
-/* Companion plugin install card */
-.field__companion-status { font-size: 0.8125rem; color: var(--aurora-text-muted); }
-.field__companion-install {
-  border: none; border-radius: var(--aurora-radius-sm); background: var(--aurora-accent); color: #fff;
-  padding: 8px 16px; font-size: 0.8125rem; font-weight: 600; cursor: pointer;
-}
-.field__companion-install:disabled { opacity: 0.6; cursor: default; }
-.field__companion-manage {
-  display: inline-block; font-size: 0.8125rem; font-weight: 600;
-  color: var(--aurora-accent); text-decoration: none;
-}
-.field__companion-manage:hover { text-decoration: underline; }
-.field__companion-error { margin: 8px 0 0; font-size: 0.8125rem; color: #e5484d; }
-
 @media (max-width: 782px) {
   .field { grid-template-columns: 1fr; gap: 12px; }
 }
diff --git a/app/src/pages/settings/settingsConfig.js b/app/src/pages/settings/settingsConfig.js
index c3720ee..8594444 100644
--- a/app/src/pages/settings/settingsConfig.js
+++ b/app/src/pages/settings/settingsConfig.js
@@ -99,7 +99,9 @@ export const settingsGroups = [
             key: 'font_family',
             type: 'font-picker',
             label: 'Font family',
-            description: 'Google Font used across the Aurora interface.',
+            description:
+              'Optional. Leave empty to use your system font (no external requests). ' +
+              'Choosing a font loads it from Google Fonts (fonts.googleapis.com) on each admin page.',
           },
         ],
       },
@@ -195,6 +197,46 @@ export const settingsGroups = [
           },
         ],
       },
+      {
+        id: 'login-redirect',
+        title: 'Login Redirect',
+        subtitle: 'Control where visitors and users land, before and after login',
+        icon: 'dashicons-redo',
+        fields: [
+          {
+            key: 'login_redirect_enabled',
+            type: 'toggle',
+            label: 'Enable login redirects',
+            description:
+              'Turns on the redirects below. This never changes, hides, or blocks your login page — wp-login.php always stays reachable at its normal address, so this can’t lock you out of logging in.',
+          },
+          {
+            key: 'redirect_unauthenticated_url',
+            type: 'text',
+            label: 'Redirect logged-out wp-admin visitors',
+            description:
+              'Send visitors who try to access wp-admin without being logged in to this URL instead of the login screen. Leave empty to keep the normal WordPress behavior.',
+            placeholder: 'https://example.com/',
+            dependsOn: 'login_redirect_enabled',
+          },
+          {
+            key: 'redirect_roles',
+            type: 'multiselect',
+            label: 'Redirect these roles after login',
+            description: 'Users with these roles are sent to the URL below after logging in, instead of the dashboard.',
+            optionsSource: 'roles',
+            dependsOn: 'login_redirect_enabled',
+          },
+          {
+            key: 'redirect_after_login_url',
+            type: 'text',
+            label: 'Redirect to',
+            description: 'Where the roles above land after logging in.',
+            placeholder: 'https://example.com/welcome',
+            dependsOn: 'login_redirect_enabled',
+          },
+        ],
+      },
       {
         id: 'menu',
         title: 'Menu',
@@ -281,6 +323,22 @@ export const settingsGroups = [
           },
         ],
       },
+      {
+        id: 'editor',
+        title: 'Editor',
+        subtitle: 'Choose the editor used for posts and pages',
+        icon: 'dashicons-edit',
+        fields: [
+          {
+            key: 'disable_gutenberg',
+            type: 'toggle',
+            label: 'Disable Gutenberg',
+            description:
+              'Use WordPress’s classic editor instead of the block editor for all post types. Off by default.',
+            default: false,
+          },
+        ],
+      },
       {
         id: 'admin-takeover',
         title: 'Admin Takeover',
@@ -493,51 +551,6 @@ export const settingsGroups = [
       },
     ],
   },
-  {
-    id: 'add-ons',
-    title: 'Add-ons',
-    icon: 'dashicons-admin-plugins',
-    categories: [
-      {
-        id: 'add-ons',
-        title: 'Add-ons',
-        subtitle: 'Standalone companion plugins',
-        icon: 'dashicons-admin-plugins',
-        fields: [
-          {
-            key: 'file_manager_addon',
-            type: 'companion-plugin',
-            label: 'Aurora File Manager',
-            description:
-              'Browse, edit, and manage your site’s files (themes, plugins, uploads, and more) directly from wp-admin. Distributed as a separate plugin rather than bundled here, since WordPress.org’s Plugin Directory policy doesn’t allow this category of functionality in a directory-listed plugin — restrictions or not.',
-            statusEndpoint: '/companion-plugins/file-manager/status',
-            installEndpoint: '/companion-plugins/file-manager/install',
-            manageUrl: 'admin.php?page=aurora-file-manager',
-          },
-          {
-            key: 'database_explorer_addon',
-            type: 'companion-plugin',
-            label: 'Aurora Database Explorer',
-            description:
-              'A Supabase-style database browser inside wp-admin — see every table with row counts and sizes, browse paginated data, and run your own read-only SELECT/SHOW/DESCRIBE/EXPLAIN queries. Distributed as a separate plugin rather than bundled here, since WordPress.org’s Plugin Directory review treats direct database-query tooling the same way it treats file-management functionality.',
-            statusEndpoint: '/companion-plugins/database-explorer/status',
-            installEndpoint: '/companion-plugins/database-explorer/install',
-            manageUrl: 'admin.php?page=aurora-database-explorer',
-          },
-          {
-            key: 'site_backup_addon',
-            type: 'companion-plugin',
-            label: 'Aurora Site Backup',
-            description:
-              'Full site backup (database + files) and restore-in-place, on demand or on a recurring schedule, stored locally or on your own S3-compatible or Google Drive remote storage. Distributed as a separate plugin rather than bundled here, to keep Aurora Admin’s own footprint away from arbitrary file-write functionality.',
-            statusEndpoint: '/companion-plugins/site-backup/status',
-            installEndpoint: '/companion-plugins/site-backup/install',
-            manageUrl: 'admin.php?page=aurora-site-backup',
-          },
-        ],
-      },
-    ],
-  },
 ];
 
 /**
diff --git a/app/src/pages/setup-wizard/SetupWizard.vue b/app/src/pages/setup-wizard/SetupWizard.vue
index bddf204..1c082dc 100644
--- a/app/src/pages/setup-wizard/SetupWizard.vue
+++ b/app/src/pages/setup-wizard/SetupWizard.vue
@@ -31,7 +31,9 @@ const steps = [
         key: 'font_family',
         type: 'font-picker',
         label: 'Font family',
-        description: 'A Google Font used across the Aurora interface.',
+        description:
+          'Optional. Leave empty for your system font (no external requests). ' +
+          'Choosing a font loads it from Google Fonts.',
       },
     ],
   },
@@ -207,7 +209,6 @@ const finish = async (target) => {
               v-for="f in current.fields"
               :key="f.key"
               :field="f"
-              :api="null"
               v-model="settings[f.key]"
             />
           </div>
diff --git a/app/src/pages/tools/Tools.vue b/app/src/pages/tools/Tools.vue
new file mode 100644
index 0000000..aa37037
--- /dev/null
+++ b/app/src/pages/tools/Tools.vue
@@ -0,0 +1,76 @@
+<script setup>
+const props = defineProps({
+  serverData: { type: Object, required: true },
+});
+</script>
+
+<template>
+  <main class="tools-page">
+    <header class="tools-page__header">
+      <p class="tools-page__eyebrow">Aurora Admin</p>
+      <h1>Tools</h1>
+    </header>
+
+    <div class="tools-page__grid">
+      <!-- Core's Categories and Tags Converter card — not produced by a
+           hook, so it's reproduced here directly (same visibility gate as
+           native tools.php: the `import` capability plus category/tag
+           manage_terms). -->
+      <article v-if="serverData.showCategoriesConverter" class="card">
+        <h2 class="title">Categories and Tags Converter</h2>
+        <p>
+          If you want to convert your categories to tags (or vice versa), use the
+          <a :href="serverData.importUrl">Categories and Tags Converter</a> available from the Import screen.
+        </p>
+      </article>
+
+      <!-- Rendered from WordPress's own `tool_box` hook — whatever other
+           active plugins add there (WooCommerce, migration tools, etc.).
+           Not Aurora-authored content, only Aurora-styled, so nothing
+           another plugin adds to this screen silently disappears. -->
+      <div v-if="serverData.nativeToolsHtml" class="tools-page__native" v-html="serverData.nativeToolsHtml" />
+    </div>
+    <p v-if="!serverData.showCategoriesConverter && !serverData.nativeToolsHtml" class="tools-page__empty">
+      No tools are available right now.
+    </p>
+  </main>
+</template>
+
+<style scoped>
+.tools-page { min-height: calc(100vh - 112px); color: var(--aurora-text); background: transparent; }
+.tools-page__eyebrow {
+  margin: 0 0 7px; color: var(--aurora-text-muted); font-size: 0.72rem;
+  font-weight: 800; text-transform: uppercase;
+}
+.tools-page__header h1 { margin: 0 0 24px; font-size: 1.45rem; line-height: 1.15; }
+.tools-page__empty { color: var(--aurora-text-muted); font-size: 0.875rem; }
+
+.tools-page__grid {
+  display: grid; gap: 16px;
+  grid-template-columns: repeat(auto-fill, minmax(300px, 1fr));
+}
+/* The v-html'd wrapper participates as if it weren't there, so cards inside
+   it (there may be several, one per plugin hooked to tool_box) lay out in
+   the same grid as Aurora's own card above instead of stacking inside one
+   grid cell. */
+.tools-page__native { display: contents; }
+
+/* Native tool_box markup is `.card > h2.title + p` (core's own Categories &
+   Tags Converter shape), but other plugins' cards may not match exactly —
+   styled broadly by element, with .card/.title as the primary targets. The
+   plain selectors below cover Aurora's own card (real template markup, gets
+   Vue's scoping attribute automatically); :deep() additionally reaches into
+   the v-html'd content, which the scoping attribute can't be applied to. */
+.card, .tools-page__native :deep(.card) {
+  background: var(--aurora-card-bg); border: 1px solid var(--aurora-card-border);
+  border-radius: var(--aurora-radius-lg); padding: 20px 22px; margin: 0;
+}
+.card h2, .card h3, .card .title, .tools-page__native :deep(h2), .tools-page__native :deep(h3), .tools-page__native :deep(.title) {
+  margin: 0 0 10px; font-size: 1rem; font-weight: 700; color: var(--aurora-text);
+}
+.card p, .tools-page__native :deep(p) {
+  margin: 0; font-size: 0.8125rem; color: var(--aurora-text-muted); line-height: 1.6;
+}
+.card a, .tools-page__native :deep(a) { color: var(--aurora-accent); text-decoration: none; }
+.card a:hover, .tools-page__native :deep(a:hover) { text-decoration: underline; }
+</style>
diff --git a/app/src/shell/components/SearchModal.vue b/app/src/shell/components/SearchModal.vue
index 4e4c0d0..06ed5f3 100644
--- a/app/src/shell/components/SearchModal.vue
+++ b/app/src/shell/components/SearchModal.vue
@@ -16,6 +16,18 @@ const highlighted = ref(0);
 let debounceTimer;
 let requestSeq = 0;
 
+// wp/v2/search returns titles with HTML entities (e.g. "Ben &amp; Jerry").
+// Decode them for display WITHOUT rendering markup: a <textarea>'s innerHTML
+// is RCDATA, so tags stay literal text and only entities are decoded — then
+// we read them back as a plain string and render with text interpolation.
+// This replaces a v-html bind on item.title, which would have executed any
+// HTML an unfiltered_html user put in a post title (admin→admin XSS).
+const decodeEntities = (str) => {
+  const el = document.createElement('textarea');
+  el.innerHTML = String(str ?? '');
+  return el.value;
+};
+
 const search = async () => {
   const q = query.value.trim();
   if (q.length < 2) {
@@ -121,7 +133,7 @@ onUnmounted(() => document.removeEventListener('keydown', onKeydown));
               @mouseenter="highlighted = i"
               @click="openResult(item)"
             >
-              <span class="smodal__result-title" v-html="item.title" />
+              <span class="smodal__result-title">{{ decodeEntities(item.title) }}</span>
               <span class="smodal__result-type">{{ item.subtype }}</span>
             </button>
           </li>
diff --git a/app/src/shell/shell-frame.css b/app/src/shell/shell-frame.css
index e9dd04e..3cb3f10 100644
--- a/app/src/shell/shell-frame.css
+++ b/app/src/shell/shell-frame.css
@@ -195,7 +195,11 @@ html.aurora-ready #wpbody-content {
   color: var(--aurora-text);
   border: 1px solid var(--aurora-frame-border);
   border-radius: var(--aurora-radius-xl);
-  box-shadow: 0 1px 2px rgba(0, 0, 0, 0.06);
+  /* A real soft shadow (not the old barely-there 0.06 one) so the rounded
+     card edge reads against dense, full-bleed page content — otherwise the
+     frame is technically rounded but visually invisible except on sparse
+     pages. Follows the border-radius, defining the card shape. */
+  box-shadow: 0 6px 24px rgba(0, 0, 0, 0.4);
   margin: 16px var(--aurora-gutter-r) 24px 24px;
   padding: 32px;
   min-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
@@ -323,7 +327,10 @@ html.aurora-ready .theme-install-overlay .wp-full-overlay-main {
   background: var(--aurora-frame-bg);
   border: 1px solid var(--aurora-frame-border);
   border-radius: var(--aurora-radius-xl);
-  box-shadow: 0 1px 2px rgba(0, 0, 0, 0.06);
+  /* Match #wpbody-content's shadow so the dashboard's rounded card edge
+     reads the same way — the dashboard is dense and full-bleed, so the old
+     0.06 shadow left it looking un-rounded. */
+  box-shadow: 0 6px 24px rgba(0, 0, 0, 0.4);
   margin: 16px var(--aurora-gutter-r) 24px 24px;
   box-sizing: border-box;
   /* Same unconditional height cap as #wpbody-content's base rule — this
@@ -335,8 +342,15 @@ html.aurora-ready .theme-install-overlay .wp-full-overlay-main {
      no document
      scroll left to fall back on either. */
   max-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
-  overflow-y: auto;
-  overflow-anchor: none;
+  /* The frame itself clips (rounded corners) and lays out as a column; the
+     actual scrolling happens on the inner app-root (see the shared scroll
+     rule below), so the native scrollbar lives INSIDE the rounded card
+     rather than squaring off its right corners. The 12px padding is the
+     gutter that keeps the scrollbar clear of the corner radius. */
+  overflow: hidden;
+  display: flex;
+  flex-direction: column;
+  padding: 12px;
 }
 
 /* Custom admin notices (Notices::render_for_dashboard(), reparented in
@@ -366,6 +380,75 @@ html.aurora-ready body.toplevel_page_aurora-admin #wpbody-content {
   box-shadow: none;
 }
 
+/* --- Scroll INSIDE the rounded frame -------------------------------------
+   A single element can't both scroll and keep its own rounded corners: the
+   native scrollbar sits in the top/bottom-right corners and squares them
+   off. So the frame clips (overflow:hidden + border-radius) and its Aurora
+   app-root child becomes the real scroll container — the scrollbar then
+   lives inside the rounded card, inset by the frame's 12px padding so it
+   clears the corner radius.
+
+   `:has()` limits the #wpbody-content half to Aurora's own hijacked pages
+   (their mount div is a direct #aurora-admin-*-root child); native WP pages
+   keep their normal single-layer 32px-padded scroll, untouched. Content
+   padding is split 12px (frame) + 20px (scroller) so it still totals the
+   original 32px — pages that assume that (e.g. AppListShell's -32px bleed)
+   keep working. */
+/* `body:not(.toplevel_page_aurora-admin)` excludes the Settings page — it
+   deliberately drops the frame and manages its own -32px/scroll-as-a-whole
+   layout (see Settings.vue), so the two-layer treatment must not touch it. */
+html.aurora-ready body:not(.toplevel_page_aurora-admin) #wpbody-content:has(> [id^="aurora-admin-"][id$="-root"]) {
+  overflow: hidden;
+  display: flex;
+  flex-direction: column;
+  padding: 12px;
+}
+.aurora-dashboard-frame > [id^="aurora-admin-"][id$="-root"],
+html.aurora-ready body:not(.toplevel_page_aurora-admin) #wpbody-content > [id^="aurora-admin-"][id$="-root"] {
+  flex: 1 1 auto;
+  min-height: 0;
+  overflow-y: auto;
+  overflow-anchor: none;
+}
+/* The hijacked/list pages need their content padding on the scroller (the
+   dashboard's own content already pads itself). */
+html.aurora-ready body:not(.toplevel_page_aurora-admin) #wpbody-content > [id^="aurora-admin-"][id$="-root"] {
+  padding: 20px;
+  box-sizing: border-box;
+}
+
+/* --- Themed scrollbars -----------------------------------------------------
+   Skin every scrollbar inside the Aurora shell in a translucent shade of the
+   active theme's accent (derived from --aurora-accent, so it tracks whatever
+   preset is selected) instead of the OS default. The plain accent-soft token
+   is a fallback for engines without color-mix; the 3px transparent border +
+   background-clip:padding-box keeps the thumb slim with a little breathing
+   room around it. */
+html.aurora-ready {
+  scrollbar-width: thin;
+  scrollbar-color: var(--aurora-accent-soft) transparent;
+  scrollbar-color: color-mix(in srgb, var(--aurora-accent) 55%, transparent) transparent;
+}
+html.aurora-ready ::-webkit-scrollbar {
+  width: 12px;
+  height: 12px;
+}
+html.aurora-ready ::-webkit-scrollbar-track,
+html.aurora-ready ::-webkit-scrollbar-corner {
+  background: transparent;
+}
+html.aurora-ready ::-webkit-scrollbar-thumb {
+  border-radius: 999px;
+  border: 3px solid transparent;
+  background-clip: padding-box;
+  background-color: var(--aurora-accent-soft);
+  background-color: color-mix(in srgb, var(--aurora-accent) 45%, transparent);
+}
+html.aurora-ready ::-webkit-scrollbar-thumb:hover {
+  background-color: var(--aurora-accent);
+  background-color: color-mix(in srgb, var(--aurora-accent) 72%, transparent);
+}
+
 /*
  * Native WordPress pages are fully dark-themed by a dedicated stylesheet
  * (admin/assets/native-dark.css), enqueued only on native pages and gated
diff --git a/app/vite.config.js b/app/vite.config.js
index 243f4d1..2d66f70 100644
--- a/app/vite.config.js
+++ b/app/vite.config.js
@@ -36,6 +36,7 @@ export default defineConfig({
         settings: fileURLToPath(new URL('./src/entries/settings.js', import.meta.url)),
         'setup-wizard': fileURLToPath(new URL('./src/entries/setup-wizard.js', import.meta.url)),
         'menu-creator': fileURLToPath(new URL('./src/entries/menu-creator.js', import.meta.url)),
+        modules: fileURLToPath(new URL('./src/entries/modules.js', import.meta.url)),
         'admin-notices': fileURLToPath(new URL('./src/entries/admin-notices.js', import.meta.url)),
         'role-editor': fileURLToPath(new URL('./src/entries/role-editor.js', import.meta.url)),
         'activity-log': fileURLToPath(new URL('./src/entries/activity-log.js', import.meta.url)),
@@ -51,6 +52,9 @@ export default defineConfig({
         'nav-menus': fileURLToPath(new URL('./src/entries/nav-menus.js', import.meta.url)),
         'themes': fileURLToPath(new URL('./src/entries/themes.js', import.meta.url)),
         'widgets': fileURLToPath(new URL('./src/entries/widgets.js', import.meta.url)),
+        'tools': fileURLToPath(new URL('./src/entries/tools.js', import.meta.url)),
+        'export': fileURLToPath(new URL('./src/entries/export.js', import.meta.url)),
+        'import': fileURLToPath(new URL('./src/entries/import.js', import.meta.url)),
         'profile': fileURLToPath(new URL('./src/entries/profile.js', import.meta.url)),
         'bug-report': fileURLToPath(new URL('./src/entries/bug-report.js', import.meta.url)),
       },
diff --git a/aurora-admin.php b/aurora-admin.php
index 349ef4c..fc274e4 100644
--- a/aurora-admin.php
+++ b/aurora-admin.php
@@ -3,7 +3,7 @@
  * Plugin Name: Aurora Admin
  * Plugin URI: https://aurora.auroradragon.studio
  * Description: A modern, fast WordPress admin interface.
- * Version: 3.6.1
+ * Version: 1.12
  * Author: Aurora Dragon Studio
  * Author URI: https://auroradragon.studio
  * Text Domain: aurora-admin
@@ -15,7 +15,7 @@
 
 defined("ABSPATH") || exit();
 
-define("AURORA_ADMIN_VERSION", "3.6.1");
+define("AURORA_ADMIN_VERSION", "1.12");
 define("AURORA_ADMIN_PATH", plugin_dir_path(__FILE__));
 define("AURORA_ADMIN_URL", plugins_url("aurora-admin/"));
 
@@ -45,6 +45,9 @@ require AURORA_ADMIN_PATH . "admin/src/Pages/NativeSettingsPages.php";
 require AURORA_ADMIN_PATH . "admin/src/Rest/PermalinksData.php";
 require AURORA_ADMIN_PATH . "admin/src/Rest/DiscussionData.php";
 require AURORA_ADMIN_PATH . "admin/src/Pages/AppearancePages.php";
+require AURORA_ADMIN_PATH . "admin/src/Pages/ToolsPage.php";
+require AURORA_ADMIN_PATH . "admin/src/Pages/ExportPage.php";
+require AURORA_ADMIN_PATH . "admin/src/Pages/ImportPage.php";
 require AURORA_ADMIN_PATH . "admin/src/Rest/NavMenusData.php";
 require AURORA_ADMIN_PATH . "admin/src/Rest/ThemesData.php";
 require AURORA_ADMIN_PATH . "admin/src/Rest/WidgetsData.php";
@@ -57,6 +60,8 @@ require AURORA_ADMIN_PATH . "admin/src/Roles/RolesData.php";
 require AURORA_ADMIN_PATH . "admin/src/ActivityLog/ActivityLog.php";
 require AURORA_ADMIN_PATH . "admin/src/ActivityLog/ActivityLogData.php";
 require AURORA_ADMIN_PATH . "admin/src/Login/LoginStyle.php";
+require AURORA_ADMIN_PATH . "admin/src/Login/LoginRedirect.php";
+require AURORA_ADMIN_PATH . "admin/src/Editor/DisableGutenberg.php";
 require AURORA_ADMIN_PATH . "admin/src/Media/SvgUploads.php";
 require AURORA_ADMIN_PATH . "admin/src/Media/MediaFolders.php";
 require AURORA_ADMIN_PATH . "admin/src/ImageFormats/ImageFormats.php";
diff --git a/readme.txt b/readme.txt
index 43c3ed0..3857bb4 100644
--- a/readme.txt
+++ b/readme.txt
@@ -4,7 +4,7 @@ Tags: admin, dashboard, admin theme, dark mode, admin redesign
 Requires at least: 5.5
 Tested up to: 7.0
 Requires PHP: 7.4
-Stable tag: 3.6.1
+Stable tag: 1.12
 License: GPLv2 or later
 License URI: https://www.gnu.org/licenses/gpl-2.0.html
 
@@ -32,20 +32,23 @@ Aurora Admin replaces the default WordPress admin with a faster, cleaner interfa
 **Look and feel**
 
 * A real dark mode covering the entire admin, not just a few screens
-* 10 color presets plus 2 flat neutrals
-* macOS-style window chrome for the block editor and other full-screen views
+* 10 color presets plus 2 flat neutrals, applied across the whole interface
+* Rounded, framed content cards with theme-tinted scrollbars; the block editor and other full-screen views get the same treatment
+* Optional Google Font for the interface typeface (off by default — see Privacy below)
 
 Everything in Aurora Admin is free — there's no license key, no locked features, and no upsell.
 
 **Aurora File Manager, Aurora Database Explorer, and Aurora Site Backup (separate plugins)**
 
-File Manager (browse/edit/manage your site's files from wp-admin), Database Explorer (browse your database tables and run read-only queries), and Site Backup (full site backup/restore, optionally to your own S3-compatible or Google Drive storage) previously shipped bundled inside Aurora Admin. All three are now distributed as their own standalone plugins — [Aurora File Manager](https://aurora.auroradragon.studio/file-manager), [Aurora Database Explorer](https://aurora.auroradragon.studio/database-explorer), and [Aurora Site Backup](https://aurora.auroradragon.studio/site-backup) — each installable with one click from Aurora's Settings → Add-ons screen. File-management/code-editing and direct database-query functionality of this kind isn't accepted into the WordPress.org Plugin Directory (see the [Plugin Developer FAQ](https://developer.wordpress.org/plugins/wordpress-org/plugin-developer-faq/#are-there-plugins-you-dont-accept)); Site Backup was split out proactively for the same class of reason, since restoring a backup means writing arbitrary files back into the site. Aurora Admin itself never contains any of that functionality.
+File Manager (browse/edit/manage your site's files from wp-admin), Database Explorer (browse your database tables and run read-only queries), and Site Backup (full site backup/restore, optionally to your own S3-compatible or Google Drive storage) are distributed as their own standalone plugins — [Aurora File Manager](https://aurora.auroradragon.studio/file-manager), [Aurora Database Explorer](https://aurora.auroradragon.studio/database-explorer), and [Aurora Site Backup](https://aurora.auroradragon.studio/site-backup) — each installable with one click from Aurora's Modules screen. File-management/code-editing and direct database-query functionality of this kind isn't accepted into the WordPress.org Plugin Directory (see the [Plugin Developer FAQ](https://developer.wordpress.org/plugins/wordpress-org/plugin-developer-faq/#are-there-plugins-you-dont-accept)); Site Backup is separate for the same class of reason, since restoring a backup means writing arbitrary files back into the site. Aurora Admin itself never contains any of that functionality.
 
-= Privacy / external service =
+= Privacy / external services =
 
 The optional "Report a Bug" screen sends your bug description and basic diagnostics (plugin version, WordPress version, PHP version, active theme name, and your site's domain) to a feedback endpoint on auroraplugins.com when you choose to submit it. Nothing is sent automatically or in the background — this only happens if you fill out and submit that form yourself.
 
-Settings → Add-ons' "Install & Activate" buttons for Aurora File Manager, Aurora Database Explorer, and Aurora Site Backup download that plugin's zip file from aurora.auroradragon.studio using WordPress's own plugin-installer API, the same mechanism the native Plugins → Add New screen uses for WordPress.org-hosted plugins. This only happens when you click one of those buttons — nothing is downloaded automatically or in the background. (Aurora Site Backup's own remote-storage options, if you install and configure it, are documented in that plugin's own readme.)
+The interface font setting (Settings → Appearance) is empty by default, in which case Aurora uses your system font and makes no external requests. If you choose a Google Font, that font file is loaded from Google Fonts (fonts.googleapis.com) on admin pages, which sends a request to Google's servers. Leave the setting empty to avoid any external font requests.
+
+The Modules page's "Install & Activate" buttons for Aurora File Manager, Aurora Database Explorer, and Aurora Site Backup download that plugin's zip file from aurora.auroradragon.studio using WordPress's own plugin-installer API, the same mechanism the native Plugins → Add New screen uses for WordPress.org-hosted plugins. This only happens when you click one of those buttons — nothing is downloaded automatically or in the background. (Aurora Site Backup's own remote-storage options, if you install and configure it, are documented in that plugin's own readme.)
 
 == Installation ==
 
@@ -65,16 +68,16 @@ Yes. Every feature listed above is available with no license key and no restrict
 
 = Will this work with my other plugins? =
 
-Aurora Admin only replaces the built-in WordPress admin screens it explicitly targets (Posts, Pages, Media, Users, Comments, Nav Menus, Widgets, Themes, core Settings screens, Profile, the block editor frame). Screens added by other plugins are untouched. Each replacement can also be toggled off individually in Aurora's settings if you'd rather keep the native screen for something specific.
+Aurora Admin only replaces the built-in WordPress admin screens it explicitly targets (Posts, Pages, Media, Users, Comments, Nav Menus, Widgets, Themes, Tools, Export, Import, core Settings screens, Profile, the block editor frame). Running an already-active importer on the Import screen still opens that importer's own native screen, since its content is entirely owned by whichever plugin registered it. Screens added by other plugins are untouched. Each replacement can also be toggled off individually in Aurora's settings if you'd rather keep the native screen for something specific.
+
+= Does Aurora load anything from external servers? =
+
+Not by default. It only makes an external request if you opt in: choosing a Google Font loads it from Google Fonts, submitting the "Report a Bug" form sends it to auroraplugins.com, and the Modules page's install buttons download the companion plugins on click. See "Privacy / external services" above for details.
 
 = Where do I report a bug? =
 
 Use the "Report a Bug" item in the Aurora sidebar menu, or open a thread in this plugin's support forum.
 
-= Where did File Manager, Database Explorer, and Site Backup go? =
-
-File Manager is now Aurora File Manager, Database Explorer is now Aurora Database Explorer, and Site Backup is now Aurora Site Backup — three separate standalone plugins, each installable with one click from Settings → Add-ons in Aurora Admin, or downloadable directly from [aurora.auroradragon.studio/file-manager](https://aurora.auroradragon.studio/file-manager), [aurora.auroradragon.studio/database-explorer](https://aurora.auroradragon.studio/database-explorer), and [aurora.auroradragon.studio/site-backup](https://aurora.auroradragon.studio/site-backup). File Manager and Database Explorer are distributed separately because WordPress.org's Plugin Directory policy doesn't allow file-management/code-editing or direct database-query functionality in a directory-listed plugin; Site Backup was split out proactively for the same class of reason (restoring a backup writes arbitrary files back into the site).
-
 == Screenshots ==
 
 1. The Aurora dashboard.
@@ -83,53 +86,48 @@ File Manager is now Aurora File Manager, Database Explorer is now Aurora Databas
 
 == Changelog ==
 
-= 3.6.1 =
-* Fixed another round of Plugin Check findings the 3.5.1 fix didn't fully cover: `WordPress.DB.DirectDatabaseQuery.DirectQuery`/`NoCaching` are attributed by PHPCS to the *outer* `$wpdb->get_results()`/`get_row()` call line, while `PreparedSQL.NotPrepared` is attributed to whichever *inner* line the interpolated table name appears on — two different lines in a multi-line call, so a single `phpcs:ignore` comment can only ever cover one of them. Collapsed the remaining multi-line calls in Menu Creator and Admin Notices to single physical lines so one ignore comment covers both sniffs' attributed lines at once. Re-verified with an automated scan plus live REST-dispatch round-trips (menu create/list/get/delete, notice create/render/delete).
+= 1.12 =
+* Added a "Disable Gutenberg" toggle (Settings > Screens > Editor): switches all post types to WordPress's classic editor instead of the block editor, using the same core-supported filter the official Classic Editor plugin uses. Off by default.
 
-= 3.6.0 =
-* Site Backup has moved to its own standalone plugin, Aurora Site Backup — install it with one click from the Settings → Add-ons screen, alongside Aurora File Manager and Aurora Database Explorer. Restoring a backup means writing arbitrary files back into the site, the same class of risk that's kept file-management functionality out of Aurora Admin proper, so it now lives in a separately-distributed companion plugin.
+= 1.11 =
+* Fixed the Updates screen (Dashboard > Updates) rendering unreadable white table rows in dark mode for available plugin and theme updates. Same underlying gap as the 1.10 fix (no dark styling for `widefat`-class tables), plus a WordPress core class collision — its plugin-update and theme-update tables reuse `tbody class="plugins"`, which core's own CSS makes explicitly white for the native Plugins screen. Visual-only fix; the actual update-checking and installation are still entirely native WordPress code.
 
-= 3.5.1 =
-* Fixed a fresh WordPress.org Plugin Check report: the previous compliance pass's `phpcs:ignore` annotations were placed above the *opening* line of several multi-line `$wpdb->get_results()`/`get_row()`/`get_var()` calls, but PHPCS attributes violations to the exact physical line where the interpolated tokens appear — often one or more lines further down inside the call — so those suppressions were never actually taking effect. Corrected across Menu Creator, Admin Notices, Site Backup, Media Folders, Analytics, and Media Library. Also fixed a real, unrelated bug found during verification: creating a menu in Menu Creator returned "Menu not found" instead of the newly created menu, because of how the internal follow-up request object was constructed.
-* Compressed files, hidden files, and non-standard markdown files flagged by Plugin Check are scanner noise from scanning the whole development repository (build zips, `.gitignore`, `.claude/`, `PROJECT_STATUS.md`) — confirmed none of these exist in the actual submission zip.
+= 1.10 =
+* Fixed Export Personal Data and Erase Personal Data (the privacy/GDPR tools) rendering with unreadable white table rows in dark mode. The actual request queue, bulk actions, and export/erase processing remain entirely native WordPress code — this was a visual-only fix.
 
-= 3.5.0 =
-* Database Explorer has moved to its own standalone plugin, Aurora Database Explorer — install it with one click from the Settings → Add-ons screen, alongside Aurora File Manager. Direct database-query tooling is treated by WordPress.org's Plugin Directory review the same way as file-management functionality, so rather than remove the capability outright, it now lives in a separately-distributed companion plugin, same as File Manager did in 3.4.0.
+= 1.9 =
+* Activity Log redesigned as a full table (Date, Author, IP Address, Type, Action, Description) with Admin and User tabs — Admin covers site/content activity, User covers account activity (login, logout, registration, profile updates). The Author column now shows the user's avatar, role, and email. Also now tracks IP address, logouts, and media uploads/deletions, and correctly labels Pages as Pages instead of Posts.
 
-= 3.4.0 =
-* File Manager has moved to its own standalone plugin, Aurora File Manager — install it with one click from the new Settings → Add-ons screen. WordPress.org's Plugin Directory policy doesn't allow file-management/code-editing functionality in a directory-listed plugin regardless of the safeguards in place, so rather than remove the capability outright, it now lives in a separately-distributed companion plugin.
+= 1.8 =
+* Full admin takeover: the Import screen is now a real Aurora-built replacement, gated behind Settings > Appearance > Admin Takeover. Installing an importer reuses WordPress's own plugin installer; running an already-active importer still opens that importer's own screen unmodified.
 
-= 3.3.2 =
-* Compliance pass against the official WordPress.org Plugin Check tool: fixed a readme.txt version mismatch, a missing input-sanitization call, and annotated ~230 custom-database-table query warnings with the justification the review process expects (Aurora's backup/analytics/activity-log/menu/notices/media-folders features all use their own tables, which necessarily means direct, non-core-wrapped database access).
+= 1.7 =
+* Full admin takeover: the Export screen is now a real Aurora-built replacement, gated behind Settings > Appearance > Admin Takeover. The actual WXR file generation is still 100% native WordPress code — only the form is Aurora's.
 
-= 3.3.1 =
-* Fixed the Settings page: the category list and the settings panel now scroll independently, so picking a category from a scrolled-down spot in the list no longer leaves the panel showing stale, off-screen content above the fold.
+= 1.6 =
+* Fixed Site Health rendering with unreadable, unthemed white panels in dark mode. WordPress's own Site Health checks (and any checks other plugins add) are kept fully intact and accurate — only the visual theming was fixed, not the underlying tests.
 
-= 3.3.0 =
-* Added Modern Image Formats: automatically generates a WebP or AVIF copy of every uploaded JPEG/PNG image and serves it via a <picture> element with the original as a fallback, configurable under Settings.
+= 1.5 =
+* Full admin takeover: the Tools screen (Available Tools) is now a real Aurora-built replacement, gated behind Settings > Appearance > Admin Takeover. Any card another active plugin adds to this screen is still shown — nothing from other plugins disappears.
 
-= 3.2.1 =
-* Security hardening: File Manager no longer allows opening or saving executable file types (PHP and similar) for a file that already exists — only creating, uploading, and renaming to those types were previously blocked. File Manager now also honors the DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS constants, the same host-level lockdown WordPress core's own file-editing and update/install flows respect.
+= 1.4 =
+* Added Login Redirect (Settings > Appearance > Login Redirect): optionally send logged-out visitors who try to access wp-admin to a custom URL instead of the login screen, and/or send specific roles to a custom URL after logging in instead of the dashboard. Both are off by default and never change, hide, or block wp-login.php itself.
 
-= 3.2.0 =
-* Added Google Drive as a second remote storage option for Site Backup, alongside S3-compatible storage. Connect your own Google Cloud OAuth client in Settings to store backups in your own Google Drive account.
+= 1.3 =
+* Added a Modules page (under the Aurora menu): install and activate Aurora's standalone companion plugins (File Manager, Database Explorer, Site Backup) with one click. This replaces the "Add-ons" section previously in Settings, and is where future Aurora addons will be installable from as they're released.
 
-= 3.1.0 =
-* Added Site Backup: full site backup (database + files) and restore-in-place, on demand or on a recurring daily/weekly/monthly schedule, stored locally or on your own S3-compatible remote storage (AWS S3, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, and similar).
+= 1.2 =
+* Menu Creator: fixed the item list showing empty (it now loads correctly), and added drag-and-drop reordering (with up/down buttons) for top-level admin menu items. The order is applied to the Aurora sidebar; hide and rename still work; newly installed plugins' menu items are always preserved.
 
-= 3.0.2 =
-* Fixed a plugin-header validation error: Plugin URI and Author URI were identical, which the WordPress.org submission checker requires to be distinct. Plugin URI now points to the plugin's own site (aurora.auroradragon.studio); Author URI stays on the studio's site.
+= 1.1 =
+* Plugins screen: the active/inactive state now always reflects the real result after activate/deactivate, even when WordPress reports a benign "unexpected output" on activation.
+* Compliance: documented a Plugin Check notice for a WordPress core filter (`emoji_svg_url`) used by the emoji-disable feature.
 
-= 3.0.1 =
-* Compliance and hardening pass ahead of the WordPress.org submission: replaced a forbidden core function in the Widgets screen, converted File Manager's file operations to use the WP_Filesystem API, added nonce/sanitization coverage to a few read paths, fixed missing translator comments, and annotated custom-table SQL queries for the plugin review process.
-
-= 3.0.0 =
-* Aurora Admin is now completely free — the entire licensing system was removed, and every previously-paid feature (Role Editor, Activity Log, Database Explorer, File Manager, Analytics, White Label, Full Admin Takeover, Media Folders) is now available to everyone.
-
-= 2.27.0 and earlier =
-* Pre-release beta versions, not distributed on WordPress.org.
-
-== Upgrade Notice ==
-
-= 3.0.0 =
-Aurora Admin is now 100% free. If you were on an earlier beta with a license key, it's no longer needed — all features are unlocked automatically.
+= 1.0 =
+* First public release of Aurora Admin.
+* Modern admin shell — fixed sidebar, toolbar, and global search — replacing the default WordPress admin chrome.
+* Real replacement screens for Dashboard, Posts, Pages, Media, Users, and Comments, plus Add User, Media Upload, and Profile.
+* Nav Menus, Widgets, Themes, and the core Settings screens (General, Writing, Reading, Discussion, Permalinks).
+* Power tools: Role Editor, Activity Log, Media Folders, Menu Creator, Admin Notices, and White Label.
+* Full dark mode with 10 color presets plus 2 flat neutrals; rounded framed content cards, theme-tinted scrollbars, and an optional (off-by-default) Google Font for the interface.
+* Security & performance hardening, custom admin CSS/JS, and a login-screen customizer.