# 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.