One month in — plan vs. reality
The original plan had seven phases laid out in a table. A month in, five are done and the remaining two look different than expected. Here's what actually happened.
The first post on this site was a table. Seven phases, most marked —. The assumption was that each phase would take roughly what it said on the tin. A month later, phases 0 through 5b are done and the table looks different in ways I didn’t expect.
What shipped vs. what was planned
Phases 0 through 1B ran close to plan. The infrastructure is live: GMKtec running n8n, Penpot, Ollama, CouchDB. Vault on LiveSync. R2 wired as CDN. The site you’re reading now.
Phases 2 and 3 collapsed. Vault structure and CLI wiring happened in parallel rather than sequentially — by the time I was writing CLI aliases they were already pointing at live n8n webhooks. The phase boundary was a planning artifact, not a real dependency.
Phase 4A and 4B (n8n agents + design pipeline) shipped, but not as originally scoped. The original spec assumed Claude API in the automation loop. That changed.
- Claude API in n8n (design-feedback, session-ingester, inbox-classifier)
- qwen2.5-coder:14b for session ingestion
- Sanity CMS
- Groq qwen3-32b + Mistral (critique chain)
- Groq llama-3.1-8b-instant (session ingestion + classification)
- MDX files committed directly to repo
Phase 5a (Storybook restructure) and 5b (Penpot bidirectional) are done. The POC confirmed: brief in, Penpot canvas frame out, under 15 minutes. Second brief uses patterns extracted from the first.
The real obstacles
ROCm + 14b + tool-calling don’t mix. qwen2.5-coder:14b on the GMKtec 780M crashes with a segfault when MCP tool-calling is in the inference path. It’s not a VRAM issue — it’s an architectural incompatibility with the gfx1102 override. The fix was a model split: 7b handles interactive MCP sessions, 14b handles n8n prompt→completion only where tool-calling never fires.
mcphost doesn’t work with cloud APIs. The MCP schema passthrough gets rejected by Mistral and Groq strict validation. This ruled out the originally planned Hermes CLI path for Penpot token extraction. The working solution is run_arm_c.py with Mistral — a custom script that forces the correct Penpot JS API path. 260%+ ground-truth coverage vs. 2% from the Hermes approach.
Figma-to-Penpot import has no free path with usable fidelity. The “Figma to Penpot” plugin failed. The REST API using an existing expert seat pulled tokens directly to Storybook — that’s the path forward. The $25–45/mo Dev seat stays deferred.
What’s left
Phase 5b has two open tasks: data ingestion sub-workflow and template iteration. These are the least glamorous items — normalising xlsx/csv/json into row arrays, cloning Penpot frames per row via the bridge service. They’re blocking iterate.[domain], the lightweight UI that makes the template pipeline usable without touching n8n directly.
Phase 5c is handoff documentation at scale. The batch driver runs qwen2.5-coder:14b sequentially against component exports — roughly 50–75 seconds per component. At that rate, 500 components is an overnight job.
Phases 6 and 7 (RAG with Qdrant, multi-agent critic loop) haven’t started. They’re not blocked — Phase 5c just needs to close first.
What this unblocks: the two remaining 5b tasks are well-scoped and don’t carry the architectural uncertainty that stalled earlier items. Template iteration in particular has a clear path: the bridge service is already running, the slot convention is defined, the Penpot write-back API is understood. It’s implementation, not exploration.