DECIDED

XiForge 架构提案 v1.2

变更摘要(v1.1 → v1.2 · 重大简化): 1. xml-tuning 子系统整体退役(用户产品决策)— 从"两套并行控件库合并"变为"单一 widget 体系 + 删除 xml 临时桥" 2. ModuleMode 4 mode → 2 mode 简化:builtin_normal/builtin_legacy/dsp_normal/dsp_legacy → normal | legacy(用户语义定义) 3. legacy / native 概念统一:def.kind='legacy/native' 删除 · 用 ModuleDef.mode 替代 4. codegen 边界明确:mode='legacy' 模块只产 HMI · 不参与 codegen · 不参与 simulation 5. 决议总数从 7 项精简为 6 项(决议 3 控件清单更新 · 决议 8 新增 xml 退役 · 决议 9 新增 mode 简化)

本文目的:基于 v1.1 + 用户产品决策,出最终落地版方案,等待最后一次确认后即可起 ADR-AIOS-04 + 实施 PROMPT。

---

0. 用户决策记录(三轮对话核心结论)

0.1 用户原话精简版

轮次	决策点	用户原话
第 1 轮	Q1 控件库	"MC 控件要全面 · 是否构建全部 vs 用户自定义上传(Vue 代码)"
第 1 轮	Q2 codegen	"set/get 接口能否从 HMI 自动生成 · preset 结构是否能自动生成"
第 2 轮	L1/L2/L3 校准	"TTSlider 是 L1 · L2 是 JSON 复合 · L3 是用户上传公司编译"
第 2 轮	Module UID	"modulename + 32 位 ModuleID · xistudio 0~0xAAAA0000 · xivst 三方在后"
第 3 轮	xml 退役	"xml 是 C# 调音工具临时桥 · 现在直接 MC 中创建 legacy 界面 · 可以删除"
第 3 轮	legacy 边界	"创建 module 时指定 legacy 还是 normal · legacy 没有源码生成 · 只是调音兼容"
第 3 轮	mode 简化	"normal 和 legacy 其实就是带链路信息还是不带链路信息直接发 command 进行调音而已"

0.2 关键产品定义(用户原话)

normal 模块 = 带链路信息(参数走 set_params 协议 · 通过 link 路由)

legacy 模块 = 不带链路信息(参数走 legacy_set_param + PID 直接寻址 · 兼容旧 DSP 固件)

legacy 模块不参与 codegen / simulation · 只为兼容旧调音内容

0.3 决策汇总表(v1.2 落地版)

决议	选择	状态
Q1 控件库策略	方案 C 三层(L1/L2/L3)	✅ 已确认
Q2 codegen 方向	方向 X 单向驱动	✅ 已确认
Module UID 命名空间	32 位 + vendor + 段位划分	⏳ 待最终确认
xml-tuning 整体退役	彻底删除 · 不留兼容	✅ 已确认
ModuleMode 简化	方案 B · 2 mode(normal/legacy)+ source 独立	✅ 已确认
codegen 边界	legacy 模块跳过 codegen + simulation	✅ 已确认
L3 实施路径	推迟决议 · 本季度不做	✅ 已确认

---

1. 当前 XiForge 实际能力盘点(真值 · v1.2 修正)

1.1 已有的扎实基础(v1.1 复用)

模块	行数	能力
ModuleCreator.vue	4575	MC 主功能 · 与 xml 子系统耦合极弱(仅 1 行 xmlStore.setAppMode('normal'))
components/TT*.vue	10 文件	将成为 v1.2 唯一控件库(L1)
types/module.ts	11633 字节	ModuleDef 主类型 · ⚠️ L4 import XmlWidgetDef · ⚠️ L78 widgets?: XmlWidgetDef[](必须迁移)
stores/presetStore.ts	168	Preset CRUD 已就绪
utils/wsClient.ts	-	控件 → store → ws 数据下发链路

1.2 v1.2 退役清单(整体删除 · 不留兼容)

