Aller au contenu

Technical write inventory — current state

Status: CURRENT Last consolidated by: BC-068D This document is the operational source of truth for currently certified technical WordPress write surfaces.

Date: 2026-07-14

BC-063E2 scope

BC-063E2 introduces an explicit technical-state boundary for the currently certified WordPress technical writes. The goal is isolation only: keys, TTLs, lock names, payloads, timeouts and public wrappers stay unchanged.

Current technical adapters:

  • CCX_WordPressTechnicalStateStore
  • wraps get_option() / update_option() / delete_option()
  • CCX_WordPressTransientStore
  • wraps get_transient() / set_transient() / delete_transient()
  • CCX_TechnicalLockService
  • wraps MySQL named locks through SELECT GET_LOCK(...) / SELECT RELEASE_LOCK(...)

Current accessors:

  • ccx_technical_state_store()
  • ccx_technical_transient_store()
  • ccx_technical_lock_service()

Certified option/state writes

Merchant activation is deliberately not an option/state write. CCX_ACTIVE_FEEDS is the only authority. ccx_runtime_set_enabled_feeds(), ccx_runtime_enable_feed() and ccx_runtime_disable_feed() reject writes explicitly, and make doctor fails if the legacy option exists.

The following technical option writes are now routed through CCX_WordPressTechnicalStateStore:

  • ccx_governance_snapshot_v1
  • wrapper unchanged:
    • ccx_governance_save_snapshot()
  • ccx_catalog_nav_cache_v1_state
  • wrapper unchanged:
    • ccx_catalog_nav_cache_set_state()
  • ccx_premium_whitelist_dryrun_last
  • dry-run payload unchanged
  • ccx_offers_version
  • version bump unchanged after successful sync-runner feed execution

Certified transient/cache writes

The following transient writes are now routed through CCX_WordPressTransientStore:

  • health endpoint rate-limit
  • key: ccx_health_lock_v5_<md5(feed:limit)>
  • TTL: 10 seconds
  • feed health heavy recalculation throttle
  • key: ccx_fh_recalc_<md5(feed)>
  • TTL: 15 * 60
  • Product Models grouped-offers cache
  • TTL: 15 * MINUTE_IN_SECONDS
  • Product Models variants cache
  • TTL: 15 * MINUTE_IN_SECONDS
  • Product specs cache
  • TTL: 15 * MINUTE_IN_SECONDS
  • Product gallery cache
  • TTL: 15 * MINUTE_IN_SECONDS
  • similar models cache
  • TTL: 15 * MINUTE_IN_SECONDS

Certified named locks

The following named-lock consumers are now routed through CCX_TechnicalLockService:

  • includes/infrastructure/db-lock.php
  • legacy wrappers preserved:
    • ccx_feeds_db_try_lock_result()
    • ccx_feeds_db_try_lock()
    • ccx_feeds_db_unlock_result()
    • ccx_feeds_db_unlock()
  • catalog navigation cache build lock
  • governance review queue sync lock
  • rebuild-chain lock fallback

Lock names and timeouts stay unchanged.

Remaining BC-063E debt

Still outside BC-063E2:

  • rewrite-maintenance fingerprints and flush paths
  • schema / install / dbDelta / migration writes
  • cron scheduling state
  • filesystem spool or snapshot side effects
  • business governance writes
  • taxonomy business writes

BC-063E4 certified schema / migration / temporary-schema boundary

BC-063E4 adds three explicit technical boundaries:

  • CCX_SchemaInstallService
  • explicit schema install entrypoint
  • wraps legacy aggregate install through ccx_feeds_install_schema_legacy()
  • CCX_MigrationRunner
  • explicit migration runner for the legacy core install/migrate path
  • CCX_TemporarySchemaService
  • explicit temporary-table boundary for the active taxonomy V2 temp-table family

WordPress-facing adapter:

  • CCX_WordPressSchemaAdapter
  • wraps schema metadata probes such as:
    • SHOW COLUMNS
    • INFORMATION_SCHEMA.STATISTICS
    • ALTER TABLE ... DROP INDEX

Versioning:

  • schema version key unchanged: ccx_feeds_schema_meta
  • version payload still contains:
  • version
  • installed_at
  • php_version
  • writes now pass through CCX_WordPressTechnicalStateStore

Certified entrypoint changes:

  • ccx_feeds_install_schema() is now a wrapper over CCX_SchemaInstallService
  • the legacy install body stays intact in ccx_feeds_install_schema_legacy()
  • taxonomy schema bootstrap now delegates through:
  • ccx_schema_install_service()
  • ccx_temporary_schema_service()

Certified gate tightening:

  • passive WP_CLI no longer implies schema install bootstrap by itself
  • passive is_admin() no longer implies schema install bootstrap by itself
  • schema bootstrap now requires explicit flags only

This does not change the SQL, table definitions, version value, install order or temporary-table names.

BC-063E5 certified global state

Global technical-write certification now holds under the following constraints:

  • direct WordPress technical write APIs are confined to:
  • CCX_WordPressTechnicalStateStore
  • CCX_WordPressTransientStore
  • CCX_TechnicalLockService
  • CCX_WordPressCronAdapter
  • CCX_WordPressRewriteAdapter
  • CCX_WordPressSchemaAdapter
  • passive load contexts are certified with zero technical write:
  • plain plugin load
  • frontend public
  • admin read-only
  • CLI simple
  • HTTP forbidden
  • cron passive
  • the sync-log stale watchdog no longer performs write-capable work from a passive init hook; stale cleanup now runs only from the explicit sync-log start path
  • the finished-feeds audit-table installer and sync-log installer now delegate their dbDelta() calls through the schema adapter boundary

Residual debt explicitly accepted:

  • includes/strict/meta-smartphone.php still owns legacy explicit temporary/build-table DDL
  • includes/taxonomy-v2/core.php still owns explicit temporary-table SQL for taxonomy V2 commands

These remaining placements are not passive-load violations. They remain explicit technical write contexts and must stay documented until a later dedicated cleanup slice.

Rollback

Rollback is mechanical:

  • restore the former direct update_option() / set_transient() / SQL lock calls in the legacy consumers;
  • remove includes/infrastructure/technical-state.php;
  • remove BC-063E2 runtime / architecture gates;
  • resync the runtime mirror;
  • rerun validation.

No SQL rollback and no live state restoration are required because certification does not execute real state-changing actions.

BC-063E3 certified cron / rewrite boundary

BC-063E3 adds two more technical boundaries:

  • CCX_CronScheduleService
  • delegates to CCX_WordPressCronAdapter
  • preserves:
    • hook name ccx_runtime_tick
    • schedule name ccx_runtime_every_5_minutes
    • interval 300
    • duplicate-prevention semantics through wp_next_scheduled()
  • CCX_RewriteMaintenanceService
  • delegates to CCX_WordPressRewriteAdapter
  • preserves:
    • Product Models route registration
    • fingerprint option ccx_product_models_route_contract_fingerprint
    • soft flush flush_rewrite_rules(false)

Current certified consumers:

  • includes/runtime/queue-runner.php
  • cron schedule registration remains at file scope via add_filter('cron_schedules', ...)
  • cron execution hook remains at file scope via add_action('ccx_runtime_tick', ...)
  • direct scheduling APIs are now confined to the cron adapter/service
  • includes/bootstrap/frontend-route-maintenance.php
  • route registration and fingerprint flush wrappers stay public
  • direct rewrite APIs and fingerprint option writes are now confined to the rewrite adapter/service

Authorized flush contexts stay unchanged:

  • admin_init
  • targeted WP_CLI init path

Public frontend traffic still does not flush rewrites.