@gurupanguji

Provider Embed Expansion Design

Goal

Resolve issue #121 by unifying standalone URL normalization across all supported embed providers while keeping the repository aligned with the post-body contract defined in issue #122.

This issue should make five provider families follow one consistent authoring rule set:

The result should preserve the same body-shape contract already approved for supported embeds:

Problem

The repository already has partial authoring-time normalization:

But the current provider behavior is uneven. YouTube and X or Twitter already have one normalization path, while Mastodon, Bluesky, and Threads are still missing from that shared policy surface. That leaves the current authoring loop uneven:

That gap directly conflicts with the approved contract in docs/superpowers/specs/2026-03-27-portable-post-body-contract-design.md.

Decision

Issue #121 should define one supported-provider normalization policy with only two final states:

  1. official provider embed
  2. plain markdown link

No third custom-card state should be introduced.

The behavior should be:

Scope

In scope

Out of scope

Canonical Author Input Rules

1. Standalone provider URLs

These are eligible for official embed normalization when they occupy their own line:

Examples:

https://youtu.be/dQw4w9WgXcQ
https://youtu.be/7EVZpW9Rdwk?si=3LCmVvZ4RojDigvj
https://www.youtube.com/watch?v=7EVZpW9Rdwk
https://x.com/example/status/1234567890123456789
https://mastodon.social/@user/123456789012345678
https://bsky.app/profile/example.com/post/3lxyzabc123
https://www.threads.net/@example/post/C8abc123xyz

For YouTube specifically, the normalizer should support at least these author-input forms:

The implementation should extract the stable video ID, ignore non-essential share noise in the embed URL, and render one canonical embed form in the committed body.

2. Provider URLs inside prose

Provider URLs inside ordinary prose paragraphs should not expand to embeds in this issue.

Instead, normalize them only to:

[https://example.com/post](https://example.com/post)

This keeps the prose path simple and avoids injecting large embed blocks into narrative flow.

Canonical Successful Output

When official embed generation succeeds, the committed body should contain:

  1. repo-owned provider wrapper
  2. provider-native official embed payload inside that wrapper
  3. canonical markdown source line immediately below

Example shape:

<div class="gp-mastodon-embed">
  <!-- provider-native official embed payload -->
</div>
*Source:* [Mastodon](https://example.com/post)

The same pattern applies to Bluesky and Threads with provider-specific wrapper classes and platform labels.

Canonical Fallback Output

If official embed generation fails for any supported provider, the normalizer should:

  1. log the error
  2. replace the standalone URL with a plain markdown link
  3. continue without blocking commit or PR

Fallback shape:

[https://example.com/post](https://example.com/post)

No extra *Source:* line should be added in the fallback case because the markdown link is already the durable source.

Source-Line Label Rule

Successful embeds should use fixed platform-name labels, consistent with the contract in issue #122.

Canonical labels for this issue:

Canonical source shape:

*Source:* [Bluesky](https://...)

The source line should preserve the original authored URL exactly.

For example, if the author pastes:

https://youtu.be/7EVZpW9Rdwk?si=3LCmVvZ4RojDigvj

the committed embed may use the normalized canonical YouTube embed URL internally, but the source line should keep:

*Source:* [YouTube](https://youtu.be/7EVZpW9Rdwk?si=3LCmVvZ4RojDigvj)

Official Embed Strategy

Issue #121 should prefer official provider embed output, not hand-built approximation markup.

But the repository should not store arbitrary provider paste blobs completely raw if that can be avoided. The recommendation is:

Reason:

Provider-Specific Wrapper Classes

Use provider-specific outer wrapper classes:

These wrappers should be the styling hooks owned by the repo. They should center the embeds and keep them responsive within the post body.

Styling Location

Embed presentation for this issue should extend the existing pattern in _layouts/post.html, not move into a new styling surface.

Reason:

So issue #121 should add or align provider-specific responsive centering rules there:

Network Boundary

Pre-commit normalization for these providers may rely on network access.

That is acceptable for this repository because the author prefers convenience over strict offline-only normalization for this workflow.

This means the implementation can call official provider embed endpoints or provider-documented embed surfaces at commit time.

Validation Policy

Validation should accept two valid final states for supported providers:

  1. successful official embed output plus source line
  2. markdown-link fallback after embed-generation failure

Validation should not force a retry loop that blocks commit or PR when provider embed generation fails.

That means:

Detection Boundaries

Issue #121 should preserve the current narrow normalization philosophy.

Do normalize:

Do not normalize:

File Changes

New

Modify

Verification

Automated

Add tests for:

Manual

Spot-check rendered output for:

Check that:

Risks

Provider embed surfaces can vary

Official embed endpoints and returned payloads can change over time. The implementation should isolate provider-specific logic so failures degrade to markdown links instead of breaking authoring.

Network-dependent commits can be noisy

Because this path may fetch provider embed payloads during normalization, transient failures are possible. The markdown-link fallback is the safety valve that keeps the authoring loop moving.

Provider markup may not be responsive by default

Official embed payloads are not guaranteed to fit the site’s layout by default. The repo-owned provider wrappers must handle centering and responsiveness without mutating the provider payload beyond what is needed for layout.

Acceptance Criteria

  1. Standalone supported provider URLs normalize to official embeds when generation succeeds.
  2. Successful embeds commit with provider-specific wrapper classes and a visible markdown source line.
  3. Embed-generation failures fall back to [url](url) and do not block commit or PR.
  4. Provider URLs inside prose normalize only to [url](url) and do not expand to embeds.
  5. Validation accepts both successful embed output and markdown-link fallback while still rejecting leftover raw standalone eligible provider URLs.