SiteAgent for Aura

Changelog

2.16.2

• /status‘s door fragment carries observation, a per-site door-version witness bumped atomically by every door-state mutation (never by a mere poll) and clock-floored so a restored backup can never reissue a value it already served, so Aura can order overlapping polls by the site’s own witness instead of request timestamps; elementor.governor reports the current value. The observation witness requires InnoDB for wp_options and 64-bit PHP; without them ordering falls back to Aura’s own request order for that site (elementor.governor reports why via observation_unsupported: engine or php32).
• /status also accepts door_observation_seen — Aura’s own last accepted observation, echoed back — so the site can bump its witness forward, clock-floored, when a restore rewound its own copy behind Aura’s. Accepted for ANY non-negative integer the site’s own witness could ever report (no magnitude ceiling — the witness only counts up); honoured only within a fixed headroom below the class ceiling, silently ignored (200, no bump, no error) above it.
• elementor.governor reports counters_as_of beside the four _30d rolling counters, which observation does not cover; the counters themselves are int|null.
• interrupted / running / held are null, not [], when their own queue could not be read, and observation is withheld entirely whenever any read behind the fragment was unreadable.
• New door_write_unsupported reason reconnect_guard_unavailable: a governed write refuses outright on a $wpdb replacement that cannot disable reconnects, rather than risk a mutation replaying on a session this plugin no longer controls.
• Door writes report a committed tri-state (true / false / unknown) and answer a retryable 503 with may_have_run: true whenever a commit cannot be proven — claims, holds, acks, and rotations alike; replay() now forwards claim()‘s own error instead of a generic one.
• Hold references and pending log-row reservations are derived from the request’s own identity, so a retry after an ambiguous commit finds and reuses its own prior write instead of risking a duplicate.

2.16.1

• /status door fragment and audit_mcp_exposure‘s elementor.governor carry binding, the site’s current binding generation, so Aura can label a departed client’s door-log entries without inferring the generation from the rows.

2.16.0

• Elementor MCP door governance: every write through Elementor >= 4.3’s official MCP server is held for approval in Aura unless an operator allow rule covers it; block refuses; every write that runs is snapshotted first on the site and recorded in a per-site door log Aura drains. New tools elementor_replay_ability, snapshot_get; new routes /aura/v1/door/reject, /aura/v1/door/ack; /status carries door; audit_mcp_exposure carries elementor.governor. Rules gain the allow effect and the design_system / page_create targets.

2.15.0

• audit_mcp_exposure reports an elementor block: Elementor >= 4.3’s official MCP module state, every elementor_mcp_consent row, every Elementor MCP… Application Password across all users (full detail), and the other Application Passwords of edit_posts users as counts. Every list is bounded (50 / 50 / 200) with a truncation flag beside it; no usermeta value over 256 KB is decoded; a scan that fails is reported as { error } in its place, never as an empty list. Read-only.
• aura_worker_app_password_list() accepts an optional byte bound, enforced in the same statement that returns the value.

2.14.0

• Feature: a self-update can now undo itself. Before installing, SiteAgent
  archives its current build — best-effort: a site without ZipArchive or with
  an unwritable backup directory still updates, and the result says
  backed_up: false so the caller knows this one had no way back. After
  installing, SiteAgent asks the new build to prove it came up. The proof is
  written by the build itself: a boot beacon recorded the first time the new
  code serves a request, and a fatal beacon recorded by
  a shutdown guard when the new code dies while loading. A build whose own
  records say it broke is rolled back to the archived one, and compiled
  copies are asked out of the opcode cache (best-effort — a host that
  restricts opcache_invalidate() may serve the old compiled code until its
  cache revalidates). The result reports exactly what happened (backed_up,
  verified, rolled_back). When neither record appears, the update stands
  and says it was not verified, never guessed.
