Make newsroom embeds the default delivery and replace source-code export with a portable package

[tomvaillant]

Problem

Source code is not a useful journalist delivery mechanic. The current interactive menu offers a React source bundle, standalone HTML, or a Fly-hosted embed. This exposes implementation details, asks the journalist to make a technical packaging choice, and makes embed hosting an optional late-stage branch even though embed should be the newsroom default.

The correct default depends on how the newsroom CMS accepts embeds. That integration should be configured once during newsroom installation/preflight, not rediscovered for every chart.

@rmdms

Suggested solution

Replace the journalist-facing delivery menu with a newsroom delivery profile and publisher adapters.

Default behavior

• Default: publish through the configured newsroom embed/CMS adapter and return the final embed snippet or inserted CMS component.
• Backup: deliver a portable ZIP package. It may contain clean separate files (index.html, assets/, embed snippet, README, metadata) rather than forcing one huge inlined HTML file.
• Remove React/source-code bundles from the journalist delivery flow. Developer/source export, if retained, should be an explicit developer tool outside Splash orchestration.

Newsroom integration inputs

During installation, ask the newsroom administrator for a small delivery profile covering:

• CMS/vendor name and version, plus staging and production destinations.
• Accepted embed mechanism: iframe URL, HTML block, script/component, CMS asset upload, or API-created content block.
• A tested embed snippet/template with placeholders such as {url}, {title}, {id}, {width}, and {height}.
• Responsive sizing rules, maximum content width, and any fixed-height policy.
• Allowed hosting domains and relevant CSP/frame-src/script-src restrictions.
• Required metadata: title, alt/description, source, credit, language, canonical article ID, and accessibility fields.
• Authentication method and least-privilege publishing credentials for the CMS or host.
• URL/slug conventions, staging review workflow, overwrite/versioning rules, cache/CDN behavior, and deletion/retention policy.
• Any consent, analytics, privacy, or third-party-script restrictions.

Store these preferences as a reusable newsroom delivery profile; keep credentials only in protected secret storage.

Hosting adapters to evaluate

Define a provider-neutral publisher interface, then evaluate at least:

• Direct newsroom CMS/media API publishing.
• Existing newsroom static hosting or S3-compatible object storage/CDN.
• Cloudflare-based static deployment, including a Pages/Workers/R2-style adapter where appropriate.
• Fly as one adapter rather than the product-level default.
• Other low-friction static-host adapters only when they meet newsroom ownership, longevity, custom-domain, CSP, and deletion requirements.

The design spike should compare authentication, custom domains, immutable/versioned URLs, cache invalidation, rollback/deletion, costs, upload limits, and iframe/CSP compatibility. Do not select a provider based only on a “drop” UX.

Acceptance criteria

• An approved interactive is delivered through the saved newsroom embed/CMS path without asking the journalist to choose source code.
• The result includes a working, newsroom-approved embed snippet or a confirmed CMS insertion.
• Fly is optional and replaceable through the same publisher interface.
• The no-host fallback is a portable ZIP with clean files and integration instructions.
• Preflight validates the selected adapter and CMS template before the first production run.
• Secrets never enter artifacts, reports, templates, or source bundles.
• Integration tests cover one direct CMS/mock adapter, Fly compatibility, one non-Fly static-host adapter, and ZIP fallback.