Execution infrastructure for WooCommerce checkout

FlxWoo implements a structured execution layer between WooCommerce hook logic and rendered checkout output — replacing implicit coordination with a deterministic, inspectable pipeline.

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.

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

Receives an immutable snapshot of validated field state. Produces checkout output. Cannot modify field definitions, trigger re-validation, or write back to Core. Render isolation prevents output generation from corrupting execution state.

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 infrastructure already implemented

FlxWoo is under active development. The following infrastructure is implemented in production-oriented code:

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

Architecture specification

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

View architecture