
AINDF
io.github.0designv0.2.1更新於 Oct 8, 2026
Read-only MCP server for one AINDF design-system bundle: look up what it offers, validate screens.
概覽
唯讀 MCP 伺服器,公開單一 AINDF 設計系統 bundle,讓助理查詢元件、插槽、修飾符與預設集,並驗證畫面。
- 功能
- 透過 stdio 提供單一 AINDF 0.2 設計系統 bundle。唯讀介面列出七個工具:list-by-facet、slot-accepts、applicable-modifiers、get-preset、get-ds、get-component 與 validate-screen。助理可據此檢視設計系統提供的內容,並對照它檢查 ScreenSpec。submit-screen、request-extension 等暫存類工具只由具備暫存能力的端點提供,本機伺服器不含。
- 適用情境
- 當助理需要針對某個 AINDF 設計系統撰寫或審查畫面,且應看到真實的元件、插槽、修飾符與預設集契約而非憑空猜測時使用。適合使用該套件產生 bundle 的畫面作者與設計系統維護者。
- 執行需求
- 以 stdio 程序在本機執行,透過 aindf mcp 指令並指定 bundle 檔案啟動。套件從 npm 安裝為 @ai-native-design-framework/kit,需要 Node.js(CI 在 Node 20 與 22 上執行)。未宣告驗證、環境變數或標頭。僅限桌面端,無網頁可執行版本。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 AINDF,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
@ai-native-design-framework/kit — the AINDF 0.2 kit
One dependency-free package for any design system that conforms to AINDF (conformsTo: "[email protected]"):
v0.2 additions to the public AINDF 0.1 contract graph: components (closed prop/slot/state contracts, templates),
bindings (named data/action adapters implemented by the DS), screen (the only author artifact), receipt, config.
MCP surface: AINDF 0.1 list-by-facet, slot-accepts, applicable-modifiers, get-preset plus get-ds,
get-component, validate-screen, submit-screen and request-extension. The last two are offered only by an
endpoint with staging (e.g. a hosted DS-MCP), need an author token and only stage unaccepted drafts; a read-only
endpoint such as aindf mcp lists 7 tools, and an agent reports the need or the validated ScreenSpec to the user.
Every tool carries a title and MCP hints (readOnlyHint, destructiveHint, idempotentHint, openWorldHint).
The kit contains no design system; its tests run against a small fixture design system kept in the repository. Limits: a builder receipt is not a signature; verified/accepted/released are never written by the kit; isolation of the author principal comes from deployment rights, not from this package.
Clean install: the repository's packages/aindf-kit/scripts/clean-install.mjs (source)
packs this package, installs the tarball into an empty project and uses it only as a consumer would — the aindf bin
(check, bundle, build, --check), the package exports and the MCP over stdio — each step with a negative. CI runs it on
Node 20 and 22 and prints the tarball sha256 and kit version it checked.
Instance on Core (ds.core + ds.coreBundle + ds.coreBundleSha256, 0.2.0)
An Instance that extends a Core pins it in aindf.config.json three ways: ds.core (id@version), ds.coreBundle
(path to that Core's AINDF bundle) and ds.coreBundleSha256 (the bundle's content hash; a self-consistent bundle with the
same id@version but other contracts is refused). Generated screens import from one module only — the Instance's
implementation.module — so a Core role a screen needs (Input, DialogPanel …) is provided by the Instance under the same
contract name, implemented with the Instance's look. aindf check then holds that contract to the Core one: it must
accept every prop value the Core contract accepts —
- every Core prop stays, with its type, required exactly where Core requires it;
- every enum value, allowed binding, rich-text mark and inline component stays (the Instance may add more);
- limits are no tighter:
maxLength,minItems/maxItems,minimum/maximum; the link pattern is the Core one; - every Core slot prop stays; props the Core role does not have are optional;
- the role keeps its place in a screen: a Core template stays a template,
routeParamsis not added, the taxonomy layer is the Core one, every Core slot exists with a cardinality no tighter; slots the Core role does not have are optional (min 0); - every Core component exists in the Instance (contract and taxonomy), every Core binding by name; a
paramsordatabinding keeps its kind (a screen uses it as$.params/$.meta), anactionbinding may change kind (props name it).
What this guarantees: a screen written for Core — its components, props, where they stand, which slots they fill and how
many children, its bindings — admits against the Instance unchanged, with one exception on purpose: what a slot
accepts is judged by the Instance's own slotsets (their accepted components are Instance components), so a narrower
accepts can still reject a Core screen with SLOT_REJECTS. That is not checked here.
coreConformance(config, components, core, { taxonomy, slots, bindings }): props, slotProps, template, routeParams and
the Core component list are checked from components alone; the taxonomy layer and presence, slots and bindings only when
that source is passed. checkDs passes all of them.
Codes: CORE_PIN (AINDF-DS-29) when the bundle is not the pinned one; CORE_CONFORMANCE (AINDF-DS-30) per narrowed prop,
moved role, narrowed or new required slot, missing component or binding. Without ds.coreBundle nothing changes.
來源:packages/aindf-kit/README.md,提交 c9a6cb9
工具
0版本歷史
1- v0.2.1最新Oct 8, 2026