• Feature: one SiteAgent mutation at a time. Every path that can replace
  SiteAgent’s own files — the self-update, the generic plugin update, a batch
  entry, the rollback endpoint — runs under a single per-site claim: taken by
  a conditional insert, seizable only after its holder has gone silent for ten
  minutes (a request that dies never releases), and released only by its
  owner. The self-update additionally renews the claim between its phases,
  so a slow step costs the lease nothing once the next phase begins. An
  overlapping request is answered “in progress” and touches nothing.
• Hardening: backups follow a symlink only while its target stays inside the
  plugin folder — a link pointing out of the tree makes the backup report
  itself incomplete instead of copying unrelated files into an archive.
  Restores never delete through a symlink, root or child, and refuse to run at
  all when a link cannot be removed. A package carrying the version already
  running is refused, because its boot records could not be told apart from
  the old build’s. Backup filenames carry a per-operation suffix, so two
  backups started in the same second never overwrite each other.

2.13.0

• Feature: Aura can now disconnect a site in two phases, and the site
  refuses changes the moment it is told to. When Aura sends a disconnect,
  SiteAgent records it and every mutation on the site — SiteAgent’s own write
  endpoints, MCP write tools, grant-signed calls, and any WordPress REST write
  made with the Application Password or site token of the departing connection
  — is answered 403 aura_site_unbound until the site is reconnected. Reads
  keep working, /status keeps answering, and Aura’s own ruleset endpoint
  stays reachable so the disconnect can be finished or retried.
• Feature: a departing connection’s Application Password stops working
  everywhere, not just on the REST API. WordPress authenticates Application
  Passwords on XML-RPC as well, so a credential the disconnect could not revoke
  is now refused where WordPress decides whether it authenticates at all. Your
  own Application Passwords are untouched, and so is admin login.
• Feature: the cleanup is proven, not assumed. SiteAgent revokes the
  Application Password(s) Aura minted, clears the stored ruleset and the
  gateway public key, forgets the connect bookkeeping, and deletes the site
  token LAST — and only when Aura says the disconnect is final. Every step is
  idempotent, runs in one fixed order, and continues past a step that failed.
  An interrupted disconnect finishes itself on the site’s next page load
  (throttled, at most once every five minutes), so a site Aura can no longer
  reach still converges.
• Feature: the answer to a disconnect now names what is still owed:
  leftovers lists the credentials or stores this site could not prove it had
  released (app_passwords, options, ruleset, grant_pubkey), alongside
  cleanup_complete. An empty list means only the shared site token was still
  outstanding; a non-empty one means Aura must keep waiting.
• Feature: the settings screen tells you when Aura disconnected the site
  (“Disconnected by Aura at …”) and offers Remove remaining Aura data — an
  admin-initiated teardown that runs the same proven cleanup, and only clears
  the disconnect record once everything it names, the site token included, is
  gone.
• Feature: manually connected sites (those with no gateway public key, which
  therefore cannot verify a signed document) can be disconnected with a bare
  { “unbind”: true, … } body on POST /wp-json/aura/v2/rules, authenticated
  by the site token alone. A site that DOES hold a gateway key refuses the
  bare form and requires the signed envelope.
• Safety: every ruleset push now runs under the site-wide claim the connect
  flow already used, so a push, a disconnect and a reconnect can no longer
  interleave. A site already busy answers 503 aura_site_busy, which is
  retryable. A claim left behind by a killed request is taken over after two
  minutes rather than blocking the site indefinitely.
• Safety: reconnecting (magic link) and Regenerate Token now settle the
  previous connection’s outstanding cleanup BEFORE installing a new token, and
  release the disconnect record only after the replacement connection is
  installed and read back — so a reconnect that fails halfway leaves the site
  still refusing the departed connection instead of quietly reviving it.
• Fix: a disconnect record damaged in the database is now REPAIRED — rebuilt
  from the site’s own state, under the claim — and then torn down through the
  ordinary path. Previously a damaged record was a permanent dead end: the
  site refused every change and no control could clear it.
