Zenith

コードにはソース管理、型、テスト、プルリクエストがありました。デザインファイルにはそのどれもありません。デザインファイルは不透明な塊で、差分を確認できず、変更をレビューできず、同じファイルでもマシンによって表示が異なることがあります。

これは人々にとって問題であり、AI にとってはさらに大きな問題です。エージェントがすでにコードを書いてプルリクエストを作成できるのは、コードが読み取って推論できるテキストだからです。デザインツールに入ると、エージェントは何も見えなくなります。エージェントに「見出しをブランドカラーの赤にして、レイアウトを詰めて」と頼んでも、安全に変更できる対象がありません。安定したターゲットも、検証も、プレビューも、結果を確認する方法もないのです。

Zenith はこの問題を解決します。目標は、デザインファイルをコードと同じように安全に自動化できるようにすることです。

• プレーンテキストを自分で所有できます。読みやすく、差分を確認でき、いつまでも自分のものです。
• 安定した IDにより、すべての変更がマウスドラッグではなく、レビュー可能なパッチになります。
• 決定論的なレンダリングにより、同じファイルから常に同じピクセルが生成されます。
• 実用的な検証により、テキストが収まり、色がデザインシステムに準拠し、何もページからはみ出さないことを確認できます。
• 安全な編集では、すべての変更が型付きトランザクションとなり、反映前に検査とプレビューが行われ、ソースの差分と監査記録も残ります。

よくある誤解なので、はっきりさせておきます。Zenith は Nano Banana、ChatGPT image、Grok Imagine のような画像モデルとは正反対です。

画像生成ツールが出力するのは平坦な画像です。ピクセルの集まりなので、開いてロゴを動かすことはできず、見出しを正確なブランドカラーにすることもできません。また、「同じものを別の日付で」と頼むと、異なる画像が生成されます。編集、レビュー、保証の対象となるものはありません。

Zenith が生成するのは画像ではありません。生成するのは、_デザインそのもの_です。すべての要素が実体を持ち、指定できる、構造化された編集可能なドキュメントです。エージェント（または人）は、1 行を変更したり、カラーのトークンを置き換えたり、ブランドに沿ったバリエーションを 100 種類再生成したりできます。そして、レンダリングの結果はすべて正確で、再現可能です。AI がソースを書き、編集し、Zenith がその意味と見た目を保証します。

多くのデザインツールは、人がボックスをドラッグすることを前提に作られており、自動化 API は後から付け足された後付けの機能にすぎません。ソフトウェアによる操作を想定していないモデルの上に、薄く機能が限られたレイヤーを重ねています。

Zenith は逆の発想で作られています。基盤となるのは、プログラムから操作できるテキストベースの決定論的なエンジンです。エージェント、スクリプト、コマンドラインから直接操作します。つまり、自動化は裏口ではなく、正面玄関なのです。

エディター。 エンジンと CLI は、AI エージェントが操作するインターフェースです。ブラウザーエディターは同じエンジン上のクライアントです。デザイナーがボックスを少し調整し、エージェントが 100 種類のバリエーションのスタイルを変更する場合も、どちらも同じ決定論的なコアを使い、同じ検証、トランザクション、バージョン履歴を利用します。GUI は、自動化を後付けした別製品ではありません。

.zen ドキュメントは、単一の決定論的なパイプラインを通ります。各ステージは、明確な契約境界を持つ独立したクレートです。そのため、GPU バックエンドもエディターも、同じシーン IR を利用できます。

_{Zenith によるレンダリング — ソース：assets/showcase/pipeline.zen。}

  design.zen  (KDL plain text)
       │  parse + validate           zenith-core   →  diagnostics (Error/Warning/Advisory)
       ▼
  Document AST  ──transaction ops──▶  Document AST'  zenith-tx  →  dry-run / apply + audit record
       │  compile                    zenith-scene + zenith-layout
       │    · resolve tokens, geometry, anchors
       │    · shape text (rustybuzz), wrap, hyphenate
       ▼
  Scene IR  (backend-neutral display list)
       │  render                     zenith-render
       ├─▶ PNG   (tiny-skia, byte-identical)
       ├─▶ SVG   (outlined text, embedded assets)
       └─▶ PDF   (vector, native CMYK, bleed / trim / crop)

  local history / undo / versions    zenith-session   (off the render path; never affects pixels)

レンダリングパスに関わるすべての処理は、決定論的で C に依存しません。時間、乱数、HashMap、unsafe、C への依存はありません。どのマシンでも、同じバイト列を入力すれば、常に同じバイト列が出力されます。

