Article CMS Persistence Workflow¶
Purpose¶
This document defines the persistence rule for article-domain changes: article and article-collection changes are not complete until the resulting state exists behind article-bff.
Authority Model¶
article-bffis the retrieval and mutation gateway.- CMS is the underlying persistence layer.
- This repo may describe desired content shape and collection usage, but it does not become the persistence layer.
Required Persistence Rule¶
When article-domain content changes:
- resolve the target object in the BFF
- validate the intended shape against the live contract
- persist through the appropriate BFF mutation
- re-read and verify the stored state
Guardrails¶
- Do not declare fields authoritative unless they are actually persisted and returned by the live BFF.
- Use BFF-returned slugs and keys as operational truth.
- Treat app caches and generated JSON as delivery artifacts, not persistence evidence.
Assistant Obligation¶
For article-related change work, the assistant should:
- identify the affected article or collection object
- validate against the live BFF contract
- mutate through the BFF when the task includes persistence
- report any contract gap instead of inventing local fallback authority