• Diagnostics: /status reports unbound: { at, site_ref } while a
  disconnect is outstanding, and app_password_probe_unproven:
{ count, at, owner } when the site cannot prove an Application Password was
  revoked — the usual reason a disconnect never finishes. Both are bounded and
  contain no secrets.
• New error codes: aura_site_unbound (403 — the site is disconnected),
  aura_site_busy (503 — retry), aura_unbind_incomplete (409 — something is
  still owed; the answer lists it), aura_unbind_unreadable (409 — the
  disconnect record could not be read, which is NOT the same as an incomplete
  cleanup), aura_unbind_unrepairable (409), aura_unbind_marker_stuck
  (500 — everything was removed but the record itself would not delete),
  aura_unbind_marker_malformed (500), aura_unbind_store_failed (500) and
  aura_ruleset_client_mismatch (409 — a disconnect addressed to a different
  Aura client), which the bare unkeyed form now checks too.
• Compatibility: a 2.13 site that is never sent a disconnect behaves exactly
  as 2.12 did. Nothing on the site changes until Aura asks for one.

2.12.0

• Feature: a rule can now apply to some of a client’s sites instead of all
  of them. Aura’s signed ruleset names the site each document was issued
  for, SiteAgent stores that identity, and a rule that lists the sites it
  applies to is enforced only where it belongs. Rules that name no sites are
  client-wide exactly as before.
• Safety: a site that cannot prove its own identity — an older record, a
  document issued before this field existed — enforces EVERY rule rather than
  skipping the ones it cannot place. Scoping only ever narrows on proof.
• Upgrade: the identity is recovered offline from the ruleset already stored,
  by re-verifying its signature locally. No new network traffic, and a site
  whose ruleset has not changed since the upgrade is repaired on its next
  request rather than waiting for the next push.

2.11.0

• Feature: the magic-link connect now mints an Application Password for
  the dashboard. A magic-link connection could run SiteAgent’s own tools
  but not the builder tools (Elementor MCP and friends) that authenticate
  with WordPress Basic auth — only a manual connect, which never provisions
  the gateway key, could. The signed /connect callback now also mints an
  Application Password named “Aura SiteAgent” for the administrator who
  created the link and returns it once, in the callback’s response, so the
  dashboard stores it encrypted beside the site token. Every connect rotates
  it (earlier ones under that name are deleted first). Where Application
  Passwords are unavailable (no HTTPS, disabled by a filter, no admin user)
  the connect succeeds token-only as before and names the reason.
• The whole install — token, client binding, gateway key, Application
  Password — runs under one site-wide connect claim, so two callbacks for the
  same site cannot split the credentials the dashboard ends up holding.
  “Regenerate Token” takes the same claim (it is refused while a connect is
  installing). The claim is never taken over by age: a callback the dashboard
  timed out on may still be running. Every write the install makes — the site
  token, the client binding, the dashboard URL, the gateway key — is issued by
  a statement conditional on holding the claim, so a claim that goes away
  mid-request costs that request its connect (retryable) rather than letting it
  overwrite the install that replaced it. If a
  killed request ever leaves a claim behind, every later connect is refused
  until an administrator deactivates and reactivates the plugin, which
  releases it.
  “Regenerate Token” issues its cleanup the same way, and skips revoking the
  Application Password when it no longer owns the claim — the password on the
  site then belongs to whichever connect replaced it. It still reveals the
  token it stored: refusing to would revoke the old token while showing no
  replacement.
• Deactivating the plugin now also revokes the Application Password Aura
  minted. Unregistering SiteAgent’s routes does not stop an
  administrator-level credential from authenticating to WordPress core and to
  other REST/MCP plugins, so “deactivated” would not have meant
  “disconnected”. If the revocation fails the owner and UUID are kept, and
  reactivating finishes the job (activation retries a revocation deactivation
  could not land), as does uninstalling. The site token binding survives
  deactivation, so the settings screen keeps showing the dashboard it is
  connected to. The Connect button is always reachable there, and the line above
  it says what the site actually holds: a working credential, one that was never
  delivered, none at all, or a site that cannot issue one (token-only).

