Adopt Letterpress at the template boundary, not inside a provider adapter.
- Map the consumer's variable registry to a versioned Letterpress schema.
- Convert legacy source into one of the public profiles.
- Compile every deliverable locale before moving the publication pointer.
- Persist the full artifact beside the consumer's version record.
- Render the artifact in the delivery job with already resolved values.
- Keep provider policy, tenancy, authorization, retries, and audit records in the consumer.
Legacy Mustache, Handlebars, EEx, or unrestricted HTML are conversion inputs,
not runtime profiles. Bounded HTML fragments may use html/liquid@1 only after
they satisfy its element, attribute, Liquid, and URL rules. A migration adapter
should fail records it cannot convert, surface diagnostics for review, and pass
successful output through the normal compiler. It must not add a compatibility
mode to Letterpress.
Use an expand/backfill/contract migration when adding artifacts to a live system. Old and new application versions must coexist until every active publication has a verified artifact and delivery no longer reads the legacy field.
Translation providers receive only extracted translation units. For email,
pass the original subject and plain-text alternative while extracting, then
apply provider responses with Letterpress.localize/5. It returns the MJML,
subject, and text authoring sources together or rejects the entire locale when
any unit is missing or changes protected structure. Compile those three
localized sources into one artifact. Letterpress.apply_translations/5
remains the source-only path for the HTML and text profiles. The consumer still
decides locale completeness, review, and publication policy.