What's new in Orbit.

14 May 2026

CTA half-pair drift detector + Braze validator now recognises standard profile fields

Two payloads in one release. The Stripo module-bindings inspector gains a half-pair drift check — catches a CTA where only one half of the text/link Smart Property pair is registered, leaving the other half hardcoded in the module HTML. This was a quiet authoring slip with loud production consequences: every compose call looked successful while shipping the master-template default for the unregistered half. Scope is gated to base names ending in cta / button / btn so image-as-link patterns don't false-positive, and an ACK comment marker is available for intentional half-pairs (split CTAs where one half is design-by-intent static). Separately, orbit_validate_braze_data now recognises Braze's 26 standard user-profile fields (first_name, country, time_zone, push_token, etc.) alongside your custom attributes, so it stops false-flagging well-known profile fields as missing. Each found attribute is now tagged with whether it's standard or custom and the exact Liquid syntax to use, so the assistant can stop guessing whether to wrap a name in custom_attribute. orbit_audit_braze_instance surfaces the same 26 standard fields alongside the custom inventory. And orbit_validate_test_users no longer 400s when you pass an array of email addresses — Braze's /users/export/ids endpoint quietly accepts an array of external_ids but only a single email_address per request, so the tool now loops emails serially. The expanded response surfaces every standard field's value plus populated / empty arrays per profile, so verifying "is first_name actually populating in this test profile?" no longer requires inspecting the raw user object.

• •New detector — orbit_inspect_stripo_module_bindings now flags CTA half-pair drift. When a Smart Property ends in `_text` or `_link` and its base name resolves to a CTA shape (anything ending in cta, button, or btn — bare like `p_cta_link`, indexed like `p_cta_link_1`, or prefixed like `p_secondary_cta_link`), the inspector checks that its companion half exists. If only the link half is registered and the text half is missing (or vice versa), the unregistered half is silently hardcoded in the module HTML and ships unchanged on every compose. The note names the present variable, the expected companion, and which half (text or link) is currently registered. Six new fixture cases cover the surface: link-only drift, indexed-pair drift, full pairs (no fire), image-as-link false-positive guard, and ACK suppression.
• •Suppression path — half-pair drift accepts an ACK comment marker for intentional half-pair authoring. Some modules deliberately bind only one half — e.g. a split-CTA module where one side's label is set in the master template and never personalised. Paste `<!-- ACK: p_cta_link half-pair is intentional -->` (or the equivalent for indexed variants) directly into the module HTML and the inspector skips the note for that variable. The wizard preserves HTML comments across re-opens, so the marker survives every subsequent edit in the Stripo editor.
• •Validator coverage — orbit_validate_braze_data now checks Braze's 26 standard user-profile fields alongside your custom attributes. Before this release, asking the validator to check `first_name` against a Braze workspace that had no custom `first_name` attribute would return missing — even though first_name is a standard Braze field every user profile carries. The 26 fields come straight from Braze's API docs: identity (external_id, email, phone), profile basics (first_name, last_name, gender, date_of_birth), localisation (country, home_city, language, time_zone), subscription/consent (email_subscribe, push_subscribe, email_open_tracking_disabled, email_click_tracking_disabled), session timing (last_used_app, first_used_app), and social (facebook, twitter). Real impact: validator stops false-flagging well-known profile fields, and the validation message now spells out which fields it covered so authors aren't second-guessing the result.

14 May 2026

Stripo setup consolidates to a single working path — Smart Element bindings, no more dead-end detours

Three empirical probes against Stripo's REST API today confirmed what 0.19.6 onward had been narrowing toward: there is exactly one path that supports per-send content substitution on Stripo modules, and it's pushing variable values into modules marked up with esd-dynamic-block Smart Element bindings via the editor's Smart Elements wizard. Every inline-HTML push path — the legacy areas shape, dataSources inline html, PUT edit-after-push — fails, the first two silently. So 0.19.10 strips user-facing references to those dead paths and consolidates around the one that works. orbit_setup_stripo gains a new Step 4 that walks you through marking up your modules with Smart Element bindings before you ever try to compose against them. orbit_inspect_stripo_module_bindings now hand-holds you toward the Smart Elements wizard when it sees a module with no or few registered variables, rather than leaving you to guess what's wrong. The three Stripo probe tools — orbit_probe_stripo_values, orbit_probe_stripo_inline_html, orbit_probe_stripo_smart_element — get their descriptions reframed so it's clear which two are internal diagnostics confirming dead paths are still dead, and which one tests the production path. And the stripo-integration skill now opens with a Foundational requirement preamble so anyone loading the skill cold lands on the right path from sentence one.

• •Setup change — orbit_setup_stripo gains a new Step 4 walking you through marking up your modules with Smart Element bindings via Stripo's editor wizard. Before this release, setup ran from workspace credentials straight through to verifying a generation area, with the binding work tucked away as an implication of later module authoring. The new Step 4 is explicit: open each module you want to use for per-send content, run the Smart Elements wizard, mark up p_title / p_description / p_cta_text / p_cta_href / p_image_src on the right DOM elements, save. The verify step is renumbered to Step 5 and still runs the end-to-end sanity check. Net effect — a fresh setup now produces modules that actually accept slot_values on the first compose call, instead of one that looks correct and silently no-ops at substitution time.
• •Hand-hold guidance — orbit_inspect_stripo_module_bindings now surfaces a sparse-binding block when it sees a module with no registered variables, or very few relative to the visible class hooks. Before, an empty inspection report would tell you the module had zero Smart Properties registered and stop there. Now the same report points you at the Smart Elements wizard step in orbit_setup_stripo and the stripo-module-bindings skill, with the canonical p_* naming reminded inline. Saves you the round-trip of running the inspector, getting an empty answer, and then having to work out from first principles which doc or skill to load next.
• •Tool descriptions — orbit_probe_stripo_values, orbit_probe_stripo_inline_html, and orbit_probe_stripo_smart_element reframed in their schema descriptions so it's clear which one tests the production path. The first two are now labelled as internal diagnostics — they exist to re-confirm that Stripo's dead inline-HTML push paths are still dead, useful for regression detection if Stripo ever quietly enables them, but not something you'd ever run as part of a normal workflow. orbit_probe_stripo_smart_element is the one to reach for when you want to empirically verify a real binding substitutes correctly end-to-end. Same tools, no behaviour change, just description hygiene so the assistant picks the right probe when you ask.

14 May 2026

Module inspector stops crying wolf — static-asset predicate tightens, wizard-link note gates on real buttons, and HTML-comment ack markers let authors mute design-intent notes

Three precision fixes to the Stripo module-bindings inspector after the 0.19.8 detectors landed and immediately produced false positives in real workspaces. The static-asset pattern check now counts a variable as image-bound only when its primary mapping targets the src attribute, so text variables with secondary alt/title mappings on an image element no longer pad the count and trigger the note. The wizard top-level link-field note now requires the module to actually contain a button-shaped element AND not already have an href binding registered against it, so modules with no button (or modules whose CTA href is already covered by a registered Smart Property) stop seeing a note they can't act on. And two HTML-comment patterns the skill already recommended are now read back by the inspector — paste the static-asset marker comment to silence the static-asset note for a module whose imagery is design-by-intent, or paste an ACK comment naming a specific variable and attribute to silence selector-without-target notes for bindings that are dormant on purpose. The skill doc gains the exact paste-ready snippets in a new Acknowledging static-asset intent subsection.

