=== M7tawa Impact Monitor ===
Contributors: aymanabdullahdev
Tags: impact monitor, diagnostics, database, cron, rest api
Requires at least: 6.5
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 2.8.3
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Monitor measurable extension impact on WordPress without deleting or changing site data.

== Description ==

M7tawa Impact Monitor is a lightweight, event-based diagnostic tool for WordPress administrators and developers.

Version 2.8.3 remains read-only for site and extension data. It does not delete tables, remove options, disable assets, or change WordPress settings.

Version 2 adds detailed before/after evidence instead of summary counts alone.

Features:

* Create a manual baseline of the current site.
* Record measurable changes after extension installation, activation, deactivation, updates, and successful deletion.
* Show a per-extension Lifecycle Timeline with event filtering, version transitions, and first/last monitored dates.
* Show exact names of added and removed database tables, cron hooks, post types, taxonomies, and REST routes.
* Index option metadata without copying option values: option name, autoload state, and byte size only.
* Skip detailed option indexing automatically on sites with more than 20,000 options to keep scans conservative; autoload total remains available.
* Show added, removed, and size/autoload-changed options after a version 2 baseline.
* Show role and capability changes.
* Show version transitions for monitored updates when available.
* Provide an impact profile for every installed extension, while clearly marking extensions that only exist in the baseline.
* Preserve v1.x history during upgrade.
* Require explicit confirmation before clearing the monitor's own history.
* Load no frontend CSS or JavaScript.
* Keep only the latest 100 monitoring events.
* Calculate a transparent 0–100 Impact Score from attributable observed evidence only.
* Show Low, Moderate, High, or Very High technical impact without labeling extensions as good, bad, safe, or unsafe.
* Break the score into Database, Runtime, WordPress Integration, and Footprint Breadth components.
* Label partial scores when activation was not observed and leave baseline-only extensions unscored.
* Show Impact Score before/after observed events and version updates.
* Distinguish Current Impact Score from Peak Impact Score and show signed Event Impact Delta.
* Keep a compact observed score history with Rising, Falling, Stable, or New history trend labels.
* Show the top score contributors and conservative Attention Flags that explain what may deserve manual review.
* Show a dedicated before/after score comparison for monitored updates and highlight notable score shifts of 10 points or more.
* Show Observed or Partial confidence directly beside scored extension profiles.
* Filter and sort extension profiles by impact level or score.
* Use cron recurrence metadata when available so high-frequency schedules contribute more than infrequent schedules.
* Never take automatic action based on a score.
* After a successful extension deletion, run a read-only Residue Monitor check for remaining tables, options, transients, cron hooks, roles, post meta keys, and user meta keys.
* Separate Observed residue from lower-confidence Likely related naming evidence instead of claiming uncertain ownership.
* Recheck a stored residue report manually without deleting or modifying any site data.
* Build a per-extension Dependency Map from the WordPress Requires Plugins header, reverse dependents, observed shared-resource evidence, and monitored footprint evidence.
* Keep declared dependency metadata separate from observed integration evidence so shared resources are never presented as proof of dependency.

The monitor uses on-demand and event-based scans. It does not run heavy diagnostic scans on ordinary frontend page loads.

== Installation ==

1. Upload the plugin to `/wp-content/plugins/m7tawa-impact-monitor/` or install the ZIP from WordPress admin.
2. Activate the plugin.
3. Go to Tools > Impact Monitor.
4. Create a version 2 baseline when prompted.
5. Future install, activation, deactivation, update, and deletion events will include lifecycle history and detailed before/after information.

== Frequently Asked Questions ==


= What does Impact Score mean? =

Impact Score is a technical footprint indicator from 0 to 100. It is based on attributable observed evidence such as tables, option metadata, autoload growth, cron hooks and recurrence, REST routes, content types, taxonomies, roles, and capabilities. A higher score does not mean an extension is bad or unsafe; feature-rich extensions can naturally have a larger footprint.

= Why is a score marked Partial? =

The monitor observed some attributable changes but did not observe the extension from activation, so it cannot claim a complete footprint. Baseline-only extensions remain unscored.

= Does it delete anything? =

No. Version 2.8.3 is read-only for site and extension data.

= Does it store option values? =

No. It stores only option names, autoload state, and byte size so it can compare metadata without duplicating option contents.

= Does Residue Monitor delete leftovers? =

No. Residue Monitor only detects, attributes, explains, and rechecks what remains after an extension is removed. Observed residue means the item was introduced during a monitored event and still exists after removal. Likely related means the current item matches extension-specific naming evidence, but ownership is not claimed as certain.


= How does Dependency Map decide that extensions are related? =

Declared dependencies come directly from the WordPress Requires Plugins header. The monitor can also show exact resource names observed with more than one extension, but those are labeled as shared-resource evidence only and are never treated as proof that one extension depends on another.

= Does it add scripts to the frontend? =

No. Admin assets load only on the monitor screen.

= Why do some extensions say Baseline only? =

Those extensions were already present when the baseline was created and no activation, deactivation, or update event has been observed for them yet. The monitor does not guess ownership.

= What is Observed? =

Observed means the monitor was present when the event occurred and could compare site state around that event.

= What happens to my version 1 history? =

It is preserved. Run a new version 2 baseline once to enable detailed option and role comparison for future events.

== Changelog ==

= 2.8.3 =
* Exclude known WordPress updater process transients, the cron storage option, and updater cleanup cron noise from extension attribution and Impact Score.
* Show excluded WordPress update process changes separately for transparency.
* Force left-to-right version flows so Before → After is displayed correctly in RTL dashboards.
* Harden Update Watch across more WordPress update flows.
* Capture pre-update state from both pre-download and pre-install upgrader hooks when available.
* Add a read-only admin fallback that detects missed plugin version changes on the next admin request and records an Updated event automatically.
* Preserve explicit attribution limits for batch or fallback-detected updates.

= 2.8.0 =
* Added Dependency Map with declared Requires Plugins relationships, reverse dependents, observed shared-resource evidence, and per-extension footprint evidence.
* Dependency relationships are separated by confidence: declared metadata is authoritative; shared resources are integration evidence only.