zenith validate file.zen は、デザインファイルを安全に編集し、安心して納品できるようにするためのステップです。ドキュメント向けのコンパイラーの型チェッカーのようなもので、ソースを読み取り、レンダリングや印刷の前に問題点、リスク、ブランドイメージにそぐわない点をすべて報告します。そのため、何かが壊れていないか確かめるために、エージェント（またはあなた）が「レンダリングして目視で確認する」必要はありません。

70 件以上のチェックを実行し、それぞれを、安定したコード（例：text.overflow）、人が読めるメッセージ、問題のあるノード ID、ソース内の位置を含む診断として報告します。各診断には、次の 3 種類の重大度のいずれかが割り当てられます。

実際のチェック内容は、平易に言うと次のとおりです。

• 構造と参照の解決 — すべてのノード ID が一意で、すべての参照が実在する対象を指していることを確認します。対象にはトークン参照、画像アセット、コネクターのターゲット、フィールド、マスター／セクションが含まれます（id.duplicate、token.unknown_reference、asset.unknown_reference、connector.missing_target）。リンク切れや、何も表示されないままになる誤記を検出します。
• デザインシステムの規律 — 視覚的なプロパティには、生の 16 進数ではなくトークンを使用する必要があります（token.raw_visual_literal）。これにより、ブランドの変更を 1 回の編集で行えます。また、循環参照、型の誤り、未使用のトークンも検出します（token.cyclic_reference、token.type_mismatch、token.unused）。
• はみ出しやオーバーフローの防止 — ジオメトリが指定され、キャンバス内に収まっていること、テキストが実際にボックス内に収まること、子要素がフレーム内に収まっていること、コンテンツがページの余白とセーフゾーンを守っていることを確認します（node.missing_geometry、text.overflow、text.fit_failed、frame.child_overflow、margin.violation、safe_zone.violation）。アンカーは、実在する参照フレームに解決される必要があります（anchor.unresolved_sibling、anchor.cycle）。
• 読みやすさと印刷対応 — テキストと背景のコントラストを**WCAG 3（APCA）**に照らして確認します（contrast.low）。また、PDF が実際に印刷できるよう、色空間、塗り足し、ページの偶奇を検証します（document.invalid_colorspace、page.invalid_bleed）。
• モデルの整合性 — 新しい variants、recipes、provenance ブロックもチェックし、生成物や派生物の一貫性を保ちます（variant.unknown_source、recipe.unknown_palette_token）。

重要な理由：

• 人にとって — 書き出し後ではなく、その前に「見出しがページからはみ出している」「このグレー同士の組み合わせは読みにくい」「この色はブランドトークンではない」「印刷ファイルの色空間が間違っている」といった問題を検出できます。
• エージェントにとって — zenith validate --json は、正確で機械可読な契約です。エージェントはソースを編集して検証し、変更が妥当かどうかを把握できます。これが、手を介さない編集を安心して任せるための安全網になります。

_{Zenith によるレンダリング — ソース：assets/showcase/loop.zen。}

zenith perceive page file.zen [--page N | --all-pages] [--json] は、zenith render --png と同様に、各ページをスケール 1 でレンダリングします。その後、トリムボックスを測定します（塗り足しは切り取られます）。zenith perceive vector は、代わりにソースからパスの形状を測定します。

出力はピクセルと宣言されたジオメトリを記述します。デザインの品質を判定するものではありません。根拠として読み取り、そのうえで判断してください。

インクとは、ページ上で最も多いピクセルと異なるすべてのピクセルです。

--json の読み方：

• schema は 1 です。互換性を損なう形状の変更では、この値が増えます。エンベロープにはツールのバージョンが含まれないため、リリースによってバイト列は変わりません。
• pages[].metrics.<name>.status は measured または not_applicable です。not_applicable の指標には reason が含まれます。
• clearspace には 4 つすべての余白、margin-top、margin-bottom、margin-inner、margin-outer（ページまたはドキュメント）が必要です。grid_conformance には、segment または circle ガイドを含む construction ブロックが必要です。どの指標も、しきい値や入力を独自に設定することはありません。
• 測定された各指標には、code、severity（info または warning）、message を含む diagnostics 配列があります。
• 整数以外のすべての数値は、decimals（4）で指定された桁数に、0 から遠ざかる方向へ丸められます。
• ページの測定が成功すると、終了コードは 0 になります。知覚の診断はシグナルであり、コマンドが失敗する原因にはなりません。ハードバリデーションエラーは処理を中断します。これは render の場合と同じです。