文件/目录	行数估算	退役理由
src/stages/xitune/xml-tuning/ 整目录	2586	C# XML 临时桥 · 用户决策退役
src/stores/useXmlTuningStore.ts	-	xml session 状态管理 · 同退役
src/utils/xmlConfigParser.ts	-	XML 文件解析器 · 用户不再需要
src/types/xmlTuning.ts	7047 字节	类型迁移到新 widget.ts 后删除
public/xml-configs/ 数据目录(若存在)	N legacy json	legacy 模块改在 MC 中重建

1.3 v1.2 退役后的修改清单(类型迁移 + 解耦)

文件	修改内容
types/widget.ts(新建)	从 xmlTuning.ts 提取 XmlWidgetDef → 重命名 WidgetDef + XmlWidgetType → WidgetType(去 Xml 前缀)
types/module.ts L4/L78	import 改 from '@/types/widget' · widgets?: WidgetDef[]
MenuBar.vue L139/148/230/517/518/568	删除 appMode='xml_tuning' 切换菜单 + 相关分支
xilink/ModuleLibraryPanel.vue L21/133/214/219/227/246	删除 xml_tuning 模式分支
xilink/index.vue L75/88	删除 xmlStore 引用
ModuleCreator.vue L1832/1844/2874	删除 3 行(xmlStore import + 实例化 + setAppMode)
ThirdPartyModuleDialog.vue	删除 def.kind 分支(legacy/native 二元) · 改为统一走 ModuleDef.mode + 新 WidgetGroupLayout
xitune/PresetPanel.vue L128/140	删除 xmlStore 引用
xitune/GenericTuningDialog.vue	检查 legacy_set_param 调用 · 保留(协议层不动)
useModuleDefStore.ts	注释清理 + ModuleMode 类型简化

1.4 ⚠️ 必须保留(不在退役范围内)

项目	保留理由
legacy_set_param 后端协议消息	6+ 文件在用 · 这是调音协议层 · 与 xml 子系统无关
mode='legacy' 概念	用户产品定义保留(不带链路信息直接发 command)
ThirdPartyModuleDialog 的 PID 寻址路径	legacy 模块仍走 PID + legacy_set_param
XmlWidgetDef 类型定义本身(50+ 字段)	类型保留,只是从 xmlTuning.ts 迁移到 widget.ts + 改名

---

2. Q1 答复 · 控件库策略(v1.2 简化版)

2.1 三层定义(v1.1 不变 · 此处摘要)

• L1 = 编译型原子控件(Vue SFC · components/TT*.vue)
• L2 = 配置型复合控件(JSON 描述 · 多个 L1 + 布局 + 联动 · 不写代码)
• L3 = 用户扩展控件(本季度不做 · 推迟决议)

2.2 v1.2 控件体系架构(单一路径 · 不再分裂)

┌─────────────────────────────────────────────────┐
│  统一 widget 渲染层                                │
│  src/widgets/ (新建 · 替代 xml-tuning/widgets/)    │
│                                                  │
│  WidgetGroupLayout.vue (替代 XmlWidgetGroupLayout) │
│         ↓                                        │
│  WidgetRenderer.vue (替代 XmlWidgetRenderer)      │
│         ↓                                        │
│  registry.ts (widget 类型注册表 · 替代 v-if 链)    │
│         ↓                                        │
│  L1 原子控件:                                     │
│  - components/TT*.vue (10 个 · 现状)              │
│  - 补齐到 30 种(决议 3)                           │
└─────────────────────────────────────────────────┘
                  ↑
                  │ ModuleDef.params.properties.widgets: WidgetDef[]
                  │
       ┌──────────┴──────────┐
       ↓                     ↓
  ModuleCreator.vue    ThirdPartyModuleDialog.vue
  (MC 编辑模式)        (调音运行时)

2.3 P-1 任务重新定义(v1.2 替代 v1.1 的 TT/Xml 合并)

