# Code & Spec Export Gakaso separates two distinct export purposes — pick the one that matches what the human actually wants: | Goal | Use | |---|---| | Turn a **semantically-authored** canvas (application or diagram mode) into production code | Code export (`gakaso_export_code` and related tools, below) | | Get a **faithfully-imported** UI back out with pixel/visual fidelity intact, for the *importing app's own* re-implementation | Faithful read-back (`gakaso_export_faithful` — see `/mcp/faithful-roundtrip.md`) | These are not interchangeable: semantic export produces idiomatic, token-referencing code from `gks-*` components; faithful read-back produces a neutral fidelity-preserving manifest (or HTML/SwiftUI/Compose-flavored output) from `gks-frame` objects. Using the wrong one against the wrong kind of canvas content will not give a useful result. ## Code export formats `gakaso_export_code` supports: - **`react-tsx`** — React/TypeScript components. - **`html-css`** — plain HTML/CSS. - **`react-tailwind`** — React components styled with Tailwind, produced by Gakaso's design-to-code compiler. ## Spec / intermediate export Beyond code, a project's design can be exported as a structured spec rather than as implementation code: | Tool | Output | |---|---| | `gakaso_export_design_spec` | Detailed UI design spec, useful for handing a precise structured description to a downstream tool or team rather than raw code. | | `gakaso_export_intermediate` | Fallback intermediate format (JSON/YAML) — useful when you need a framework-agnostic structural dump rather than either code or a full design spec. | | `gakaso_spec_get` / `gakaso_spec_lint` / `gakaso_spec_reconcile` | Read the current structural spec, lint it for issues, and reconcile drift between spec and implementation. | | `gakaso_get_schema_version` | Check the export schema version in play, relevant if you're consuming exports programmatically and need to handle version differences. | ## Higher-fidelity / auxiliary export - `gakaso_export_high_res` — high-resolution image export (e.g. for handoff artifacts, not code). - `gakaso_export_svg` — SVG export for vector content. - `gakaso_generate_code_samples` — generate representative code samples from the current design (lighter-weight than a full export). - `gakaso_generate_stateful_code` — generate code that includes state handling (e.g. interactive components), rather than purely static markup. - `gakaso_scan_exported_code` — run a security/quality scan over already-exported code before it's used downstream. ## Design tokens Token-specific import/export (`gakaso_import_tokens`, `gakaso_export_tokens`, `gakaso_distribute_tokens`) is covered in `/design/tokens.md` rather than here, since tokens are consumed by both code export and faithful round-trip and aren't really a separate "export format" in the same sense. ## Publishing a document None of the tools above publish anything to a public URL — they all return content to *you* to apply elsewhere. If what's actually wanted is a shareable public link (e.g. "publish this spec so I can send it to a client"), that's a different tool, `gakaso_publish_doc`, covered fully in `/publish-doc.md`. ## Practical guidance - If the human's project is a from-scratch application/diagram canvas and they want a working codebase: use `gakaso_export_code` with the format that matches their stack. - If the human's project started as a faithful import of an existing app's UI and they want changes reflected back into *that* app: use `gakaso_export_faithful` instead (see `/mcp/faithful-roundtrip.md`), not code export. - If what's wanted is a structured description rather than runnable code (e.g. for documentation, for a non-Gakaso tool to consume): reach for the spec/intermediate tools rather than code export.