序章 · 这本魔典是什么

xrune 是一台符文刻录引擎。

你递给它一段咒文（写在 ui! { … } 里的声明式 DSL），它在编译期解读这串咒文的形状，把它转写成符文，再让你绑定的符文师（rune，即一个 DsRune 实现）把这些符文刻录到具体的代码上。最后封印（seal）一道，整段咒文凝结为一段可被宿主直接吸收的 TokenStream。

这套切分就是整个设计的全部。同一段咒文，可以被刻录成 ECS spawn 调用，可以被刻录成渲染树构建器，可以被刻录成调试用的回响打印，也可以经由格式化器原样回环。决定它变成什么的不是咒文本身，而是你绑了哪一位符文师。

咒文不知道「部件」是什么。咒文只认形态。

何时召请 xrune

宿主已有自己的组件、状态、渲染机关，要在上层叠一层好用的咒文，但不愿把咒文跟某种类型系统绑死。
多位符文师需要共用同一套咒文（譬如：一位 ECS 运行时符文师 + 一位誊章符文师 + 一位静态分析符文师，三者同念一段咒）。
渲染目标尚未敲定，但表层咒文先要立起来。

如果你的 DSL 需要在编译期就对部件名、属性键作类型检查，请改投 typed-builder 风格的咒法。xrune 把所有语义全数交托给符文师。

五位符文师与一座中枢

子典	名号	司掌
`xrune`	—	入口卷轴。读者只需直接召请这一卷，它会把 `xrune-nexus` 与 `ui!` 两道咒符一并取出。
`xrune-nexus`	中枢	AST 节点（`Ds*` 一族）、`DsRune` 师契、`decipher` 遍历器，全在此卷。
`xrune-incant`	咒坛	`ui! { … }` 这道过程宏咒符的本体。
`xrune-sigil`	印玺	`DsRef` derive 宏，为 AST 锻造 `Rc<RefCell<>>` 的引用印记。
`xrune-fmt`	誊章	CLI 工具，把 `ui! { … }` 整段经真实的咒文 parser 来回誊写一次，确保形态无走样。

五卷同住一座 cargo workspace，版本同行同步：每次发版，五卷一齐推到同一道 X.Y.Z 版号。

命名契约

xrune 的词系偏中世纪魔法，因为架构本身就长这副样子：一咒多译。读者第一次撞见某个陌生词，去附录 · 术语对照查一次，往后应当不必再翻字典。最短摘要如下：

rune（符文师）：一个 DsRune 实现，亦即一种后端。
decipher（译咒）：遍历函数，遍历 AST，把每个节点喂给符文师的 inscribe（刻录） 方法。
inscribe（刻录）：符文师在每个节点上落笔的动作。
seal（封印）：遍历走完，符文师将累积之物收束为最终发出的 TokenStream。

整个概念面就这些。其余诸词，sigil（印记）、niche（壁龛）、enchant（附魔）、walk（巡历）、on（事件咒符），都是咒文形态的具体一支，后续章节逐个揭。

这本魔典如何编排

第一卷 · 初次施咒 从 cargo new 起，直到看见 decipher 真正跑起来，并罗列每一种咒文形态。
第二卷 · 内里机关 解读 AST 节点，并教你亲手锻造一位自己的符文师。
第三卷 · 外用之器 讲誊章与工坊（workspace）本身。
第四卷 · 流变与典故 记跨版本的形态演化，以及 xrune 与相邻 DSL 思路的对照。

附录是逐词对照的术语表与公开 API 索引。

体例约定

代码块默认皆为可 copy-paste 即跑的真实 Rust，例外会就地标注。少数仅为演示 ui! parser 输出、不挂宿主环境的代码块，现场会标。
类型名、错误消息、CLI 文本一律自源码引用，不作转译。