Repository navigation
release: SiteAgent 2.22.0 — the install ledger (P6.3 phase 2) - #140
Conversation
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 827ac3b372
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| = 2.22.0 = | ||
| * New: an install ledger. Every plugin and theme install or update is recorded with how it arrived (wp-admin, REST, WP-CLI, cron, a WordPress auto-update, or SiteAgent itself), which user and application password, and where the package came from, so Aura can flag packages an AI agent installed. It only observes; it never blocks an install. Nothing to configure. | ||
| * Privacy: each record keeps the user ID, the application password's name (never the password) and the REST route. Records are kept at most 90 days or 200 installs, are not autoloaded, and are deleted when the plugin is uninstalled. |
There was a problem hiding this comment.
When SiteAgent is deactivated for more than 90 days, its wp_scheduled_delete callback is not registered, and neither report() nor append() can run, so the options containing the user ID, password name, and REST route remain stored indefinitely until reactivation or uninstall. This makes the public claim that records are kept “at most 90 days” false for deactivated installations; either remove the data on deactivation or describe that expiry is enforced on the next run while the plugin is active.
Useful? React with 👍 / 👎.
…is active; say so Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a42ea333b3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| = 2.22.0 = | ||
| * New: an install ledger. Every plugin and theme install or update is recorded with how it arrived (wp-admin, REST, WP-CLI, cron, a WordPress auto-update, or SiteAgent itself), which user and application password, and where the package came from, so Aura can flag packages an AI agent installed. It only observes; it never blocks an install. Nothing to configure. | ||
| * Privacy: each record keeps the user ID, the application password's name (never the password) and the REST route. While the plugin is active, records older than 90 days (or beyond the latest 200 installs) are deleted; a deactivated plugin keeps them until it is reactivated or uninstalled. Records are not autoloaded and are deleted when the plugin is uninstalled. |
There was a problem hiding this comment.
The revised wording still implies that reactivation ends retention of the rows, but aura_worker_activate() only calls restart_coverage(), whose existing-ring path explicitly leaves the ring untouched. Thus a site can reactivate and retain records older than 90 days until a later ledger read, append, or wp_scheduled_delete run. This is fresh evidence against the revised claim; describe cleanup as occurring on the next such pass after reactivation, or purge during activation.
Useful? React with 👍 / 👎.
…activation, not at reactivation Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 11843d4b22
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ### 2.22.0 | ||
|
|
||
| - **An install ledger** (Digitizers/Aura spec 2026-09-21 §4, P6.3 phase 2). New `Aura_Worker_Install_Ledger` observes the upgrader for plugin and theme runs only — a per-run token in `hook_extra`, `upgrader_pre_download` at `PHP_INT_MAX`, the entry at `upgrader_install_package_result` — and records and never decides. Each entry: when, type, action, slug, version (the main file), transport (`siteagent` for SiteAgent's own upgrader object, `wp_cli`, `auto_update` only inside core's `wp_maybe_auto_update` — never the upgrader skin, `cron`, `rest`, `wp_admin`), user id, auth, the application password's name (never its uuid), REST route, and the package source (`wporg`, `uploaded_zip`, `remote_host` + host, `local_path`, `unknown`). (#139) |
There was a problem hiding this comment.
The advertised source and siteagent transport classification cannot work with these hooks: WP_Upgrader::run() invokes download_package() (and therefore upgrader_pre_download) before install_package() applies upgrader_package_options. Consequently, the token added by on_package_options() is never present when on_pre_download() checks it, no frame is created, and on_install_result() always falls back to context(false) plus source: unknown (class-aura-worker-install-ledger.php:527-529,574-580,641-665). This makes SiteAgent-driven installs indistinguishable from their ambient request transport and discards the package source for every normal upgrade, undermining the grading this release claims to enable; correlate the pre-download observation without relying on a token added later in the upgrader flow.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Not the order in core. WordPress 7.1.2 wp-admin/includes/class-wp-upgrader.php, WP_Upgrader::run(): line 818 $options = apply_filters( 'upgrader_package_options', $options ); → line 849 $download = $this->download_package( $options['package'], false, $options['hook_extra'] ); (which applies upgrader_pre_download at line 322 with that same $hook_extra) → line 898 install_package → line 917 apply_filters( 'upgrader_install_package_result', $result, $options['hook_extra'] ). The token added at 818 is therefore present at pre-download and at the result, which is what the ledger relies on (spec §4.1, read from core). The staging field check before promotion exercises this on a real install.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 11843d4b22
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| = 2.22.0 = | ||
| * New: an install ledger. Every plugin and theme install or update is recorded with how it arrived (wp-admin, REST, WP-CLI, cron, a WordPress auto-update, or SiteAgent itself), which user and application password, and where the package came from, so Aura can flag packages an AI agent installed. It only observes; it never blocks an install. Nothing to configure. | ||
| * Privacy: each record keeps the user ID, the application password's name (never the password) and the REST route. While the plugin is active, records older than 90 days (or beyond the latest 200 installs) are deleted; a deactivated plugin cannot delete anything, so they stay until its first cleanup after reactivation (the daily clean-up, an audit or the next install) or until it is uninstalled. Records are not autoloaded and are deleted when the plugin is uninstalled. |
There was a problem hiding this comment.
The release now explicitly stores user_id, Application Password names, and REST routes and exposes them through audit_agent_code, but Aura_Worker::add_privacy_policy_content() still tells site owners that “No personal user data is collected or transmitted by this plugin.” Sites that use WordPress's suggested policy text will therefore publish a false disclosure after upgrading to 2.22.0; update that generated privacy-policy content to describe the ledger data, its transmission to Aura, and its retention.
Useful? React with 👍 / 👎.
…es the install ledger Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. Delightful! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Version bump to 2.22.0, readme.txt changelog (with a privacy line about the ledger's personal data and 90-day/200-entry retention) and README changelog for #139. Readme limits pass (593 words headroom).
After merge: prerelease v2.22.0 → staging 6631144 field check (spec §7) → promote.
🤖 Generated with Claude Code