What's new in Orbit.

19 June 2026

New — a skill that tidies your Stripo library: dedupe templates, bin stale copies, file loose emails into folders

Most Stripo workspaces rot the same way. You build v1 of a template, then v2, then a quick fix, and now there are three near-identical copies — one in a folder, two loose at the root, and no clear signal which is current. The new stripo-library-cleanup skill does the housekeeping: it reads your whole library, groups emails by template, keeps the latest of each, and files loose root-level emails into the right (often nested) folders. Ask Orbit to "clean up Stripo", "dedupe Stripo", or "sort my emails into folders" and it inventories first, shows you a plan, and waits for your go before deleting anything — because Stripo deletes are permanent. It's the focused cleanup counterpart to the build-and-export work the stripo-email-builder skill already handles.

• •New skill — stripo-library-cleanup. It separates housekeeping from building: where stripo-email-builder composes, pushes, and exports emails, this one only tidies. It reads your library, groups emails by template name, marks everything but the latest of each as a delete candidate, spots the classic duplicate (a loose root copy of an email that already lives in a folder), and identifies loose emails that just need filing. You get a tight diff — what gets deleted, what moves where, any new folder it'll create — before a single change lands.
• •Confirm before any permanent delete — Stripo deletes can only be undone by rebuilding the email, so the skill never deletes on a guess. It inventories the workspace, presents the plan, and waits for an explicit go-ahead, then re-confirms if the scope grows mid-run. It also won't touch your master template, and it flags that Stripo-to-Braze exports are independent copies, so removing a stale Stripo source never affects a live Braze send — one less thing to worry about when you approve the cleanup.
• •Built to dodge the slow paths — tidying a Stripo library by hand is a maze of small traps, and the skill routes around the ones that waste the most time: it uses search-filter plus Select All to move a whole template family at once instead of clicking card by card, opens folders the safe way rather than the double-click that silently starts a rename, and reloads to clear the phantom stale cards Stripo leaves behind after a delete. The result is a cleanup that finishes in one pass instead of degrading into one-email-at-a-time cleanup.

18 June 2026

New — two skills for email hero design and IP warming, plus clearer signals for when Orbit is doing the work

Two new skills join the library. email-header-design runs a multi-agent loop that researches a brand from its live site, generates a hero image, and has a panel of design reviewers critique and re-prompt it until the design clears a quality bar — for the banner at the top of a marketing email. ip-warming does the maths for micro IP warming — spreading a one-time full-base send across several days so daily volume never spikes above what the IP's recent history earned — then shows you how to build it in Braze with Audience Paths, Random Bucket Numbers, and Delays, including the live Braze MCP method for pulling your trailing-30-day send volume when Braze exposes no single rollup for it. Alongside the skills, heavy Orbit tools are now easier to spot: in Claude Desktop they carry a branded chip title like "Orbit · Braze Sync", and their replies open with a concrete outcome line naming what Orbit did and the real result numbers, not just the closing signature.

• •New skill — email-header-design. It treats hero design as a process, not a one-shot generation: an agent pulls the brand's palette, type, and style from the live website, then several rounds of AI image generation are each critiqued by a panel of reviewers (brand fidelity, mobile legibility, composition) and the feedback is synthesised into the next prompt, looping until a quality score is hit. It produces a finished hero plus a reviewer scorecard. Because it spawns roughly ten to twenty agents per run, it needs multi-agent orchestration and explicit opt-in, and it's for the top-of-email banner only — not in-body images, full email builds, or anything that should stay vector.
• •New skill — ip-warming. The focus is micro IP warming: your IP is already warm, but a one-time send to the full base would spike daily volume far above the norm, and mailbox providers read a sudden 5x jump as a different sender and throttle it. The skill anchors every daily cap to your baseline volume (trailing-30-day sends divided by 30), then spreads the single send across N days with escalating random-bucket splits and delays so no day exceeds what recent history earned. The maths mirrors the IP Warm-Up Planner web app; the skill adds the Braze build via Audience Paths, Random Bucket Numbers, and Delays. For cold-IP or new-domain warming over weeks, it defers to the deliverability-management skill instead.
• •ip-warming carries the live Braze read method — Braze exposes no single "total email sends" series, so the skill enumerates and sums: paginate the campaign list, sum the email-channel sent field across each campaign's 30-day data series, then add the canvas sends. It flags the trap that canvas series caps at 14 days, so a true 30-day canvas total needs two rolling windows summed — or a 14-day proxy that's labelled as such, never a silent undercount.

