Expand description
YAML schema types for values/<env>.yaml per RFC §2.2.
Phase 1 scope: deserialize the file and validate built-in shapes
(lid: [a-z0-9]{8,}, cb_id: cb[0-9]+). Resolution wiring per
resource/field comes in Phase 2 / Phase 3.
Forward-compat policy: #[serde(deny_unknown_fields)] is intentionally
NOT applied here — values files are user-edited and the RFC permits
omitting empty namespaces (e.g. preheader: {}). The strict shape
check happens via validate() after parsing.
Structs§
- CbId
Entry - A cb_id value. Key = referenced content_block name slug (RFC §3 Q3).
- Content
Block Values - Resource-scoped values for a content_block. content_block bodies are
single-body so
lid/cb_id/customlive directly under the resource (RFC §2.2). - Custom
Entry - User-managed custom value; opaque string. No shape validation per RFC §9 Q3 (custom is left to user).
- Email
Template Values - Resource-scoped values for an email_template.
lid/cb_idare field-scoped because lid is a per-occurrence ID tied to in-field position.customlives at the resource root only (RFC §2.2). - Field
Values - lid / cb_id namespaces for one email_template field.
- Globals
- Cross-resource per-env values. Currently only
customis populated; future extension may addglobals.lid/globals.cb_id(RFC §2.2). - LidEntry
- A lid value with its correlation anchor.
urlis set for fields that have a hyperlink context (HTML / plaintext bodies);anchoris set for URL-less fields (subject / preheader). Either may be absent for skeletons generated bytemplatize(RFC §2.7). - Values
File - Top-level
values/<env>.yamldocument.
Constants§
- SUPPORTED_
VERSION - Currently supported values file schema version (RFC §5 Edge cases).
Functions§
- default_
values_ path - Default location resolver. RFC §2.1:
values_fileconfig field wins, otherwisevalues/<env>.yamlrelative to the config dir.