Staging and publishing

Live publishing is default-off and gated behind a release check. Building and inspecting a draft is always available and always zero-write.

Building a draft

Approved recommendations are turned into a deployment draft in one action. The draft is idempotent: running it twice with the same approved set produces the same draft rather than a second one.

Building a draft writes nothing to any store. It is a local plan.

What a draft contains

Per item: the application, product, and market; the exact before price read from the store; the exact target price; and any validation messages.

Draft-level checks run before it is considered ready:

• Stale-state refusal — the draft is built against the latest store read, and refuses if the store has moved since.
• Confidence checks — items whose confidence dropped below threshold since approval do not pass.
• Protected-market checks — a protected market cannot be included.
• Plan-relationship checks — the change must not invert the economics of a plan ladder, such as making an annual plan cost more per month than the monthly one.
• New-customer-only warnings — subscription price changes apply to new customers; existing subscribers are governed by store policy and consent rules. The draft says so explicitly rather than leaving it implied.

A withdrawn product fails the whole selection, which is why withdrawn items are excluded when the draft is assembled rather than left to break it.

Publishing

Publishing is a separate, explicit action on a ready draft, and it is only enabled when the deployment is configured to allow live writes or the connection is running in fixture mode.

When it runs:

1. An atomic execution claim is taken, so two workers cannot publish the same deployment.
2. The store is re-read immediately before the write. If the live state no longer matches the diff, the write is refused.
3. Each item is written independently. A rejection on one market does not roll back or hide the others.
4. Each item is read back from the store and compared against what was intended.
5. Every item reports its own status and result.

The publish worker retries provider failures and isolates per-item failures. Nothing is reported as succeeded that was not verified by a read-back.

Why this is still beta

Three things are missing before live publishing can be generally enabled:

• Controlled real-account mutation proof. The path has not been exercised end-to-end against a real Google product under release conditions.
• Stale publishing-claim recovery. If a worker crashes mid-publish, the claim is not yet reclaimed automatically.
• Rollback as a new forward deployment. Reverting currently means staging the inverse change by hand.

Until all three are done, treat publishing as a capability that exists and is tested but is not yet warranted for production use — and do not rely on rollback existing.

Fixture mode

Fixture mode runs the entire loop against a fixture provider instead of a live store. The orchestration is identical, which is the point: the same code path is exercised, so a fixture run is a real test of the flow rather than a simulation of it.