16 June 2026

Most of Orbit now works without an account — only the live integrations need a key

We narrowed what the Activation Key gates. Orbit's calculators, validators, email and template builders, diagram rendering, copy tools, and the full skill library now run without an account. A key is only needed when Orbit connects out to Braze, Stripo, Figma, or AI image generation. Plus a fix for keys that wouldn't take after pasting: fully quit Claude Desktop and relaunch so the change is picked up.

• •Less is locked — when 0.24.0 added the account step, it gated every tool. That was heavier than it needed to be. From 0.24.1, everything that runs on your own machine works without a key: the sample-size, LTV, RFM and retention calculators, the email and MJML builders, template and component work, lifecycle diagrams, subject-line and preheader scoring, deliverability and accessibility checks, and all 62 skills. Open Orbit and use them straight away.
• •A key is only for going out to a service — the Activation Key is now asked for at the moment Orbit actually connects to an external account: reading or writing in Braze, pushing or pulling a Stripo email, importing a Figma design, or generating a brand image with AI. If you don't reach for one of those, you'll never see the prompt. And tools that do both — like composing an email locally before pushing it to Stripo — let you do the local part without a key and only ask when you push.
• •Fixed: a key that wouldn't take after pasting — some people pasted a valid key and still saw Orbit report it as not activated. Orbit reads the key when its background server starts, and opening a new chat reuses the same one, so the key never got picked up. The fix: fully quit Claude Desktop (Cmd+Q, not just closing the window) and reopen it. The activation message now says this plainly.

16 June 2026

Orbit now needs a free account — paste your Activation Key once and you're back in

From 0.24.0, Orbit asks for a free account before its tools will run. Create one at yourorbit.team, copy the Activation Key off your account page, and paste it into Claude Desktop — Settings → Extensions → Orbit → Activation Key. That's the whole thing. Orbit is free and stays free: no payment, no trial countdown, no card. The account exists so every user has a way to get product updates and support, not to put a wall in front of the product. Until a key is in, the tools that do real work stay locked and return a short note telling you exactly how to activate — but the diagnostics still run, so you can check your setup, check your version, and browse the full skill list while you sort the key out.

• •Behaviour change — Orbit's tools now require an Activation Key. Sign up free at yourorbit.team, copy the key from your account page, and paste it into Claude Desktop under Settings → Extensions → Orbit → Activation Key. Once it's saved, every tool works exactly as before. There's no paid tier behind this — the key just confirms you have a free account.
• •What you need to do if you're updating — anyone coming from an earlier version adds their key once. The first time you reach for a tool after updating, it'll prompt you to activate instead of running. Grab your key from yourorbit.team, paste it into the Activation Key field in the Orbit extension settings, and you're set. It's a one-time paste, it's free, and you won't be asked again.
• •You can still get oriented without a key — the diagnostics aren't gated. Check setup, check version, and browse the skill list all work before you activate, so you can confirm the extension installed cleanly and see what Orbit does while you fetch your key.

16 June 2026

Fixed — Braze emails exported through Orbit now render correctly in Outlook and webmail

Export a finished Stripo email to Braze through Orbit's bridge, send it for real, and in Outlook and some webmail clients it could arrive broken — buttons rendered as plain underlined links, padding collapsed. The same email exported with Stripo's own Export to Braze button rendered fine. We confirmed it with a live Braze test send: bridge export broken, native export correct. The cause was where the styling lives. Stripo returns an email's button look and spacing — background, padding, border-radius — in a separate stylesheet, not on the elements themselves, and the bridge folded that stylesheet into a single <head> style block. That renders correctly in clients that honour head styles, but Outlook and several webmail clients strip head styles on the way in, so the styling vanished and CTAs landed unstyled. Stripo's native export sidesteps this by writing the styling directly onto each element. The bridge now does the same — it inlines Stripo's styling onto the elements so it survives even where head styles get stripped, exactly matching what the native button produces.

