orbit_compose_stripo_email — name your pushed emails properly, plus advisory warnings for em dashes and bloated hero H1s
Two small additions to orbit_compose_stripo_email, both born out of running enough real Stripo pushes to feel the friction. First: an optional email_name argument. Pass email_name: "Welcome - Paid" (or whatever program-variant label makes sense) and that string is written to Stripo verbatim as the email's display name. Omit it and the existing Orbit · <subject> · <timestamp> auto-name still fires — but anyone running a real lifecycle program ends up renaming every pushed email in the Stripo UI to find anything later, so the override is the path you actually want. Square brackets are stripped defensively because Stripo's API rejects them in email names. Second: convention_warnings on the push response. Two non-blocking checks against the workspace's own brand-guidelines and email-design-conventions docs — em dashes anywhere in subject, preheader, email_name, or any nested slot_values text (recursive); and a hero H1 cap of one sentence and four words, scoped to the position-1 module's title slot so long titles on later modules don't false-positive. Warnings are advisory; the push still succeeds. Each warning carries rule, location, value, and a fix hint, so the assistant can self-correct on the next pass rather than wait for a human read-through.
What shipped
•New parameter — orbit_compose_stripo_email now accepts an optional email_name string. When set, it becomes the email's display name in Stripo's email list, verbatim. When omitted, the existing Orbit · <subject> · <timestamp> auto-name still applies. The use case: a real lifecycle program runs dozens of distinct emails across journeys, segments, and variants — Welcome - Paid, Welcome - Free, M2 Phone Divert A - Starter — and the auto-named format made every pushed email read identically in the Stripo UI, forcing a manual rename on every single push to find anything later. Recommended convention is program-variant naming (Program - Variant - Step) but the field is free text, so any naming scheme your team already runs works. Square brackets are stripped before push because Stripo's API rejects them in email names — the strip is silent and the bracketed content is preserved as plain text.
•New response field — convention_warnings. Push responses now carry a convention_warnings array surfacing non-blocking violations of two universal copy rules sourced from the workspace's brand-kit/brand-guidelines.md and conventions/email-design-conventions.md. Rule one: no em dashes (—) in any user-supplied string — subject, preheader, email_name, or any text value inside slot_values, including text nested in content[] arrays for Smart Container modules. The recursive walk means a hero H1 with an em dash inside a layout shell's third child module still gets flagged. Rule two: hero H1 cap — the first module in the resolved sequence (position 1) must have a title slot (p_title / title / headline) of one sentence and four words or fewer. Bounded to position 1 by design so longer titles on body modules, comparison rows, or feature blocks don't trigger.
•Warning shape — each entry in convention_warnings carries rule (the named convention being checked), location (which input field tripped it — subject, preheader, email_name, slot_values.<module_id>.<key>, or hero_title), value (the offending string so you can see what triggered it), and fix (a short hint — e.g. 'replace — with , or split into two sentences'). Warnings never block the push: a pushed email with three warnings still lands in Stripo and Braze, just with a heads-up that the copy drifts from the brand's stated conventions. The assistant reading the response can self-correct on the next compose pass; brands whose conventions don't include these rules can ignore the field entirely.