決定性：同じドキュメントからは、どのターゲットでも同じバイト列が生成されます。zenith-cli/tests/perceive_hashes.json には、Linux x64 および arm64、macOS arm64 および x64、Windows x64 で、すべての例から生成される出力が固定されています。MCP では、同じエンベロープが zenith_perceive（doc、page、all_pages）として公開されます。

1 つのデザインから複数の出力を生成する、相補的な 2 つの方法です。一方はサイズを変え、もう一方はコンテンツを変えます。

_{Zenith でレンダリング — ソース：assets/showcase/variants.zen。}

connectorは2つのノード間のセマンティック矢印です。記述されたジオメトリはありません — fromとtoにノード ID を指定すると、コンパイル時にエンジンがそれぞれの端点を、対象ノードの解決済みボックスから導出します。どちらかのボックスを動かすと、コネクターは自動的に再ルーティングされます。同じソースからは常に同じパスが生成されます。これはストロークのみのリーフで、塗りつぶしも子要素もありません。描画にはstrokeの色が必要です。

• 端点のアンカー — from-anchor / to-anchorで各端点の接続位置を指定します。シンプルなフローチャートでは名前付きグリッドアンカー（top-left、bottom、center-right）を、複数のリンクを1つの形状の周囲に配置する洗練された図では、35/60のような分割アウトラインアンカーを使います。分割アンカーは上中央から始まり、時計回りに進みます。楕円では周囲の線上を、長方形では各辺の長さに沿って配置されます。デフォルトのautoは、もう一方のボックスを向いた辺を選びます。
• ポート — ページではports { port node="agent" id="memory.vector" anchor="38/60" }のように、セマンティックな接続点を宣言できます。コネクターではfrom="agent#memory.vector"やto="store#in"のように指定できます。コンポーネントのポートはインスタンスを通じて投影されるため、connector from="agent.instance#out"は座標をコピーせずにコンポーネント内部のジオメトリに結び付いたままになります。
• ルートモード（route=）— straight（デフォルト）は直線を描画します。orthogonalは直角の折れ線を描画します。avoidは障害物を避ける直交ルーターを使い、他のノードボックスを迂回するパスを描画します（明確な経路がない場合は通常の折れ線にフォールバックします）。
• 自己ループ — fromとtoが同じノードを指定している場合、コネクターは片側に小さなループを作ります（側はアンカーから決まり、デフォルトはtopです）。
• 矢印の先端 — marker-start / marker-end = arrowで、ストロークと同じ色の塗りつぶされた矢印の先端を追加します（デフォルトはnoneです）。先端は実際にルーティングされたセグメントに沿って向きが調整されるため、軸に沿って配置されます。
• ラインジャンプ — ページレベルでline-jumps="arc"またはline-jumps="gap"を指定すると、コネクターは交差箇所で跳ね上がります。交差する線には、小さな半円状の膨らみ（arc）または途切れた隙間（gap）ができ、矢印の重なりが分かりやすくなります。動作は決定的で、水平線が垂直線を飛び越えます。ネストされたコネクターにも適用されます。指定がない場合（none / デフォルト）は、バイト単位で同一に描画されます。
• スタイル設定 — 他のプリミティブと同じプロパティ／スタイルのカスケードに従い、stroke（必須）、stroke-width、opacity、rotate、およびstyle参照を指定できます。

page id="pg" w=(px)640 h=(px)360 line-jumps="arc" {
  ports {
    port node="n.start" id="out" anchor="1/4"
    port node="n.end" id="in" anchor="3/4"
  }
  shape id="n.start"  kind="process" x=(px)40  y=(px)150 w=(px)130 h=(px)60 fill=(token)"c.node" stroke=(token)"c.line" { span "Start" }
  shape id="n.end"    kind="process" x=(px)470 y=(px)150 w=(px)130 h=(px)60 fill=(token)"c.node" stroke=(token)"c.line" { span "Finish" }
  shape id="n.block"  kind="process" x=(px)290 y=(px)130 w=(px)70  h=(px)100 fill=(token)"c.block" stroke=(token)"c.blockline" { span "Block" }

  // Auto-routed flow bends around the Block instead of crossing it…
  connector id="e.flow"  from="n.start#out" to="n.end#in" route="avoid" marker-end="arrow" stroke=(token)"c.flow"  stroke-width=(token)"cw"
  // …and where a second connector crosses it, the page's line-jumps hops it.
  connector id="e.cross" from="n.top"   to="n.bottom" marker-end="arrow"               stroke=(token)"c.cross" stroke-width=(token)"cw"
}