• •The fix — orbit_export_stripo_email_to_braze now inlines Stripo's separate styling onto each element's own style attribute instead of parking it all in a <head> style block. That mirrors Stripo's native Export to Braze output, so a bridge-exported template renders the way it does in Stripo's preview — including in Outlook and webmail clients that strip head styles and used to drop the styling entirely.
• •Responsive rules still travel — styling that genuinely can't be inlined (mobile @media breakpoints, :hover states, custom @font-face) stays in a <head> block as the fallback, the same place Stripo's native export keeps it. Stripo's own Outlook-specific head CSS and conditional comments are left untouched, so nothing Stripo set up for Outlook gets disturbed.
• •What changes for you — emails you export to Braze through Orbit now match what you'd get from Stripo's native export, so the buttons and spacing hold up in real sends. If you'd been re-exporting affected templates by hand from the Stripo UI to dodge the broken render, that workaround is no longer needed. Nothing to do beyond re-exporting any template that shipped before this fix to pick up the corrected styling.

15 June 2026

Fixed — deleting or exporting a batch of Stripo emails works in one call again

Hand orbit_delete_stripo_email or orbit_export_stripo_email_to_braze an array of email IDs — say all 36 in a program at once — and the call failed with Email IDs must be numeric Stripo email IDs. Got: "[...]". Single-ID calls were fine, so the only way through was 36 separate one-at-a-time calls. The cause was a stringified array: both tools accept a single ID or an array, and because the input is allowed to be a plain string, the desktop client is free to send your array as JSON text — [101, 102, 103] arrives as the literal string "[101, 102, 103]". The tool read that string as one ID, found it wasn't a number, and rejected the whole batch. Both tools now detect a JSON-encoded array or object and unwrap it back into a real list before validating, so the batch path works whether the client sends a real array or a stringified one.

• •Bug fix — orbit_delete_stripo_email and orbit_export_stripo_email_to_braze now unwrap a JSON-stringified array of IDs before validating it. Both tools advertise that their ID input can be a single value or an array; because a plain string is also valid, the client can serialise an array argument to text, and your [101, 102, 103] lands as "[101, 102, 103]". The validator read that one string as a single ID, saw it wasn't numeric, and failed the batch. They now parse the string back into a list first, so a batch of 36 IDs goes through in one call instead of degrading to 36 separate fallbacks.
• •Same fix on the export tool's braze_template_map — the parameter that maps each Stripo email to the Braze template it should overwrite had the identical stringified-input problem, so a map passed as JSON text was unwrapped the same way. orbit_compose_stripo_email was audited for the same pattern and was never affected; no change there.
• •What changes for you — point batch delete and batch export at all your IDs at once again. If a long session had you falling back to deleting or exporting one email at a time, that workaround is no longer needed.

9 June 2026

New — the module audit catches background images that vanish on send

If a Stripo module paints a panel or gradient using a background image on a <table>, it looks perfect in the Stripo editor and then disappears once the email is exported and sent. Gmail, Outlook, and Braze's render all strip background images off <table> elements — but the identical image on a <td> survives. orbit_audit_stripo_modules now flags this directly, so you catch the silent fill-loss before it ships instead of after a test send, and the finding tells you exactly how to fix it.

• •New finding — table_background_image (warning). The audit scans every synced module and flags any <table> carrying a background image (a background="…" attribute or background-image:url(…) in its style), because that fill renders in the Stripo editor but collapses to nothing in Gmail, Outlook, and Braze once exported.
• •It tells you the fix — move the background onto a wrapping <td> that holds the module's content, and keep a solid bgcolor on that same <td> as a fallback. That is how Stripo's own hero and structure modules apply gradients, which is why theirs survive the Stripo-to-Braze handshake and a table-based one does not.
• •Why it matters — background-image-on-a-table is the classic reason a chat bubble, gradient panel, or coloured section looks right while you are building and then sends with a blank background. Surfacing it at audit time turns a confusing test-send mystery into a one-line structural fix.

9 June 2026

Fixed — overwrite-by-name actually overwrites now, instead of quietly duplicating

0.23.2 promised that re-exporting a Stripo email to Braze would update the same-named template rather than create a second copy. It didn't work. The name-dedupe step couldn't read your existing Braze templates, so it silently fell back to creating new ones — re-exports piled up duplicates, the exact thing the release was meant to stop. The cause was a one-line read bug: the template-list call returns a wrapper object and the dedupe code iterated the wrapper instead of its items. orbit_export_stripo_email_to_braze now unwraps the list correctly, so overwrite-by-name works as advertised.

