diff --git a/dash/docs/theme-switching-plan.zh.md b/dash/docs/theme-switching-plan.zh.md
index e658d80..e2aad1e 100644
--- a/dash/docs/theme-switching-plan.zh.md
+++ b/dash/docs/theme-switching-plan.zh.md
@@ -33,7 +33,9 @@ SH: 主题切换后，即刻拉取一次
 
 - 不在 Kindle 上重新渲染整张日历页
 - 不引入 Kindle 端复杂主题模板引擎
+SH: kindle端还是保持，拉背景图片+绘制时钟
 - 不要求首次版本就支持任意数量主题的自动发现
+SH：主题清单（名称和路径等信息），可以放在calendar项目下，用json文件，比如themes.json，kindle可以一天同步一次该主题，或者主动拉取。
 
 ## 3. 设计原则
 
@@ -50,6 +52,8 @@ SH: 主题切换后，即刻拉取一次
 - 当前链路已经验证“远端产图 + 本机分钟级叠时钟”可行
 - 主题扩展主要发生在样式层，天然更适合留在前端工程里
 
+SH: 增加主题配置json
+
 ### 3.2 Kindle 只保存“当前主题 ID”
 
 Kindle 端不保存复杂主题配置，只保存一个很小的状态：
@@ -62,6 +66,9 @@ Kindle 端不保存复杂主题配置，只保存一个很小的状态：
 - 使用哪套本地表盘素材
 - 使用哪份时钟区域配置
 
+SH： kindle侧最简化，甚至只需要在固定位置取json来看，calendar支持哪些主题，主题图在哪里取？
+时钟大小和和位置等，由calendar维护。kindle所需的信息，可以在主题对应的json中描述，这样kindle不用决定时钟应该画在那里，按json配置即可。
+
 ### 3.3 先做“背景主题切换”，再做“完整主题切换”
 
 建议分两阶段：
@@ -78,7 +85,9 @@ Kindle 端不保存复杂主题配置，只保存一个很小的状态：
 建议明确两条链路：
 
 - 预览链路：用户访问网站，通过菜单切换 `theme`
+SH：这个没问题，只要看效果就行了。且效果和kindle上显示一致就行了。
 - 导出链路：脚本继续按当前默认行为生成 `calendar/dist/kindlebg.png`
+SH：主题的路径管理由calendar决定，路径不写死，不通主题不通路径
 
 只有在后续正式接入 Kindle 多主题切换时，再额外增加“按主题导出”的产物目录。
 
@@ -220,6 +229,8 @@ calendar/dist/clock-region.json
 
 ### 5.5 多主题导出作为附加能力
 
+SH：主题清单由calendar供给，kindle只要依据themes.json获取现有什么主题。kindle切换主题时拉一次该主题对应的背景和主题级json。
+
 当需要支持 Kindle 端切换主题时，再额外增加按主题导出的能力，例如：
 
 ```text
@@ -373,6 +384,8 @@ Dashboard Debug Off
 
 - 不支持不同主题使用不同表盘位置或不同指针样式
 
+SH：现在kindle的时钟绘制不依赖表盘和指针素材吧？
+
 ### 7.2 级别 B：完整主题切换
 
 适用场景：
@@ -489,9 +502,13 @@ Dashboard Debug Off
 进入实现前，建议先明确这几个评审点：
 
 1. 网站预览菜单放在哪个区域最合适，是否只在 `mode=full` 显示
+SH：这个没有问题，放在顶部的随意位置，可选即可，不影响截图效果。
 2. 第一阶段是否只做 2 个主题，例如 `paper` 和 `classic`
+SH：保持当前主题，命名为default，新增这两个。
 3. 第一阶段主题是否允许改变时钟区域位置
+SH：这个位置由calendar中时钟的占位位置决定，按主题时钟位置，不是随意改变。
 4. KUAL 菜单是否接受“每个主题一个菜单项”的交互形式
+SH：统一主题配置，点进去从themes.json获取主题清单，点具体主题，切换主题
 5. 远端发布目录是否可以稳定提供 `/themes/<theme-id>/kindlebg.png`
 
 如果以上五点都确认，本方案可以直接拆成小步实现。