実行可能なドキュメントの全体例は、examples/connector-routing.zenを参照してください。

パックは名前付きのアイテムをエクスポートし、<package>#<item> で指定します。アイテムは zenith library add でドキュメントに実体化されます。アイテムには component（instance として配置されるノードグループ）、token（フィルター／マスクトークン）、action（定型のトランザクション）の3種類があります。

パックは次のいずれかの形式で保存されます。

• .zen ファイル — トークン、コンポーネント、アクションを直接記述できる、機能豊富な形式です。library の自己エントリーで独自の識別情報を宣言します。
• *.svg のディレクトリ — アイコンセット向けの、配置するだけでインストールできる形式です。各 *.svg が1つのアイコンで、その ID はファイル名（拡張子を除いた部分）です。記述作業は不要です。フォルダーを <project>/libraries/ に配置するとパックになり、@local/<dirname>#<stem> で指定できます。

SVG アイコンは追加時にネイティブの編集可能な path ノードに変換されます。不透明なラスター画像や <image> 参照として埋め込まれるわけではありません。他のジオメトリと同様に、インスタンスのオーバーライド（override ref="icon.0" stroke=(token)"brand" …）でスタイルを変更できます。変換は決定的かつ対象を限定して行われ、1つのアイコンを追加すると、そのアイコンだけが変換されます。

組み込みの @zenith/icons-lucide パックには、Lucide のアイコンセット全体（1745 個のアイコン、ISC AND MIT）が含まれています。列挙するには数が多すぎるため、検索を優先して見つけられるようにしています。

zenith library search sync                       # → refresh-cw (matched on its alias)
zenith library search arrow --category navigation
zenith library search cloud --kind component --limit 5
zenith library show  @zenith/icons-lucide#house  # format, license, aliases, tags, geometry
zenith library add   @zenith/icons-lucide#house --into poster.zen --page pg --at 40,40

検索結果は順位付けされ、単純な部分文字列検索ではありません。クエリに名前が一致するアイテムは、クエリに別名が一致するアイテムより上位になり、クエリにタグが一致するだけのアイテムよりさらに上位になります。そのため、home で検索すると lamp ではなく house が返されます。すべてのクエリ語が一致する必要があり、categories は順位付けではなく絞り込みに使われます。

アイコンと同じ場所にある任意の library.kdl で、識別情報と検索用メタデータを指定できます。指定がなくても、アイコンはファイル名で検索できます。

library id="@acme/icons" version="1.0.0" {
  license "CC0-1.0"
  icon "rocket-launch" aliases="liftoff" tags="spaceship booster" categories="space"
}

どちらの形式でも、プロジェクトのパックは、同じ ID を持つ組み込みパックより優先されます。

フラグを確認するには zenith <command> --help を実行してください（各コマンドの説明と使用例が表示されます）。すべてのコマンドで、機械可読な出力を得るための --json を指定できます。

ソースペインが正となるデータです。キャンバスには、そのテキストをエンジンでレンダリングした結果が表示されます。キャンバスでの編集（移動、サイズ変更、回転、インスペクターフィールド）は、テキストを変更するトランザクションになります。

Zenith は、レンダリング処理には一切影響しない、ドキュメントごとのローカル編集履歴を保持します。ピクセルが変化することはありません。最初の編集時に、ドキュメントには安定した識別子が付与されます。これはファイルに記録され、レンダラーからは無視される ULID の doc-id です。それ以降、エンジンによるすべての編集（tx --apply、library add、undo／redo／restore）は完全なスナップショット（操作ログではなく状態）として記録されるため、手動編集を行った場合でも履歴が保持されます。

zenith tx poster.zen recolor.json --apply   # an edit — recorded automatically
zenith undo poster.zen                       # step back, rewriting the file in place
zenith redo poster.zen                       # step forward again
zenith history poster.zen                    # list the timeline (--json for tooling)

zenith version poster.zen "launch-v1"        # save a NAMED version, kept indefinitely
zenith restore poster.zen launch-v1          # rewrite the doc to that version
zenith restore poster.zen @head~1            # …or to a revspec: v2, @head~1, @latest:named, a name

zenith sync poster.zen                        # capture an out-of-band change (GUI / hand-edit / git checkout)