• •Bug fix — orbit_export_stripo_email_to_braze now reads your existing Braze email templates before deciding whether to create or update. The list call returns { items, truncated, pages_fetched }, but the dedupe code iterated that wrapper instead of its items array and threw "(items || []) is not iterable". The error was swallowed and the export degraded to create-new, so every re-export without an explicit braze_template_map left a fresh duplicate. Unwrapping .items restores the name match, and same-named templates update in place again.
• •Who this hit — anyone who re-exported a program on 0.23.2 and relied on the default behaviour. The explicit braze_template_map path (passing the map from the previous run) was never affected and remained the reliable workaround. If 0.23.2 left you with duplicate templates, this won't clean them up retroactively — delete the extras once, then re-export, and you're back to one template per email.

9 June 2026

Improved — exporting to Braze overwrites by name instead of piling up duplicates

Re-exporting a Stripo email to Braze used to create a second copy unless you hand-fed it the template map from the previous run. Now it overwrites by default: before creating, orbit_export_stripo_email_to_braze lists your existing Braze templates and updates any whose name matches the email being exported, so running the same program twice leaves one clean template per email rather than a pile of duplicates.

• •Overwrite by name is the default — the exporter lists existing Braze email templates once per batch and UPDATES any whose name matches the Stripo email's name, instead of always creating. Re-export the same forty-email program as many times as you like and you get forty templates, not eighty. Each row reports operation (create or update) and matched_by (id, name, or none) so you can see exactly what happened.
• •Precedence is explicit — a braze_template_map you pass still wins per email id (the most precise control), then a name match, then create-new. Two switches cover the edges: force_create makes fresh templates on purpose even when a same-named one exists, and dedupe_by_name:false skips the existence check entirely.
• •Safe by construction — if two Braze templates already share a name the export updates the first and flags the duplicate so you can tidy it, rather than guessing silently; and if the one-time listing call fails the export degrades to create rather than sinking the batch.

9 June 2026

Fixed — exported Braze templates now render their buttons and spacing

The Stripo-to-Braze export carried the email's HTML but not Stripo's separate stylesheet, so in Braze the call-to-action buttons fell back to plain underlined links and padding collapsed. Stripo returns a template's styling in two parts — the HTML document and a separate CSS field with the real button look, spacing, and mobile rules — and the export now folds that CSS into the template's head before it reaches Braze, so an exported email renders the way it does in Stripo's own preview.

• •The fix — orbit_export_stripo_email_to_braze folds Stripo's separate CSS field into the exported template's head as a style block. Stripo's GET on an email returns two style carriers: the HTML document (which holds only stub class rules) and a separate ~16KB CSS field with the real button styling, padding, and mobile overrides. The first cut sent only the HTML, so buttons rendered as plain links and class-based spacing collapsed; the folded template now matches Stripo's hosted preview.
• •Safe to re-run — the fold is idempotent (it will not stack a second copy on a re-export) and passes the HTML through untouched when an email has no separate CSS. Each exported email reports css_folded and css_byte_count so you can confirm the styling travelled.

8 June 2026

New — export finished Stripo emails to Braze as templates, in one batched call

Once an email is built in Stripo, getting it into Braze meant opening each one in the Stripo editor and clicking Export to ESP, one at a time. orbit_export_stripo_email_to_braze does the whole batch in a single call — point it at one Stripo email ID or all forty-two, and each becomes a Braze email template a Canvas can reference. Under the hood it reads each email's rendered production HTML from Stripo and creates the matching Braze template; Liquid like {{custom_attribute.first_name}} carries through untouched, because Braze resolves it at send time, not Stripo. Re-run it and it updates the templates it made the first time instead of piling up duplicates. Stripo has no native export-to-ESP API — the GUI button is the only first-party path — so this reproduces what that button does, programmatically.

