WooCommerce execution platform

FlxWoo implements a deterministic checkout pipeline, a headless rendering service, and operational reliability infrastructure. Three subsystems with enforced boundaries — Core, Render, and Control — operate on top of WooCommerce without replacing it.

Checkout state is mutable shared state

In a standard WooCommerce checkout, every plugin that touches checkout fields reads and writes to the same shared state independently. There is no coordination layer. Hook execution order determines behavior. Plugins are unaware of what others have already done.

Validation logic accumulates across hooks without a unified pass. Rendering couples to execution timing — what gets rendered depends on what happened to be resolved at the moment render ran. Debugging becomes probabilistic because failures do not correspond to inspectable phases.

The result is a checkout that produces different output under different conditions: different plugin load orders, different session states, different request timing. The failures are not random — they are structurally determined. But without phase boundaries, there is nothing to observe.

What FlxWoo changes

FlxWoo imposes explicit structure on the checkout execution lifecycle. Three subsystems own distinct responsibilities with enforced boundaries between them. Execution state is inspectable at every phase — failures become observable engineering events, not intermittent production mysteries.

Core

Owns the canonical field registry. Manages data resolution by declared priority, not hook order. Runs all validation rules against resolved state before any render phase. Core state is finalized before Render executes.

Render

A dedicated service operating independently from WooCommerce rendering. Receives an immutable snapshot of validated field state and produces product, cart, checkout, and thank-you page output. Cannot modify field definitions, trigger re-validation, or write back to Core.

Control

Coordinates the pipeline lifecycle. Sequences phases, enforces completion before advancement, wraps each phase in error boundaries, emits structured traces, and handles pipeline interruption.

Operational reliability infrastructure

Deterministic execution produces consistent behavior. Operational reliability makes that behavior inspectable. Every pipeline execution produces a structured trace; replay tooling reproduces past executions from stored state rather than requiring live system conditions. The following infrastructure is implemented:

Request tracing — unique IDs scoped to each pipeline execution
Phase-level logging — start, completion, and error events per phase
Structured validation failure types — field key, rule name, message
Webhook replay tooling — reproduce and debug webhook execution from logs
Stripe event handling infrastructure
Idempotency handling for payment and order operations
Deployment verification scripts
Smoke test tooling for pipeline integrity checks
Observability scripts for execution auditing
WP-CLI operational tooling for diagnostic and maintenance workflows
Cache/no-cache configuration with operational guidance

Deterministic guarantees

These invariants hold for every FlxWoo pipeline execution. They are enforced by the system, not by convention.

Render never receives unvalidated field state
Validation completes before any render phase begins
Field registration closes before resolution begins — no late additions
Output depends on finalized, resolved state — not on execution timing
Phase ordering is fixed — no phase can be skipped or reordered
Pipeline execution is fully inspectable via structured trace logs
Validation never mutates field values
Render has no write path back to Core

Production fallback

FlxWoo includes a production fallback path. If pipeline execution fails or the Render service is unavailable, execution falls back to WooCommerce native rendering. No request fails silently.

Render service unavailable — WooCommerce rendering serves the request; the degradation event is logged with failure reason and duration
Output failure — falls back to WooCommerce default rendering with a full pipeline trace logged
Pipeline interruption — Control halts cleanly; no partial output is delivered

Fallback events are observable through the same trace infrastructure as normal executions. Degradation is explicit and logged — not silent.

Architecture specification

The architecture page defines subsystem boundaries, execution guarantees, the observability model, and the failure model in detail.

View architecture