v1.2 P-1 任务清单(不再是"合并",而是"清理 + 统一"):

1. 类型迁移(0.5d):
2. 新建 src/types/widget.ts
3. 从 types/xmlTuning.ts 提取 XmlWidgetDef → 重命名 WidgetDef
4. XmlWidgetType → WidgetType(去 Xml 前缀)

5. 修改 types/module.ts 的 import 路径

6. 新建统一 widgets 目录(0.5d):

7. src/widgets/(新)
8. 移动 + 重命名:XmlWidgetGroupLayout.vue → WidgetGroupLayout.vue
9. XmlWidgetRenderer.vue → WidgetRenderer.vue(改造为 widget 注册表 + 动态组件路由)

10. 5 个 XmlXxxWidget 暂保留(在 P0 阶段逐个被 TT* 替换 · 或合并为单一实现)

11. 删除 xml 临时桥(1d):

12. 删除 src/stages/xitune/xml-tuning/ 整目录(8 文件 2586 行)
13. 删除 src/stores/useXmlTuningStore.ts
14. 删除 src/utils/xmlConfigParser.ts
15. 删除 src/types/xmlTuning.ts(类型已迁移)
16. 删除 public/xml-configs/ 数据目录(若有 · 用户确认 legacy 模块改在 MC 中重建)

17. 修改 9 处外部引用(MenuBar / ModuleLibraryPanel / ModuleCreator / ThirdPartyModuleDialog / xilink/index 等)

18. ThirdPartyModuleDialog 简化(0.5d):

19. 删除 def.kind: 'legacy' | 'native' 二元分支
20. 改为统一走 ModuleDef.mode: 'normal' | 'legacy' 判断协议路径(set_params vs legacy_set_param)
21. UI 层都用 WidgetGroupLayout 渲染

P-1 总工作量:2.5d(原 v1.1 估算不变 · 但任务变成清理而非合并)

2.4 P0 任务定义(在 P-1 之上)

1. widget 注册表正式化(0.5d):
2. src/widgets/registry.ts · API:registerWidget(type, component) / getWidget(type)

3. 内置 30 种类型注册(L1 清单)

4. L1 控件清单评审 + 补齐(0.5d):

5. 评审决议 3 的清单

6. 缺失的控件用 TT* 风格补齐(可放后续 sprint)

7. Module UID 命名空间落地(2d):

8. 见 §3.6(v1.1 不变)

P0 总工作量:3d

2.5 推荐方案:单一控件库 + 渐进补齐 + UID 落地

阶段	内容	工作量
P-1(必做 · 1 周内)	xml 退役 + 类型迁移 + 渲染器去 Xml 前缀	2.5d
P0(必做 · 1 周内)	widget 注册表 + L1 控件评审 + Module UID	3d
P1(必做 · 2 周内)	code mode codegen + Preset Schema 自动派生	3d
P2(下季度)	code mode UI(Monaco)+ simulation 简化版	4.5d
P3(下季度后)	L2 复合控件机制	8d
P4(明年视生态)	L3 实施(A 或 B)	推迟

Phase 1 (P-1 ~ P1) ≈ 8.5d · 双 agent(ClaudeB + ClaudeC)并行 ≈ 5-6 天

---

3. Q2 答复 · 代码生成 + Preset 联动 + Module UID 命名空间 + legacy 边界(v1.2)

3.1 v1.2 关键边界:legacy 模块不参与 codegen

用户产品定义:

normal 模块 = 带链路信息(set_params 协议) legacy 模块 = 不带链路信息(legacy_set_param + PID) legacy 模块只为兼容旧调音内容 · 不参与 codegen / simulation

实施约束(必须写入 PROMPT 和 ADR):

// codegen 工具应该这样判断
function shouldGenerateCode(def: ModuleDef): boolean {
  return def.mode === 'normal'  // legacy 模块跳过
}

