◆ Mission Log FILED · May 6, 2026 STATUS · OPEN TRANSMISSION
Mission Log

Feinschliff architecture: one DSL, three outputs

How Feinschliff renders three output modalities from one DSL grammar: decks, architecture diagrams, and SVG infographics, all against the same brand tokens.

feinschliffclaude-codedesign-systemspowerpointarchitecture
Code ↗

Feinschliff architecture pipeline: Design Brief and DSL flow through Parser, Expander, and Render Dispatcher into three outputs (PPTX, PNG, SVG), with Brand Bridge supplying tokens

One DSL, three outputs. The pipeline is linear, the render dispatcher forks at the end. If the system is built right, brand tokens flow through every output modality without the renderer adding special cases per modality. That’s the point Feinschliff exposes.

Four components. Parser reads .slide.dsl files and produces DSL nodes. Expander handles slot interpolation and resolves compound blocks: Excalidraw diagram calls and SVG infographic blocks both get pre-rendered to PNGs here. Brand Bridge loads tokens.json from the active brand pack and walks the inheritance chain, so child overrides merge cleanly on top of a parent brand. Render Dispatcher forks at the end by output modality: python-pptx for 1920×1080 .pptx, pure-Python (~150ms, Playwright as fallback) for PNG diagrams, brand-resolved SVG for infographics.

The real test isn’t the fork itself. It’s the question: does the same code path carry four brands with contradictory chrome rules? Four reference packs span the test space. They carry rules that can’t all be true at once:

  • Pack A: sharp corners everywhere, no shadows, 700/300 weight ladder with 500 explicitly missing.
  • Pack B: fully-rounded pills (radius=9999) for CTAs, heavy OOXML shadows, dark canvas.
  • Pack C: also sharp corners, but never bold display weight (500 is the cap), negative letter-spacing.
  • Pack D: bespoke chrome: a data-dense table tile as hero, an OOXML gradient, a light reset-footer band on dark canvas.

If the renderer serves all of that through the same primitives (add_button, add_chip, add_column(as_card=True)) without special cases, the architecture is load-bearing. If it can’t, brand-pluggable was marketing. Concretely: radius.btn = 0 produces sharp rectangles in Pack A. radius.btn = 9999 produces fully-rounded pills in Pack B. Same call, four brands, four decks.

The public brand gallery is the test: 12 brand packs against 30+ layouts, click-through in the browser. Don’t take the claim from the README. Take it from the pixels. Falsifiable, no setup.

An atlas layer grounds planning before rendering. 39 curated slide exemplars across 6 domains live in the repo as a corpus, each with thumbnail and metadata for genre, headline pattern, and nearest Feinschliff layout. Phase 1 is the corpus. Phase 2 is retrieval inside /deck and comes later. Once the system can pull concrete patterns instead of leaning on model prior alone, the planning gap closes.

Bring your own brand? A single DESIGN.md in Google’s open spec format plus a bake call:

mkdir -p feinschliff/brands/myco
$EDITOR feinschliff/brands/myco/DESIGN.md
uv run python scripts/bake_palette.py from-design-md --brand myco --base feinschliff
FEINSCHLIFF_BRAND=myco /deck "..."

Next: drop-in support for any DESIGN.md from awesome-design-md. Stripe, Vercel, Linear, Notion. Anything that’s open. Brand-pluggable hangs on one code path. The code path holds. Now the door opens for more brands.