将 WordPress 主题移植到 EmDash
以 EmDash 为后端，将主题的相关布局和交互重新创建为 Astro 站点。保留用户要求的视觉保真度和功能范围；不要假设每个 WordPress 模板或演示功能都属于移植内容。
加载 building-emdash-site 以获取当前的 EmDash schema、查询、渲染、缓存和种子模式。如果有实时参考站点，使用 agent-browser CLI 进行渲染比较；运行 agent-browser skills get core --full 获取其命令参考。
选择证据
按优先级使用最佳可用来源：
- 主题源码和
theme.json、样式表、模板以及functions.php； - 在典型桌面和移动视口下的实时演示；
- 用户提供的截图或设计文件；
- 在来源不明确时做出明确的设计决策。
不要推断演示内容或图片与主题代码共享相同的许可。仅在资产许可或用户权利允许时复用；否则，使用具有相似尺寸和视觉权重且许可明确的替代资产。
规划移植
仅盘点请求站点所需的页面类型、组件、响应式状态和交互。在实现之前映射 WordPress 的功能职责：
- PHP 模板转换为 Astro 路由、布局和组件。
- 自定义文章类型、元数据和分类法转换为 EmDash 集合、字段和分类法。
- 主题自定义器值转换为站点设置或显式的项目配置。
- 菜单位置转换为由模板查询的命名 EmDash 菜单。
- 侧边栏和小工具转换为小工具区域或普通的 Astro 组件。
- 短代码和插件拥有的行为可能需要单独的插件迁移。
在转换模板层级、functions.php 注册、模板标签、钩子、小工具或可复用区块时，阅读 WordPress 主题概念映射。
动态 EmDash 内容路由必须保持服务端渲染。对 EmDash 媒体字段使用 EmDash Image 组件；普通主题资产可以使用 Astro 的资源处理。
分阶段工作
仅在适用阶段读取对应的阶段文件：
创建独立主题项目时，从仓库当前的站点模板或用户的现有项目开始。在写入之前确认目标位置，未经明确指示不要替换现有站点结构。
验证结果
构建站点并测试每个范围内的页面和交互。对照参考比较匹配的视口，包括响应式导航、长值及缺失值的内容、RTL（当管理后台或主题行为依赖方向时），以及相关的空状态或错误状态。
当视觉保真度是验收标准的一部分时，捕获前后对比或参考与结果的截图。报告有意偏差、缺失的源证据、不支持的 WordPress 行为以及资产替换。
许可与署名
检查源主题的实际许可证和声明。保留所需的版权和署名信息，包含复用代码的适用许可证文本，并单独标识第三方资产。不要仅仅因为源是 WordPress 主题就将其标记为 GPL-2.0-or-later。