AINDF

@ai-native-design-framework/kit — AINDF 0.2 キット

AINDF（conformsTo: "[email protected]"）に準拠するあらゆるデザインシステム向けの、依存関係のない単一パッケージです：

コマンド	役割	実行内容
aindf check <aindf.config.json>	DS メンテナー	準拠性：ソースが固定された AINDF 0.1 スキーマ（schema/0.1、SHA256SUMS）および v0.2 の追加分（schema/0.2）に対して検証され、スロット/修飾子/プリセットのエッジにぶら下がりがなく、レイヤールール、下方向のみのトークン、閉じた props（className/style/children/ハンドラーなし）、バインディングが解決されることを確認します。
aindf bundle <config> --out <file>	DS メンテナー	不変でコンテンツアドレス指定された DS リビジョン（bundleSha256）。スクリーンはこれを固定し、MCP がこれを提供します。
aindf build <config> --screens <dir> --app <dir> [--check]	信頼されたビルダー	すべての *.screen.json を受け入れ、Next.js App Router ページ（// @generated）を生成します。--check は手動編集、古いスペック、DS の変更、孤児に対して失敗します。書き込むのは built レシートのみです。
aindf mcp <bundle.json>	スクリーン作成者	stdio MCP。createDsMcp + mcpFetchHandler がエッジランタイム上で同じサーバーを実行します。

公開 AINDF 0.1 コントラクトグラフへの v0.2 の追加分：components（閉じた prop/スロット/状態コントラクト、テンプレート）、 bindings（DS によって実装される名前付きデータ/アクションアダプター）、screen（唯一の作成者向け成果物）、receipt、config。 MCP サーフェス：AINDF 0.1 の list-by-facet、slot-accepts、applicable-modifiers、get-preset に加えて get-ds、 get-component、validate-screen、submit-screen、request-extension。最後の 2 つはステージングを備えた エンドポイント（例：ホスト型 DS-MCP）のみが提供し、作成者トークンが必要で、未承認のドラフトのみをステージングします。aindf mcp のような 読み取り専用エンドポイントは 7 つのツールを一覧表示し、エージェントは必要性または検証済みの ScreenSpec をユーザーに報告します。 すべてのツールは title と MCP ヒント（readOnlyHint、destructiveHint、idempotentHint、openWorldHint）を備えています。

このキットにはデザインシステムは含まれていません。そのテストはリポジトリ内に保持された小さなフィクスチャデザインシステムに対して実行されます。 制限：ビルダーレシートは署名ではありません。verified/accepted/released がキットによって書き込まれることはありません。作成者プリンシパルの分離は このパッケージではなく、デプロイ権限からもたらされます。

クリーンインストール：リポジトリの packages/aindf-kit/scripts/clean-install.mjs（ソース）は このパッケージをパックし、tarball を空のプロジェクトにインストールし、消費者が使うようにのみ使用します — aindf bin （check、bundle、build、--check）、パッケージエクスポート、stdio 経由の MCP — 各ステップにネガティブテストがあります。CI はこれを Node 20 と 22 で実行し、チェックした tarball の sha256 とキットバージョンを出力します。

Core 上のインスタンス (ds.core + ds.coreBundle + ds.coreBundleSha256、0.2.0)

Core を拡張するインスタンスは、aindf.config.json 内で 3 つの方法によりその Core を固定します。ds.core (id@version)、ds.coreBundle (その Core の AINDF バンドルへのパス)、そして ds.coreBundleSha256 (バンドルの内容ハッシュ。同じ id@version を持ちながら 他のコントラクトを持つ自己矛盾のないバンドルは拒否されます) です。生成される画面は 1 つのモジュール — インスタンスの implementation.module — からのみインポートするため、画面が必要とする Core のロール (Input、DialogPanel など) は、 同じコントラクト名の下でインスタンスによって提供され、インスタンスの見た目で実装されます。その後 aindf check が、そのコントラクトを Core のものに対して検証します。すなわち、Core のコントラクトが受け入れるすべての prop 値を受け入れなければなりません —

• すべての Core の prop がその型とともに残り、Core が必須とする箇所で正確に必須となります。
• すべての enum 値、許可されたバインディング、リッチテキストマーク、インラインコンポーネントが残ります (インスタンスはさらに追加してもよい)。
• 制限はより厳しくなりません。maxLength、minItems/maxItems、minimum/maximum。リンクパターンは Core のものです。
• すべての Core のスロット prop が残ります。Core のロールが持たない prop は任意です。
• ロールは画面内での位置を保ちます。Core のテンプレートはテンプレートのままであり、routeParams は追加されず、タクソノミー層は Core のものであり、すべての Core のスロットがより厳しくないカーディナリティで存在します。Core のロールが持たないスロットは任意 (最小 0) です。
• すべての Core のコンポーネントがインスタンス内に (コントラクトとタクソノミーにおいて) 存在し、すべての Core のバインディングが名前によって存在します。params または data バインディングはその種類を保ち (画面はそれを $.params / $.meta として使用します)、action バインディングは種類を変更してもよい (props がそれを名指しします)。

これが保証するもの: Core 向けに書かれた画面 — そのコンポーネント、props、それらがどこに位置するか、どのスロットを埋めるかと 子の数、そのバインディング — は、インスタンスに対しても変更なしで通ります。ただし意図的な例外が 1 つあります。スロットが 受け入れるものはインスタンス自身のスロットセットによって判定されるため (それらが受け入れるコンポーネントはインスタンスのコンポーネントです)、より狭い accepts は SLOT_REJECTS で Core の画面を依然として拒否する可能性があります。それはここではチェックされません。

coreConformance(config, components, core, { taxonomy, slots, bindings }): props、slotProps、template、routeParams および Core のコンポーネント一覧は components のみからチェックされます。タクソノミー層と存在、スロットおよびバインディングは そのソースが渡された場合にのみチェックされます。checkDs はそれらすべてを渡します。

コード: CORE_PIN (AINDF-DS-29) はバンドルが固定されたものでない場合。CORE_CONFORMANCE (AINDF-DS-30) は狭められた prop、 移動されたロール、狭められたまたは新たに必須となったスロット、欠落したコンポーネントまたはバインディングごとに。ds.coreBundle がなければ何も変わりません。