履歴には 2 つの層があります。取り消し／やり直しは、一時的なセッションのタイムラインをたどる機能で、進行中の作業に適した高速なローカル操作です。名前付きバージョンは、SHA-256 と DEFLATE を使用した永続的なコンテンツアドレス指定チェックポイントで、削除するまで保持されます。restore を使うと、任意のバージョンに移動できます。エンジンの外部で行った編集を履歴に取り込み、履歴を完全な状態に保つには sync を使用します。履歴の記録はベストエフォートです。書き込みに失敗してもファイルは保存され、編集が妨げられることはありません。

Zenith には、AI コーディングエージェントに CLI の操作方法を教えるスキルが付属しています。エージェントによる作成 → 検証 → レンダリング → 編集のループ、デザインのレシピ、そして --help では伝えきれないトークン／ブランドの規律を学べます。使用するエージェントにインストールしてください。

zenith plugin install                  # auto-detect installed agents, install for your user
zenith plugin install --claude --codex # choose specific agents
zenith plugin install --all            # every supported agent
zenith plugin install --claude --scope project   # into ./ for one repo
zenith plugin list                     # see what's installed where

Claude Code、Codex、OpenCode には、完全なフォルダ形式のスキル（リファレンスパック、テンプレート、テーマ）が提供されます。その他のエージェント（Cursor、Windsurf、Aider、Zed、Gemini、Copilot、Continue、Kiro、Antigravity）には、自己文書化機能を備えた CLI を参照する、自己完結型の単一ルールファイルが提供されます。一致するファイルは変更されません。インストール済みのアセットをアップグレードするには、次のコマンドを実行します。

zenith plugin install --force

--force を指定すると、ユーザーによる変更を含む、インストール済みの異なるファイルが上書きされます。指定しない場合、異なるファイルは変更されません。インストールを削除するには、zenith plugin uninstall を実行します。

MCP サーバー（リモート／CI／ホスト型エージェント）

Model Context Protocol を通じて機能を検出するエージェント、または CI やホスト型／SaaS パイプライン向けに、Zenith は第一級の MCP サーバーとして動作します。これは単なる CLI ラッパーではありません。ツールの結果は不要な情報を省いた構造化 JSON で返され、スキーマの詳細は単一の zenith_schema ツールを使って必要に応じて取得するため、モデルがすべてのノード／操作スキーマを保持する必要はありません。大きな成果物やバイナリ成果物（レンダリング結果、大きなツリー、差分）はインラインで返されるのではなく、コンテンツアドレス指定ストアへのリソースリンクとして返されます。また、ドキュメントは doc-id で指定できるため、エージェントがパスを管理する必要はありません。作成の全工程が公開されており、zenith_schema、zenith_validate、zenith_inspect、zenith_tokens、zenith_tx、zenith_fix、zenith_render、zenith_perceive、zenith_fmt、zenith_merge、zenith_theme_new に加え、スクラッチ／候補／昇格／確定用のワークスペースツールが利用できます。ポインタースタイルの編集（ヒットテスト、ドラッグ、取り消し、ライブレンダリング）には、ブラウザーエディターで説明されている zenith_editor_* ツールを使用します。

MCP の zenith_merge は format: png|svg に対応しており、既定値は PNG です。SVG では有限の raster_scale 値を 0 < F <= 4 の範囲で指定でき、既定値は 1 です。ドキュメント単位、ローカル単位、グローバル単位のバッチポリシーが適用されます。構造化レスポンスには、コミットされたパスと部分的な行が保持されます。マニフェストの書き込みエラーが発生した場合も行数が保持され、ツールの結果はエラーとして示されます。MCP 版のツールはありません。

stdio（既定のトランスポート）で実行します。

zenith mcp

対応する MCP クライアントから接続します：

{
  "mcpServers": {
    "zenith": { "command": "zenith", "args": ["mcp"] }
  }
}

…または、Claude Code の場合：claude mcp add zenith -- zenith mcp。

リモート／ホスト型での提供。 オプションの http 機能を有効にしてビルドすると、単一の /mcp エンドポイントでネイティブの Streamable-HTTP を提供できます。トランスポートは zenith edit と同じ、上限が設定された std::net HTTP レイヤーで動作し、依存関係は追加されません：

cargo install --path zenith-cli --features http --locked
zenith mcp --http 127.0.0.1:8080     # prints the token to stderr
# test it:
curl -s -XPOST http://127.0.0.1:8080/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

