Review: apps/design — Vision 2026 PR #545

[synerbot]

Review scope

Changes to apps/design in PR #545 (feat/vision-2026 → main).

Lead agent: syner/design

What to cover

Based on the PR diff, describe:

• What changed in this app
• New routes, handlers, or API endpoints
• Dependencies added or modified
• Breaking changes or migration notes
• Anything that needs attention during review

Key files changed

• apps/design/app/api/slides/[deckId]/[index]/route.tsx
• apps/design/app/api/slides/generate/route.tsx
• apps/design/package.json
• apps/design/AGENTS.md
• apps/design/README.md

[synerbot]

apps/design: what you can do in vision-2026 that you can't in main

In main

syner.design is a static app: landing page + Card component showcase. No API routes, no generation capability. Visual only.

In vision-2026

A Slide Generation API is added — any agent or service can programmatically generate presentation decks as PNG images.

---

Example 1: Generate a full deck

const response = await fetch('https://syner.design/api/slides/generate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    slides: [
      { template: 'title', heading: 'Q1 Results', subtitle: 'syner platform metrics' },
      { template: 'highlights', items: ['50% faster skill resolution', 'osprotocol v1 shipped', '4 new packages'] },
      { template: 'metrics', entries: [{ label: 'Skills', value: '47' }, { label: 'Agents', value: '12' }] },
      { template: 'outlook', heading: 'Q2 Focus', bullets: ['Self-development pipeline', 'Cross-instance communication'] },
    ],
    style: { theme: 'dark' },
  }),
})

const { deckId, slides } = await response.json()
// slides[0].url → "https://abc.public.blob.vercel-storage.com/slides/xK9f2/0.png"
// slides[1].url → "https://abc.public.blob.vercel-storage.com/slides/xK9f2/1.png"

Example 2: Retrieve an individual slide

GET /api/slides/xK9f2/0
→ image/png (cached 1 year, immutable)

Useful for embedding in Slack messages, GitHub comments, or any surface that supports images.

Example 3: A bot generates slides on-demand

// Inside a Slack handler or GitHub webhook
const deck = await fetch('https://syner.design/api/slides/generate', {
  method: 'POST',
  body: JSON.stringify({
    slides: [
      { template: 'title', heading: issue.title, subtitle: `#${issue.number}` },
      { template: 'highlights', items: issue.labels.map(l => l.name) },
    ],
  }),
})

const { slides } = await deck.json()
await slack.postMessage({ 
  channel, 
  text: `Deck ready: ${slides.map(s => s.url).join('\n')}` 
})

---

Summary

Capability	main	vision-2026
Landing page + component showcase	✅	✅
Slide generation API	❌	✅
Slide retrieval API	❌	✅
Vercel Blob storage	❌	✅
@syner/ui/slides template system	❌	✅
New deps: @vercel/blob, nanoid	—	added

The new functionality is purely additive — nothing existing breaks. The app goes from being a static showcase to a visual asset generation service that other apps and agents can consume.

[rbadillap]

Answer the following questions as concise as possible:

1. Are you using the SDK??

[synerbot]

1. No. apps/design does not use @syner/sdk. The slide routes import directly from @syner/ui and @vercel/blob — no orchestrator, no skill resolution, no vault context. It's a standalone API.

[rbadillap]

One more question before ideating something for you.

1. Can you explain why you need @vercel/blob ?

[synerbot]

1. @vercel/blob is used for two things:

   • generate/route.tsx: After rendering each slide to PNG via next/og, it uploads the buffer to Vercel Blob with put() — this gives each slide a persistent public URL.
   • [deckId]/[index]/route.tsx: Uses head() to look up the blob metadata, then fetches and proxies the image back.

   Why Blob instead of just returning the image directly? Persistence. Without Blob, slides only exist during the request. With Blob, a generated deck gets permanent URLs that can be shared in Slack, GitHub, docs — anywhere that renders images. The trade-off is storage cost per generation.

[rbadillap]

You don't need to generate in runtime, my intention is to use the Build step for that.

Let me elaborate this topic later, but the point is, you should assume the markdown files are already there, you work with files instead of infrastructure.

Stand by for new indications.

[synerbot]

Debate: Build-time slide generation

Context shift: Slides should be generated at build time from markdown files, not at runtime via API. No @vercel/blob, no POST endpoint. The markdown files are the source of truth.

Question for leads: If we move to build-time generation from markdown, what changes in your domain? Be specific about files that need to change, add, or remove.

Pinging: syner/ui, syner/vaults, syner/design

[synerbot]

syner/vaults here — I own the deck parser, so weighing in:

1. Reuse, don't duplicate. lib/deck-parser.ts imports Deck/Slide/Style types from @syner/ui/slides/types — it's already decoupled from vaults. Move it to packages/ui (or a shared package) so design imports it directly. No reason for two parsers.

2. MDX format maps cleanly to Slide types. The parser splits on \n---\n separators, parses per-slide frontmatter (template, heading, subtitle, style), and returns a typed Deck with Slide[]. The example MDX in content/decks/ is currently a placeholder — real decks would use the separator format. The Fumadocs collection (source.config.ts) handles discovery via defineDocs({ dir: 'content/decks' }).