// XiForge 3 mode chip 的可见性
{
  layout:     true,                          // 所有模块都有
  code:       def.mode === 'normal',         // 仅 normal 模块
  simulation: def.mode === 'normal'          // 仅 normal 模块
}

3.2 ⭐ ModuleMode 简化方案(v1.2 新增 · 用户决策方案 B)

3.2.1 当前问题(types/module.ts)

// 当前 4 mode 矩阵(v1.1)
export type ModuleMode = 'builtin_normal' | 'builtin_legacy' | 'dsp_normal' | 'dsp_legacy'

加上 ThirdPartyModuleDialog 的 def.kind: 'legacy' | 'native' · 总共 3 套术语并存,语义重叠。

3.2.2 v1.2 简化方案(用户方案 B · 2 mode + source 独立)

// v1.2 简化版
export type ModuleMode =
  | 'normal'    // 带链路信息 · 走 set_params 协议
  | 'legacy'    // 不带链路信息 · 走 legacy_set_param + PID

// ⚠️ 注意:source 字段含义改变(从原来的 'library' | 'backend_json' 扩展)
export type ModuleSource =
  | 'builtin'      // XiStudio 内置(取代旧 'library')
  | 'backend'      // 后端推送 JSON(取代旧 'backend_json')
  | 'thirdparty'   // 三方插件(L3 用)

export interface ModuleDef {
  mode: ModuleMode              // ✅ 简化为 2 mode
  source: ModuleSource          // ✅ 取代旧 'library' | 'backend_json'

  // ⚠️ 删除字段:
  // (旧 ThirdPartyModuleDialog 的 def.kind 不再存在)

  // 其他字段不变
  id: string
  displayName: string
  uid: number                   // v1.1 新增 · UID 命名空间
  vendor: VendorTag             // v1.1 新增
  // ...
}

3.2.3 创建模块流程(v1.2 简化)

XiForge 创建模块时,用户在第 1 步选择 mode:

[ 创建模块 ]
   ↓
┌────────────────────────────────┐
│ 第 1 步:模块类型               │
│  ☑ Normal(走 set_params 协议) │
│  ☐ Legacy(走 PID + 兼容旧固件) │
└────────────────────────────────┘
   ↓ 选 normal           ↓ 选 legacy
┌──────────────┐    ┌──────────────┐
│ 完整 3 mode:  │    │ 仅 layout:    │
│ - layout HMI │    │ - layout HMI │
│ - code .h 生成│    │ (无 code)    │
│ - simulation │    │ (无 simulation)│
└──────────────┘    └──────────────┘

3.2.4 数据迁移脚本(P-1 阶段必做)

// migrate-module-mode.ts(伪代码)
function migrateMode(oldMode: string): { mode: ModuleMode, source: ModuleSource } {
  switch (oldMode) {
    case 'builtin_normal': return { mode: 'normal', source: 'builtin' }
    case 'builtin_legacy': return { mode: 'legacy', source: 'builtin' }
    case 'dsp_normal':     return { mode: 'normal', source: 'builtin' }  // dsp 视为 builtin 的子类
    case 'dsp_legacy':     return { mode: 'legacy', source: 'builtin' }
    default: throw new Error(`Unknown mode: ${oldMode}`)
  }
}

// def.kind 迁移
function migrateKind(kind: 'legacy' | 'native'): ModuleMode {
  return kind === 'legacy' ? 'legacy' : 'normal'
}

⚠️ 注意:用户问到 "目前看不区分 dsp 还是 builtin,没有这个需求了" — v1.2 实施时把 dsp_* 也归并到 source='builtin',不区分。如未来再有需求(如客户定制硬件 DSP),再扩展 source 字段。

3.3 三个候选方向(代码生成方向 · v1.0 不变)

方向	说明	推荐度
方向 X	HMI 单向驱动代码	⭐⭐⭐⭐⭐
方向 Y	代码单向驱动 HMI	⭐⭐
方向 Z	双向同步	⭐

(详细对比见 v1.0 · 此处省略)