• •New tool — orbit_export_stripo_email_to_braze. Pass a single numeric Stripo email ID or an array (up to 100 per call) and each finished email lands in Braze as an email template, ready for a Canvas to reference. It reads each email's rendered HTML, subject, and preheader from Stripo via GET /emails/<id>, then creates the Braze template via POST /templates/email/create. The job it replaces: opening every email in the Stripo editor and clicking Export to ESP / Braze by hand — fine for one email, a slog for a forty-email program.
• •Why a bridge and not a wrapper — Stripo exposes no export-to-ESP endpoint over its REST API. We confirmed it: OPTIONS on the email resource allows only DELETE, GET, HEAD, and OPTIONS, and every plausible export, ESP, and integrations route 404s. The Export to ESP button lives only in Stripo's hosted editor. So the tool does what that button does under the hood — fetch the rendered email from Stripo, create the template in Braze — rather than calling an export API that doesn't exist.
• •Liquid survives the round-trip — personalisation tags written into the Stripo email as literal {{...}} stay literal in the exported template, which is exactly right: Braze resolves Liquid at send time, Stripo never should. Each exported email reports a liquid_tag_count so you can confirm the personalisation made it across rather than discovering a flattened tag at send.

29 May 2026

New — read, delete, and auth-check tools for Stripo emails

Three new Stripo tools close gaps that turned up during a large email build. You can now read a pushed email back by ID, delete generated emails (one or many) without leaving Orbit, and check your Stripo connection before a push instead of finding out mid-send. The setup check now reports your Stripo credentials too.