ツールはファイルの読み書きを行うため、HTTP トランスポートはリクエスト本文を読み取る前に、すべてのリクエストを検証します：

• バインド。 ループバックのみです。--allow-remote を指定すると、別のアドレスからの接続を許可します。通信は平文 HTTP です。前段に TLS リバースプロキシを配置してください。
• トークン。 Authorization: Bearer <token> を使用します。トークンには ZENITH_MCP_TOKEN（32 文字以上）を使用し、設定されていない場合は起動時にランダムなトークンが生成され、stderr に出力されます。
• Host と Origin。 Host は localhost、IP アドレス、--http のホスト、または --allow-host で指定した名前である必要があります。ブラウザーの Origin は同じホストを示す必要があります。
• 本文。 Content-Type: application/json を指定し、サイズは最大 8 MiB です。
• ルート。 すべてのツールパス（ドキュメント、出力、データ、バンドル）は --root の配下に置く必要があります。デフォルトは作業ディレクトリです。stdio では --root は省略可能です。ルートを設定すると、ドキュメントが読み取るすべてのファイル（インポート、アセット、データ、ローカルの .zenith.kdl）はルートの配下に制限されます。ユーザーレベルのグローバル設定（$HOME/.config/zenith/config.kdl）とシステムフォントは制限されません。

ワークスペースストア（スクラッチ候補、バージョン履歴、レンダリング済みリソースアーティファクト）は $XDG_DATA_HOME/zenith（デフォルトでは ~/.local/share/zenith）に保存されます。分離環境やホスト型デプロイで保存先を変更するには、ZENITH_DATA_DIR を設定してください。

ローカルエージェントでは、MCP ではなく CLI とスキルを優先してください。 環境でバイナリを実行できる場合は、zenith plugin install で使い方を学習できる zenith の直接実行が最も速い方法です。リモートホスト、CI、サンドボックス、または読み取りと書き込みの全機能をプロトコル経由で利用したいホスト型／本番サービスなど、バイナリを実行できない環境では MCP サーバーを使用してください。そうした用途では、このサーバーが第一級の選択肢です。

リポジトリには server.json（MCP レジストリマニフェスト）が含まれています。手動の MCP の公開 ワークフローでは、選択した安定版タグに対応する npm ランチャーとレジストリエントリを公開します（GitHub OIDC を使用するため、レジストリトークンは不要です）。これにより、Zenith は MCP ディレクトリから見つけられるようになり、クライアントは npx -y @zenitheditor/zenith-mcp から起動できます。

• MCP レジストリ名：mcp-name: io.github.zenitheditor/zenith

各クレートは単一の関心事を担い、安定した契約を公開します。zenith-geometry は他の Zenith クレートに依存しません。zenith-core は、これらのうち zenith-geometry のみに依存します。

Zenith ファイルは単なるテキストなので、コードと同じ場所に置けます。git にコミットできます。プルリクエストでデザインの変更を差分と並べてレビューできます。CI でレンダリングして、リリース前にレイアウトの崩れを検出できます。パイプラインでバリエーションを生成できます。他のファイルと同じようにロールバックできます。デザインは、エクスポート先とエクスポート元を持つ別世界ではなく、ビルドの一部になります。

• スクリーンショットを頼りに祈るのではなく、ビジュアルを確実に生成・編集したい AI およびエージェントの開発者。
• リポジトリにデザインアセットを置き、PR でレビューし、CI でビルドしたい エンジニアリングチーム。
• 正確なバリエーションを大量に必要とする 大量生産を行う担当者（マーケティング、出版、ローカライズ）。
• クローズドなクラウド API ではなく、オープンフォーマットを基盤に構築したい ツール開発者。

公開ショーケースは zenitheditor/zenith-showcase にあり、zenith-showcase サブモジュールとしてここからリンクされています。

ここには、再利用可能な Zenith のサンプルを掲載しています。.zen ソース、レンダリング結果、ビジュアルレシピ、アクション、フィルター、背景、ポスター、チラシ、書籍、雑誌、広告、図表、プレゼンテーション、その他の生成されたデザイン作品が含まれます。

ショーケースには、共有する権利があり、提出したソース、出力、アセットを、明記されたライセンスの下で他の人が再利用することを許可できるファイルのみを掲載してください。非公開の作品、クライアント向けの作品、ポートフォリオ限定の作品、または独自ライセンスの作品は、ショーケースの外部ギャラリーからリンクしてください。外部作品のライセンスは、引き続き所有者が管理します。