3.4 Preset 自动 vs 手写边界

推荐方案:
  Preset 数据结构 = HMI 自动派生(用户不写 schema)
  Preset 实例值 = 用户在 XiTune 中调试调音得出 + 手动收藏

⚠️ legacy 模块的 Preset:
  schema 仍可自动派生(基于 ModuleDef.params)
  但实例值仍走 legacy_set_param + PID(运行时协议层不变)

3.5 推荐:方向 X · HMI 单向驱动 + Preset 自动 schema · normal 模块限定

                   ┌─────────────────────────┐
                   │  XiForge HMI 设计(SSOT)  │
                   │   ModuleDef + params    │
                   │   if (mode === 'normal')│ ← 边界
                   └────────┬────────────────┘
                            │ 一键生成
        ┌───────────────────┼────────────────────┐
        ↓                   ↓                    ↓
   ┌──────────┐       ┌──────────┐         ┌──────────┐
   │ .h 头文件 │       │ Preset   │         │ XiTune   │
   │ set_xxx  │       │ Schema   │         │ 调音界面  │
   │ get_xxx  │       │ (自动)   │         │ (运行时) │
   └────┬─────┘       └──────────┘         └────┬─────┘
        │ 用户实现                                 │ 用户调音
        ↓                                        ↓
   ┌──────────┐                            ┌──────────┐
   │ .cpp 算法 │                            │ Preset   │
   │ (人工)   │                            │ 实例值   │
   └──────────┘                            └──────────┘

   ⚠️ legacy 模块 → 跳过整个 codegen + simulation 流程 · 仅做 HMI

3.6 Module UID 命名空间方案(v1.1 不变 · 此处摘要)

(完整设计见 v1.1 §3.6)

• 32-bit unsigned int · 高 16 位 = vendor · 低 16 位 = 模块号
• 0x00000000 ~ 0x0000FFFF → XiStudio 内置基础库(子段细分 source/sink/filter/...)
• 0x00010000 ~ 0xAAA9FFFF → XiStudio 扩展
• 0xAAAA0000 ~ 0xFFFEFFFF → XiVST 三方厂商(每家 65536 个 · 共 21845 家)
• 全局唯一标识:vendor:id@uid(如 xistudio:gain@0x00000200)

---

4. 实施优先级路线图(v1.2 最终版)

优先级	任务	工作量	依赖	价值
P-1	xml-tuning 退役 + 类型迁移 + 渲染器去 Xml 前缀 + ThirdPartyModuleDialog 简化	2.5d	无	单一控件体系前置
P0	widget 注册表 + L1 控件清单评审	1d	P-1	解锁后续扩展
P0	ModuleMode 简化迁移(4→2 + source 独立 + 数据迁移脚本)	1d	P-1 类型	contract 简化
P0	Module UID 命名空间落地(types + 协议 + 迁移脚本)	2d	无	contract-v1 freeze 前必须
P1	code mode codegen 起步(C 头文件模板 · normal-only)	2d	ModuleDef + UID + mode	实现 demo code chip
P1	Preset Schema 自动派生(支持 legacy + normal)	1d	presetStore + UID	闭环 HMI → Preset
P2	code mode UI(Monaco editor 嵌入)	1.5d	P1	用户可见
P2	XiForgeSimView 简化版仿真(信号生成 + 滤波 · normal-only)	3d	DSP 后端	实现 demo simulation chip
P3	L2 复合控件模板机制	8d	P0 注册表	视客户反馈
P4	L3 实施(路径 A 或 B)	推迟	决议推迟	战略级

总计 Phase 1 (P-1 ~ P1) ≈ 9.5d · 双 agent 并行 ≈ 5-6 天

---

5. 待人类拍板的关键决议(v1.2 最终版)

决议 1 · Q1 控件库策略 ✅ 已确认

• ☑ 方案 C 三层(L1 编译 + L2 配置 + L3 上传)