• •Bug fix — static-asset pattern detector no longer counts secondary alt/title mappings as image bindings. The 0.19.8 check counted a Smart Property as image-bound whenever any of its blockMapping[] entries had attribute === src, which falsely included text variables (p_name, p_title) that carried a secondary mapping onto an image's alt or title attribute for re-use. Modules with a single hero image but multiple text variables linking alt-text into it were tripping the note. The predicate now reads only the first blockMapping entry — the primary binding — so a text variable whose first mapping is on a description class no longer qualifies as image-bound regardless of what its secondary mappings touch. Real impact on a typical workspace: false-positive notes drop on quote, two-column, and grid modules; the genuine static-asset case (comparison tables, emoji bullets, badge grids) still fires cleanly.
• •Bug fix — wizard top-level link-field note gated on actual button presence and binding coverage. The note 'Button CTA may be bound via the Smart Element wizard's top-level link field…' previously fired on every module whose top_level_link_field flag was set, regardless of whether the module contained a button at all or whether the CTA href was already bound. The check now requires both: (a) the module HTML contains a button-shaped element (a tag with es-button or esd-button class, role='button', a button element, or a Stripo es-button- table wrapper), AND (b) no registered variable already has an href binding in the module. Modules with no button suppress the note entirely; modules where p_image_link or similar already owns the click suppress the note as well. The genuine case — real button, no binding — still fires.
• •New feature — HTML-comment markers suppress design-intent notes. Two paste-ready patterns the inspector now reads back. (1) A static-asset intent marker — paste an HTML comment starting with 'Static asset markers' above a module whose imagery is intentionally static (tick markers, badge grids, brand-logo walls) and the inspector skips the static-asset note for that module. (2) Per-variable acknowledgement markers — paste '<!-- ACK: p_title.alt selector-without-target is intentional -->' to silence the selector-without-target note for one specific variable + attribute combo, or '<!-- ACK: p_title selector-without-target is intentional -->' to silence all attributes for that variable. The wizard leaves HTML comments alone, so the markers survive every re-open of the module in the Stripo editor.

13 May 2026

Module inspector now catches the two Stripo authoring traps that quietly break compose: static-asset re-registration and nested-selector clobbering

Two new detectors land on orbit_inspect_stripo_module_bindings and orbit_audit_stripo_modules, both targeting Stripo authoring patterns that pass structural inspection, render fine in the editor, and then misbehave at compose time. First: the static-asset pattern. When a module registers three or more image variables all bound to src on esd-gen-image* class elements, the asset URLs are almost always design — tick markers, badge grids, brand-logo walls — not per-send content. The trap is that Stripo's Smart Element wizard auto-re-registers esd-gen-* classes every time the module is reopened in the editor, so deregistering from the Data tab doesn't stick. The fix is documenting which variables are static-by-design as an HTML comment at the top of the module, which the wizard leaves alone. The inspector flags the shape and tells you what comment to add. Second: nested selectors. When two Smart Property bindings target elements where one contains the other in the DOM, Stripo writes the outer binding by replacing the inner element wholesale at compose time, and the inner binding's value gets clobbered. Detection uses real DOM containment via Cheerio, not string matching. Both detectors fire in the single-module inspector and the bulk auditor, and the static-asset best practice is now in orbit_setup_stripo's onboarding instructions. Also in this release: a brand-name fallback fix so unconfigured workspaces no longer see a hardcoded value.

• •New detection — static-asset pattern. orbit_inspect_stripo_module_bindings and orbit_audit_stripo_modules now flag modules that register three or more image-bound variables (p_image, p_image2, p_image3, etc.) all targeting src attributes on elements with esd-gen-image* classes. This shape almost always indicates a module whose imagery is design rather than dynamic content — a row of tick markers, a feature-comparison grid, a logo wall. The pitfall the detector exists to prevent: Stripo's Smart Element wizard auto-re-registers esd-gen-* classes every time the module is reopened in the editor, so removing the variables from the Data tab doesn't survive the next edit. The recommended fix surfaces in the inspector's notes — add an HTML comment at the top of the module listing each static variable and its canonical asset URL. The wizard leaves HTML comments alone, so the comment is the durable record of what's intentionally static.
• •New detection — nested Smart Property bindings. When a module has two bindings where one selector targets a DOM element that contains the other binding's target, the inspector and auditor now flag the pair. The mechanism: at compose time Stripo applies bindings by replacing the targeted element wholesale, so when the outer binding fires it overwrites the inner element and the inner binding's value never lands. Detection walks the parsed DOM with Cheerio's $.contains rather than guessing from selector strings, so cases like a header binding wrapping a CTA binding are caught reliably regardless of how the selectors are written.
• •Onboarding update — orbit_setup_stripo's 'Module design — works best with these principles' section now includes the HTML-comment best practice for static assets. New modules built against the latest setup output get the durable-contract pattern baked in from the start, rather than discovering the wizard-re-registration trap after the fact.

12 May 2026

Module-bindings inspector now catches the silent-no-op variable, plus a hardened binding skill and a probe-email recipe in the guide

0.19.6 made per-send substitution on Stripo modules work end-to-end. 0.19.7 is the follow-up that closes the loop on verification. A registered Smart Property can point at a CSS class hook that doesn't exist anywhere in the module's HTML — the variable accepts values at compose time, the API returns success, and substitution silently never fires. You only notice when the defaults ship in production. orbit_inspect_stripo_module_bindings now flags exactly this case per-variable, with the fix path inline. The stripo-module-bindings skill has been hardened around what the inspector still can't catch on its own: a pre-flight checklist before treating a binding as done, the end-to-end probe-email recipe that's the only honest way to confirm substitution actually fires, the canonical p_* naming table, and worked examples of three common silent-no-op patterns. The Stripo Modular MCP integration guide has been extended with the same probe-email procedure so anyone working from the docs can verify their bindings without loading the skill first.

• •Bug fix — orbit_inspect_stripo_module_bindings now detects registered Smart Properties bound to a CSS class hook that doesn't exist in the module's HTML. Before, a variable registered against .esd-gen-headline on a module whose Design tab never created an esd-gen-headline class anywhere would pass inspection clean — the variable was structurally valid, just bound to nothing. Compose calls accepted values for it and Stripo silently dropped them on substitution. The inspector now cross-references every registered variable's blockMapping[].selector against the actual class hooks in the module HTML and emits a per-variable warning in the notes array when the target class is missing, with the exact fix path: either add the class in Stripo's Design tab or remove the dead registration.
• •Skill update — stripo-module-bindings hardened with the four things the inspector alone can't catch. A pre-flight verification checklist that runs before any binding work is treated as done. The end-to-end probe-email recipe — push a real email with sentinel values, fetch the rendered HTML, confirm the sentinels landed — which is the only honest way to verify substitution actually fires given that structural inspection can't catch every silent-no-op pattern. A canonical naming-conventions table for p_* Smart Property variables (p_title / p_description / p_cta_text / p_cta_href / p_image_src / p_image_alt) so workspaces don't drift across modules. And worked examples of three common silent-no-op patterns: selector-without-target (the case the new inspector check covers), class-on-wrapper (where the class lives on a parent element that doesn't carry the bindable attribute), and the Smart Element wizard's top-level link-field dead-end (the editor binding that's invisible to the API).
• •Guide update — Stripo Modular MCP integration guide gains the probe-email recipe inline. The new section, 'Verifying that bindings actually substitute — the probe-email recipe,' walks through Stripo's preview-API endpoint (/cabinet/stripeapi/v2/preview/web/<uuid>), the four common substitution failure modes (missing class hook, class on wrong element, wizard-bound CTA, Smart Container slot misregistration), and the five-step probe procedure: push with sentinel values, fetch the previewed HTML, search for sentinels, diagnose the failure mode if any are missing, fix and re-probe. Existing sections sharpened to acknowledge that orbit_inspect_stripo_module_bindings catches structural gaps but not substitution failures — the probe is the only way to close that gap. Reading time bumps from 9 to 13 minutes.

12 May 2026

Per-send substitution on Stripo modules works end-to-end, plus a new skill that walks you through binding them

