Operations

ConfigOps is suitable for production observation only when it sits inside ordinary WordPress operational controls: tested backups, least privilege, database health monitoring, and a staging path for risky settings.

Recommended production posture

• Let automatic request-local observations cover ordinary settings saves.
• Keep named Change Sessions short and scoped to one operator task.
• Treat exported Pack files as private configuration material and review every destination warning.
• Avoid upgrades, imports, bulk jobs, and deployments during a named Change Session.
• Give configops_rollback to fewer people than configops_view.
• On Multisite, reserve Network Admin evidence, named Network Change Sessions, and mutation undo for super administrators with manage_network_options.
• Treat mail, authentication, URL, indexing, cache, and integration settings as staging-first changes.
• Leave experimental generic array undo off unless you have exercised the owning plugin's save and undo path in staging; it provides structural safety, not plugin semantics.
• Monitor WordPress/PHP logs and database write health.
• Verify behavior after undo; do not rely on a success badge alone.

Automatic observation is limited to authorized administrative, REST, and WP-CLI contexts and begins lazily on the first Options API mutation. WP-CLI itself is the administrative authority when its optional --user argument is omitted; ConfigOps records that evidence with actor ID 0. Named Change Sessions observe site option writes across their active window. High traffic is not itself a problem, but a long named session creates more unrelated evidence and more ambiguity. Duration and operational scope matter more than visitor count.

Local storage

ConfigOps uses dedicated WordPress tables for observation sessions, mutations, value-free write signals, and restore audit runs. The internal table identifiers retain capture for schema compatibility. On Multisite the shared tables use the network base prefix, and every site-owned row is pinned to its network and blog identity. Network evidence reserves blog ID zero and uses separate network-owned state. Evidence remains in the WordPress database.

The REST interface is local to WordPress, scope- and capability-gated, and returns private no-store responses. Network routes additionally require manage_network_options. There is no ConfigOps account, cloud collector, public Pack registry, or remote control plane in 0.7.0.

Version 0.7.0 registers site-scoped native WordPress Abilities and machine-readable JSON wp configops commands. These are authenticated transports over the existing application services, not a second control plane. Read operations require configops_view, capture control requires configops_capture, and non-writing restore validation requires configops_plan. Pack draft/export and Apply Preview also require configops_plan; Pack Apply requires configops_apply. Single-mutation automated undo additionally requires an explicit dangerously-run-undo acknowledgement. See Automation & agents and Configuration Packs.

Retention

History retention runs daily and removes completed or interrupted observation evidence older than 30 days by default. Change the period only through site code:

add_filter(
	'configops_retention_days',
	static fn (): int => 14
);

The value is bounded by the plugin. A failed dependent delete preserves the observation instead of leaving a falsely clean partial removal. Retention shares the restore mutex in its site or network scope, so it refuses to run while an undo is reading the evidence it would delete.

Health checks

After installation or an incident, verify:

1. ConfigOps loads for an authorized administrator.
2. A small settings save creates one completed automatic change and an evidence card.
3. A named Change Session can start, stop, and reach completed.
4. A known setting appears with the expected actor and request path.
5. A harmless conflict test refuses undo after the setting is changed again.
6. WordPress and PHP logs contain no ConfigOps warnings, notices, or deprecations.
7. The daily configops_history_retention event is scheduled.
8. If the generic array experiment is enabled, a harmless unknown-plugin array update shows Undo verified keys, preserves an unrelated later key, and refuses a deliberately changed target key without writing.
9. A harmless Core Change Session can export one Pack, preview a changed destination without writing, apply it as Pack History, and undo it to the destination baseline.

On Multisite, also verify one disposable site's evidence cannot be read from another site, Network Admin → ConfigOps identifies its network-wide scope, and a harmless Network Options update can be reviewed and undone by a super administrator. Networks WordPress classifies as large are provisioned lazily per site instead of being synchronously traversed during activation; new sites still use the normal initialization hook. Deactivation closes open site evidence with one network-scoped storage update and lets each skipped site's stale active pointer reconcile on its next ConfigOps request.

Incident response

If a restore fails or compensation fails:

1. Stop further ConfigOps and native settings writes to the affected option.
2. Record the change ID, mutation ID, UTC time, and value-free failure code.
3. Verify current state in the owning plugin and, if appropriate, WP-CLI.
4. Check PHP, WordPress, and database logs without copying credentials into a ticket.
5. Recover through the owning plugin or a tested backup when the intended value cannot be proven.

Never paste raw database option values into a public issue. Use the private security contact in SECURITY.md when evidence could expose credentials or site internals.