Preserve recipient output with a canonical rendering profile

This work is explicitly blocked on #1, #29, Relay UI, and AISL context-owner acknowledgements, so first confirm those contracts are accepted before implementation. Then read mailing/services/transactional_markdown.py and the canonical rendering, version, dry-run, and send-preparation seams; add focused profile-output and integration tests there, reusing #1's engine/security tests and #29's footer tests. Done means independently inspected artifacts match the donor outputs without weakening validation or adding side effects.

Preserve recipient output with a canonical rendering profile

Status: groomed preservation child of Relay #30; implementation blocked.
Depends on: #1 accepted canonical validator/context/source-selection/rendering capability; #29 accepted literal footer capability; AISL #1885 frozen synthetic preview inputs/schema.
Blocked by: #1 rendering/version owner, #29 footer, Relay ui and AISL context owner acknowledgements. Any donor-template construct incompatible with #1 safety remains an owner-ruling and adoption blocker.

Goal

Supply only the missing recipient-compatible profile/output delta through #1's native renderer. Preserve existing AISL subject, HTML/chrome, plain text, authored formatting/links and footer actions. Consume #1's validator, typed contexts, immutable source selection, zero-write rendering and queued snapshot contract; do not create a parallel renderer/context engine/version owner or relax its safety policy.

Scope

• Use an explicit generic profile in the canonical rendering pipeline for Markdown/plain-text conversion, branded chrome and supplied recipient action slots. Existing Relay clients retain their profile and visible behavior. No plugin framework, arbitrary rendering language, site imports or copied AISL renderer.
• Agree a pinned profile identity/revision seam with #1's immutable source owner. If the canonical source cannot freeze that reference, stop for its owner's narrow contract change; this child must not invent another snapshot lifecycle or resolve queued content from mutable defaults.
• AISL's P07 adapter supplies donor aliases user_name, user_email, site_url, site_name and purpose keys, caller-precedence/default values, greeting fallback without email handles, recipient-local datetime/DST formatting, classifications and fresh action policy. Relay consumes already normalized #1-compatible contexts, not AISL users/timezones/token minting. Preserve caller-authored names; no silent name/email remapping. Schema/type/error enforcement remains #1-owned.
• Preserve exact donor-equivalent Markdown formatting and plain-text conversion rather than using Markdown source unexamined as text. Retain branded chrome, literal footer escaping and action order: authored footer, verification, unsubscribe. Supplied actions are identical between HTML/text; absence and template opt-outs come from the adapter. No second template execution of footer.
• Enumerate actual bundle template constructs against #1's allowed expressions/filters/tags and safe escaping. Incompatibility fails safely and blocks adoption. Never weaken #1 validation, replace required authored behavior silently, or change donor templates under this child. Root/owners must agree a safe preserving disposition before the conflicting case can pass.
• Preview, dry-run and mocked real-send preparation exercise #1's same pinned source and validator plus this profile. Rendering adds no database/history/queue/provider effect. Existing screens/routes/API/permissions/editor/task behavior stay; catalog truncation is not recipient evidence and gets no redesign here.

Acceptance criteria

• The dynamic fixture ledger covers named/nameless recipients; file, whole-record override and override-only sources; representative timezones/DST and already-formatted strings; verified/unverified and opt-outs; promotional/transactional/welcome action contexts. No fixed catalog count or one-template-per-purpose assumption.
• Content-safe donor expected and native Relay subject/HTML/plain-text outputs match at full preview, dry-run and mocked-send preparation for the same canonical source/context/profile. Compare authored formatting, links/attributes, chrome/brand/footer and action order/targets. Independently inspect rendered artifacts.
• Each permitted normalization is explicit and cannot hide a visible or semantic loss. Synthetic token/clock substitution or justified transport line endings may be normalized; do not erase CSS/tags, meaningful whitespace, punctuation, brand, text formatting or action differences.
• Controls cover canonical escaped hostile variables, donor alias/caller precedence, greeting fallback, adapter-formatted datetime/string variants, literal footer delimiters, action combinations, inline bullets/code/tables and internal/external links. #1 rejected types/constructs remain rejected with stable safe errors; no duplicated validator.
• Mutations substituting Relay default chrome, Markdown-as-text, dropping footer/verify/unsubscribe, remapping aliases or ignoring the pinned profile fail comparison assertions. Earlier immutable outputs remain unchanged after a later draft/profile revision through #1's existing contract.
• Existing other-client profile, API permissions/statuses and screen/history behavior remain characterized and unchanged. Exact header/sender parity is not claimed until P03/#22 passes its separate boundary, including body/header HTTPS token equality and donor Reply-To rules; P15 calendar and #32 outcome safety remain pending.
• Fresh independent Tester terminal evidence binds exact source/tree/donor/schema/profile/fixtures and inspected output hashes. PM accepts recipient fidelity afterward. Unknown construct mismatch or pending adapter/owner proof stays blocked; no redesign or feature retirement disposition is accepted.

Meaningful tests and ownership

Add focused profile-output and canonical integration tests at the existing rendering/version/dry-run/send-preparation seams; reuse #1's engine/security tests and #29's footer tests. No credentials, real SES, live links, recipient data or network. Recipient visual artifact inspection is required although website-page screenshots may be not applicable to unchanged screens.

Review targets: mailing/services/transactional_markdown.py and #1's canonical rendering seam; cohesive email_plain_text.py/profile module only if needed; native profile chrome template under ui ACK. #1 owns source/context validation and selection; #29 owns footer composition/storage. transactional.py remains thin delegation, not new logic in an oversized file. No generic model/API refactor, new public route, editor control or framework. Any profile metadata field is a narrow owner-coordinated canonical change, not a second version store. New files <=300 lines, functions <=30; explicit control flow/no ternaries/simple loops, DRY one business owner. No invented waiver.

Follow current Relay role/test process. #1's safe API contract is the foundation; old R1.3 #10/#11 are historical coverage, not permission to duplicate it or a recipient-parity receipt.

Boundaries

Proposed P01 owns atomic bundle import only. P07 owns AISL greeting/timezone/verification/token/lifecycle policy, P03/#22 transport headers/campaign preview semantics, P10 operator/editor fidelity, P15 raw calendar MIME, #26 history and #32 send-outcome certainty. Durable bundle inputs never gain live bearer payloads; ephemeral delivery resolution must meet its own accepted P07/canonical contract. No UI changes, data/feature removal, source template rewrite, production access, real import/send/deployment/cutover or donor deletion. Keep current donor paths until actual preservation/adoption is accepted; #30 stays open.