Two halves of the same release. First, the sync bug that was silently breaking every per-send substitution call is fixed. Smart Properties in Stripo carry two labels — a canonical API identifier (e.g. p_title) and a human label shown in the editor (e.g. Title) — and Orbit's sync was storing the human label, so the compose validator kept rejecting correctly-formed payloads asking for p_title. The extractor now reads the API identifier, the CSS class hook gets persisted alongside it, and slot_values substitution works against the variable names Stripo's docs already tell you to use. Second, a new skill — stripo-module-bindings — walks you through the editor work that has to happen before any of this is useful. Registering a Smart Property in Stripo's UI has a load-bearing picker that's the same shape as a similar wrong option: pick the wrong one and the binding looks fine in the editor and is invisible to the API. The skill is the antidote: step-by-step registration, the verification check that catches the silent-failure mode, and a naming convention that matches Stripo's own.

• •Bug fix — orbit_compose_stripo_email now accepts the canonical Smart Property variable names (p_title, p_description, etc.) instead of the human-readable editor labels (Title, Description). Stripo's variable config gives each Smart Property both a 'variable' field (the API key) and a 'name' field (the editor label); Orbit was reading the wrong one and storing the editor label as the substitution key. Every compose call passing the documented variable identifier was getting rejected with 'Variable p_title is not defined.' The extractor now reads 'variable' first, falling back to 'name' then to the legacy cssClass field for older modules.
• •Bug fix — synced modules now record the CSS class each Smart Property is bound to, not null. The class hook (e.g. esd-gen-title) lives on the variable's blockMapping selector and that's where the extractor reads it from. No user-visible behaviour change at compose time — that path already read the selector directly — but anything downstream that depended on the persisted css_class field would have been working off null. Locked in with a fixture-based regression test.
• •New skill — stripo-module-bindings. Walks you through registering a Smart Property on a Stripo module so its text, link, or image can vary per send. The skill exists because Stripo's Configuration dialog has two ways to target an element that look interchangeable: Block Type and Your CSS Selector. Block Type works in the editor's preview and is invisible to the REST API. CSS Selector works through the API. Pick the wrong one and the variable saves fine, renders correctly inside Stripo, and silently no-ops on every compose call. The skill walks you through the right picker, the right attribute, the naming convention that matches Stripo's own (p_title / p_description / p_cta_text), and the verification step using orbit_inspect_stripo_module_bindings that catches the silent-failure mode before you ship.

11 May 2026

Module-bindings inspector stops crying wolf on selector-bound Smart Properties

Hotfix to the orbit_inspect_stripo_module_bindings tool shipped yesterday in 0.19.3. The 'unmapped esd-gen-* classes' note used to infer the expected variable name from each CSS class — so a module that bound .esd-gen-title to a Smart Property called p_title (variable name doesn't match class basename, common in workspaces with a p_* naming convention) got falsely flagged as unmapped, with a follow-up instruction to register a variable that already existed. The inspector now cross-references actual blockMapping selectors instead of inferring names, so only genuinely orphan classes get flagged. CTA dead-end guidance also softened — no longer hardcodes cta_text / cta_href as the recommended names, since workspaces using a different prefix would get pushed toward names that conflict with their own convention.

• •Bug fix — orbit_inspect_stripo_module_bindings no longer false-flags Smart Properties bound by selector when the variable name differs from the class basename. The 'unmapped esd-gen-* classes' note previously inferred the expected variable name from each class (e.g. .esd-gen-title → expected 'title') and flagged the class as unmapped whenever no variable with that exact name existed. That broke for any workspace using a naming convention like p_* — a perfectly-fine binding of p_title → .esd-gen-title got reported as 'register a Smart Property for title' even though one was already registered. Now the inspector builds a Set of selectors from every registered variable's blockMapping[].selector and only flags classes whose `.${cls}` form is not in that Set. Same code path catches the cases the old check caught; stops manufacturing the cases it shouldn't have.
• •Behaviour change — CTA dead-end note no longer hardcodes variable names in its fix instruction. When a module has a top-level link field but no CTA variable registered, the note used to read 'Register Smart Properties named cta_text and cta_href via the Data tab' — Stripo's documented convention, but wrong for workspaces using a different prefix. Now reads 'match the workspace's existing naming convention if one is in use (e.g. p_cta_text + p_link when the module uses a p_* prefix)'. Same diagnosis, no longer pushes you toward names that fight your existing setup.

11 May 2026

Smart Container support in compose, plus a module-bindings inspector for verifying setup

Two additions to the Stripo composer toolkit. orbit_compose_stripo_email now accepts the canonical-JSON content[] shape, so Smart Container modules — the layout shells with empty slots that host child modules per send — can be populated end-to-end from a single tool call. And a new orbit_inspect_stripo_module_bindings tool reports exactly what a given module accepts via the API: which Smart Properties are registered, which esd-gen hooks exist in its HTML, whether it looks like a Smart Container, and whether its CTA is bound to the editor's silent-fail OG-preview field. Pair the two: inspect first, then compose with the right shape.

• •orbit_compose_stripo_email — slot_values now accepts a nested { values, content: [...] } shape per module, matching Stripo's canonical-JSON spec for Smart Container modules. Today slot_values: { '<id>': { 'p_title': '...' } } substitutes into a standalone module's Smart Properties at push time. Now you can also pass slot_values: { '<container_id>': { values: { ... }, content: [{ id: 'product_card', values: { p_name: '...', p_price: '$9.99', url: 'https://...' } }, ...] } } and Orbit emits the canonical content[] payload so Stripo populates each slot of the layout shell with the right child module and the right per-send values. The flat shape still means values, so existing slot_values payloads keep working unchanged. Child module ids that don't resolve against the synced library are rejected before push with a clear error that names the offending id.
• •New tool orbit_inspect_stripo_module_bindings — pass a Stripo module id (numeric or UID string) and get back a structured report of what the module accepts via the API. Surfaces: which Smart Property variables are registered in the module's Data tab (with their blockMapping selector + attribute), the esd-gen-* CSS class hooks present in the module HTML, whether the module looks like a Smart Container, whether it has a top-level link field (the editor's wizard-driven CTA binding that silently drops at compose time), and the recommended varName list to pass in slot_values today. If a CTA appears bound to the link field with no matching variable, the report names that explicitly and tells the author how to re-bind via Data tab → Smart Properties. Reads the synced library first; falls back to /modules/{id} if not cached. Run this after authoring a new module to verify its bindings landed where the API can reach them.

11 May 2026

html_overrides extraction hardened — previewUrl-first, field-scan fallback, debug-ready failures

Stripo doesn't publish a stable contract for which field on GET /emails/<id> carries the rendered HTML, so the 0.19.1 html_overrides path was one response-shape quirk away from a silent miss. 0.19.2 fixes it with a two-source fetch chain — first the previewUrl that comes back on POST /email (public, full document, no JSON parsing), then the REST endpoint with a smart field scan that tries six likely names and auto-detects HTML by content when none match. Every failure path now returns fetch_source, html_length, html_excerpt and a typed list of response keys, so when something does miss the next debug round is one step instead of three.

• •Source 1 — previewUrl. Stripo's POST /email response includes a previewUrl that serves the fully-rendered email as a standalone HTML page. No auth, no JSON, no field-name guessing. This is now the default fetch path for html_overrides; if Stripo returns one, Orbit uses it and never makes the REST call.
• •Source 2 — GET /emails/<id> with field scan. Falls back when previewUrl is missing or returns nothing usable. Tries html, markup, body, template, htmlContent, emailHtml in order, then scans every string field longer than 500 chars on the response looking for HTML markers (<!DOCTYPE, <html, <body, es-button). First match wins; the matched field name surfaces in fetch_source so subsequent runs are deterministic.
• •Debug surface. Every non-patched status now carries the context you'd otherwise have to derive from a second tool call. fetch_source names which source produced the HTML (or which sources failed). html_length and html_excerpt show what actually came back when the a.es-button selector matched zero elements. response_keys returns a typed list with the length of every string field on the Stripo response, so an unknown field name is identifiable from the first failed run rather than the third.

