Runtime Current State

Status: CURRENT / P1.4 CERTIFIED 2026-09-05

This document is the operational source of truth for the observed runtime posture of CMonChoix Platform. It records what is actually deployed, how it is executed, and which operational invariants must remain true.

It is not the architectural specification. For architecture, see ../runtime/overview.md.

Certified operational baseline — P1.4

The current infrastructure/observability closure was certified on 2026-09-05 against:

main/release SHA  c1b2f6a356f23c1ace064a2a7e4f71c33ffb584e
P1.3 DR           CLOSED / PASS
P1.4 GLOBAL       CLOSED / PASS

The observability runtime intentionally uses two release authorities because P1.4B2B changed Alertmanager/systemd alert delivery without recreating the already-certified Prometheus runtime:

Prometheus authority  88ae34f6563cf10f75726501d6266405bf28201b
Alertmanager authority c1b2f6a356f23c1ace064a2a7e4f71c33ffb584e

Current certified observability posture:

• Prometheus is healthy/ready and keeps 14/14 rules healthy;
• Prometheus targets prometheus, node, cadvisor and alertmanager are up;
• Prometheus routes alerts to http://alertmanager:9093/api/v2/alerts;
• Alertmanager uses the immutable image ghcr.io/prometheus/alertmanager:v0.34.0@sha256:690c7b525f4367aa91f73e2f91c632206d32e97c6384bdbf2fb7a861b420340d;
• Alertmanager host API exposure is loopback-only on 127.0.0.1:9093;
• Alertmanager persistent state is bind-backed by /mnt/data/cmonchoix-infra/observability/alertmanager;
• Discord external delivery was certified for both firing and resolved notifications;
• the backup/maintenance systemd authority is 13/13 byte-identical to the P1.4B2B Git authority;
• backup and maintenance failures enter the same Alertmanager routing authority through the local loopback API.

The final P1.4 evidence manifest is:

/home/ubuntu/.local/state/cmonchoix/p1-4b2b-final-certify/20260905T150609Z/evidence.sha256
sha256=b09c31f9972e6dfa39bf74e7b05305ed7305ebce6cb0bd0e8031f11425161cde

See ../certification/p1-4-observability-alerting.md for the certification scope and reopening rules.

Server context

Project root:

/mnt/data/cmonchoix-platform

WordPress tracked runtime material:

/mnt/data/cmonchoix-platform/wordpress

WordPress Core must remain absent from the host checkout. The running WordPress container owns Core through the persistent wordpress_runtime volume; the self-contained worker embeds its own certified Core/runtime filesystem in its image.

WP-CLI operational commands are executed from the worker service. Prefer Compose service resolution or Compose labels in reusable tooling rather than hard-coding a transient container ID.

Historical production baseline — P0.11

Observed and certified on 2026-09-03 after P0.10 canonical business certification and P0.11 stateful re-provenance/recovery retirement:

main/release SHA  bea709e6d4fc910dfd4fbd9a051ff27492152b2a
WordPress         3aafdd78a702
MariaDB           139ad5203b7b
Redis             887fab68058b
platform-worker   9e17b183f0a5
DB table count    59
Samsung run       20260903_145152_5a781a3024

Canonical worker image:

ghcr.io/neweden52/cmonchoix-platform-worker@sha256:85cdadb6db1f193a990bfe8d039e9802be1a80eb9ec6f5bbbd42abc8507911d3

Persistent volumes certified unchanged through the P0.11 re-provenance:

cmonchoix-platform_wordpress_runtime
cmonchoix-platform_cmonchoix_mariadb_data
cmonchoix-platform_redis_data

WordPress, MariaDB and Redis now report only the release Compose as com.docker.compose.project.config_files. None of the four active services references ~/.local/state/cmonchoix/live-ops/20260901T104715Z/.

The worker intentionally retains its own earlier canonical release provenance label from its targeted P0.9 rollout; its runtime contract is certified by image digest, mounts, networks, embedded filesystem, database contract and Runtime Guard v2 rather than by forcing an unrelated stateful recreation.

Certification markers observed after the P0.11 re-provenance include:

RUNTIME_GUARD_FAILURES=0
RUNTIME_GUARD_WARNINGS=0
RUNTIME_GUARD_STATUS=PASS
CCX_RUNTIME_GUARD_V2_RUNTIME=PASS
CCX_P0_11_STATEFUL_CANONICAL_REPROVENANCE=PASS
CCX_P0_11_RUNTIME_POST_REPROVENANCE=PASS

The exact container IDs above are certification evidence, not stable configuration identifiers. Scripts must continue to resolve the Compose project/service authority dynamically.

Canonical plugin source

The repository contains one canonical plugin source:

plugins/ccx-feeds-industrial/

The WordPress service mounts this directory read-only at:

/var/www/html/wp-content/plugins/ccx-feeds-industrial/

The self-contained platform-worker does not bind-mount the plugin, src/, vendor/, theme, mu-plugins or a WordPress root from the host. Those runtime assets are embedded in the immutable worker image. The worker keeps exactly two mutable bind mounts: uploads and runtime-spool.

The legacy repository path must remain absent:

wordpress/wp-content/plugins/ccx-feeds-industrial/

Operational rules:

• patch only the canonical source under plugins/;
• never materialize or track an independent runtime mirror;
• keep the WordPress plugin bind mount read-only;
• require the certified worker image to contain the expected plugin/runtime tree without host-code mounts;
• compare host/release and worker plugin trees when certifying a new immutable worker image;
• use Runtime Guard v2 / make doctor to enforce the deployment invariants before and after deployment.

Canonical Platform classes remain under:

src/
vendor/

WordPress consumes them through configured read-only mounts. The worker consumes its embedded image copies. Do not copy src/ into wordpress/ and do not create a second Platform namespace inside the plugin.

Bootstrap topology

The certified WordPress bootstrap graph is:

ccx-feeds.php
    -> bootstrap/platform.php
    -> bootstrap/plugin.php
        -> route-maintenance.php
        -> worker.php
        -> http.php
        -> admin.php
        -> cli.php
        -> frontend.php

Context runtimes:

admin    -> bootstrap/runtime-admin.php
HTTP     -> bootstrap/runtime-http.php after authorization
CLI      -> bootstrap/runtime-cli.php
worker   -> bootstrap/runtime.php

Targeted capability loaders:

bootstrap/mapping.php
bootstrap/quality.php
bootstrap/pipeline.php
bootstrap/strict.php
bootstrap/strict-schema.php
bootstrap/verticals.php
bootstrap/product-models-application.php

These loaders must remain lazy. The presence of the runtime bootstrap does not prove that the Pipeline, Mapping or Quality stack has been loaded.

Context loading matrix

Context	Frontend	Admin	CLI	HTTP	Worker	Pipeline
frontend request	1	0	0	0	0	0
admin read-only	0	1	0	0	0	0
admin action	0	1	0	0	0	targeted
CLI simple	0	0	1	0	0	0
CLI targeted action	0	0	1	0	0	targeted
HTTP forbidden / health	0	0	0	1	0	0
HTTP worker authorized	0	0	0	1	service	targeted
passive cron / empty queue	0	0	0	0	1	0
resumable worker run	0	0	0	0	1	targeted

Operational consequences:

• frontend, admin, CLI, HTTP and worker adapters must not include one another;
• a read-only request must not bootstrap the full Pipeline;
• cron registration must remain lightweight when there is no resumable work;
• the Pipeline is loaded only by actions that actually execute pipeline work.

Sync runtime

The Sync Runtime boundary is split by responsibility:

interfaces/admin/sync-runtime.php
application/admin-sync-runtime-read.php
application/admin-sync-runtime-actions.php
interfaces/admin/sync-runtime-view.php

CLI reads and actions are delegated through application facades:

application/cli-sync-runtime-read.php
application/cli-sync-runtime-actions.php
application/sync-runtime-actions.php

Rules:

• adapters perform parsing, authorization, validation, delegation and output formatting only;
• application facades remain transport-neutral;
• no HTML, redirects, headers or direct request-global reads belong in application services;
• no direct SQL belongs in the public adapter surfaces;
• command names, nonces, redirects and observable payloads must remain stable unless explicitly versioned.

Projection writes

Projection writes are centralized behind dedicated services.

Offer projection:

CCX_OfferProjectionWriteService

Product Model projection family:

CCX_ProductModelProjectionWriteService
CCX_ProductVariantProjectionWriteService
CCX_ProductSpecificationProjectionWriteService
CCX_ProductGalleryProjectionWriteService

Multi-projection rebuild orchestration:

CCX_ProductModelRebuildOrchestrator

Canonical rebuild order:

1. Product Models
2. Variants
3. Specifications
4. Gallery

Entrypoints and orchestrators must not call legacy projection writers directly. Only the dedicated projection services and explicitly documented compatibility writers may touch projection SQL.

Media Quality operational posture

Media Quality runs after offer projection through the normalized offers path:

projection writer
    -> ccx_feeds_upsert_items_to_offers_norm()
    -> pipeline/90-offers-norm.php
    -> includes/media-quality/engine.php
    -> includes/media-quality/rules/*

Current policy is audit-first:

• mutation is disabled by default;
• image_norm must not be cleared because evidence is uncertain or contradictory;
• observations, reason codes and metrics are produced before any write is considered;
• replacement is allowed only when a sufficiently strong candidate is available;
• a historical run whose images were already cleared must be regenerated before new metrics are trusted.

Historical destructive behavior under includes/pipeline/norm/25-image-quality.php is compatibility debt, not the policy reference.

Operational checks must distinguish at least:

• scanned rows;
• rows with image and color evidence;
• checked rows;
• matched rows;
• mismatched rows;
• unknown actual color;
• ambiguous evidence;
• replacement candidates found or absent;
• mutations attempted and applied.

A run is not considered healthy merely because it completed. Its evidence distribution and mutation counters must also be reviewed.

WP-CLI verification

Do not verify command presence with plain grep against wp cli cmd-dump --format=json. The command emits a nested JSON tree.

Use one of these approaches:

docker compose exec platform-worker wp --allow-root --path=/var/www/html help ccx

or parse the JSON structurally:

docker compose exec platform-worker wp --allow-root --path=/var/www/html cli cmd-dump --format=json | jq ...

Operational scripts must fail explicitly when a command is absent instead of interpreting an empty grep result as authoritative.

Health and HTTP

The health route remains a thin HTTP adapter around application services. Authorization, throttling and response translation belong at the boundary; health computation belongs in the application layer.

The generic runtime bootstrap must not register HTTP hooks directly. Unauthorized and health-only requests must not load the full Pipeline.

Technical state

WordPress options, transients and named locks are accessed through the technical state boundary rather than scattered direct calls.

Technical state includes, among other concerns:

• governance snapshots;
• cache state;
• health throttles;
• Product Models cache entries;
• ccx_offers_version;
• named-lock consumers.

Merchant activation is not WordPress technical state. CCX_ACTIVE_FEEDS is the single deployment-owned authority. The legacy ccx_runtime_enabled_feeds option must remain absent, and runtime activation write helpers fail closed.

Loading a capability must not install or mutate schema implicitly. Schema work belongs to explicit installation, migration or maintenance commands.

Run safety

Every operational run must expose enough information to diagnose and resume safely:

• run identifier;
• feed or scope;
• start and end timestamps;
• current status;
• processed and failed counts;
• batch or offset information;
• last error and reason codes;
• whether persistence or mutation occurred.

Expected safety properties:

• idempotent replay where supported;
• explicit resume semantics;
• no duplicate projection caused by retry;
• no silent partial success;
• bounded batches;
• controlled locks and timeouts;
• observable cancellation.

Deployment and synchronization procedure

Before runtime work:

1. confirm the active Git branch;
2. confirm the plugin/runtime authority actually loaded by the target service;
3. inspect the relevant bootstrap and application service;
4. capture baseline command and database metrics.

After a change:

1. run syntax and targeted tests;
2. verify bootstrap isolation for affected contexts;
3. run the relevant WP-CLI command in the worker service;
4. compare runtime metrics with the baseline;
5. verify that unintended schema or projection writes did not occur;
6. record the commit SHA and operational result.

When historical data has been destructively altered, rebuild the affected projection before evaluating a new algorithm.

Recovery evidence posture after P0.11

The temporary recovery authorities from the 2026-09-01 incident are no longer active runtime inputs. P0.11 archived them, together with the P0.9/P0.11 rollback evidence, historical Compose and incident evidence, under:

~/.local/state/cmonchoix/archive/p0-11-recovery-retirement-20260903T151852Z/

MANIFEST.sha256 contains 35 entries and was verified before and after publication. RETIREMENT.txt records why the archived rollback files are evidence only and are not directly executable authorities.

The historical absolute paths inside archived rollback records are intentionally preserved. Do not rewrite the archive, and do not restore those historical paths without a new recovery decision and a separate validation plan.

Operational invariants

The runtime is considered conformant only while all of the following remain true:

1. Adapters are thin and context-specific.
2. Shared application services are transport-neutral.
3. Read-only contexts do not load the full Pipeline.
4. Frontend requests do not perform persistent route-maintenance writes.
5. Passive cron does not bootstrap pipeline work without a resumable job.
6. Projection writes pass through dedicated write services.
7. Schema mutation is explicit and never an incidental side effect of loading code.
8. Media Quality is non-destructive by default.
9. The canonical plugin source remains unique; WordPress consumes it read-only and the worker consumes its certified embedded image copy without host-code binds.
10. Merchant activation has one deployment-owned authority and no WordPress option shadow.
11. Every material run is traceable, diagnosable and safely resumable.
12. Active runtime and systemd authorities do not depend on retired live-ops recovery overrides.

Related documents

• deployment.md
• recovery.md
• recovery-p0-11-archive.md
• ../runtime/overview.md
• ../architecture/media-quality-engine.md
• ../pipeline/normalisation.md
• ../business-domains/catalog/projection-engine.md
• ../contracts/quality-scorer.md
• ../../plugins/ccx-feeds-industrial/README.md