2.10.3

• Fix (security): “Regenerate Token” revealed a new site token without ever
  storing it. The option was registered as a read-only setting, and the
  callback enforcing that ran on every write — not only on the settings form —
  so the handler’s write was discarded while the one-time reveal still
  appeared. Two consequences: an admin rotating a leaked token was told it was
  revoked when the old token stayed valid, and a site disconnected from the
  dashboard could not be reconnected, because no token the screen displayed
  ever authenticated. The token is no longer registered as a setting (it is
  display-only, so nothing submits it), and regeneration now stores the new
  hash with a single compare-and-swap, out of reach of any option filter — a
  token is revealed only when that one statement reports it wrote the row, and
  a site whose row is missing or empty can be given its first token the same
  way.

2.10.2

• Fix: a site moved from one Aura client to another while the old client’s
  last push was still in flight could end up holding the old client’s ruleset
  and refuse the new client’s rules until it was reconnected. The connect
  callback now names the client the site belongs to (a signed, optional field
  — older dashboards keep working unchanged) and writes that binding into the
  ruleset store itself, so a ruleset for any other client is refused from then
  on, whatever was in flight.

2.10.1

• Fix: audit_rules could report zero blocked/warned events for the current
  hour. Reading the counters before the hour’s first refusal put the bucket in
  WordPress’s negative option cache, and the refusal’s atomic insert did not
  clear it — so the count stayed at zero for the rest of the request, and on a
  site with a persistent object cache until the cache was flushed. Enforcement
  was never affected; only what the audit reported.
• Fix: two rulesets pushed to a site at the same moment, before it held any,
  could answer the loser with 500 instead of the ordinary “a newer ruleset is
  already installed” decision. Aura retries a 500, so no policy was lost; the
  site now classifies the database’s duplicate-key or deadlock answer as the
  lost race it is.

2.10.0

• New: operator rules, enforced on the site. A rule is an Aura memory entry
  (rule/<slug>) naming a resource — the whole site, a page or post by ID, or a
  plugin by slug — with an effect of block or warn and an optional expiry.
  Aura signs the client’s whole ruleset with the same key that signs approval
  grants and pushes it to every connected site (POST /aura/v2/rules), the site
  verifies it and keeps only a newer one (a replayed older ruleset is refused
  even when validly signed). No ruleset means no policy — nothing is refused. A
  site that has never been reconnected since signed approvals shipped holds no
  gateway key and cannot verify a ruleset; it says so, and Aura tells you to
  reconnect it.
• Enforcement runs on every path a write can take: inside the tool executor
  before anything runs or is snapshotted; explicitly on the legacy REST update
  routes; and at WordPress core’s own REST API for posts and pages — so a rule on
  a page holds against Aura’s content tools, an assistant with an application
  password, or another plugin’s MCP server alike. A block refuses the call and
  names the rule; a rule outranks an approval — a granted call is still
  refused, and the message says to release the rule first. A warn runs and
  attaches the warning. Previews are never blocked; they now report what a call
  touches and which rule would decide it.
• New: audit_rules (read-only) — ruleset presence and age, whether the site
  can verify one, 24h block/warn counts, expired-but-listed rules, and the
  enforcement points in this build.
• Every mutating tool now declares what a call touches; one that does not is
  caught by every rule rather than by none.

2.9.1 and earlier

• WordPress.org truncates a Changelog over 5,000 words, and this plugin’s history is longer than that.
  The entries for 2.9.1 and every release before it were moved out of this file verbatim and are kept in full at:
  https://github.com/Digitizers/SiteAgent/blob/main/docs/changelog-archive.md