11 May 2026

CTA overrides on orbit_compose_stripo_email — vary text and href per send without touching Stripo

Stripo's write APIs for existing emails are a dead end. PUT and PATCH on /emails/<id> return 405, and the inline-html dataSources field that looks like it should let you override copy gets silently regenerated from the master template on every gen pass. So Orbit stops trying to write back. orbit_compose_stripo_email now accepts an html_overrides argument that fetches the Stripo-rendered email after push, Cheerio-patches the CTA text and href on every a.es-button element, and writes the patched HTML to disk for Braze sync. Stripo stays the source of structure; the per-send CTA variation happens client-side, after Stripo has done its job.

• •html_overrides on orbit_compose_stripo_email. Two optional fields — cta_text (≤200 chars) and cta_href (≤2000 chars). After Stripo generates the email server-side, Orbit fetches the rendered HTML, applies the patches to every a.es-button via Cheerio, and writes the result to ~/Orbit/outputs/stripo-compose/<timestamp>-patched.html. The patched file is what your Braze sync should pull from — Stripo's copy is left structurally correct but contains the unpatched master-template CTA.
• •Requires push:true. The override is meaningless on preview-only compose because there's no Stripo email yet to fetch back and patch. Returned on the tool response under html_overrides_result, carrying status (patched / no_buttons_found / fetch_failed / html_not_extractable), the patched file path, the count of buttons matched, and the list of individual patches applied.
• •Why client-side. The Stripo write surface for existing emails was probed exhaustively in 0.18.x: PUT /emails/<id> returns 405, PATCH returns 405, and the dataSources inline-html field that the docs imply is editable gets overwritten by Stripo's own renderer on the next gen pass. The only working write path is replacing the canonical content[] payload, which loses per-send specificity and re-runs every module. html_overrides treats Stripo as source-of-structure only and does per-send variation downstream.

9 May 2026

Smart Element slot overrides, bindable-variable discovery, and single-image Braze upload

Three new capabilities for the Stripo and Braze workflows. Smart Element modules can now have their slot content varied per send directly in orbit_compose_stripo_email — no manual Stripo work needed between sends. orbit_list_stripo_modules now shows which variables are bindable in each module so you know before you compose. And a new orbit_upload_image_to_braze tool uploads a single image from disk and hands back a Braze CDN URL ready to drop into any template or content block.

• •orbit_compose_stripo_email now accepts a slot_values map on any module in the sequence. Pass slot key → content pairs and Orbit injects them into the module's Smart Element placeholders at compose time. Lets you run the same modular email template with different headlines, offer copy, or imagery per audience without touching Stripo's editor between sends. Slot keys come from the slot_definitions field on each module (see below).
• •orbit_list_stripo_modules now returns slot_definitions alongside each module — a map of bindable variable names to their kind (text, url, image_src, image_alt). Use these keys when building slot_values for orbit_compose_stripo_email. Modules without Smart Element bindings return null, so you can see at a glance which modules support per-send variation.
• •New tool orbit_upload_image_to_braze — upload a single image to the Braze media library and get back a hosted CDN URL. Accepts a remote URL (Braze fetches it server-side), a local file path (base64-encoded, 4 MB cap), or raw base64 data. The returned URL is ready to drop directly into slot_values or any Braze template without opening the Braze console.

8 May 2026

Anonymous usage telemetry now on by default, Stripo values-field probe, slop detector catches a new viral opener

Three customer-facing changes in this release. Anonymous usage telemetry is now on by default in the Orbit MCPB — until now we collected nothing unless you'd manually set ORBIT_TELEMETRY=1, so the dashboard was blind to which skills and tools were actually being used. We send only the skill or tool slug, the MCPB version, and an opaque per-install ID. Never your prompts, your tool arguments, or your IP. There's a new install-time checkbox to opt out, and ORBIT_TELEMETRY=0 still works. A new orbit_probe_stripo_values tool empirically tests Stripo's `values` field against your live workspace — the gating step before we ship slot-aware overrides on orbit_compose_stripo_email. And the slop detector now catches the 'There's a specific kind of [feeling] that comes from…' viral opener template.

• •Behaviour change — the MCPB now sends anonymous usage telemetry by default. Each event carries: type (skill_load / tool_call / session_start / tool_error), the kebab-case slug of the skill or tool, the MCPB version, and a SHA-256-hashed install UUID stored locally at ~/.orbit/client-id. Nothing else. The endpoint is /api/mcp/telemetry on yourorbit.team and the contract is enforced server-side: payloads with anything resembling a prompt or tool argument are rejected.
• •Opt-out paths — the MCPB install screen now shows a new 'Anonymous usage telemetry' checkbox (ticked by default). Untick it during install or any time afterwards via Claude Desktop's MCP settings. Power users can also set ORBIT_TELEMETRY=0 (or `false`/`no`/`off`) in the MCP config; the env var wins. When telemetry fires for the first time in a session, the MCP server log gets a one-line stderr disclosure noting it's enabled and how to opt out — visible in Claude Desktop's MCP server logs.
• •Privacy posture unchanged. We have no IP column on the receiving table. The install ID is local to your machine and only ever appears in our database; it carries no name, no email, no fingerprint. We can answer 'how many distinct installs hit this skill last week' but not 'which person did it.' Reading mcp_telemetry rows isn't enough to identify anyone — by design.

8 May 2026

Stripo composer hardening — overrides honoured, push verified, multi-email gate, padding fix

Production-test of orbit_compose_stripo_email on a multi-module welcome email surfaced four issues; this release fixes all of them. Multi-email briefs now build one at a time with an explicit gate between each. Push responses always make it back through Anthropic's 1 MB tool-result cap, so you can verify what landed instead of guessing. Copy and image overrides no longer silently disappear when push:true is set — the tool now refuses with a clear message rather than pushing the wrong content. And the master-template setup instructions now tell you to zero out the wrapping Structure's padding so pushed modules render flush with the canvas.

