docs(spec): plugin preview bake pipeline — couple bakes to source, bound R2 growth

[lefarcen]

Why

The maintainer flagged 6 open chore(plugin-previews): refresh baked preview manifest PRs from the bot — none merged, several APPROVED but stuck BLOCKED. The pile-up exposed three workflow bugs and one deeper design gap.

• Use case: triage of the stuck bake-PR queue (gh pr list --author app/github-actions). 5 of the 6 (chore(plugin-previews): refresh baked preview manifest #4261, chore(plugin-previews): refresh baked preview manifest #4408, chore(plugin-previews): refresh baked preview manifest #4415, chore(plugin-previews): refresh baked preview manifest #4433, chore(plugin-previews): refresh baked preview manifest #4437) are already closed as superseded by chore(plugin-previews): refresh baked preview manifest #4442; chore(plugin-previews): refresh baked preview manifest #4442 stays open as the immediate cleanup item.
• Pain: (1) no merge automation — main's merge queue never gets the bot PRs enqueued; (2) a fresh branch + PR per run instead of one rolling PR; (3) a generatedAt timestamp defeats the diff guard so a PR opens even with zero plugin changes (chore(plugin-previews): refresh baked preview manifest #4261 was timestamp-only). The deeper gap: the bake PR is decoupled from the source change — revert the code and the detached bake lingers.

What this PR is

A spec only (no code yet), written to the spec-battle author template so it can go on the review arena. It proposes:

1. Pre-merge bake for same-repo PRs → manifest committed into the author's branch, atomic with the code change (this is the coupling fix).
2. Post-merge/nightly demoted to uploader + fork path + backstop, with the generatedAt diff-guard fix and a single rolling branch.
3. Release-cut full bake → authoritative manifest snapshot (closes path-trigger blind spots like design-systems/, craft/, fonts).
4. Single R2 bucket + tag-union GC → protect every filename any live release references; deterministic content-hash makes deletions recoverable. (The two-bucket / per-channel-prefix idea was considered and rejected — see Alternatives.)

What reviewers will see

A new doc at specs/current/plugin-preview-bake-pipeline.md. The Sources section carries verified file:line references (.github/workflows/bake-plugin-previews.yml, scripts/bake-plugin-previews.mjs, apps/daemon/src/plugin-preview-bakes.ts, apps/web/src/components/plugins-home/cards/MediaSurface.tsx) so claims can be checked against main.

Surface area

• Docs / specs (specs/current/)
• No code, CLI, UI, contracts, or i18n changes in this PR.

Open questions (in the spec)

Land #4442 first vs regenerate; optional R2-existence self-heal; GC grace window (90d?); pre-merge upload vs manifest-only.

[lefarcen]

The pipeline write-up is easy to follow, especially the Sources section and the alternatives tradeoff.

One body-template nudge before arena review: could you add a user-facing What users will see section plus a short Validation section, and translate Surface area into the current checklist format so reviewers can scan it quickly?

Related: #4442 (the merged cleanup item this spec builds on), #4537 and #4490 (current bake-manifest PRs that still show the queue shape).

[mrcfps]

Thanks for writing this up — the Sources section made the current pipeline easy to verify. I found a few spec-level gaps worth tightening before implementation so the release bake and GC behavior stay aligned with the live release workflows.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

[mrcfps]

Problem: this cleanup recommendation is already stale: #4442 is merged, and the current queue shape has moved on to other bake-manifest PRs. Why it matters: this section is part of the rollout guidance, so keeping the wrong PR here sends follow-up work to the wrong manifest state and makes the spec's narrative drift from reality. Evidence: the changed text says #4442 is still open and should be landed first, but gh pr view 4442 now returns state=MERGED, and the maintainer's PR comment on this spec points reviewers at #4537 and #4490 as the current queue. Suggested change: refresh the queue references in Why, Related material, and this open question to the current bake-manifest PR(s), or rewrite the guidance in terms of "the current open bake PR at merge time" so the document does not rot immediately.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

[mrcfps]

Problem: the release-cut workflow as written will retrigger itself: it is triggered by push to release/**, and this same section also says it commits the baked manifest back onto the release branch. Why it matters: without an explicit loop break, the workflow-authored manifest commit becomes another push event and can keep rebaking/recommitting the same branch. Evidence: unlike the pre-merge path above, this section does not define any paths filter or actor/commit guard around the workflow's own data/plugin-previews/manifest.json writeback. Suggested change: spell out the loop guard in the spec — for example, exclude data/plugin-previews/manifest.json from the trigger paths or skip the job when the head commit/actor is the bake bot — and include that in the acceptance criteria.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

[mrcfps]

Problem: the protected-set formula only unions release/prerelease tags plus main, so it misses live preview/nightly artifacts that are published from non-tagged refs. Why it matters: that breaks goal 3's “never reference a deleted clip” guarantee for exactly the channels the repo documents as long-lived but not tag-backed. Evidence: the changed formula here is tags ∪ current main manifest; meanwhile .github/workflows/notify-release-feishu.yml builds nightly on every release/** push, and root AGENTS.md defines preview as an independent release channel published under preview/latest. Neither channel is protected by a tags-only set until some later tag exists. Suggested change: extend the protected set to include the manifests for the currently published nightly/preview channels (or the release-branch manifests that feed them), and note how the GC job discovers those manifests/metadata.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}