决议 2 · Q2 代码生成方向 ✅ 已确认

• ☑ 方向 X 单向驱动(HMI 是 SSOT)

决议 3 · L1 核心控件清单(待确认 · 评审用)

v1.2 退役 xml-tuning 后,L1 = TT 系列(10 个) + 5 个 XmlXxxWidget 改造(去 Xml 前缀整合) ≈ 15 个去重后: - 现状(15):Slider / Toggle / Button / Label / GGEQ / Mixer / Tabs / ComboBox / EQ / ProgressBar / ChartTable / LabelComboBox / ButtonRenamed / TabRenamed / ComboBoxRenamed - 建议补齐到 30 的候选(15)*:TextBox / NumberBox / RadioGroup / Checkbox / ColorPicker / FileSelect / ChartLine / ChartBar / ChartSpectrum / ChartWaveform / Table / Tree / Accordion / Divider / Image

问:这 15 种候选是否合适?是否还有客户必须的特殊 DSP 控件?

决议 4 · 是否起 ADR-AIOS-04? ✅ 已确认

• ☑ 起 ADR(包含三层控件 + UID + codegen + xml 退役 + mode 简化)

决议 5 · code mode + simulation mode 是否本季度?

• ☐ 仅本季度补 code mode
• ☐ 本季度同时补 code + simulation
• ☐ 仅做 layout 增强 · code/simulation 推迟

(待用户确认)

决议 6 · Module UID 命名空间方案 ⏳ 待最终确认

子决议: - 6a · UID 段位规划:☑ 推荐 0x00000000-0xAAAA0000 = XiStudio · 0xAAAA0001-0xFFFFFFFE = XiVST 三方 - 6b · 位宽划分:☑ 推荐 高 16 位 = vendor · 低 16 位 = 模块号 - 6c · 迁移策略:☑ Phase 0 兼容期 → Phase 1 强制(contract-v1 freeze) → Phase 2 三方接入 - 6d · 是否 freeze 前完成:☑ 必须

⭐ 决议 7 · L3 路径 ✅ 已确认推迟

• ☑ 推迟决议 · 等 L1+L2 落地后视客户反馈再定

⭐ 决议 8 · xml-tuning 整体退役方案 ✅ 已确认(v1.2 新增)

• ☑ 整体删除(无兼容期):
• 删除文件:xml-tuning/ 8 文件 + useXmlTuningStore.ts + xmlConfigParser.ts + xmlTuning.ts + public/xml-configs/
• 类型迁移:XmlWidgetDef → WidgetDef(放新建 types/widget.ts)
• 渲染器改造:XmlWidgetGroupLayout → WidgetGroupLayout
• 修改 9 处外部引用
• ☑ legacy 模块改在 MC 中手动重建(用户接受)
• ☑ legacy_set_param 后端协议保留(与 xml 子系统无关)

⭐ 决议 9 · ModuleMode 简化方案 ✅ 已确认(v1.2 新增)

• ☑ 方案 B:ModuleMode = 'normal' | 'legacy' + ModuleSource = 'builtin' | 'backend' | 'thirdparty' 独立
• ☑ 删除 def.kind: 'legacy' | 'native'(ThirdPartyModuleDialog 改用 ModuleDef.mode)
• ☑ 不再区分 dsp / builtin(按用户原话:"目前看不区分 dsp 还是 builtin · 没有这个需求了")
• ☑ codegen 边界:mode='legacy' 模块跳过 codegen + simulation
• ☑ 数据迁移脚本:builtin_normal/dsp_normal → mode=normal,source=builtin 等

---

6. 拍板后的下一步(v1.2 最终版)

人类拍板后,AIOS 将:

1. 起草 ADR-AIOS-04 · 落盘 docs/08-implementation/40-aios/ADR/
2. 章节 1:三层控件库架构(L1/L2/L3)
3. 章节 2:Module UID 32 位命名空间
4. 章节 3:codegen 方向 X · legacy 边界
5. 章节 4:xml-tuning 整体退役(决议 8)
6. 章节 5:ModuleMode 简化(决议 9)
7. 更新 KANBAN.md v5 · ClaudeB(XiForge stage)+ ClaudeC(XiTune stage)任务表加 P-1/P0/P1 共 7 项
8. 起草 PROMPT 文件清单:
9. PROMPT-claudeb-xml-tuning-decommission.md(P-1 · 2.5d · xml 整体退役 + 类型迁移)
10. PROMPT-claudeb-widget-registry.md(P0 · 1d · 注册表 + L1 评审)
11. PROMPT-claudeb-module-mode-simplify.md(P0 · 1d · 4mode→2mode + 迁移脚本)
12. PROMPT-claudeb-module-uid-namespace.md(P0 · 2d · UID 32 位)
13. PROMPT-claudeb-codegen-c-header.md(P1 · 2d · normal-only codegen)
14. PROMPT-claudeb-preset-auto-schema.md(P1 · 1d · Preset schema 派生)
15. PROMPT-claudeb-code-mode-ui.md(P2 · 1.5d · Monaco)
16. PROMPT-claudeb-simulation-mode.md(P2 · 3d · 视决议 5)

---

7. 调研真值参考(v1.2 累计 8 份 subagent 报告)

第一轮(2026-05-25 16:00) · 5 份: - ModuleCreator.vue 4575 行全量分析 - xml-tuning/ 8 文件 2586 行全量分析 - stores/utils/types 基础设施分析 - ThirdPartyModuleDialog + demo + index 分析 - 全局关键词扫描 8 组(codegen/customWidget/cHeader 等均 0 命中)

第二轮(2026-05-25 18:25) · 2 份: - TT* 控件 10 个 SFC 形态确认 + TT/Xml 双轨揭露 - ModuleDef.id 现状 + Module UID 兼容性分析

第三轮(2026-05-25 19:20) · 1 份: - xml-tuning 调用拓扑 + MC 真实耦合度(发现 MC 仅 1 行依赖) + types 层耦合分析(XmlWidgetDef 必须迁移)

调研基线 commit:8e7071b488a68135f6f995bc6eef18356c427c11

---

END · v1.2 最终落地版 · status: decided · 9 项决议全部拍板

---

8. 决议拍板记录(2026-05-25 19:50)

用户最终拍板内容(覆盖剩余 3 项决议):

决议 3:采取建议 15 中目前合适(L1 控件清单 15 候选全部采纳) 决议 5:仅做 layout 增强 · code/simulation 推迟下季度 决议 6:6a · UID 段位规划采纳推荐方案 · 6b/6c/6d 默认推荐

9. 实施落盘清单(本季度)

文档	路径	status
ADR-AIOS-04	docs/08-implementation/40-aios/ADR/ADR-AIOS-04-xiforge-architecture.md	✅ accepted
PROMPT P-1 · xml 退役	docs/08-implementation/30-frontend-vue3/active/PROMPT-claudeb-xml-tuning-decommission.md	✅ ready-for-agent · 2.5d
PROMPT P0 · widget 注册表	docs/08-implementation/30-frontend-vue3/active/PROMPT-claudeb-widget-registry.md	✅ ready-for-agent · 1d
PROMPT P0 · ModuleMode 简化	docs/08-implementation/30-frontend-vue3/active/PROMPT-claudeb-module-mode-simplify.md	✅ ready-for-agent · 1d
PROMPT P0 · Module UID	docs/08-implementation/30-frontend-vue3/active/PROMPT-claudeb-module-uid-namespace.md	✅ ready-for-agent · 2d ⚠️ contract-v1 freeze 前必须
KANBAN.md v5	docs/08-implementation/40-aios/KANBAN.md	✅ §1.2.2 新增 P-1/P0 共 4 项任务

Phase 1 (P-1 + P0) 总工作量:6.5 工作日 · ClaudeB-XiForge agent 5-7 天完成