• •Behaviour fix — multi-email briefs (welcome series, winback flows, anything covering more than one email) now compose one email at a time. Orbit builds email 1, renders the preview, and stops. It then asks whether to push, change, move to email 2, or stop. Stops a wrong header on email 1 from compounding into the same wrong header on emails 2–5. Opt out by saying 'build all of them, I'll review at the end' — the gate is the default, not a policy.
• •Bug fix — copy_overrides and image_overrides used to be silently discarded when pushing to Stripo. The push payload sends module UIDs and Stripo regenerates server-side from its own copy of each module, so client-side substitutions never reached the rendered email. The tool now hard-fails with `overrides_not_pushable` when push:true is combined with non-empty overrides, and the error message tells you the two paths forward: compose with push:false to receive the override-applied HTML for paste-in, or push without overrides and apply edits in Stripo's editor. Per-slot overrides via Stripo's canonical-JSON `values` field are roadmap once Stripo's findmodules API exposes slot keys.
• •Bug fix — the compose tool used to embed the assembled HTML inside its response payload, which on emails with several inlined images blew Anthropic's 1 MB tool-result cap. The push fired against Stripo, the email landed in your workspace, but the chat saw an error and you couldn't confirm what was created. Now the assembled HTML always gets written to disk at `~/Orbit/outputs/stripo-compose/<timestamp>.html` and the response carries `html_path` + `html_byte_count` instead of the raw HTML. Pushed responses drop the HTML entirely (you're past preview at that point); preview-mode responses keep the artifact-render directive so the layout still shows inline.

7 May 2026

Stripo email previews now render images correctly in Claude artifacts

When Orbit composed an email and showed the preview as a Claude artifact, all the placeholder images in your modules rendered as broken-image icons. Turns out Claude artifacts run inside an iframe with a strict CSP that blocks external img-src — Stripo's CDN was serving the images perfectly, the artifact just couldn't fetch them. Fix: orbit_sync_stripo_modules now downloads each module's images locally during sync, and orbit_compose_stripo_email inlines them as base64 data: URIs in the preview HTML. The preview now matches what the actual email looks like in your inbox. Images you push to Stripo still use the original CDN URLs (data: URIs never leave Orbit) — Stripo composes server-side from its own copy of the module HTML.

• •orbit_sync_stripo_modules now downloads every image referenced in your synced modules to a local cache at ~/Orbit/library/_image-cache/. Cache is keyed by SHA-1 of the URL, so the same image used in multiple modules is only downloaded once. Re-syncs skip already-cached images entirely (idempotent).
• •Stripo CDN URLs are content-addressed (each image has a unique GUID baked into the URL), which means cache invalidation is automatic — if a module is updated in Stripo to use a different image, the new URL produces a fresh cache entry; same URL is guaranteed-identical bytes. No staleness risk.
• •Each sync prunes orphan cache entries for URLs no longer referenced by any module, so the cache doesn't grow indefinitely as old image URLs get replaced. Sync output reports new downloads, cache hits, and bytes freed.

7 May 2026

Releases 0.18.7 → 0.18.10 finally ship — CI was silently failing for 4 days on a deps audit

Awkward operational story worth being honest about: the four versions shipped today (0.18.7 Stripo native integration, 0.18.8 Braze fix, 0.18.9 Stripo audit/fix tools, 0.18.10 MCP server lifecycle fix) were all committed and pushed to GitHub, but none of them actually reached the .mcpb download because the CI build job had been failing since 27 April on a transitive-dependency audit gate. Discovered the failure when the website kept showing v0.18.5 despite 4 successful-looking pushes. 0.18.11 fixes the underlying CI break by bumping mjml to v5 (which removes the dead html-minifier dependency), and bundles every feature from those four prior versions into one deploy that actually lands.

• •CI's `npm audit --omit=dev --audit-level=high` was failing on 32 high + 1 critical vulnerabilities, all traceable to one dependency tree: html-minifier (unmaintained, REDoS regex DoS bug) → mjml-core → every mjml-* sub-package → mjml. The audit had been failing since the 28 April release was attempted.
• •Fix: bumped mjml from ^4.18.0 to ^5.1.0 (which uses a different minifier and drops html-minifier entirely) plus npm audit fix for the lodash + protobufjs + ip-address vulns. Verified non-breaking: all 78 tests pass, including the full email-pipeline suite that uses mjml.
• •All features from the four undeployed releases now ship in this build: the Stripo native API integration (orbit_setup_stripo / orbit_sync_stripo_modules / orbit_list_stripo_modules / orbit_document_stripo_design_system / orbit_compose_stripo_email), the orbit_audit_stripo_modules + orbit_fix_stripo_module pair for catching and correcting saved-module structural issues, the orbit_braze_performance fix for scheduled-blast canvases, and the MCP server lifecycle handlers that stop zombie processes accumulating after Claude Desktop quits.

7 May 2026

MCP server exits cleanly when its parent disconnects — no more zombie processes

Until this release the Orbit MCP server didn't watch for the signals that mean 'your parent's gone, stop running.' The result was zombie server/index.js processes accumulating in the background after Claude Desktop quit — each burning 50–80% CPU, sitting around for days. Reliability fix: every shutdown signal now funnels into a single idempotent exit path, including a parent-alive watchdog for the rare case where stdio events don't fire. Routine fix; you'll notice it as 'Activity Monitor stops filling up with old Orbit processes.'

• •Added handlers for SIGTERM, SIGINT, SIGHUP, stdin 'end', stdin 'close', and the MCP transport's onclose hook. Any of these now triggers a graceful exit.
• •Replaced the previous uncaughtException handler that swallowed fatal errors and kept running. The handler now logs and exits with code 1, so a crashed server actually dies and Claude Desktop respawns it cleanly on the next call. Same treatment for unhandledRejection.
• •Added a parent-alive watchdog that polls process.ppid every 30 seconds and exits if the parent has been reaped (process.ppid === 1 means we're orphaned to launchd). Belt-and-braces for the rare case where stdio events don't fire on abnormal parent termination. Uses .unref() so it can never keep the process alive on its own.

7 May 2026

Stripo push is wired end-to-end, plus an audit + fix tool for saved modules

The Stripo integration's push half is now live — orbit_compose_stripo_email with push:true creates a real email in your Stripo workspace from your synced module library, every time. Two new tools land alongside it: orbit_audit_stripo_modules catches a class of structural issues that emerge when you reuse modules across contexts (the lopsided-block bug being the most visible one), and orbit_fix_stripo_module returns the corrected HTML for paste-back into Stripo's module editor. Stripo's REST API is read-only for modules, so the fix is necessarily manual — but the audit catches everything programmatically, including a surprise gotcha around how Stripo's API references modules.

• •orbit_compose_stripo_email push:true now creates real emails in your Stripo workspace via the canonical-JSON /emailgeneration/v1/email endpoint. Master template stays untouched (a hard programmatic guard in the HTTP client refuses any non-GET request to /template paths — defence-in-depth). Push response includes the new email's ID, the editor URL deeplink (so you can click straight to it), and the public preview URL.
• •Discovered the hard way that Stripo's dataSources[].value[].id field references the module UID (the short positional string like 'STRIPE1' / 'STRUCTURE7'), NOT the numeric module ID. Posting numeric IDs produces silent empty emails — Stripo accepts the request, strips the gen-area marker, and fills with nothing. Now uses UIDs throughout. Failing loud with a clear error if a synced module is missing its UID metadata (means an older sync ran against an API surface that didn't return the field — re-sync to fix).
• •Discovered emailName cannot contain square brackets — Stripo rejects with a generic 'Can not save generated email' 400. Other ASCII punctuation (parens, slashes, ampersands, middots), Unicode arrows, and ISO timestamps all save fine. Generated names now use 'Orbit · subject · timestamp' format.

7 May 2026

Braze Performance fix from 0.18.6 — actually shipping this time

The 0.18.6 changelog two days ago promised a fix for orbit_braze_performance reporting zeros on scheduled-blast canvases. Turns out the manifest version bumped but the underlying code never made it into the published .mcpb — so anyone who downloaded 0.18.6 (or 0.18.7 yesterday) still got the old broken behaviour. The actual code now ships in 0.18.8. If you saw the entry, downloaded the update, and noticed nothing changed: that's why. Sorry.

• •Headline metrics for canvases now correctly show sent / delivered / unique opens (with open_rate) / unique clicks (with click_rate) / unsubscribes / bounces (hard + soft, broken out) — pulled from the step-level rollup, not from total_stats.entries which can be 0 for scheduled audiences. Conversions stay in the response as a secondary metric.
• •Triggered canvases continue to work exactly as before — the rollup is computed from the same step-level data the API already returned, the field set is just richer.
• •When a canvas has message steps but the Braze API returns no step metrics (the scheduled-audience case), the response now carries a warnings array explaining what happened. No more wrong-but-plausible zeros.

7 May 2026

Stripo API integration — sync your saved modules and compose emails directly into your workspace

Orbit now talks to Stripo's REST API. Connect once, and Orbit pulls every custom module you've saved, documents your modular design system as a markdown brief, and lets you compose on-brand emails from a sequence of modules — with an HTML preview rendered inline in Claude before you push the result back to your Stripo workspace as an editable email. The paste-driven Stripo flow still works; this is the API-driven sibling for users who want a tighter loop.

• •New tool orbit_setup_stripo walks you through connecting Stripo. Stripo uses two separate credentials (Plugin ID + Secret Key for the editor, plus a per-project REST API token for the API itself) — the setup tool reports which are present, runs live probes to confirm they work, and returns a step-by-step markdown checklist with ✅/⬜ ticks that update each time you re-run it.
• •New tool orbit_sync_stripo_modules pulls every custom saved module from your Stripo workspace into Orbit's local library. Classification is automatic via Stripo's own category taxonomy (header → header, banners → hero, footer → footer, content_canvas → content). Modules deleted in Stripo are tagged archived locally, never hard-deleted.
• •New tool orbit_list_stripo_modules reads the synced library without re-hitting Stripo's API. Filter by classification (header / hero / content / footer) or free-text search.

5 May 2026

Braze Performance now reports real sends for scheduled-blast canvases

orbit_braze_performance was returning zeros for canvases that use a scheduled audience instead of an action-based trigger — even when the canvas had clearly sent. The headline metric now rolls up sent / delivered / opens / clicks / unsubscribes / bounces directly from the Braze step rollup, so a 582-send blast reads as 582, not 0. When a canvas has message steps but the API gives back nothing, you'll see a warning instead of a silent zero.

• •Headline metrics for canvases are now sent, delivered, unique opens (with open_rate), unique clicks (with click_rate), unsubscribes, and bounces (hard + soft, broken out). Conversions stay in the response but as a secondary metric, not the headline.
• •Triggered canvases keep working exactly as before — the rollup is computed from the same step-level data Braze already returned, the field set is just richer.
• •When a canvas has message steps but the Braze API returns no step metrics (the scheduled-audience case), the response now carries a warnings array explaining what happened. Worst-kind-of-bug protection: no more wrong-but-plausible zeros.

30 April 2026

Orbit Dictation is now Comet, plus a refreshed Orion icon

Two macOS app updates landed today. Orbit Dictation has been renamed Comet — same app, same shortcut, same menu-bar behaviour, on-theme name. Orion picked up a refreshed app icon (the Orbit planet plus AI sparkles), and the unsigned-app footer in install instructions was rewritten so it no longer claims Orion is 'the founder of Orbit' (he's the dock assistant, not the founder).

• •macOS dictation app renamed: Orbit Dictation → Comet. The .app, the DMG, the GitHub release titles, the menu-bar entry, and the website landing page (now /comet) all carry the new name. Existing installs keep updating cleanly because the bundle identifier, Sparkle update chain, and Keychain account are unchanged.
• •/orbit-dictation permanently redirects to /comet so every previous link still resolves.
• •New Comet app icon — handheld microphone silhouette with the Orbit planet as the head. Visually pairs with Orion as siblings in the Orbit family.

28 April 2026

/download is now /sign-up — clearer about what the page does

The page that creates your free Orbit account moved from /download to /sign-up. Same form, same flow — the URL was misleading because the page is primarily account creation (which then unlocks the MCP server download, your tool history, course progress, and LinkedIn certifications), not a direct file download.

• •/download (and /download/free) permanently redirect to /sign-up — every external link still resolves.
• •Anonymous CTA in the top right now reads 'Sign up free' instead of 'Get Orbit'. The link still routes to the same form.
• •Copy across the site reframed: 'sign up to download' rather than 'download Orbit'. Makes it clear that the free account also gives you saved tool history (naming conventions, scored subject lines, IP-warm plans, more), course progress with completion badges, and LinkedIn-shareable certifications.

28 April 2026

Orbit MCP server is free for everyone

Orbit (the .mcpb extension and every web tool) is now free for everyone. No flat fee, no purchase, no gate. Donations return as a separate, optional pay-what-you-want surface at /support — decoupled from getting Orbit.

• •/download is now a free direct-download surface. Create a free account so the portal works across versions, then install the MCP server.
• •/support returns with the pay-what-you-want slider. Donations are voluntary, one-time, and have no link to access — no license unlock, no portal change.
• •New 'Download Orbit MCP' link in the top nav, sitting next to Tools — install is one click from anywhere on the site.

28 April 2026

New pricing: $9.99 USD — buy once, keep forever

Orbit moves from pay-what-it's-worth to a single flat fee. $9.99 USD, one-time. Every future Orbit release is included on the same payment — no subscription, no upgrade tier. The free path stays exactly where it was for anyone who can't pay.

• •One number instead of an 11-stop slider: $9.99 USD covers the lifetime license. The slider and custom-amount input on /download have been replaced by a flat-fee CTA.
• •Buy once, keep forever — every future Orbit release lands on your portal at /account/downloads with no renewal email and no expiry.
• •Free-path bypass at /download/free is unchanged. Same product, same updates, same portal.

27 April 2026

IP Warm-Up Planner: copy segment names per row

Each row of the warm-up schedule now has a click-to-copy chip with a ready-made segment name like 'IP Warming Day 1 - RBN 0-90'. Build the schedule, copy the segment name for the day you're configuring, and paste straight into your ESP — no manual concatenation.

• •New 'Segment name' column on the warm-up table. Each row renders a chip showing the canonical name format: IP Warming Day {N} - RBN {bucket range(s)}.
• •Click the chip to copy the segment name to clipboard with a brief 'Copied!' confirmation.
• •Output normalises the en-dash in the bucket label to an ASCII hyphen so the name pastes cleanly into Braze (or any ESP) where unicode dashes can break exact-match segment lookups.

27 April 2026

Liquid Syntax Generator: year-only date format

Added a Year option to the date/time formats in the Liquid Syntax Generator. Outputs just the four-digit year (%Y) — useful for footer copyright notices, anniversary messaging, and 'Year in review' content where the rest of the date is noise.

27 April 2026

0.18.5: Orbit logo now renders in Claude Desktop again

Claude Desktop was falling back to a generic 'O' placeholder instead of the Orbit logo because the bundled icons were 1024×1024 — larger than Claude Desktop's icon size cap. Resized to 512×512 (the size every working extension on the platform ships) and the logo renders correctly again.

• •icon.png, icon-light.png, and icon-dark.png all resized from 1024×1024 → 512×512.
• •Manifest icon size declarations updated to match. No visual change at the rendered display size — Claude Desktop renders the icon at 32–64px in lists, 512 source still has plenty of pixels for high-DPI surfaces.
• •Update Orbit (sign in → /account/downloads) to grab 0.18.5 and the Orbit logo will be back in your Claude Desktop sidebar.

27 April 2026

Claim badges directly from /account/badges (with confetti)

The Claim button now lives inline on the badges page itself. One click to issue the cert, watch the confetti, and the card flips to Earned in place — no more navigating to the course page just to hit Claim. The course-page Claim button also fires confetti now for consistency.

• •/account/badges shows a real Claim button on each Ready-to-claim card. Click → cert issues → confetti → card flips to Earned with the issued date and the Add-to-LinkedIn button.
• •New Quiz pending section on /account/badges separates 'all guides read but quiz not yet passed' from 'ready to claim' — so the Claim button only appears when both gates are actually green.
• •Course-page Claim button (CourseCompletionBlock) also fires confetti on first issue. Re-renders of an already-earned badge don't re-celebrate — the burst only fires when the cert is genuinely new.

27 April 2026

Fix: claimed certifications now persist correctly

If you claimed a course completion badge but came back to find the course had reverted to 'Ready to claim', the claim was succeeding in the UI but silently failing to save server-side under specific account conditions. Fixed: every claim now persists, every revisit shows your earned badges. Same fix also applied to quiz-pass and reading-progress saves so they can't fail silently either.

• •Claimed badges now reliably appear in the Earned section on /account/badges across page reloads and devices.
• •Quiz passes and reading progress also persist under the same conditions — no more 'I read this guide, why isn't it ticked?' on rare account states.
• •If you previously hit this and your earned badges disappeared, sign in and re-claim them on the course page — the claim will stick this time.

27 April 2026

Orbit Namer remembers your last 10 names

Signed-in users now see a Recent names list under the Namer output. Save-on-copy persists the name plus the dimension selections, so a click on any history row repopulates the form for further editing. Up to 10 entries, oldest dropped first.

• •Save-on-copy: every Copy click stores the generated name, the dimension selections, and the custom inputs as one history entry. No extra step.
• •Click any row to repopulate the form — useful for iterating on a name pattern across a series of related campaigns.
• •Hover-revealed × deletes a single row; Clear all wipes the list. Both write through to the server immediately.

27 April 2026

0.18.4: Updated for the BrazeAI rebrand (formerly Sage AI)

Braze rebranded its generative AI layer from Sage AI to BrazeAI. Every reference inside the AI personalisation course (4 guides, course description, quiz pool) and the AI personalisation skill in the Orbit MCPB now uses the new name, with a 'formerly Sage AI' disambiguator on first mention so readers searching with either name still find the content.

• •Renamed across the AI personalisation course on the website: ai-personalisation-architecture, predictive-models-lifecycle, generative-content-lifecycle, ai-personalisation-measurement.
• •Renamed in the course description and the 30-question quiz pool.
• •Renamed in the AI personalisation skill description inside the Orbit MCPB so the trigger surface picks up users searching with either old or new name.

26 April 2026

0.18.3: New Advanced course bundled — AI Personalisation at Scale

Seven-guide course on AI personalisation now ships as MCP resources, so Claude can cite each guide inline when AI personalisation comes up in conversation. Grounded in BrazeAI / Predictive Suite / Connected Content / Catalogs but speaks broadly across ESPs.

• •New guide: AI personalisation architecture — the four-layer stack (events, profile, content, activation) that decides whether AI personalisation moves revenue.
• •New guide: Predictive models in lifecycle — when to use ESP-native (Predictive Suite, Iterable Brain, Klaviyo Predictive) vs custom warehouse-trained models.
• •New guide: Generative AI for lifecycle content — the three modes (acceleration, approved variant rotation, real-time generation), governance, and what doesn't ship to users without review.

24 April 2026

0.18.2: Orbit now activates on a wider range of lifecycle topics

Expanded the trigger surface so Orbit responds to every major lifecycle, deliverability, experimentation, compliance, and platform concept inside Claude — plus an explicit 'don't activate' list to prevent false positives outside the marketing domain.

• •Trigger surface now covers every channel (email, SMS, push, in-app), every canonical program (onboarding, winback, cart, loyalty, referral, transactional), every deliverability concept (SPF/DKIM/DMARC, reputation, MPP, 2024 Gmail rules), and every experimentation method (A/B, incrementality, sample sizing).
• •Recognises pasted artifacts as activation signals — raw HTML, A/B test JSON, deliverability CSVs, Postmaster exports.
• •Explicit do-not-activate list — pure product engineering, sales pipeline, general business strategy, non-marketing analytics — so Orbit stays out of conversations outside its lane.

24 April 2026

0.18.1: Transparent fallback icon

The fallback extension icon now has a transparent background, matching the light/dark theme variants already in the manifest. Cosmetic consistency fix — no functional change.

• •icon.png (fallback used when a client doesn't honour the light/dark icon variants) was an opaque black square. Replaced with the transparent-black variant so the fallback also renders cleanly. The existing icon-light.png (transparent black) and icon-dark.png (transparent white) variants were already correct.

24 April 2026

0.18.0: Orbit Intelligence — guided discovery, hand-holding, further reading

A behavioural rewrite of Orbit's routing contract. Claude now walks users through getting the right inputs before tools run, cites the practitioner guides that informed each answer, and refers to the senior-operator layer as Orbit Intelligence when framing judgment or recommendations.

• •Orbit Intelligence — the senior-operator layer — is now named explicitly. Used when Orbit frames a diagnosis, recommendation, or synthesis across multiple tool calls. Voice standards ban robotic narration ("I'll do X"), passive deference ("let me know what you'd like"), and frame-breaking ("as an AI").
• •Guided Discovery — when a tool needs data the user hasn't supplied, Claude now walks them through getting it before running the tool. Canonical playbooks for deliverability audits (Postmaster CSV walkthrough), pre-send QA (HTML extraction from Stripo / Braze / Figma), RFM scoring, cohort retention, A/B test readouts, and template learning.
• •Further reading — when a practitioner guide informed the answer, Orbit now cites it at the end of the response with the public URL. Format: a "Further reading" block linking to https://yourorbit.team/guides/<slug>. No padding — only guides that genuinely informed the answer.

24 April 2026

0.17.0: Audit fixes + 6 new tools + 2 new skills

Big polish + capability release. Six critical / major audit findings fixed (Stripo parser, contrast walker, SPF counter, replenishment ordering, dark-mode accuracy, exec-report escaping). Six new tools for pre-send QA, rendering, Postmaster parsing, list growth, GDPR audit, and A/B test readouts.

• •orbit_qa_email — one-shot pre-send gate that runs accessibility + dark-mode + Gmail-clipping checks in a single call and returns a combined pass/warn/fail verdict.
• •orbit_render_email_preview — desktop / mobile / dark-mode preview HTML artifacts from arbitrary email HTML. Viewport-matched wrapper so Claude Desktop renders them as inline artifacts. No headless-browser dependency.
• •orbit_parse_postmaster_signal — interpret Gmail Postmaster Tools data (CSV export or structured snapshot) with per-metric verdicts against Gmail's thresholds and recommended actions.

23 April 2026

0.16.0: Deliverability, segmentation, content, and calculator tools

Thirteen new tools + five new skills. DNS-level email auth checks, WCAG email lint, RFM scoring, cohort retention, preheader scoring, Liquid validation, SMS composer, free-shipping / replenishment / exec-report calculators — plus emergency and planning skills.

• •orbit_check_email_auth — DNS-resolves SPF, DKIM, DMARC for a domain. Flags multi-SPF, >10 lookups, p=none, empty DKIM keys. Returns pass/warn/fail with specific remediation.
• •orbit_check_bimi — BIMI record + VMC + DMARC-policy-prerequisite check for Gmail / Yahoo's authenticated-brand rendering.
• •orbit_dark_mode_check — scans inline colour pairs and flags invisible-text risk under Apple Mail / Outlook mobile dark-mode inversion.

23 April 2026

0.15.0: Stripo-aware template learning

Three new tools for persistent-memory email template workflows. Paste your existing HTML once, Orbit remembers its modules and brand tokens, and every future email gets built from the same modular system.

• •orbit_learn_email_template — parses an HTML email (Stripo-aware) into modules classified by structural signature (hero, content-with-cta, two-column, pricing-table, testimonial, feature-list, app-download, etc.), extracts brand tokens (primary button colour, font family, border radius, body text colour, link colour, backgrounds), and saves the full record to Orbit's library under a template_id you reference later.
• •orbit_build_email_from_template — compose a new on-brand email from a previously-learned template's modules. Output preserves the full <head> / <style> / MSO conditional shell plus the es-* / esd-* classes so Stripo still recognises it as editable when pasted back in.
• •orbit_modify_email_template — structured edits (remove module by id / type / index, set CTA or heading text, swap image URL). Returns per-instruction success/skip report.

23 April 2026

0.14.0: Course catalogue as MCP resources

Orbit now ships the full 9-course curriculum as MCP resources, so Claude can recommend the right course URL when a user's question has real training depth. orbit.md updated so Claude answers first and only surfaces a course when it materially expands on the answer.

• •The nine Orbit courses (Lifecycle Foundations, Launch Your First Program, The Email Craft Playbook, Programs That Compound, Ecommerce Retention, SaaS Activation & Retention, Deliverability Mastery, A/B Testing That Sticks, Winning the Inbox) now live inside the extension as MCP resources at orbit://courses/index and orbit://courses/{slug}.
• •orbit.md's "Pointing Users at Deeper Learning" routing tells Claude to answer the question substantively first, then recommend a course by URL only when the question has real training depth — never force one on a narrow tactical ask.
• •The website's /api/courses/export endpoint ships the course catalogue to the MCPB build pipeline automatically, so future catalogue edits land in Orbit on the next release.

22 April 2026

0.13.4: Private distribution + portal-gated downloads

Downloads are now portal-only. The .mcpb moved off the public GitHub mirror to a private Railway-backed bucket. Unauthenticated requests to the download endpoint are redirected to sign in or create a free account.

• •Downloads are now portal-gated. /api/mcpb-download requires a valid session cookie — either from a Stripe contribution or from the free account-creation flow. Unauthenticated hits get redirected to /download with a 'Sign in first' banner so the path to the binary is always clear.
• •The .mcpb file itself moved off the public orbit-for-claude-dl GitHub mirror onto a private Railway-backed Tigris bucket. Each download returns a 5-minute signed URL to the bucket — the raw bucket endpoint is never exposed, and shared links expire quickly.
• •Installed MCPBs check for updates via a new public endpoint at /api/orbit/latest-version (proxies the bucket's manifest). Version-check still works after the old GitHub mirror is retired.

22 April 2026

0.13.3: Clearer error when a paused job is lost to a restart

If you restart Claude Desktop between pausing a job and continuing it, Orbit now tells you so — plainly. Previously both "an hour passed" and "you restarted" surfaced as the same generic "expired" error.

• •When orbit_continue_job can't find a token, it now distinguishes two cases: (a) the paused work was cleared by an Orbit restart (quitting Claude Desktop, reloading the extension, or a sleep/wake cycle), or (b) it genuinely aged out after an hour. The error message and Claude's follow-up offer now say which one happened.
• •Technical: continuations are held in memory inside the local Orbit process and don't survive a restart. That's by design — the TTL is 1h and the state would be evicted anyway — but users shouldn't see "expired" when they only paused 5 minutes ago. The new classifier compares process uptime against the TTL to pick the accurate message.
• •Added three unit tests covering both branches (fresh process, long-running process, exact-boundary case) so this stays correct.

22 April 2026

0.13.2: Timestamp parity on resumed audits

When an Orbit workspace audit pauses and resumes, the final result now carries the original call's timestamp — not the resume moment. A cosmetic fix that closes the last parity gap between uninterrupted and resumed runs.

• •Instance audits that resume from a checkpoint now return the timestamp from when you originally asked, not when the resume landed. Previously a resumed audit picked up a fresh wall-clock timestamp at completion, so the same result looked slightly different depending on whether it paused — now the two are byte-for-byte equivalent.
• •Added a continuation parity test suite (4 scenarios across audit, content-blocks, and performance pulls) that deep-equals resumed output against uninterrupted output. Resumed calls must be indistinguishable from clean runs; the suite locks that contract on every build.

22 April 2026

0.13.1: Performance regression fix

Braze performance pulls are fast again — 0.13.0 accidentally serialised per-ID fetches to enable resume, which slowed down the common case. Now processes 5 IDs in parallel with checkpoints between batches.

• •Braze performance pulls are fast again for typical requests. 0.13.0 processed IDs one-at-a-time so the audit could resume between any single ID; that regressed the common case (5–30 IDs) by 3–10x. 0.13.1 processes 5 IDs in parallel per batch with checkpoints between batches — the resume path still works cleanly, and small requests finish in a single batch.
• •Added a smoke test for the continuation path so the resume-from-checkpoint code gets exercised on every build.

22 April 2026

0.13.0: Continue where you left off, for real this time

Big Braze audits and performance pulls that previously hit the context limit now pause cleanly and offer to continue — no re-running, no lost work. Claude picks up exactly where it stopped when you say go.

• •When a heavy Orbit tool runs into the Claude context limit, the response now carries a continuation token — and Claude will ask "I've pulled X of Y so far, would you like me to continue?". Say yes and Claude calls the new orbit_continue_job tool, which picks up from the last checkpoint. Previous work is preserved.
• •Retrofitted three tools that hit this most often: full Braze instance audits (orbit_audit_braze_instance), Content Block deep audits (orbit_audit_content_blocks), and Braze performance pulls (orbit_braze_performance). More will follow as usage data tells us which tools to convert next.
• •Checkpoints last an hour and clear if Orbit restarts. If you try to continue after that, Claude will tell you the paused work has expired and offer to re-run the original request fresh.

22 April 2026

0.12.1: Fewer "request expired" errors, proper Continue prompts

Tighter time budgets and response caps so tool calls land inside Claude Desktop's window — and when a tool does run out of time, Claude now offers you a Continue instead of breaking the conversation.

• •Tool time budgets tightened across the board. Most tools now finish in 45s or return a clean timeout, well inside Claude Desktop's tool-call window — the "Tool result could not be submitted" error banner should appear far less often.
• •Response size cap halved from 200KB to 100KB. Large Braze pulls (instance audits, full Canvases, template lists) now trim gracefully to fit rather than silently overflowing Claude's tool-result submission limit.
• •When a tool times out, Claude now offers a Continue prompt. Instead of dead-ending the conversation with an "expired" banner, the tool returns a structured response that tells Claude to ask: "That request hit the time budget. Want me to retry with a narrower scope?" Answer yes and Claude reruns with reduced inputs.

17 April 2026

0.10.0: Stability hardening + Orbit Intelligence signatures

Per-tool deadlines, response size caps, retry + circuit breakers, attribution signatures, artifact chrome, and the new orbit_check_version tool.

• •Tool deadlines: every tool handler now runs under a per-tool timeout (default 60s, heavy tools up to 120s). No more hung MCP calls quietly blocking a conversation
• •Response size caps: outputs over 200KB are intelligently truncated with an _orbit_truncation block so Claude can still reason about what was returned
• •Retry with exponential backoff: every outbound fetch (Braze, Figma, GitHub) now retries 3 times with 300/600/1200ms delays on transient failures

17 April 2026

0.9.0: Audit, hardening, foolproof e2e tests

20 audit findings resolved, full Braze region support, 58-test foolproof e2e test package, and a shared error classifier across all 54 tools.

• •20 audit findings resolved: cursor pagination fix, Braze auth-error classification (no more silent empty-workspace reports), all 54 tool handlers wrapped in shared error classifier, process-level uncaughtException and unhandledRejection handlers, concurrent-safe rate limiter
• •All Braze cluster regions now supported: US (iad), EU (eus, fra), Australia (au), India (ind) and any future clusters — dashboard URLs derived generically instead of a hand-maintained list
• •Dedupe: braze-sync.js now uses the shared Braze client instead of its own private copy. Bug fixes land in one place

16 April 2026

7 Free Web Apps

Standalone browser-based tools for Braze naming, email size checks, Liquid syntax, push previews, significance testing, IP warm-up, and percentage change.

• •Email Size Checker: check HTML file size, Gmail clipping risk (102KB), inline data URI detection, missing alt text, bloated CSS, and HTML comment weight
• •Orbit Namer: generate consistent Braze naming conventions with smart tag recommendations and custom free-text option per dropdown
• •Percentage Change: calculate period-over-period percentage change between two values

16 April 2026

Braze Intelligence Layer: 17 New MCP Tools

Full workspace-awareness for Braze: instance audit, canvas reader, performance data, segment analysis, template collision detection, and more.

• •Instance Audit: full inventory of Canvases, campaigns, segments, content blocks, and templates
• •Canvas Reader: read Canvas structures and reverse-map to Orbit message plans
• •Performance Data: time-series metrics for Canvas entries, campaign rates, segment growth

7 April 2026

Email Production and Brand Kit

MJML templates, HTML compilation, cross-device previews, Figma import, brand kit intake, and Braze sync — the full email production loop.

• •Brand header generation with Gemini AI integration
• •Brand kit intake workflow: colors, logos, fonts, tone of voice
• •Email template specs, MJML generation, HTML compilation

31 March 2026

Orbit Launch

Initial release: Claude Desktop MCP extension with 50+ lifecycle marketing skills, program discovery, message planning, and lifecycle diagrams.

• •Initial release of Orbit as an MCP extension for Claude Desktop
• •50+ specialist lifecycle marketing skills
• •Program discovery workflow with structured intake