• •New — orbit_get_stripo_email fetches a generated email from your Stripo workspace by ID, so you can recover the rendered copy of an email you pushed earlier. (Content set at push time isn't in the local preview, so reading it back is the only way to get it.)
• •New — orbit_delete_stripo_email removes generated emails by ID, one or many at a time, with a per-email success/failure breakdown. It only ever touches the IDs you name, and your master template stays protected.
• •New — orbit_check_stripo_auth tests your Stripo REST connection with a quick read-only call, so an expired or stale token is caught up front rather than failing partway through a push. Worth running before a big batch.

29 May 2026

Fixed — uploading a local image to Braze now works

The fix shipped in 0.21.2 didn't hold — local image uploads to Braze still failed with the same 400. The real cause was the upload format: Braze's media library expects a local file as a binary upload, not as base64 data tucked inside a JSON request. orbit_upload_image_to_braze, orbit_upload_images_to_braze, and the Braze template image upload now send the file the way Braze expects, so uploads from a file path or raw base64 land in your media library and return a hosted CDN URL. Verified end to end against the live Braze API. Remote-URL uploads were never affected.

• •Fixed — orbit_upload_image_to_braze now uploads local files (file_path) and raw base64 data (image_data_base64) successfully and returns a hosted CDN URL. The 0.21.2 attempt addressed the wrong cause; this corrects the upload itself by sending the file as a binary upload rather than base64 in a JSON body.
• •Fixed — orbit_upload_images_to_braze, the bulk path used when hosting images for a generated email, uploads local images the same way.
• •Fixed — hosting local image assets while learning or syncing a Braze master template now works too.

28 May 2026

Attempted fix — local image upload to Braze (superseded by 0.21.3)

This release attempted to fix local-file uploads to Braze (orbit_upload_image_to_braze and orbit_upload_images_to_braze), which were failing with a 400 reading "Either asset_url or asset_file must be provided". The change addressed the wrong cause and did not resolve the issue — uploads from a file path or raw base64 still failed. The working fix shipped the next day in 0.21.3. If you're on 0.21.2, update to 0.21.3 to upload local images successfully.

• •Known issue — local-file and base64 uploads to Braze still failed in this release despite the attempted fix. Remote-URL uploads were unaffected. Resolved in 0.21.3.

22 May 2026

orbit_compose_stripo_email — autogenerated Stripo emailName drops to a date stamp, no more ISO-timestamp tail

Small but user-visible cleanup to how orbit_compose_stripo_email labels pushed emails in Stripo when you haven't supplied an email_name override. The auto-name used to read Orbit · <subject> · 2026-05-22T02-16-18-620Z — a full ISO timestamp with colons swapped for hyphens, useful for sub-second collision avoidance but unreadable in the Stripo email list. It now reads Orbit · <subject> · 2026-05-22. Scannable in the workspace, still distinguishable across days, and aligns with how program-variant labels (Welcome - Paid, M2 Phone Divert A - Starter) read in the same list. Scope is strictly the user-facing emailName written to Stripo — local workspace HTML filenames and the diagnostic probe scripts keep their full timestamps because the collision-avoidance reasoning still applies on disk. The email_name override parameter is unchanged, so callers passing program-variant names continue to land them verbatim.

• •Behaviour change — orbit_compose_stripo_email's autogenerated emailName now uses a YYYY-MM-DD date stamp instead of a full ISO timestamp. Before: Orbit · subject · 2026-05-22T02-16-18-620Z. After: Orbit · subject · 2026-05-22. The Stripo email list is the surface this affects — anyone reading down their list of pushed emails now sees a date they can parse at a glance instead of a 24-character timestamp tail. Heads-up if you'd built a Stripo Saved Filter or external script that pattern-matches on the old T..Z suffix: those will stop matching from this version forward.
• •Unchanged — the email_name override parameter still wins when supplied and is still written to Stripo verbatim (minus the defensive square-bracket strip). Anyone already passing program-variant labels like email_name: "Welcome - Paid" sees no difference. The date-stamp change is purely the no-override default path.
• •Unchanged — local workspace HTML filenames and the Stripo probe scripts keep their full ISO timestamps. The reasoning splits cleanly: on disk, multiple composes in the same minute need to not collide, so the millisecond precision earns its keep; in Stripo's UI, that precision was just noise.

21 May 2026

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.

• •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.

15 May 2026

Two new read-only Braze tools for drift detection, plus the audit now names every custom event and attribute

Three read-only additions aimed at the same job: auditing a Braze workspace against the source of truth that's supposed to feed it. Most lifecycle programs accrete custom attributes and segment filters faster than anyone documents them, and the drift between what the warehouse / PostHog / Stripe says and what's actually populated on Braze profiles is where personalisation quietly breaks. orbit_export_braze_user_by_id reads up to 50 raw user profiles by external_id and returns custom_attributes, custom_events, campaigns_received and the identity fields exactly as Braze stores them — pass-through, no QA-style filtering, so you can diff billingLifecycleState / planType / hasActiveSubscription against your warehouse and see where the wires crossed. orbit_read_braze_segment returns a single segment's full definition — name, description, filter logic, tags, analytics-tracking status — so segment targeting can be audited against canonical attribute names without clicking through the dashboard. And orbit_audit_braze_instance now surfaces the actual NAMES of custom events and custom attributes alongside the existing counts, so naming hygiene checks (case drift, plural-vs-singular, leftover test attributes) are one call instead of three. All three tools are read-only; none of them write to Braze.

• •New tool — orbit_export_braze_user_by_id. Reads up to 50 Braze user profiles by external_id and returns custom_attributes, custom_events, campaigns_received, canvas_steps_received, and identity fields exactly as Braze stores them. Pass-through wrapper over POST /users/export/ids with no QA-style filtering on top — for the QA-flavoured 'are test users populated correctly' check, orbit_validate_test_users is still the right call. Optional fields_to_export argument narrows the response to a specific subset of profile fields when you only need a few. Use case the tool exists for: drift detection. Given a list of external_ids and a warehouse export, the assistant can now diff what Braze has against what the source of truth says — billingLifecycleState, planType, hasActiveSubscription, any custom attribute that should be moving in lockstep with another system. Returns the requested / found / not_found counts so missing profiles surface immediately rather than getting lost in the user array.
• •New tool — orbit_read_braze_segment. Reads one Braze segment's full definition via GET /segments/details: name, description, text_description, tags, created_at, updated_at, analytics_tracking_enabled, the full filter logic JSON, and the dashboard URL. The use case is auditing segment targeting against canonical attribute names — e.g. checking whether a 'Paying customers' segment actually filters on billingLifecycleState equals active, or whether it's pointing at a stale attribute name from before a schema rename. The tool returns the filter as Braze structures it, so the assistant can read the targeting logic without manual dashboard clicking. Read-only by design — segment edits still happen in Braze's UI.
• •Enhancement — orbit_audit_braze_instance now returns the actual names of custom events and custom attributes alongside the existing totals. Previously the audit summary gave you the count of custom events and custom attributes but not their names, so any naming-hygiene question (is the casing consistent, are there plural / singular duplicates, are there leftover test_* attributes from a long-ago experiment) required a follow-up tool call. Now the summary's custom_events and custom_attributes blocks carry a names array alongside total, matching the existing shape of standard_attributes. One audit call, full attribute inventory, ready to diff against the warehouse schema or the canonical naming convention.

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