3. One concern: The parser uses gray-matter to parse per-slide frontmatter within the already-parsed MDX body. This works at build-time but is fragile if MDX remark plugins interfere with the --- separators. If design adopts this, lock in a remark plugin that preserves raw separators, or switch to a custom directive like {/* slide */}. Otherwise, no blockers — extracting the parser is straightforward.

— syner/vaults

[synerbot]

Reviewed the slide infrastructure in @syner/ui. Here is what matters for the build-time shift:

1. Types and registry need zero changes. Slide, Deck, Template, renderSlide() are pure data-in, JSX-out. No HTTP, no Blob, no request context. They return ReactElement for Satori — works identically whether called from an API route or a build script.

2. renderSlide() is runtime-agnostic. It resolves a template from an in-memory Map and calls template.render(slide, deckStyle). No Request, no Response, no ImageResponse. The caller (currently apps/design) wraps the result in next/og — that coupling lives in the app, not in @syner/ui.

3. Font loading works as-is at build time. loadGeistSans() and loadGeistMono() use fs.readFile on static .ttf files resolved via import.meta.url. This is pure Node filesystem — no network fetch, no Blob download. A build script calling Satori directly can use these loaders unchanged.

Net impact on @syner/ui: none. The entire runtime assumption lives in apps/design's API route and its @vercel/blob upload. The shared package is already build-time compatible.

-- syner/ui

[synerbot]

1. Remove: apps/design/app/api/slides/ (entire directory — both generate/route.tsx and [deckId]/[index]/route.tsx).

2. Drop deps: @vercel/blob and nanoid. Both are only used by the runtime slide API. next/og stays (it powers build-time rendering).

3. Replacement: Slide decks become markdown files (e.g. apps/design/content/decks/*.md). At next build, a script/plugin parses each markdown file, calls renderSlide + ImageResponse to produce static PNGs into public/slides/, and Next.js serves them as static assets. No API, no Blob, no runtime cost. Images are committed or generated in CI.

4. Update docs: AGENTS.md — remove the two API route references, the agent-relevant files table entries for both routes, and the "Production" status rows for both APIs. Replace with the new markdown-to-static-PNG pipeline. README.md — remove the API section, the BLOB_READ_WRITE_TOKEN env var, update the Stack table (drop Vercel Blob, Edge runtime), and update the Routes table.

— syner/design

[synerbot]

Debate summary

Three leads responded. Here's the consensus:

syner/ui: No changes needed. renderSlide() is pure, font loaders use fs.readFile — fully build-time compatible.

syner/vaults: Deck parser already exists (lib/deck-parser.ts). Suggests moving to shared package. Flags potential --- separator conflict with remark plugins.

syner/design: Remove api/slides/ entirely, drop @vercel/blob + nanoid. Replace with build-time pipeline: markdown → parse → render → static PNGs in public/slides/.

Open questions before planning

1. Deck parser location: vaults already has it. Should design import from vaults, or should we extract to @syner/ui (since it already owns slide types)?
2. Where do markdown source files live? In apps/design/content/decks/? Or reuse apps/vaults/content/decks/?
3. Build script or Next.js plugin? The build-time generation could be a standalone script (bun run generate-slides) or a Next.js generateStaticParams + dynamic route. Which approach?

@rbadillap — your call on these three before I draft the plan.

[synerbot]

Answering: what does deck-parser do?

It converts a single MDX file into a Deck object with typed Slide[]. The format uses --- as slide separators, and each slide block has its own frontmatter:

---
title: Q1 Report
style: { theme: dark }
---

---
template: title
heading: Q1 Results
subtitle: Platform metrics
---

---
template: highlights
heading: What shipped
---
- osprotocol v1
- SDK rename
- 4 new packages

The parser: (1) extracts deck-level frontmatter, (2) splits on ---, (3) extracts per-slide frontmatter into typed Slide objects.

Is it necessary? It bridges markdown → Slide[] types that renderSlide() expects. Without it, you'd need another way to go from .mdx files to the typed slide data. It's ~25 lines of code, mostly gray-matter calls.

Honest take: The current example.mdx doesn't even use this format — it's just a placeholder with no slide blocks. So the parser exists but isn't battle-tested yet.

[synerbot]

Debate summary (updated)

Owner decisions

1. Deck parser: Needs evaluation — it exists but is untested. The --- separator approach may be fragile.
2. Content location: apps/design/content/decks/ ✅
3. Build approach: Next.js first, extend if needed.

Lead consensus

Lead	Impact	Action
syner/ui	None	renderSlide() is pure, fonts use fs.readFile. Build-time compatible as-is.
syner/vaults	Low	Deck parser exists (lib/deck-parser.ts, ~25 lines). Suggests extracting to shared package. Flags --- separator fragility with remark.
syner/design	High	Remove api/slides/ dir, drop @vercel/blob + nanoid. Replace with build-time pipeline: markdown → parse → render → static PNGs. Update AGENTS.md + README.md.

Key facts from discussion

• @syner/sdk is not used by design — it's standalone
• @vercel/blob was for runtime persistence — unnecessary with build-time static assets
• The existing example.mdx is a placeholder that doesn't use the actual deck format
• next/og stays — it powers the Satori rendering regardless of build vs runtime

What's next

Awaiting owner's final approval to draft the implementation plan.