← Journey PHASE 5b — Design system: client design system + Penpot bidirectional

design.md grows a Penpot spine

The design.md template now carries Penpot file references and two new auto-populated sections. Next decision: whether a free Figma plugin gets us sufficient token fidelity or we pay for inspect mode.

Two template changes landed today, both scoped to the design.md file that the design agent writes for every component. Neither is visible in the UI yet — this is scaffolding for the three n8n workflows that wire Penpot bidirectionally.

What shipped

The frontmatter block in design.md got four new fields:

~/projects/templates
├─ design.md base template, updated
├─ design.md#penpot_file_id new UUID populated by sync workflow
├─ design.md#penpot_project_id new target project in Penpot instance
├─ design.md#penpot_last_synced new ISO timestamp, written on each push
└─ design.md#token_source new enum: figma_plugin | manual | penpot_native

Below the frontmatter, two new ## sections append themselves when the extraction workflow runs: ## Extracted patterns and ## Penpot components. Both are empty stubs until a workflow populates them — the template just reserves the headings so downstream parsers have a stable anchor.

Next decision

Before any workflow runs, there is a fork: Option A is the free “Figma to Penpot” plugin applied to the client design file; Option B is a Figma Dev seat for manual token extraction. Option A gets evaluated first — if the exported token fidelity is workable, token_source stays figma_plugin and we skip the $25–45/mo seat entirely.

What this unblocks

With the template stable, the three n8n workflows can be drafted against a known schema. The penpot_file_id field is the handshake point — once that’s populated from whichever import path wins, the push and pull workflows have everything they need to start moving frames and tokens.