diff --git a/council-output/EDITOR_RESEARCH.md b/council-output/EDITOR_RESEARCH.md
index f5d949d..02bef3d 100644
--- a/council-output/EDITOR_RESEARCH.md
+++ b/council-output/EDITOR_RESEARCH.md
@@ -163,35 +163,103 @@ if(isset($ret['code']) && $ret['code'] != 0) {
 
 ## Q1：JSON 编辑器复杂度评估（FrontendDev）
 
-> [待 FrontendDev 填写]
+### Q1.1: ShopXO DIY 组件中是否有现成 JSON 编辑器？
+
+**结论：ShopXO DIY 编辑器为商业闭源组件，无公开源码，无 JSON 编辑能力。**
+
+调研过程：
+- `shopxo/public/static/diy/js/entry/index-d71f3dad.js` — 预构建的单个大型压缩包（4MB+ CSS + 完整 Vue3 运行时），无可读源码
+- `shopxo/public/static/diy/js/chunk/` — 仅含 3 个空壳 JS 文件，总计 ~5 行代码
+- `shopxo/sourcecode/index.html` — 空占位文件（ShopXO 源码包需从其商业平台单独获取）
+- `shopxo/app/admin/view/default/diy/saveinfo.html` — 仅一行 `ModuleInclude`，无组件定义
+
+**ShopXO DIY 编辑器是页面可视化装修工具**（拖拽组件排版），不是通用 JSON 编辑器。其 `custom` 组件类型支持输出 HTML 代码片段，不可复用。
+
+---
+
+### Q1.2: Vue3 + JSON Schema Form 编辑器复杂度估算
+
+**现有插件的起点**：SeatTemplate 已使用**原始 textarea**（`save.html:40`）直接编辑 seat_map JSON，无任何可视化。
+
+**引入"场馆"后的嵌套结构**：
+```
+venue { name, address, image }
+  └─ seat_map
+       ├─ map[]        string[]
+       ├─ seats{}      { [key]: { price, color, label, classes? } }
+       ├─ row_labels[] string[]
+       ├─ sections[]   { name, color }[]
+       └─ zones{}      { [key]: { ... } }
+```
+实际嵌套深度：**3 层**（venue → seat_map → seats/sections）。不是"4层"，venue 和 seat_map 各算一层。
+
+**实现方式对比**：
+
+| 方案 | 代码量 | 工时 | 难度 | 可维护性 |
+|------|--------|------|------|----------|
+| **原始 textarea**（现状） | 0 | 0 | 无 | 差（无校验） |
+| **表单可视化编辑器** | ~500行 Vue3 | ~1-1.5人天 | 中 | 好 |
+| **JSON Schema + 校验** | ~1000行 Vue3 | ~2人天 | 高 | 好（需维护 schema） |
+
+**推荐方案：表单可视化编辑器（中等方案）**
+- venue 信息：独立字段（text + image upload）
+- seat_map.map[]：动态行编辑器（每行一个 input，支持增删）
+- seat_map.seats{}：键值对表格（行标签 → {price/color/label}）
+- seat_map.sections[]：卡片式列表（每区一张 card，含 color picker）
+- 无需引入 JSON Schema 库，直接写 Vue3 render function
+
+**技术实现路径**：
+1. 创建 `plugins/vr_ticket/admin/view/goods/ticket_editor.html`（layui 表单 + Vue3 CDN）
+2. 通过 `AdminGoodsSave.php` hook 注入到商品发布页 base tab
+3. seat_map 作为单个 JSON 字段存储（不做拆表）
+
+---
+
+### Q1.3: JSON 编辑器 vs 拆表方案成本对比
+
+**JSON 单表方案（推荐）**：
+- 数据存储：1 个 `seat_map` JSON 字段在 `plugins_vr_seat_templates` 表
+- 编辑器：自定义 Vue3 表单，500行代码，1-1.5人天
+- 优点：schema 演进灵活（加字段不影响表结构），无 JOIN 查询
+- 缺点：无数据库级数据完整性约束，查询特定座位需 JSON 函数
+
+**拆多表方案**：
+```
+plugins_vr_venues (venue 信息)
+  └─ plugins_vr_seat_templates (seat_map FK)
+        ├─ plugins_vr_seat_sections (座位区：区名/颜色)
+        └─ plugins_vr_seat_zone_mappings (座位字符→区的映射)
+```
+- 代码量：需建 3-4 张表 + 4 套 CRUD + 模型关联，~1000行 PHP，~800行前端
+- 工时：~2.5-3人天（远超 JSON 方案）
+- 优点：数据库约束强，适合超大规模（万级座位）
+- 缺点：表结构变更成本高；这个场景下收益有限
+
+**结论**：vr_ticket 插件的座位数通常 < 1000，JSON 单表方案**开发和维护成本均显著低于拆表方案**。拆表仅在需要单独查询座位库存、索引、或座位有独立业务属性时才值得。
 
 ---
 
 ## 最终推荐
 
-### 推荐方案：**插件钩子注入 + JSON Schema 编辑器**
+### 推荐方案：**钩子注入 + 表单可视化编辑器（中等方案）**
 
-**理由**：
+**综合 Q1 + Q2 结论**：
 
-1. **完全替换方案不可行**：`plugins_view_admin_goods_save` 是注入点而非替换点，位于 base tab 的 `<div class="am-form-group">` 内。要完全替换需覆盖核心 `saveinfo.html`，代价是失去 ShopXO 升级兼容性。
+| 评估维度 | 结论 |
+|----------|------|
+| 页面替换（邪门方案）| **不可行** — 钩子仅注入非替换，需覆盖核心模板失去升级兼容性 |
+| 独立路由方案 | 可行但工作量大（~3人天） |
+| **钩子注入 + JSON 表单编辑器** | **推荐** — 约 1-1.5人天，升级兼容，数据可控 |
+| JSON vs 拆表 | **JSON 单表** — 开发成本低 50%+，维护简单 |
 
-2. **注入 + 隐藏策略可行但脆弱**：通过钩子注入 HTML + JS 隐藏标准字段能实现视觉替换，但依赖 DOM 操作，维护成本高。
+**具体实施路径**：
+1. 在 `plugin.json` 注册 `plugins_view_admin_goods_save` 钩子
+2. 实现 `AdminGoodsSave.php` 返回 ticket 专属表单 HTML（layui + Vue3 CDN）
+3. 表单编辑器结构：`venue 字段组` + `seat_map 可视化编辑器`（非 textarea）
+4. `plugins_service_goods_save_handle` 钩子接收并处理 ticket 数据（引用 `$data`）
+5. `item_type='ticket'` 时前端走 `ticket_detail.html`（已有实现）
 
-3. **Save() 数据流完全可控**：`plugins_service_goods_save_handle` 钩子在事务前以引用方式接收 `$data`，插件有两条清晰路径（填最小字段走标准流，或自行处理返回）完成数据保存。
-
-4. **与 JSON 编辑器方案互补**：插件钩子注入 ticket 专属表单 + JSON Schema 编辑器处理 `seat_map` 嵌套数据，可以完整覆盖票务商品编辑场景。
-
-### 备选：走插件独立路由
-
-即 `admin/goods/saveinfo` → 重定向到插件自己的控制器方法（如 `plugins/vr_ticket/admin/goods/Save`），完全独立实现票务编辑器。不经过 ShopXO 的 `Goods::SaveInfo()` 和 `Goods::Save()`，干净隔离但需要开发独立的菜单和控制器。
-
----
-
-## 总结
-
-| 维度 | 完全替换 | 钩子注入（推荐） | 独立路由 |
-|------|----------|----------------|----------|
-| 实现复杂度 | 高（需覆盖核心模板） | 中 | 高（重写全套） |
-| 升级兼容性 | 差 | 好 | 好 |
-| 数据保存可控性 | 好 | 好 | 好 |
-| 开发工作量 | ~2人天 | ~1人天 | ~3人天 |
+**不推荐**：
+- 完全替换 saveinfo.html（失去升级兼容性）
+- 拆多表（收益<成本）
+- 引入 JSON Schema 库（过度工程化）
diff --git a/plan.md b/plan.md
index 374fed9..3a3d8f8 100644
--- a/plan.md
+++ b/plan.md
@@ -39,12 +39,12 @@ venue（name/address/image）
 
 ## 任务清单
 
-- [ ] **Q1.1**: 调研 ShopXO 后台是否有现成 JSON 编辑器组件（ShopXO DIY 组件） `[Claimed: FrontendDev]`
-- [ ] **Q1.2**: 评估 4 层嵌套 Vue3 + JSON Schema form 编辑器复杂度（代码量/工时） `[Claimed: FrontendDev]`
-- [ ] **Q1.3**: JSON 编辑器 vs 拆表方案开发和维护成本对比 `[Claimed: FrontendDev]`
+- [x] **Q1.1**: 调研 ShopXO 后台是否有现成 JSON 编辑器组件（ShopXO DIY 组件） `[Done: FrontendDev]` — 商业闭源，无公开源码，仅预构建 SPA，无 JSON 编辑能力
+- [x] **Q1.2**: 评估 Vue3 表单可视化编辑器复杂度（代码量/工时） `[Done: FrontendDev]` — 嵌套深度3层（非4层），表单编辑器~500行/1-1.5人天
+- [x] **Q1.3**: JSON 编辑器 vs 拆表方案开发和维护成本对比 `[Done: FrontendDev]` — JSON单表成本低50%+，拆表仅座位万级+时值得
 - [x] **Q2**: 商品发布页替换方案可行性（BackendArchitect 并行调研） `[Done: BackendArchitect]` ✅
   - **结论**：钩子仅注入非替换；Save()支持标准POST；推荐钩子注入+JSON编辑器
-- [ ] **Final**: 输出 `council-output/EDITOR_RESEARCH.md` 并给出明确推荐 `[Pending: FrontendDev]` — 等 Q1 完成
+- [x] **Final**: 输出 `council-output/EDITOR_RESEARCH.md` 并给出明确推荐 `[Done: FrontendDev]` ✅ — Q1+Q2 完成，推荐：钩子注入+表单可视化编辑器
 
 ---
 
@@ -100,8 +100,8 @@ venue（name/address/image）
 
 | 任务 | 状态 |
 |------|------|
-| Q1.1 | [Claimed: FrontendDev] |
-| Q1.2 | [Claimed: FrontendDev] |
-| Q1.3 | [Claimed: FrontendDev] |
-| Q2 | [Done: BackendArchitect] — 注入点非替换点，Save()标准POST |
-| Final Output | [Pending: FrontendDev] — 等 Q1 完成 |
+| Q1.1 | [Done: FrontendDev] |
+| Q1.2 | [Done: FrontendDev] |
+| Q1.3 | [Done: FrontendDev] |
+| Q2 | [Done: BackendArchitect] |
+| Final Output | [Done: FrontendDev] — Q1+Q2 complete, final recommendation added |