camox 0.53.1 → 0.56.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "camox",
-  "version": "0.53.1",
+  "version": "0.56.0",
   "license": "MIT",
   "bin": {
     "camox": "./bin/camox.mjs"
@@ -112,7 +112,6 @@
     "@shikijs/langs": "^4.5.0",
     "@shikijs/themes": "^4.5.0",
     "@sinclair/typebox": "^0.34.52",
-    "@takumi-rs/image-response": "^2.16.3",
     "@tanstack/react-form": "^1.33.5",
     "@tanstack/react-hotkeys": "^0.16.0",
     "@tanstack/react-query-devtools": "^5.104.3",
@@ -133,11 +132,12 @@
     "react-dom": "^19.3.1",
     "react-og-preview": "^0.2.0",
     "shiki": "^4.5.0",
+    "takumi-js": "^2.18.1",
     "unhead": "^3.4.3",
     "zod": "^4.6.7",
-    "@camox/api-contract": "0.53.1",
-    "@camox/cli": "0.53.1",
-    "@camox/ui": "0.53.1"
+    "@camox/api-contract": "0.56.0",
+    "@camox/cli": "0.56.0",
+    "@camox/ui": "0.56.0"
   },
   "devDependencies": {
     "@earendil-works/pi-ai": "1.3.0",

package/skills/camox/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: camox
-description: Use when working in a Camox codebase with Block Definitions, Layout Definitions, Pages, Block content, the Camox CLI, or publishing. Applies to code-defined site structure and agent-driven content changes.
+description: Use when writing or changing a Camox website's code: Block Definitions, Layout Definitions, singleton pages and derived routes, localized code, field styling, artifacts, or DOM integrations.
 ---
 
 # Camox
@@ -43,15 +43,8 @@ For specialized changes to an existing block, read the specialist reference dire
 
 Use the platform. Build tabs, dialogs, carousels, menus and disclosures from native HTML and CSS (`<details name>`, `<dialog>` with `command`/`commandfor`, `popover`, scroll snap), and reach for JS only where modern HTML can't do the behaviour. Compose the project's own Components in `src/components/ui/` when it has them (Camox's Template ships accordion, tabs, dialog, carousel and mobile menu). Target Baseline Newly available, with a fallback that keeps the content reachable in browsers lacking the feature, and keep every tab, dialog and slide in the page's markup, opened or not, and reachable with the keyboard. Editors edit hidden content by turning the Canvas off, opening it, and turning the Canvas back on.
 
-## Content and CLI
+## Content
 
-For any CLI operation, first read [CLI common guidance](references/cli-common.md), then only the relevant command reference:
-
-- Pages, metadata, layout assignments, Blocks, content, or ordering:
-  [CLI Content](references/cli-content.md).
-- Where the CLI writes, publishing or discarding the development draft, or its status:
-  [CLI Publishing](references/cli-publishing.md).
-
-Code definitions do not place blocks on existing Pages or assign their layouts; `blocks.initial` only seeds the initial homepage. When the request includes placement or assignment on existing Pages, follow with the relevant CLI workflow. Singleton pages and derived routes are declared in code, not created through the pages CLI.
+Code definitions do not place blocks on existing Pages or assign their layouts; `blocks.initial` only seeds the initial homepage. When the request includes placement or assignment on existing Pages, make it as a content change once Camox has discovered the new definition. Singleton pages and derived routes are declared in code, never created as Pages.
 
 A request can cross boundaries. Load an additional reference only once that need is established.

package/skills/camox/references/artifacts.md

@@ -44,7 +44,7 @@ Spread the props onto your own `<iframe>`: they carry `srcDoc`, `sandbox="allow-
 
 ## Write a source
 
-Write the source to a local file and push it with `blocks edit --id <ID> --field-file <NAME>=<PATH>` (or `blocks create`), then check it with `camox preview`; see [Set string fields from files](cli-content.md#set-string-fields-from-files). `blocks describe` lists artifact fields with `fieldType: "Artifact"` and their `size`. Artifacts that share Artifact Data also list the sibling names in `data`, and the exact shape of `camox.data` as JSON Schema in `dataSchema`: write the source against it.
+The source is content, not code: set it as the artifact field's value, like any string field, then check the rendered page and iterate. The block type's description lists artifact fields with `fieldType: "Artifact"` and their `size`. Artifacts that share Artifact Data also list the sibling names in `data`, and the exact shape of `camox.data` as JSON Schema in `dataSchema`: write the source against it.
 
 - **Under 256 KB.** Larger writes are rejected. Load libraries from a CDN instead of inlining them.
 - **Import from esm.sh with exact pinned versions**, so the artifact never changes under the website:
@@ -67,7 +67,7 @@ Never implement your own `postMessage` protocol with the page. The website and t
 
 ### `camox.data`
 
-The artifact's Artifact Data: an object with one entry per name in the field's `data`, matching the `dataSchema` that `blocks describe` shows. It's `{}` for artifacts that share no data. It's available from the first render, so the first paint can already show the right labels and values.
+The artifact's Artifact Data: an object with one entry per name in the field's `data`, matching the `dataSchema` that the block type's description shows. It's `{}` for artifacts that share no data. It's available from the first render, so the first paint can already show the right labels and values.
 
 Values are normalized:
 

package/skills/camox/references/block-definitions.md

@@ -2,7 +2,7 @@
 
 A block definition specifies a reusable section's schema and rendering, not an instance's content.
 
-When asked to add a section, also place an instance after dev-server discovery using the [CLI workflow](../SKILL.md#content-and-cli). For shared chrome, use [Layout Definitions](layout-definitions.md) instead. Defining a type alone does not place it on a Page.
+When asked to add a section, also place an instance as a [content change](../SKILL.md#content) once Camox has discovered the definition. For shared chrome, use [Layout Definitions](layout-definitions.md) instead. Defining a type alone does not place it on a Page.
 
 ## Quick Start
 

package/skills/camox/references/layout-definitions.md

@@ -4,7 +4,7 @@ A curated layout (`kind: "curated"`, the default) is a reusable shell for editor
 
 All editable content lives in blocks; layouts have no editable `content` schema or `.Field` helpers.
 
-Defining a layout does not assign it to existing Pages. When assignment is requested, wait for dev-server discovery, then follow the [CLI workflow](../SKILL.md#content-and-cli).
+Defining a layout does not assign it to existing Pages. When assignment is requested, make it as a [content change](../SKILL.md#content) once Camox has discovered the layout.
 
 ## Quick Start
 
@@ -85,25 +85,20 @@ Singleton and derived layouts also receive `data` and `params`, and record pages
 
 ## OG Image — `toImage` (optional)
 
-Returns JSX rendered as a 1200×630 image. Use **inline styles, not Tailwind**, and `display: "flex"` for layout: this runs in an image-generation engine, not a browser.
+Returns JSX rendered as a 1200×630 image. Style it with the Theme's utilities, like a block: the image renders with the site's compiled `src/styles.css` and the Google Fonts that `src/document.ts` loads. It runs in an image engine, not a browser, so:
+
+- Size the root with `h-full w-full`, and lay out with flexbox or grid.
+- Put the color scheme class (`dark`, `brand`, …) and `font-body` on the root: the document's `<html>` classes and base styles don't apply.
+- Only class, id and descendant selectors match, so `hover:` and other state variants do nothing. Breakpoints see a 1200px-wide viewport.
 
 ```tsx
 toImage: ({ page, project }) => (
-  <div
-    style={{
-      display: "flex",
-      flexDirection: "column",
-      width: "100%",
-      height: "100%",
-      padding: 60,
-      backgroundColor: "#09090b",
-      color: "#fafafa",
-      fontFamily: "sans-serif",
-    }}
-  >
-    {project.name && <div style={{ fontSize: 24 }}>{project.name}</div>}
-    <div style={{ fontSize: 64 }}>{page.title}</div>
-    {page.description && <div style={{ fontSize: 28 }}>{page.description}</div>}
+  <div className="dark bg-canvas text-ink font-body flex h-full w-full flex-col justify-center px-20 py-16">
+    {project.name && <div className="text-brand mb-6 text-2xl uppercase">{project.name}</div>}
+    <div className="font-heading line-clamp-2 text-6xl font-semibold">{page.title}</div>
+    {page.description && (
+      <div className="text-ink-muted mt-6 line-clamp-2 text-3xl">{page.description}</div>
+    )}
   </div>
 ),
 ```

package/skills/camox/references/routed-layouts.md

@@ -54,10 +54,10 @@ function PokedexPage() {
 - Before/after blocks must be `layoutOnly: true`. Put editable headings, introductions, and other bespoke content in these blocks; keep structural application UI in the component. See [Block Definitions](block-definitions.md).
 - For a navbar or footer whose content must stay identical across different layouts, also set `synced: true` in its `createBlock` options. `layoutOnly: true` alone only restricts placement. See [Synced blocks](block-definitions.md#synced-blocks-synced-optional) for sharing behavior.
 - No `children` slot or `blocks.initial`: editors do not compose or create these pages.
-- No curated page record is created. Do not use the pages CLI to create, duplicate, move, or assign a singleton.
+- No curated page record is created. Never create, duplicate, move, or assign a singleton as a Page.
 - Studio lists singletons as directly navigable pages with block editing, without deletion or URL/layout controls. They also appear in link destination pickers (including inline text links), “Go to page” actions, and the runtime sitemap. Derived pages appear in the sitemap only when their layout declares `routes` (see [Route discovery](#route-discovery)).
 - Singleton links are saved as fixed internal URLs, not synthetic database page IDs: link fields use `{ type: "external", href: "/pokedex", text: "Pokédex", newTab: false }` (the existing URL representation), while inline text uses `[Pokédex](/pokedex)`. Renaming a code-owned URL requires updating links or adding a redirect. Curated-page links retain their page-ID references.
-- Curated-only mutation surfaces, such as page-parent selectors and the pages record API/CLI, remain separate from the navigable destination list.
+- Curated-only mutation surfaces, such as page-parent selectors and the Pages record API, remain separate from the navigable destination list.
 - The route renders the current editable blocks.
 - Code deployment controls route existence. Removing the definition and syncing releases its reserved URL. Existing curated URL collisions or layouts still assigned to curated pages must be resolved explicitly before sync can succeed.
 - Curated pages cannot claim singleton URLs or use singleton/derived layouts. Literal singleton routes take precedence over parameterized derived routes.

package/skills/camox-cli/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: camox-cli
+description: Use when running the Camox CLI to read or change a Camox project's Pages, Blocks, content, layout assignments or metadata, to preview a change, or to publish or delete the development draft.
+---
+
+# Camox CLI
+
+For any CLI operation, first read [CLI common guidance](references/cli-common.md), then only the relevant command reference:
+
+- Pages, metadata, layout assignments, Blocks, content, or ordering:
+  [CLI Content](references/cli-content.md).
+- Where the CLI writes, publishing or deleting the development draft, or its status:
+  [CLI Publishing](references/cli-publishing.md).
+
+The CLI changes content, never code. To create or change Block or Layout Definitions first, follow the [`camox` skill](../camox/SKILL.md), then wait for the dev server to discover the new definition before placing or assigning it.

package/skills/{camox → camox-cli}/references/cli-common.md

@@ -1,6 +1,6 @@
 # Camox CLI common guidance
 
-Use the Camox CLI for CRUD operations on Pages, Blocks, Layout assignments, and metadata. Use the code references instead when changing Block Definitions or Layout Definitions in `src/blocks/` or `src/layouts/`.
+Use the Camox CLI for CRUD operations on Pages, Blocks, Layout assignments, and metadata. Follow the [`camox` skill](../../camox/SKILL.md) instead when changing Block Definitions or Layout Definitions in `src/blocks/` or `src/layouts/`.
 
 If a change should be visible without a code deployment, it is usually a CLI content operation. Some requests require both code and CLI work: define the new type first, wait for the dev server to discover it, then create or assign its content through the CLI.
 

package/skills/{camox → camox-cli}/references/cli-content.md

@@ -2,7 +2,7 @@
 
 Read [cli-common.md](cli-common.md) first for `{{CAMOX_CMD}}`, help verification, and the dev-first workflow.
 
-Use these commands for Pages, metadata, Layout assignments, Blocks and their Content, and review. To change Block schemas or rendering, read [Block Definitions](block-definitions.md); to create or change Layout Definitions, follow the code-definition routing in [the Camox skill](../SKILL.md).
+Use these commands for Pages, metadata, Layout assignments, Blocks and their Content, and review. To create or change Block or Layout Definitions, follow the [`camox` skill](../../camox/SKILL.md).
 
 ## Pages
 
@@ -111,7 +111,7 @@ Content patches merge ordinary fields, so send only fields that should change:
 
 ### Set string fields from files
 
-Use `--field-file <NAME>=<PATH>` on `blocks create` and `blocks edit` to set a top-level string field to a file's raw contents, without escaping it into JSON. It suits long Markdown and [Artifact](artifacts.md) sources. Repeat the flag to set several fields. It merges with `--content`; when both set the same field, the file wins. On `blocks create`, pass `--content`, `--field-file`, or both.
+Use `--field-file <NAME>=<PATH>` on `blocks create` and `blocks edit` to set a top-level string field to a file's raw contents, without escaping it into JSON. It suits long Markdown and [Artifact](../../camox/references/artifacts.md) sources. Repeat the flag to set several fields. It merges with `--content`; when both set the same field, the file wins. On `blocks create`, pass `--content`, `--field-file`, or both.
 
 ```sh
 {{CAMOX_CMD}} blocks edit --id <BLOCK_UUID> --content '{"title": "Orbit"}' --field-file source=./orbit.html

package/skills/{camox → camox-cli}/references/cli-publishing.md

@@ -2,15 +2,15 @@
 
 Read [cli-common.md](cli-common.md) first for `{{CAMOX_CMD}}`, help verification, and the dev-first workflow.
 
-Every command works in the current developer's development draft. Its changes reach Live, the public site, only when the draft is published. Agents in parallel worktrees share their developer's development draft, so publishing or discarding it covers all of their changes.
+Every command works in the current developer's development draft. Its changes reach Live, the public site, only when the draft is published. Agents in parallel worktrees share their developer's development draft, so publishing or deleting it covers all of their changes.
 
-Don't publish or discard unless the user asks you to.
+Don't publish or delete unless the user asks you to.
 
 ```sh
 {{CAMOX_CMD}} status                   # whether the development draft exists, and how many changes it holds
 {{CAMOX_CMD}} publish                  # what publishing would do, with a token
 {{CAMOX_CMD}} publish --confirm TOKEN  # publish the whole draft to Live
-{{CAMOX_CMD}} discard --yes            # empty the development draft; Live is untouched
+{{CAMOX_CMD}} delete --yes            # empty the development draft; Live is untouched
 ```
 
 `publish` lists, in order:
@@ -23,4 +23,4 @@ Don't publish or discard unless the user asks you to.
 
 Show the user the list, especially conflicts and lost changes, and get their confirmation before passing the token to `publish --confirm`. If Live changed since the list was printed, nothing is published: the command prints the new list with a new token and fails with `CONFLICTS_CHANGED`. Review the new list with the user before confirming again.
 
-After publishing, the development draft stays open and empty. `discard` empties it without publishing and can't be undone; it requires `--yes` when not run in a terminal.
+After publishing, the development draft stays open and empty. `delete` empties it without publishing and can't be undone; it requires `--yes` when not run in a terminal.

package/skills/camox-expand/SKILL.md

@@ -55,7 +55,7 @@ Make only these kinds of change:
 - **New Settings on existing Block Definitions**, with defaults that leave current rendering unchanged. Existing content schemas stay exactly as they are. Before editing the block, capture it at desktop and mobile on a Page that places it, on the running dev server; step 6 compares against this capture.
 - **Description edits.** A new block's `description` says when to choose it over its siblings. Edit the siblings' descriptions so each one names what sets it apart, and the Agent can choose between them.
 
-New blocks live only in code, plus one review Page in the development draft: create it with the CLI (see [Managing Pages and Blocks](../camox/references/cli-content.md)) and place each new block on it with its default content. Leave every other Page, layouts, and publishing alone. This rules out new Layout-only Blocks: a Page can't hold them, and they only sync once a layout uses them. An existing Layout-only Block that gains a Setting is captured and checked on a Page whose layout uses it.
+New blocks live only in code, plus one review Page in the development draft: create it with the CLI (see [Managing Pages and Blocks](../camox-cli/references/cli-content.md)) and place each new block on it with its default content. Leave every other Page, layouts, and publishing alone. This rules out new Layout-only Blocks: a Page can't hold them, and they only sync once a layout uses them. An existing Layout-only Block that gains a Setting is captured and checked on a Page whose layout uses it.
 
 ## 6. Verify
 

package/skills/camoxify/SKILL.md

@@ -79,7 +79,7 @@ Use inline formatting and `textStyle`, including highlights, instead of fields s
 
 ## Populate and verify
 
-Follow the [Camox CLI workflow](../camox/SKILL.md#content-and-cli) to assign layouts, place blocks, and populate content, including shared navigation/footer content. Don't publish unless asked.
+Follow the [Camox CLI workflow](../camox-cli/SKILL.md) to assign layouts, place blocks, and populate content, including shared navigation/footer content. Don't publish unless asked.
 
 Compare the rendered site with the reference at desktop and mobile sizes. Verify that fields remain editable and that longer text and different repeater counts still work. Fix the reusable implementation, not just the one captured arrangement.
 

package/dist/features/og/defaultFonts.js

@@ -1,31 +0,0 @@
-import { GEIST_VARIABLE_TTF_BASE64 } from "./geist-variable-ttf-base64.js";
-
-//#region src/features/og/defaultFonts.ts
-/**
-* Decoded default fonts for the OG image wrapper.
-*
-* Takumi's wasm renderer ships with no embedded fonts — rendering without
-* `fonts` produces zero text runs and OG images come out as featureless
-* rectangles. We always inject Geist Variable so text has something to render
-* with; the user can still pass their own `fonts:` through the ImageResponse
-* constructor and override this default.
-*
-* Decoded once at module load. Takumi keys registered fonts by their bytes, so
-* passing the same `data` on every render registers Geist only once per
-* isolate.
-*/
-function decodeBase64(b64) {
-	const binary = atob(b64);
-	const bytes = new Uint8Array(binary.length);
-	for (let i = 0; i < binary.length; i++) bytes[i] = binary.charCodeAt(i);
-	return bytes;
-}
-const DEFAULT_FONTS = [{
-	name: "Geist",
-	data: decodeBase64(GEIST_VARIABLE_TTF_BASE64),
-	weight: 400,
-	style: "normal"
-}];
-
-//#endregion
-export { DEFAULT_FONTS };