edit-app

插件检查：运行 node "${PLUGIN_ROOT}/scripts/check-version.js"——如果输出消息，请在继续之前向用户展示。

共享说明：shared-instructions.md——请先阅读。

编辑应用（/edit-app）

针对现有移动应用的生成后编辑。native-app-plan.md 仍是唯一可信来源，但默认结果是一个固定的生成应用，而非仅包含计划差异的版本。用户批准计划变更后，继续修改 Dataverse／原生／设计／屏幕内容，运行验证，更新 memory-bank.md，并在 UI 发生变化时重新生成静态预览。

仅当用户明确要求在不更改应用代码的情况下更新规划文档时，才使用 --plan-only。在 Copilot Chat Agent 模式下，常规的后续提示应端到端地应用应用更改。

编辑文档协议

每次编辑期间都要保持以下两个 HTML 文件为最新状态：

• <edit-temp-dir>/edit-app-progress.html 显示实时操作清单。
• docs/create-app-plan.html 持续记录应用说明。

这两项文档工作均尽力完成。渲染失败并不意味着可以执行更改、取消审批关卡，或将失败的验证视为成功。

进度页面

第 0 步解析出 working_dir 后，立即让 app-docs.js 在用户操作系统的临时目录中请求一个带命名空间的目录，且必须在同步推断出的计划或首次写入进度之前完成：

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' temp

在本次运行的其余过程中，使用返回的 directory、progress、progressHtml 和 sync 路径。不要在项目内创建进度文件。创建 <edit-temp-dir>/edit-app-progress.json，为本次编辑将执行的每项操作各添加一行。 使用 inspect、impact、plan、approve、save-plan、data、native、design、screens、verify、preview 和 sync-plan 等稳定 ID。省略不适用的操作。 每行都包含 id、label、status（pending、active、waiting、done、skipped 或 failed）以及可选的 note。 为 Changes 标签页添加顶层 changes 数组。 在初始检查期间保持该数组为空。 第 2 步之后，每个条目都必须包含 kind、title、rationale 以及可选的 detail。 纯文本变更使用 kind: general。 数据模型和屏幕变更使用结构化图表数据：

{
  "changes": [
    {
      "kind": "data-model",
      "title": "Add inspection evidence",
      "detail": "Create a child table for photos and signatures.",
      "rationale": "One inspection can have several evidence records with independent metadata.",
      "dataModel": {
        "tables": [
          {
            "name": "Inspection",
            "columns": [{ "name": "inspectionid", "type": "guid", "primaryKey": true }]
          },
          {
            "name": "Evidence",
            "columns": [
              { "name": "evidenceid", "type": "guid", "primaryKey": true },
              { "name": "inspectionid", "type": "guid", "foreignKey": true }
            ]
          }
        ],
        "relationships": [
          {
            "from": "Inspection",
            "to": "Evidence",
            "cardinality": "one-to-many",
            "label": "contains"
          }
        ]
      }
    },
    {
      "kind": "screen",
      "title": "Add inspection detail",
      "detail": "Add a route that shows findings and evidence.",
      "rationale": "Inspectors need a focused review surface before updating a record.",
      "screenGraph": {
        "screens": [
          { "id": "list", "name": "Inspections", "route": "/inspections" },
          { "id": "detail", "name": "Inspection detail", "route": "/inspections/[id]" }
        ],
        "edges": [
          { "from": "list", "to": "detail", "label": "Select inspection" }
        ]
      }
    }
  ]
}

根据已验证的架构提案推导数据模型中的表、列和关系。 根据更新后的 Screen Map 和 Navigation Contracts 推导屏幕节点和边。 显示多个屏幕时，包含解释用户如何在这些屏幕之间移动所需的所有导航边。 不要在负载中手动编写 Mermaid 源代码。 app-docs.js 会根据结构化数据生成并渲染 ER 图或屏幕图。 在实现和验证过程中保留已批准的措辞、理由和图数据。

在每个编号步骤的边界处重写该 JSON，并运行：

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' progress \
  --json-file '<edit-temp-dir>/edit-app-progress.json'

每个进度负载都是完整快照，而不是补丁。保留所有操作行，并在发布前更新状态发生变化的所有行。 顶层阶段推进时，较早阶段的任何行都不得仍处于 active 或 waiting 状态。 尤其是等待审批时，必须将检查和计划标记为已完成，并将审批行标记为 waiting。

顶层对象还包含 phase、status、note、waiting 和 devicePreviewReady。每次向用户提问前，将当前行设为 waiting，并将 waiting: true。将已完成的行设为 done；不要让第一行在整个运行期间都保持活动状态。发生失败时，将失败行和顶层状态设为 failed。工作进行期间，页面会在右侧保留手机预览。在本次编辑的第 8 步手机命令成功之前，将 devicePreviewReady: false。之后，在最终进度写入时将其设为 true，将所有适用的行标记为已结清，并将顶层状态设为 done。之前运行留下的二维码绝不能作为本次运行预览的证据。每个会结束工作流的分支都必须发布终止进度写入。保留操作的实际结果，将已完成的行标记为 done 或 failed，将不会执行的行标记为 skipped，清除 waiting，并将顶层状态设为 done 或 failed。

首次写入后，使用主机的文件打开器打开一次 <edit-temp-dir>/edit-app-progress.html。如果没有可用的打开器，请打印绝对路径。工作进行期间，页面会自动刷新。

持续更新的应用计划

app-docs.js sync 接受结构化快照，而非文字摘要：

{
  "appName": "Field inspections",
  "dataPlatform": "dataverse",
  "inferred": false,
  "summary": "Added inspection detail and evidence capture.",
  "sections": {
    "requirements": {},
    "architecture": { "dataPlatform": "dataverse", "nativeCapabilities": [], "connectors": [] },
    "dataModel": { "tables": [] },
    "screens": { "navigation": "", "list": [] },
    "design": {},
    "offline": {},
    "trust": {}
  },
  "sectionStates": { "screens": "approved" }
}

对于现有计划，请包含此次编辑更改的所有部分，并省略未更改的部分。实现完成后，序列化完整的当前部分；同步命令会替换该部分，因此已移除的屏幕、连接器、功能和表格不会以过时行的形式残留。请根据已验证的应用及其持久计划填写值，而非依据审批前的提案。

将负载写入 <edit-temp-dir>/app-plan-sync.json，然后运行：

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' sync \
  --json-file '<edit-temp-dir>/app-plan-sync.json'

如果缺少 docs/.run-plan.json，负载必须涵盖所有可从应用推导出的部分：screens 的路由和布局、dataModel 的生成模型／服务和清单、连接器的 power.config.json 及生成的注册项、原生功能的 src/native/ 和模板依赖项，以及 design 的品牌／令牌文件。将此第一份快照标记为 inferred: true，并使用说明 Plan inferred from existing app state because no prior create-run plan was present.。对于未知事实，应明确标记为未知；不要猜测。

在后台更新 docs/create-app-plan.html。在 /edit-app 期间不要打开或聚焦该页面。在创建推断基线后、保存获批的计划部分后，以及 Step 8 验证后，都要运行同步命令，确保页面最终反映应用的实际当前状态。告知用户持续更新的应用计划已更新，以反映最新的已验证更改。

适用情况

• “改进搜索屏幕，让它在移动设备上更易用”
• “为列表屏幕添加加载、空数据和错误状态”
• “为所选记录添加详情屏幕”
• “更新设计，使其更符合公司品牌”
• “添加一个表单，以在 Dataverse 中创建新记录”
• “添加条码扫描功能，并使用扫描值搜索记录”
• “为更新后的应用生成新的静态预览”
• “向数据模型添加 case 表”
• “将 Drawer 导航替换为 Tabs”
• “将 expo-camera 添加到原生功能中”
• “为审批添加签名采集功能，并将签名存储在 Dataverse 中”
• “生成证据 PDF，并将其保留在检查记录中”
• “为 HTTPS 报告 URL 添加‘查看 PDF’操作”
• “重新排序屏幕——将个人资料移出标签页，改为从主页页眉打开的模态框”
• “为此应用启用 Application Insights”
• “更改此应用使用的 Application Insights 资源”
• “为此应用禁用 Application Insights”

不适用情况

• 全新项目 → /create-mobile-app
• 明确仅要求实现 → 使用 app-edit-routing.md 中对应的叶级技能；不要根据简短请求或缺少屏幕详情推断为此类请求。
• 找不到可识别的生成应用根目录（package.json 加上 app/）→ 停止并询问应用目录。仅缺少计划时，按下文的推断基线路径处理。

工作流

此技能负责处理由原生、连接器、数据模型和设计入口转交的直接功能请求。复用转交过来的原始请求、参数和回答；不要要求用户重复提供。

这些入口会在调用此完整工作流前征求许可。对于当前请求，复用 entry_choice: full-integration，不要再次询问模式。直接调用 /edit-app 也无需显示入口选择菜单。 这两种情况都不代表已授权进行变更：仍须遵守下文的影响评估和计划审批关卡。已获批准的子调用会跳过入口问题并返回此处；不要创建递归菜单。

每次调用子技能时，都要明确传入 app-edit-routing.md 上下文： MOBILE_APP_ORCHESTRATING=1、orchestrator: edit-app、working_dir、phase 和 approved_scope。规划阶段只提出只读方案；第 5 步的实现使用第 3 步批准并在第 4 步保存的范围。此标记不代表批准，也不得持久化或依赖此前导出的 shell 环境变量。

0. 定位应用 + 健康状态/偏差探测 → 0.5 适用时走 Application Insights 快速路径 → 1. 梳理意图 + 检查现有应用 → 1.5 影响预览 → 2. 重新规划受影响的部分 → 3. 审批意图、计划和变更预览 → 4. 编写计划差异 → 5. 应用新增内容/刷新 → 6. 重建受影响的屏幕 → 6.5 注销已批准退役的数据源 → 7. 验证 + 质量检查 → 8. 预览 + 更新 memory-bank + 可选的调试交接

---

编辑质量关卡政策 — 绝不降低质量标准

这是一个专注于编辑的工作流，不意味着质量标准更宽松。按编辑规模复用 /create-mobile-app 的关卡。

按编辑类型划分的必需关卡：

编辑涉及内容	必需关卡
任意源文件	现有应用健康状态关卡、最终运行 npx --no-install tsc --noEmit
Dataverse/架构/连接器	环境偏差关卡、数据源/架构关卡、刷新 Generated Services 快照、最终运行 tsc
导航/路由	导航/布局关卡、路由契约检查、最终运行 tsc
新屏幕	共享脚手架关卡、骨架关卡、屏幕构建器批次关卡、样式质量检查、路由检查、最终运行 tsc
现有屏幕 TSX	屏幕编辑关卡、样式质量检查、导航变更时进行路由检查、最终运行 tsc
原生功能	原生允许列表关卡、封装层存在性关卡、最终运行 tsc
纯 JavaScript 依赖项	已批准的精确版本依赖项表、包内容关卡、包验证、最终运行 tsc
设计/组件/密度	设计系统关卡、受影响屏幕的样式检查、最终运行 tsc、预览
仅 Application Insights 配置	有效的 app.json、提供程序 appConfig 接线；仅当 app/_layout.tsx 发生变更时才运行最终 tsc

关卡未通过时： 完整捕获一次输出，按根本原因分类，批量修复，然后重新运行同一关卡一次。不要每改动一点点就运行 tsc 逐行修复。只有关卡通过后才能继续；否则在 memory-bank.md 中记录 BLOCKED: / DONE_WITH_CONCERNS: 条目。

硬性停止条件：

• 如果无法识别应用根目录/环境，不要执行数据源变更。
• 如果生成的服务、路由布局、共享代码或骨架存在问题，不要启动屏幕构建器。
• 在 /add-native 生成原生封装层之前，不要在屏幕中导入原生封装层。
• 不要仅为满足 TypeScript 而用模拟对象或 TODO 隐藏不受支持的原生功能。
• 如果已更改的屏幕未通过 TypeScript、路由契约或必需的验证器检查，不要将编辑标记为成功。

步骤 0 — 定位应用并探测健康状况／偏差

遥测检查点：assess_app_health_and_drift

读取任何项目内容或运行任何命令之前，先执行 app-working-directory.md。 仅解析一次绝对路径 working_dir，将每次 Shell 调用都绑定到该路径，并使用失败即关闭的保护机制；文件工具使用绝对路径。将同一个根路径传递给每个数据子任务；先前的 cd 或继承的启动工作目录不算交接。 立即运行编辑文档协议的 temp 命令，并在下面任何推断计划同步或进度写入之前，将其返回的 directory、progress、progressHtml 和 sync 路径绑定为 <edit-temp-dir> 值。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
test -f native-app-plan.md && echo "OK: plan found" || echo "INFO: plan will be inferred"
test -f package.json && echo "OK: package found" || echo "ERROR: no package"
test -d app && echo "OK: app routes found" || echo "ERROR: no app routes"
test -f memory-bank.md && echo "OK: memory bank found" || echo "WARN: no memory bank"
git status --short

如果缺少 package.json 或 app/，请停止，因为这不是可识别的生成式应用。 如果缺少 native-app-plan.md，请先检查当前应用，再询问编辑相关问题。根据路由／布局、power.config.json、生成的 模型／服务、.datamodel-manifest.json、src/native/、包依赖、品牌／令牌文件，以及存在时的 memory-bank.md，构建推断出的当前状态基线。编写 native-app-plan.md，涵盖所有有证据支持的部分，将其标记为 Inferred current-state baseline，并将尚未确定的事实标记为未知。不要运行 /create-mobile-app、臆造缺失的业务意图，也不要将推断视为变更授权。 根据相同的证据创建 <edit-temp-dir>/app-plan-sync.json，并运行 sync 命令，使导入的应用在开始规划前获得 docs/create-app-plan.html。

现在创建编辑进度载荷，将 inspect 设为 active，运行 progress 命令，并打开 <edit-temp-dir>/edit-app-progress.html。

如存在，请阅读：

• memory-bank.md — 项目事实、目标环境、视觉配套标志、先前的阻塞项
• .datamodel-manifest.json — 现有 Dataverse 表／列
• brand/design-system.md 和 brand/tokens.ts — 设计约束和令牌可用性
• src/generated/services/*.ts 和 src/generated/models/*.ts — 生成的数据接口

任何变更之前，先运行以下现有应用健康检查：

此步骤仅用于检查。在拟议的变更范围中加入必需的脚手架／提供程序／服务修复；未获步骤 3 批准前，不要应用这些修复。 --plan-only 绝不授权进行这些修复或任何其他应用／云端变更。

检查	不健康时的操作
memory-bank.md 存在且包含预期标题	如果缺失／损坏，询问是否在降低恢复安全性的情况下继续；仅在获批后创建／更新
power.config.json、.resolved-environment.json 和 memory bank 中的环境一致	对于数据源／架构编辑，在用户确认预期环境之前停止
src/components/index.tsx、src/hooks/index.ts、src/utils/index.ts、src/tokens/index.ts 存在	在屏幕构建器开始工作前，从 shared/samples/src/ 恢复缺失的共享脚手架；不要覆盖现有文件
app/_layout.tsx 仍正确封装提供程序和 SafeAreaProvider	在屏幕工作前谨慎修补；路由／安全区域验证器依赖此项
如果编辑依赖生成的服务，则 src/generated/ 能通过编译	先重新生成架构／服务，否则在屏幕工作前阻止继续
存在 node_modules 和验证所需的包脚本	如果缺失，请用户运行安装；不要假称验证已通过

如果工作树存在未提交更改，且与可能的编辑目标重叠，请列出受影响的文件并在继续前询问。不要自动还原或暂存更改。

如果应用运行 npx --no-install tsc --noEmit 时已失败，请记录一次错误。仅当失败发生在本次编辑将触及的文件中，或属于本次编辑可以修复的生成服务偏差时，才继续；否则说明这是已有故障，并询问是否继续。如果编辑将添加屏幕或生成的服务，请先通过前置条件检查。

步骤 0.5 — Application Insights 配置快捷流程

如果存在 --plan-only，请勿调用配置技能或更改 Application Insights。对于仅涉及配置的请求，请报告其没有计划部分，并保持原样停止；对于混合请求，仅继续处理所请求的计划提案。

仅当请求只涉及启用 Application Insights、更改其资源或将其禁用时，使用此快捷流程。Application Insights 属于主机／运行时配置，而不是连接器或计划部分，因此不要运行规划器、数据模型、本机、设计、屏幕或预览流程。 对于仅涉及配置的请求，请使用 configure-insights 检查清单行。委派前，将 inspect: done 和 configure-insights: active 标记为已完成和进行中。

如果请求还要在应用屏幕中添加或更改自定义事件，请先在此处配置 Application Insights，然后继续执行常规编辑工作流，处理这些源代码更改。

所有 Application Insights 逻辑都位于专用的 /setup-app-insights 技能中。请委派给该技能，不要在此重复 Azure 发现、连接字符串处理、提供程序接线或隐私规则：

Invoke skill: /setup-app-insights

Environment:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: edit-app
  working_dir: <working_dir>
  phase: configuration
  approved_scope: <requested configuration action; setup-app-insights owns approval>

Arguments:
  --working-dir <working_dir>
  --action <enable|change-resource|disable>   # omit to let the skill infer + ask

根据请求确定 --action（enable / change-resource / disable）；如果请求只说“更新 Application Insights”，则省略该参数，让技能进行询问。该技能负责变更预览、审批、app.json + PowerAppsProvider appConfig 接线、memory-bank.md 更新和选择遥测的发送。

根据状态协议（AGENTS.md 规则 #12）处理返回结果：

• DONE → 输出已完成的操作。然后，如果返回结果包含 instrumentation_offer: available（成功启用／更改资源），询问用户一个问题，默认选择 No：“Application Insights 已启用。要我为应用的主要操作（创建／更新／删除）添加自定义遥测吗？”
  • Yes → 带着以下简述继续进入常规编辑工作流（从步骤 1 开始）：“在应用主要实体每次成功创建、更新和删除时添加自定义事件；通过 getCustomEventsLogger 发送命名事件，且仅使用经批准的标量属性（不得包含操作结果、负载、表单值、自由文本、记录标题、个人标识符、令牌、精确坐标、嵌套对象或完整 URL）；任何持续时间都使用 trackScenario()。” 屏幕规划器和屏幕构建器根据现有隐私允许列表负责源代码编辑。
  • No（或 instrumentation_offer: none）→ 将 configure-insights: done 标记为已完成，将所有剩余行标记为 skipped，清除 waiting，将顶层 phase: done 和 status: done 标记为已完成，发布进度页面，然后停止。
• DONE_WITH_CONCERNS → 将 configure-insights: done 标记为已完成，将所有剩余行标记为 skipped，清除 waiting，将顶层 phase: done 和 status: done 标记为已完成，在备注中包含相关顾虑，发布进度页面，说明这些顾虑，然后停止。
• NEEDS_CONTEXT → 说明问题，收到答案后重新调用。
• BLOCKED → 将 configure-insights: failed 标记为失败，将所有剩余行标记为 skipped，清除 waiting，将顶层 phase: done 和 status: failed 标记为已完成和失败，发布进度页面，说明错误（通常是 app.json 无法使用），然后停止。

步骤 1 — 了解意图并检查现有应用

更新 <edit-temp-dir>/edit-app-progress.json：读取应用期间保持 inspect 为进行中；在了解现有路由、数据界面、本机包装器和设计限制后，将其标记为 done。每次更新后运行协议的 progress --json-file 命令。

尽可能根据 $ARGUMENTS 推断需求，但在获得明确的编辑简述前，不要修改文件。这是针对一个现有应用变更的迷你 /create-mobile-app 需求阶段。

先检查应用，这样提问时就能使用实际选项，而不是抽象描述：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
find app -name '*.tsx' -not -name '_layout.tsx' -not -name '+not-found.tsx' | sort
ls -1 src/generated/services/*.ts 2>/dev/null | sed 's|src/generated/services/||;s|\.ts$||'
ls -1 src/generated/models/*.ts 2>/dev/null | sed 's|src/generated/models/||;s|\.ts$||'
find src/native -maxdepth 1 -type f -name '*.ts*' 2>/dev/null | sort

同时阅读相关的 native-app-plan.md 章节（如果存在，包括 ## Data Model、## Native Capabilities、## Design、## Screens 和 ## Generated Services），以及任何候选屏幕对应的现有 TSX。如果存在 brand/design-system.md，请先阅读，再询问设计或屏幕相关问题，确保编辑保留产品规范、信息密度、组件规则和禁用项。

只询问无法从应用中推断的信息。如果只有一个合理的屏幕／表格／服务，请在变更预览中说明推断出的选择，而不是提问。如果存在多个合理选择，请用真实名称提供一个简短的多选题。

在第 2 步之前，先编写编辑简报：

## Edit Brief
- Intent: <what user wants to accomplish>
- Target screens/routes: <existing or new>
- Data surface: <generated service/table/connector, or none>
- Native capability: <wrapper/control needed, or none>
- Design scope: <tokens/component grammar/screen-specific, or none>
- Plan sections to update: <Data Model / Native Capabilities / Screens / Design / Connectors>
- App files likely touched: <routes/layouts/src/native/src/generated/brand/etc.>
- Verification gates: <schema, tsc, routes, validators, preview>

如果检查后编辑简报仍不完整，请先提出针对具体场景的问题，再继续。

仅当检查后仍不清楚需要进行什么更改时，才通过 AskUserQuestion 提问：

"此应用需要更改什么？ (a) 数据模型 — 新增／扩展／复用 Dataverse 表 (b) 原生功能 — 相机、扫描仪、PDF、手写笔、文件、安全存储 (c) 屏幕／导航 — 列表、搜索、详情、表单、选项卡、状态 (d) 设计 — 配色、字体、组件、信息密度、品牌规则 (e) 连接器／数据源 — SharePoint、Office、自定义连接器 (f) 多部分功能 — 一项需要涉及以上多个方面的用户可见变更 (g) 仅预览 (h) 取消"

只有当原始请求和已提供的答案仍未说明要更改的内容时，才询问简要描述。每次只询问一个尚未解决的问题。

仅在答案无法从现有信息中明显得出时，才提出针对具体场景的问题：

场景	规划前必须询问的问题
搜索／移动端易用性	要修改哪个现有搜索／列表屏幕？搜索应覆盖哪些字段？搜索应在已加载的行中本地执行，还是在服务端查询 Dataverse／连接器？是否需要筛选器／排序／范围？
加载、空状态、错误状态	涉及哪些列表屏幕？如果不存在列表屏幕，/edit-app 是否应创建新的列表屏幕，还是将状态应用于其他数据屏幕？是否已有应改进而非重复创建的加载／空／错误组件？
详情屏幕	用户从哪个来源屏幕选择记录？记录来自哪个表／服务？必须显示哪些字段／操作？路由应采用推送详情、模态框还是 formSheet？
品牌／设计	品牌来源是什么（品牌文档、徽标、URL、文字描述、现有应用）？这是仅调整配色、字体排版、组件／密度，还是全面换肤？应更新所有屏幕，还是仅更新指定屏幕？
Dataverse 创建表单	使用哪个 Dataverse 表？是现有表还是新表？哪些字段是必填／可编辑的？从哪里打开表单？保存后如何处理（返回、详情、再添加一条）？是否包含查找／文件／图像字段？
条形码／QR 码扫描搜索	扫描功能应放在哪里（新建扫描器屏幕、现有搜索屏幕操作、表单字段）？扫描值代表什么（记录 ID、序列号、资产标签、SKU、自定义字段）？应搜索哪个表／服务／字段？未匹配或匹配多条时如何处理？
新需求＋屏幕	要添加什么用户工作流？由谁使用？需要哪些数据／原生功能／连接器？它在导航中的位置是什么？成功／失败时如何处理？
新数据源	该数据源支持什么用途？它是结构化业务数据（Dataverse）、SharePoint 列表／库、连接器操作，还是其他连接器？目前有哪些屏幕（如有）应使用它？
移除／替换表或集成	仅从此应用中移除，还是也打算单独删除服务器端数据？哪些现有屏幕、查找／身份辅助功能、原生同步或离线行为仍需要它？默认保留服务器数据。
无工作流的原生功能	该功能应实现什么、用户应从哪里调用，以及结果应仅保留在本地还是保存到现有数据源？
仅预览	预览所有屏幕，还是仅预览已更改／关键屏幕？是否应遵循 Visual Companion 自动打开行为？

决定新增还是编辑前，检查现有状态：

• 对于指定屏幕，确认路由文件是否存在。如果不存在，询问是创建该屏幕还是选择现有屏幕。
• 对于列表状态，使用 grep 搜索目标屏幕中的 LoadingState、EmptyState、ErrorState、refreshing 和 onRefresh；改进缺失或不足的状态，不要重复创建已有状态。
• 对于表单，在规划界面之前检查生成的服务方法是否包含 create／update。如果方法或表不存在，先添加／刷新数据模型。
• 对于扫描器工作，在处理屏幕之前检查 src/native/ 和计划的 Native Capabilities 表中是否已有扫描器／摄像头封装。
• 对于详情屏幕，在创建另一个 [id].tsx 之前，检查 Navigation Contracts 和现有动态路由。
• 对于品牌，在决定是否需要重建 TSX 之前，检查 brand/design-system.md、brand/tokens.ts 和 tamagui.config.ts。

常见后续需求请使用此场景覆盖矩阵。目标是一次用户提示词对应一次编排编辑，而不是让用户手动运行一系列命令。

用户需求	计划部分	应用路径	屏幕 / 验证
改进移动端搜索屏幕	Screens	仅执行 mobile-app:screen-planner 编辑流程	重新构建指定的搜索 / 列表屏幕；运行 tsc、路由检查和预览
添加加载、空状态和错误状态	Screens	屏幕规范 + 现有 TSX 编辑	重新构建受影响的列表屏幕；验证可见的加载、空状态、错误、重试和刷新状态
为所选记录添加详情屏幕	仅当缺少字段 / 服务时添加 Screens；Data Model	更新 Screen Map + Navigation Contracts；仅当缺少数据层时运行 /add-dataverse 或 /add-datasource	按需创建路由 / 文件夹 / 布局；构建详情屏幕以及源列表 / 搜索导航
更新设计以符合公司品牌	Design；仅当组件规范 / 密度发生变化时添加 Screens	/design-system --refresh <dimension> 或 --reskin	仅当仅凭令牌不足以满足要求时重新构建受影响的屏幕；始终进行预览
添加用于创建 Dataverse 记录的表单	Screens；如果缺少表、列、查找字段 / 创建服务，则添加 Data Model	缺少架构 / 服务时使用 /add-dataverse --skip-planning	构建表单路由、创建负载辅助程序、父级导航和焦点刷新；验证创建 / 更新负载
添加条码扫描，并使用扫描值搜索记录	Native Capabilities、Screens；如果缺少扫描目标字段，则添加 Data Model	/add-native barcode-scanner；仅当缺少目标字段 / 表时使用 /add-dataverse	构建扫描器 / 搜索流程，暂停 / 锁定扫描回调，通过服务筛选器搜索，并进行预览
添加完整的日历、日程或排期视图	Screens → JavaScript Dependencies	将准确的 react-native-calendars 版本添加到获批表格，然后在运行构建器前执行 npm install --save-exact	使用获批模式构建日历屏幕；不使用 /add-native，也不重新构建 Android/iOS
添加包含新屏幕的新需求	通常为 Screens，以及需求所涉及的 Data Model、Connector、Native、Design	分解为一个连贯的功能；先应用数据 / 连接器 / 原生 / 设计改动，再处理屏幕	生成 / 刷新服务快照、布局、骨架 / 共享代码，然后构建受影响的屏幕
添加新数据源，但不添加屏幕	Connector/Data Source；有时为 Data Model	需求不明确时使用 /add-datasource；需求明确时使用 /add-sharepoint、/add-connector 或 /add-dataverse	刷新生成的服务和记忆库；除非用户要求 UI，否则不重新构建屏幕
添加 Teams/电子邮件操作或个人资料查找	Connectors；使用时添加 Screens	获批后使用 /add-connector	接入该操作 / 读取功能及其加载 / 错误 / 成功行为；默认不添加 Dataverse 架构
添加 SQL/Excel/SharePoint 数据	Connectors，包括外部表 / 列表架构；使用时添加 Screens	获批后使用对应的连接器子命令	不要仅因为连接器提供表格数据就添加 Dataverse 模型
添加新表 / 实体，但不添加屏幕	Data Model	mobile-app:data-model-architect -> /add-dataverse --skip-planning	刷新生成的服务；可选择植入示例数据；UI 未变更时无需预览
停止使用某个表 / 连接器 / 流程，或替换其数据源	Data Model/Connectors 及受影响的 Screens	在第 6 步更新使用方后，通过对应子命令执行获批的退役操作	CLI 会移除应用注册并重新生成服务 / 配置；第 6.5 步会验证剩余数据源并刷新架构映射
移除、重命名、重新排序屏幕，或更改屏幕原型	Screens	执行 mobile-app:screen-planner 编辑流程	更新路由文件 / 布局 / 导航契约；仅删除获批文件；运行路由检查
生成新的静态预览	除非源文件已过时，否则无需任何部分	/preview-screens	不编辑源文件；不要执行数据 / 原生 / 设计相关工作
一个用户可见功能可能需要多个计划章节。这是允许且预期的。如果一个提示词中包含多个无关功能，应将其拆分：列出这些功能，询问先执行哪一个，不要将它们的变更打包在一起。

数据模型是有条件的。 连接器、操作或原生功能并不自动需要 Dataverse。应复用现有存储和架构。仅在功能确实需要新增或变更 Dataverse 表、列或关系时，规划 Dataverse 变更；仅缺少生成的服务时，只需重新生成，不需要新增架构。将连接器操作以及外部表／列表架构保留在 ## Connectors 中。未受影响的数据模型内容须原文保留。

继续之前检查以下漏洞：

• 如果请求新增会读取或写入数据的 UI，请确认生成的服务已存在，或先添加数据源，再进行屏幕工作。切勿让屏幕构建器自行编造服务。
• 如果请求对 Dataverse、SharePoint 或其他连接器的选择存在歧义，请只读查阅 /add-datasource 路由表，并在审批前确定选择。仅在第 5 步执行选定的叶节点。
• 如果屏幕需要原生封装层，请在屏幕构建器导入 src/native/* 之前运行 /add-native。
• 如果模板未提供某项原生功能，请停止并明确说明阻塞原因；不要安装原生包或伪造支持。
• 如果屏幕需要纯 JavaScript 库，请将其及精确版本添加到 ## Screens → ### JavaScript Dependencies，纳入变更预览，并在运行屏幕构建器前安装。根据已提供的内容判断是否为纯 JavaScript，不要仅凭包名前缀判断。
• 如果请求要更改导航，请在启动屏幕构建器之前更新路由布局和导航约定。
• 如果请求新增屏幕，请在构建 TSX 之前生成所需的路由文件夹、生成的服务快照、共享代码和骨架。
• 不要在写完 native-app-plan.md 后就停止。计划更新是内部检查点；应用变更和验证才是用户可见的结果。

对于 PDF／签名请求，应将变更映射到所有受影响的章节，而不是只编辑第一个显而易见的章节：

用户请求	必需的计划更新
添加签名采集、签核、手写笔、墨迹或绘图功能	原生功能：pen-input；屏幕：采集、预览、取消及适用的失败状态；询问保留方式，然后仅在需要新增或变更 Dataverse 存储时更新数据模型
将已签署的审批存储为 Dataverse 图像	数据模型：图像列；屏幕：更新前规范化 data:image/png;base64,...；若在应用内采集，则原生功能需包含 pen-input
生成／导出／打印证据 PDF	仅当存在 expo-print 时添加原生功能 pdf-report；仅当需要本地分享且存在 expo-sharing 时添加 sharing；数据模型：仅在需要保留时添加文件列；屏幕：生成中、失败和成功状态
持久化生成的 PDF	数据模型：Dataverse 文件列或子级附件表；屏幕：先创建／更新行，再上传文件字节；原生功能：pdf-report
查看／打开／预览 PDF	当存在 @microsoft/power-apps-native-pdf-viewer 0.2.9+ 时，对 HTTPS URL 或本地 file:// URI 使用原生功能 native-pdf-viewer；屏幕：无效 URL 和查看器失败状态

如果单个 PDF／签名请求需要更新多个计划章节，请说明这一点，并逐节执行编辑循环。不要编写引用计划中尚未包含的 Dataverse 列或屏幕状态的原生功能条目。

步骤 1.5 — 影响预览（低成本中止关卡）

遥测检查点：analyze_edit_impact

在显示影响确认问题之前，将 inspect: done 标记为完成，将 impact: waiting 设为等待，将顶层 phase: impact、waiting: true，然后运行 progress --json-file。如果用户继续，将 impact 改为 done，将 plan: active 设为活动状态，清除 waiting，然后再次运行该命令。取消时，将 顶层状态设为 done，并将所有尚未开始的操作标记为 skipped。

在启动架构师或修改文件之前，先展示粗略的影响预览，并询问用户是继续、编辑还是取消。这与 /create-mobile-app 的第 2c 步相对应，只是范围缩小到编辑。

计算：

• 成本等级： 低（单个现有屏幕）、中（新路由／表单／详情页或一个数据源）、高（多个屏幕／导航／设计／数据／原生功能）、重大（换肤或大范围重建屏幕）。
• 可能涉及的计划部分： 数据模型、原生功能、连接器／数据源、设计、屏幕。
• 可能涉及的文件： 已知时列出具体的屏幕／布局／原生功能／品牌／生成文件／记忆文件。
• 可能涉及的技能／Agent： mobile-app:data-model-architect、mobile-app:screen-planner、mobile-app:screen-builder、/add-datasource、/add-dataverse、/add-sharepoint、/add-connector、/add-native、/design-system、/preview-screens；仅当用户提供具体的运行时问题时，才可选用 /debug-app。
• 验证关卡： 架构、生成的服务、路由契约、屏幕验证器、预览。
• 主要风险： 环境偏差、不受支持的原生软件包、缺失生成的服务、导航契约变更、大范围设计变动、过时的已安装插件缓存。

输出：

─── Edit impact preview ─────────────────────────────
Intent        <one sentence>
Tier          <cheap|medium|heavy|major> (~<time range>)
Plan          <sections>
Skills/agents <list>
Files         <screen/layout/data/native/brand/memory summary>
Verification  <gates>
Preview       <yes/no>
Risks         <none or bullets>

Choose:
  (a) Proceed
  (b) Edit intent / answer more detail
  (c) Cancel

如果用户选择编辑，返回步骤 1 并完善编辑说明。如果选择取消，则停止，不修改任何文件。如果选择继续，则进入步骤 2。

如果用户选择 (d) 设计：

阅读 /design-system 参考资料，提出设计变更，但暂不执行该技能。 根据用户的描述确定变更维度：

用户表述	转到
"change colors", "palette", "accent"	/design-system --refresh palette
"change fonts", "typography", "font"	/design-system --refresh typography
"change components", "buttons", "cards"	/design-system --refresh components
"change spacing", "density", "compact"	/design-system --refresh density
"add rule", "remove rule", "negatives"	/design-system --refresh negatives
"change animations", "motion"	/design-system --refresh motion
"full redesign", "reskin", "new theme"	/design-system --reskin

每条提示词仅允许一项重大变更。 如果用户同时要求更改调色板和字体排版 → 拒绝并询问应先处理哪一项。这与 /design-system 自身的行为一致。

在提案中包含运行时令牌／提供方接线，以及所有受影响的屏幕。 继续执行步骤 2 至 4，然后再于步骤 5 执行 /design-system。 在获得批准之前或处于 --plan-only 模式期间，不得编写品牌产物；如果需要更改屏幕，也不得从设计刷新直接跳到验证。

步骤 2 — 重新规划受影响的部分

遥测检查点：revise_affected_app_plan

当架构师或内联规划正在更新受影响的部分时，保持 plan: active。如果规划器需要用户提供背景信息，将 plan 改为 waiting，设置 waiting: true，并在提问前运行进度命令。 收到答复后，将其恢复为 active。

复用 /create-mobile-app 中相同的规划基础构件，但只针对受影响的界面：

界面	复用创建流程中的内容	编辑应用范围
Dataverse 架构	data-model-architect + /add-dataverse Step 8	新增或变更的表、列、查找、计算字段、生成的服务
连接器选择	/add-datasource、/add-sharepoint、/add-connector	新增或变更的外部数据／操作界面
原生功能	/add-native Step 9	编辑后的屏幕所需的新包装器／控件
JavaScript 依赖	screen-planner + shared/references/javascript-dependency-planning.md	明确提出的包请求，或编辑后的屏幕所需的既有 JS 库
设计	/design-system Step 9b	刷新设计令牌、换肤、密度／组件规则
导航	/create-mobile-app Step 10b	变更后的标签页、堆栈、路由组、模态框／formSheet 呈现方式
服务快照	/create-mobile-app Step 10.7	任何数据源／架构变更后、构建器运行前刷新
共享代码 + 骨架	/create-mobile-app Step 10.8	新屏幕、变更后的数据导入、新的共享行／卡片／钩子
屏幕实现	/create-mobile-app Step 11	仅处理受影响的屏幕，通过 mobile-app:screen-builder 分批执行
质量检查	/create-mobile-app Step 11.4	变更后的屏幕文件和路由布局

从 native-app-plan.md 中逐字读取每个受影响章节，并将其作为输入传给相应的只读 Agent。每次调用 Task 时都使用插件命名空间。

对于 Dataverse 架构／新绑定工作，先阅读并执行 dataverse-change-planning.md。 使用请求中的差异及必要依赖，而非所有历史计划行。前台获取并验证精简证据；架构师使用 Dataverse planning mode: required，而非旧版实时发现。

仅涉及原生功能／设计／连接器的编辑、应用绑定移除，以及保留服务的刷新，均跳过此规划流程，且绝不复用其旧产物。

首次调用 Task 前，针对所需的叶级 Agent 运行静默预检（mobile-app:data-model-architect、mobile-app:screen-planner，或稍后运行 mobile-app:screen-builder 的预检）。如果宿主无法启动 Agent，只打印一次：

"→ Planner agents unavailable in this host — running inline planning. (No action needed; this is automatic.)"

内联回退规则：

• Data Model：将现有计划、清单、模型和编辑简述用作上下文， 但决策须以共享工作流中已验证的精简证据为依据。 生成 _dm_section.md 和规范化架构契约，并运行与 Agent 结果相同的 决策验证器；本地文件本身不能证明服务器当前的架构。
• Screens：使用 agents/screen-planner.md、shared/references/screen-templates.md 和现有屏幕 TSX，内联起草 Screen Map / Navigation Contracts / 各屏幕规范变更；随后按与 Agent 结果完全相同的方式进行审核。
• Native Capabilities 和 Connectors：此技能已通过内联方式处理。
• 绝不可仅因叶级 Agent 不可用而跳过审批。

章节	Agent（只读）	输出文件
Data Model	mobile-app:data-model-architect	_dm_section.md + .tmp/dataverse-schema-contract.json
Native Capabilities	（内联处理 — 无需单独的 Agent）	_native_section.md
Screens	mobile-app:screen-planner	_screens_section.md

Spawn agent: mobile-app:<agent-name>

Prompt:
  Update the existing <section-name> section based on the user's change request.

  User request: <verbatim>
  Current section content: <verbatim>
  Working directory: <absolute path>
  Plugin root: ${PLUGIN_ROOT}
  Phase: planning
  Proposal only: <true for --plan-only or a planning-phase caller>

  Mode: edit (preserve existing decisions where the change doesn't affect them).
  Existing generated app must be updated after approval, so include enough detail for builders to mutate code without guessing.
  Return the updated section as a markdown file.

对于 Data Model 交接，还要逐字包含以下字段：

Dataverse planning mode: required
Normalized Dataverse foreground planning snapshot (validator input only): <SNAPSHOT_PATH>
Compact Dataverse architect evidence: <ARCHITECT_EVIDENCE_PATH>
Structured schema contract output: <working_dir>/.tmp/dataverse-schema-contract.json
Scope: <requested delta and necessary dependencies; preserve unrelated rows>
Native capabilities and connector ownership: <retained approved constraints>

对于结构化的 Dataverse 上下文／修订信号，先使用共享规划恢复流程，再考虑通用重试限制。对于其他信号，遵循 AGENTS.md： DONE 继续进行输出验证；DONE_WITH_CONCERNS: 必须呈现并记录；NEEDS_CONTEXT: 进行一次补充说明后的重试；BLOCKED: 在变更应用前停止；未知的首行视为 BLOCKED: malformed agent return。 所有 Data Model 结果（包括内联输出）都必须通过共享决策验证器；仅有 DONE 绝不授权执行 Step 3。 在 Step 3 之前，根据已完成的受影响部分提案重建进度载荷的 changes 数组。 每项变更都必须说明其必要原因。 对于 Data Model 差异，请纳入已验证规范化契约中的受影响表、相关列和关系，以便 Changes 选项卡呈现拟议的 ER 图。 对于 Screens 差异，请纳入受影响的现有屏幕和拟议屏幕，以及实际导航边，以便 Changes 选项卡呈现更新后的屏幕图。 写入此载荷后、将 approve 改为 waiting 前，运行 progress --json-file。

对于 Native Capabilities（无单独 Agent），请直接内联处理：读取当前能力表、应用变更并重新生成该表。对于 PDF/pen 行，请在表格中或紧接其下方注明存储/输出信息：

• native-pdf-viewer 0.2.9+ 可打开 HTTPS URL 和本地 file:// URI；不支持 content://、blob: 或 http://。
• 只有存在 expo-print 时，pdf-report 才会生成本地 PDF；本地输出可由 native-pdf-viewer 0.2.9+ 打开，在存在 expo-sharing 时可通过它共享，或上传到 Dataverse File 存储。
• pen-input 返回 PNG data URI；取消属于非错误状态；Dataverse 目标必须为 Image、File 或子级 Evidence/Signature 行。

对于连接器/数据源编辑，请阅读 connector-planning.md 和 /add-datasource 路由表，仅作参考。提出 ## Connectors 差异，列出操作、外部表/列表架构以及使用它们的屏幕。 Step 2 中不要执行连接器技能、创建连接或生成服务。如果连接器会驱动新屏幕/表单，请更新 Screens；获批后再于 Step 5 处理选定的叶节点。

对于移除/替换，请遵循 data-source-removal.md。 更改计划前，先记录当前注册清单，并提出保留/新增/刷新/移除集合。不要将未列出的表解读为允许删除。请纳入非屏幕使用方和离线依赖，保留服务器端表/记录，并在 Step 6.5 中沿用获批的移除集合。

第 3 步——确认意图、计划和应用变更预览

遥测检查点：approve_app_mutation_plan

在请求批准之前，将 plan: done 标记为完成，将 approve: waiting 设为等待，将顶层 phase: approval、waiting: true，然后运行 progress --json-file。修订会将 plan 恢复为 active。批准后，将 approve: done 标记为完成，将 save-plan: active 设为活动状态，清除 waiting，并再次运行该命令。取消后，将页面结算，并把剩余操作标记为 skipped。

对于 Dataverse 计划，在显示此确认步骤之前，必须针对当前规范化契约 和快照，通过 validate-dataverse-planning-decisions.js，且退出码为 0。修订时 需重复该检查。创建流程没有额外的批准步骤；保留此编辑现有的用户体验。

如果这是从其他负责人移交的计划阶段任务，现在就将经过验证的 提案和顾虑交还给该负责人，不保存实时计划，也不打开实施确认步骤。不要把调用方对计划的同意 当作应用编辑的批准。直接请求 --plan-only 时，仍需按下文所述明确批准计划文档。 返回之前，将 inspect、impact 和 plan 标记为 done；将批准、保存、 实施、验证、预览、同步和设备行标记为 skipped；清除 waiting；将顶层 phase: done、status: done 和 devicePreviewReady: false；并发布一次最终进度更新。 说明必须写明，经过验证的提案已交还给负责的工作流。

向用户展示所有变更计划部分的并排差异（或变更前后对比）。同时展示应用变更预览：

• 编辑概要：意图、目标屏幕/路由、数据/原生/JavaScript/设计依赖项，以及假设
• 要执行的数据/架构操作（/add-dataverse --skip-planning、添加连接器、添加原生包装器）
• 将要移除的确切应用数据源、需要更新的使用方，以及将保留的服务器数据
• 如果请求样本数据，则列出确切的允许使用的样本数据表及数量/媒体策略；排除将退役的表，且仅在明确批准后纳入必需的种子父级数据。 空的已批准集合不授权任何种子数据写入。
• 要创建、重写、重命名或删除的屏幕文件
• 要更新的导航/布局文件
• 要运行的验证命令
• 是否将重新生成 preview.html

询问：

“是否批准此编辑并将其应用到应用中？ (a) 批准并应用 (b) 修订——提供反馈以进行新一轮修改 (c) 取消——放弃变更”

如果选择修订 → 返回第 2 步，并附上用户的备注。如果选择批准 → 继续。如果选择取消 → 停止，保持计划和应用不变。

如果 $ARGUMENTS 包含 --plan-only，则将选项 (a) 改为“仅批准并保存计划”，并在第 4 步之后停止，明确说明应用有意保持不变。

步骤 4 — 编写计划差异

编写已批准的 native-app-plan.md 部分时，保持 save-plan: active。

将 native-app-plan.md 中已批准的部分替换为已批准的内容（其他所有部分原样保留）。打印统一差异，以便用户留存记录：

diff --git native-app-plan.md native-app-plan.md
---
+++ Section: Data Model
- | 🆕 Create (Tier 2) | contoso_workitem | ... |
+ | 🆕 Create (Tier 2) | contoso_workitem | ... |
+ | 🆕 Create (Tier 2) | contoso_case | Lookup → account, severity, status |

如果这是 --plan-only，则在 memory-bank.md 中将 plan_only: true，将 save-plan: done 标记为完成，将每一行实现、验证、预览和设备交接操作标记为 skipped，将顶层 phase: done、status: done 和 devicePreviewReady: false，并发布一次最终进度更新。保持 docs/create-app-plan.html 不变，因为它描述的是当前应用，而 native-app-plan.md 保存的是已批准但尚未应用的意图。然后打印确切的后续命令并停止。

对于实现运行，在步骤 8 验证已实现状态之前，保持 docs/create-app-plan.html 不变。 已批准的提案应保存在 native-app-plan.md 和编辑进度页面中，而不是当前应用的现行计划中。 在进度页面中将 save-plan: done 标记为完成，并将第一个适用的实现操作标记为 active。

已保存的计划描述的是已批准的意图，不代表已成功应用。当数据模型发生变化时，将新接受的 _dm_section.md 提案合并到此处；对于无关编辑，切勿重放过时的临时输出。保留无关部分，且不要重复使用绑定到旧计划的执行产物／批准回执。叶级操作仅在验证架构／服务结果后更新 .datamodel-manifest.json；待处理的退役项在步骤 6.5 之前保持过渡状态。在 memory-bank 中记录任何失败和剩余操作，不要声称此计划已应用。对于已批准的 Dataverse 实现，在 approved_scope 中冻结共享工作流的 contract_sha256 和最终保存计划的 plan_sha256，并保留绝对路径 planning_snapshot、architect_evidence 和 schema_contract。仅保存计划不会创建此实现批准上下文。

步骤 5 — 应用应用变更

遥测检查点：apply_app_mutations

对以下每项适用操作完成后，都要更新进度页面。仅在各自的叶级操作运行期间，将 data、native 和 design 标记为 active；随后根据实际结果将其标记为 done、skipped 或 failed。每次状态转换后运行 progress --json-file，以便检查清单标明当前正在运行的操作。

按依赖顺序应用各部分，确保屏幕始终基于当前的数据／原生功能界面构建：

仅运行已批准差异中的操作，不要运行现有计划中的每个部分。每次交接（包括经由路由器和重试时）都要传递 MOBILE_APP_ORCHESTRATING=1 和上述明确的实现上下文。重复使用已提供的答案；如果未解决的选择会改变范围，则返回批准关卡。 0. 数据编辑的环境漂移门禁 — 在处理 Dataverse、SharePoint、连接器或示例数据之前，对比 memory-bank.md、power.config.json 和 .resolved-environment.json。如果它们不一致，展示各项值，并询问用户要使用哪个环境。确认之前不要创建表或连接。

1. 数据模型 — 使用获批的变更内容和下方限定范围的规划上下文调用 /add-dataverse --skip-planning，而不是传入计划中的所有行。 该叶级操作会验证证据/审批哈希，并在执行限定范围的变更前重新进行实时协调；不使用任何仅创建部分内容的快速通道标志，也不伪造创建回执。它会刷新受影响的服务、更新已验证的清单，并确保生成的服务能够编译。 传入 offline_reconciliation_owner: edit-app；步骤 5.6 负责离线检查，因此叶级操作应返回已验证的变更内容，不要重复提示。 操作返回后，运行 npm run generate-schemas 和 npx --no-install tsc --noEmit；只有检查通过后才能继续处理屏幕。
2. 示例数据 — 仅为步骤 3 中获批的明确表白名单填充数据。 将变更屏幕所用的新建 Dataverse 表作为候选项提出，而不是纳入整个项目清单。区分 createdThisEdit 与历史清单中的 status: new；现有/复用的父表必须明确纳入。 根据已验证的输出和退役集合验证获批的名称。 范围为空时跳过数据填充。缺失/未验证/即将退役的目标应退回负责人修正，不得回退到项目范围的数据填充。传入下方的交接内容。 如果插入失败，记录部分结果；只有应用能够处理空状态时才继续；绝不要报告数据填充覆盖完整。
3. 连接器/数据源 — 存在歧义时，阅读并执行 /add-datasource；对于获批的连接器变更，执行 /add-sharepoint 或 /add-connector。要刷新保留的数据源，请传入仅供技能使用的 --refresh --data-source-name "<registered-name>"，并在 approved_scope 中提供其已验证的身份信息；不要通过新增流程处理刷新。对于不涉及架构变更、仅修复服务的 Dataverse 操作，也使用同一刷新分支。重新生成服务，并在 memory-bank.md 中记录连接说明。
4. 纯 JavaScript 依赖项 — 对获批的 ## Screens → ### JavaScript Dependencies 表中新增或变更的行，执行 shared/references/javascript-dependency-planning.md 中的安装契约。审批即表示同意使用其中确切的软件包和版本。先安装并验证，再处理屏幕；如果最终检查发现原生代码/配置或不兼容的运行时依赖项，只移除新添加的软件包，并以确切的失败标准停止。
5. 原生功能 — 对每项新增功能，阅读并执行 /add-native <capability>。不要安装缺失的原生软件包，也不要伪造包装器。如果当前模板不支持某项功能，请在重建导入该功能的屏幕前停止，记录阻塞原因，并告知用户缺少哪些上游模板支持。
6. 设计 — 阅读并执行获批的 /design-system 操作（刷新、 重新设计、主题或回滚）。在子进程环境中加入 CODE_APPS_NATIVE_ORCHESTRATING=1，以禁止打开中间浏览器标签页，同时加入上方限定范围内的 MOBILE_APP_ORCHESTRATING=1 上下文。验证前，将其 Tamagui 集成参考应用于变更的令牌/主题和提供程序接线；仅有品牌资源并不能证明已完成运行时集成。仅变更令牌通常不需要重写屏幕 TSX；组件/密度/否定规则的变更则可能需要。应在步骤 6 中重建受影响的屏幕，而不是提前返回。 对于获批的自定义深色调色板，执行参考中的获批的深色调色板分支：将 darkTokens.color 接入 appDarkTheme，再接入提供程序的 brandedDarkTheme。验证导出/键以及解析后的深色表面/文本值；仅写入 brand/tokens.dark.ts 并不算完成。 Step 5 处理新增和刷新，不处理移除。如果 Data Model 的变更仅涉及移除，不要针对缩减后的计划运行 /add-dataverse 的新增工作流：它既不会注销旧源，也无法安全地更新其使用方。将已批准的退役操作推迟到 Step 6.5，在更新源的使用方之后执行。

对 Data Model、Connector/Data Source、JavaScript Dependency 或 Native Capabilities 进行任何变更后，在处理屏幕之前，重新运行生成服务/依赖项/原生封装器探测。屏幕提示词必须反映磁盘上的当前内容，而不是早期计划中的预期内容。

Dataverse 交接（仅适用于已批准的架构/新绑定工作）：

Invoke skill: /add-dataverse

Context:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: edit-app
  working_dir: <working_dir>
  phase: implementation
  offline_reconciliation_owner: edit-app
  planning_snapshot: <SNAPSHOT_PATH>
  architect_evidence: <ARCHITECT_EVIDENCE_PATH>
  schema_contract: <working_dir>/.tmp/dataverse-schema-contract.json
  approved_scope: <accepted delta and dependencies, contract_sha256, plan_sha256>

Arguments:
  --working-dir '<working_dir>'
  --plan-section '<working_dir>/native-app-plan.md#data-model'
  --skip-planning

示例数据交接（仅适用于非空且已批准的种子范围）：

Invoke skill: /add-sample-data

Context:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: edit-app
  working_dir: <working_dir>
  phase: implementation
  approved_scope: <approved seed tables, count/media policy, and lookup decisions>
  retiring_tables: <approved retirement list, or empty>

Arguments:
  --working-dir '<working_dir>'
  --tables "<approved-seed-table-logical-names>"
  --exclude-tables "<retiring-table-logical-names-or-empty>"

这些是技能参数，不是 Dataverse CLI 标志。允许列表之外的必需上级项会返回 NEEDS_CONTEXT；播种叶节点不得扩大范围，也不得为了满足覆盖规则而对正在过渡退役的表进行播种。

Step 5.5 — 刷新生成的服务快照

在任何数据源/架构/连接器变更后、任何屏幕构建器提示之前运行：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
for svc in src/generated/services/*.ts; do
  [ -e "$svc" ] || continue
  name=$(basename "$svc" .ts)
  methods=$(grep -oE 'static async [a-zA-Z_]+' "$svc" | sed 's/static async //' | tr '\n' ',' | sed 's/,$//')
  echo "| \`$name\` | \`src/generated/services/$name.ts\` | $methods |"
done

在 native-app-plan.md 中的 ## Screens 后立即替换或创建 ## Generated Services (snapshot at <ISO timestamp>) 部分。如果没有服务，写入一个空表并附上一条说明。屏幕构建器必须以此表为准。

将已批准的移除集合中仍然存在的服务标记为正在退役：构建器不得引入或保留对它们的依赖。Step 6.5 之后再次刷新此快照，使其描述实际剩余的输出。

不要让用户手动运行这些后续技能。本技能是编排器。

Step 5.6 — 离线配置文件协调

如果 Step 5 创建或扩展了 Dataverse 表，现有的 Mobile Offline Profile 可能会缺少这些表/列（新表不会同步到设备；新列的内容为空白）。Step 5 的完整且限定范围的 /add-dataverse --skip-planning 交接会指定 offline_reconciliation_owner: edit-app，因此此编排器负责检查，而不是由叶节点在 Step 8.5 负责。仅有此标志还不够。如果本次编辑没有发生 Data Model 变更，则跳过。

对于混合新增/移除的编辑，在提供/应用配置文件变更之前，将任何返回的新增项与已批准的保留/新增 Dataverse 集合求交集。不得仅因为某个表的过渡清单条目会保留到 Step 6.5，就将正在退役的表添加到离线配置文件。

运行本地、无网络的差异检查：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node "${PLUGIN_ROOT}/scripts/offline-profile-delta.js" --project-root '<working_dir>'

记录退出状态以及 stdout/stderr，并在继续之前遵循 offline-profile-reconciliation.md 中的失败处理流程：非零退出状态、status: error、JSON 格式错误/缺失或未知状态，都会跳过变更辅助程序，并以 DONE_WITH_CONCERNS 结束（如果已应用变更），否则以 BLOCKED 结束；绝不能视为干净成功。 对于有效的 no-manifest / no-profile / in-sync，静默继续。 对于 delta，获取批准并执行参考文档中的 限定范围辅助程序交接，并指定 orchestrator: edit-app、相同的绝对 working_dir、phase: implementation 以及确切的已批准环境/配置文件/表范围。向每个辅助程序传递 --working-dir '<working_dir>' 以及其表和列参数，然后通过相同的失败处理流程重新检查。 在 Step 8 的 memory-bank 条目中记录结果，不要清除待处理的 offlineRetirement 结果。

这些状态仅涉及新增项。保留之前尝试中的任何 offlineRetirement 结果，并在 Step 6.5 收集移除叶节点更新后的结果；in-sync 结果绝不能解决待处理的退役事项。

Step 6 — 重建受影响的屏幕

遥测检查点：rebuild_affected_screens 在路由、布局或共享代码相关工作开始前，将 screens: active。每轮构建完成后更新其备注， 例如 Wave 2 of 3 complete，并运行进度命令。只有在导航/骨架检查关卡和所有必需的 构建轮次均通过后，才能将其标记为 done。

根据计划差异和用户请求，构建受影响的屏幕集：

Change type	Screens to rebuild
Existing screen behavior/layout/state/search change	指定的屏幕
New detail screen	新详情屏幕，以及导航到该屏幕的来源列表/搜索屏幕
New create/edit form	表单屏幕，以及启动该表单并在获得焦点时刷新的父级列表/详情屏幕
New scanner/camera/PDF/pen workflow	功能屏幕，以及它所路由到的任何结果/详情/表单屏幕
Data-model field added for visible UI	显示或写入该字段的每个屏幕
Data source removed/replaced	每个获准的使用方，包括共享钩子/辅助函数和原生上传/同步代码；这些编辑完成前保留旧注册
Navigation pattern changed	每个标签页/根屏幕，以及契约已更改的任何路由
Design component/density/reskin changed	布局规范受影响的所有屏幕；全面重设计时，执行广泛的屏幕轮次或受控样式清理

启动构建器前：

• 将获准弃用的服务/来源列表传给每个受影响的构建器。 仍然存在的生成文件属于过渡依赖，不能据此保留或引入本次编辑旨在移除的用法。
• 如果导航发生变化，按照 /create-mobile-app 第 10b 步的布局规则更新路由布局文件。
• 为新屏幕创建缺失的路由文件夹。
• 如果数据源/架构发生变化，按照 /create-mobile-app 第 10.7 步的规则刷新 ## Generated Services 表格。
• 如果两个或更多受影响的屏幕共用实体行/卡片、选项映射、游标钩子或保存辅助函数，则按照 /create-mobile-app 第 10.8a 步生成或刷新应用专用共享代码。
• 对于全新屏幕，在调用构建器前，按照 /create-mobile-app 第 10.8b 步的模式编写带类型的骨架文件。
• 对于现有屏幕，不要用骨架覆盖文件。以编辑模式将当前文件内容和变更请求传给构建器。如果导入项/数据钩子发生变化，则在构建器填充或修改 JSX 前，先精确更新这些内容。
• 对于已移除的屏幕，仅在用户于第 3 步批准删除后，才删除路由文件并移除布局条目。

导航/布局算法：

• 阅读获准的 ## Screens 屏幕映射和导航契约。
• 编辑前将每个目标文件规范化为其 Expo 路由。拒绝重复的规范化路由，尤其是 <parent>/[id].tsx 与 <parent>/[id]/<child>.tsx 同时存在的情况；在运行构建器前，将详情契约移至 <parent>/[id]/index.tsx。
• 对于每个新路由，创建父文件夹；如果路由为嵌套路由，还要创建内部 _layout.tsx。
• 对于模态框/表单页/详情路由，在所属文件夹布局中添加正确的 <Stack.Screen name="..." options={{ presentation: 'modal' | 'formSheet' }} />。
• 对于标签页/根路由变更，仅修改 app/(app)/_layout.tsx 中的路由列表；保留身份验证/提供程序逻辑，以及与路由注册无关的导入项。
• 对于已移除的路由，仅在用户于第 3 步明确批准后，才删除路由文件并移除布局条目。
• 路由/布局编辑完成后、启动构建器前，如果命令可用，运行 npm run check-routes --if-present 或 node scripts/check-routes.js。

共享脚手架算法：

• 如果缺少 src/components/index.tsx、src/hooks/index.ts、src/utils/index.ts 或 src/tokens/index.ts，请从 shared/samples/src/ 复制缺失文件。切勿覆盖现有的共享文件。
• 如果受影响的屏幕共用实体卡片/行、选择映射、游标 Hook、详情 Hook 或保存辅助函数，请在启动构建器之前创建或更新专用的应用级共享文件。
• 对于全新屏幕，请使用相关的 /create-mobile-app 第 10.8b 步模板，在 target_file 中编写带类型的骨架。屏幕构建器运行前，骨架必须能通过 return null 编译。
• 对于现有屏幕，切勿用骨架替换整个文件。仅当经批准的修改会改变数据/原生表面时才修改导入/Hook，然后要求构建器保留现有行为。

运行导航/骨架检查门，再进行屏幕构建器工作：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
npx --no-install tsc --noEmit

如果检查失败，请批量修复布局、路由名称、骨架导入、生成服务名称、共享导出或 Hook 签名，然后再运行一次。不得从有问题的壳层启动屏幕构建器。

步骤 6.1 — 屏幕构建器预检与分波次

第一波开始前，使用无操作的屏幕名称，静默运行针对 mobile-app:screen-builder 的 Task 预检。如果不可用，只提示一次，并使用 agents/screen-builder.md 在行内构建。行内模式必须满足相同的质量规则。

将受影响的屏幕分成多波，每波最多 5 个。每一波：

1. 输出波次开始信息：Wave <N>/<N> starting: <screen names>。
2. 在一条消息中启动所有构建器，以便它们并行运行。
3. 按 AGENTS.md 解析每个结果的首行（DONE、DONE_WITH_CONCERNS、NEEDS_CONTEXT、BLOCKED）。首行未知时视为 BLOCKED。
4. 对 NEEDS_CONTEXT，使用计划/文件/服务中的缺失上下文重试一次。
5. 遇到 BLOCKED 时停止，除非用户选择使用经批准的占位项跳过。
6. 每波结束后、启动下一波之前，运行 npx --no-install tsc --noEmit。
7. 如果该波检查失败，按根本原因归类错误，并向受影响的构建器重新提供汇总后的 TypeScript 输出。每个屏幕最多重试 2 次。

在第 N 波通过检查之前，不得启动第 N+1 波。

按最多每波 5 个屏幕的方式启动 mobile-app:screen-builder Agent。向每个构建器提供以下提示：

Follow screen-builder.md.
Mode: edit existing generated app.
User change request: <verbatim>
working_dir: <absolute path>
screen_name: <screen id>
route: <route>
target_file: <absolute path>
plan_path: <absolute path>/native-app-plan.md
current_file: <paste current file content if the file exists>

Preserve unaffected behavior from the existing screen. Apply the approved plan diff. If this is an existing screen and no skeleton marker is present, update the screen from current_file instead of falling back to sample layout.

步骤 6.5 — 注销已退役的数据源

如果经批准的移除集合为空，则跳过。步骤 6 更新/移除使用方后，请重新检查是否有保留的数据源依赖即将退役的注册项。 对于 Dataverse 绑定，通过 /add-dataverse 执行 data-source-removal.md；对于 SharePoint，通过 /add-sharepoint 执行；对于其他连接器/过程/流程，通过 /add-connector 执行。传入移除模式、准确的已注册标识，以及当前经批准的编排上下文。 使用仅供技能使用的 --remove 参数选择移除模式；切勿将其传给 CLI。

叶级流程会绕过添加工作流，并使用受支持的 CLI 移除命令；该命令负责清理 .power/schemas/、src/generated/ 和 power.config.json。 然后重新生成运行时架构映射，验证注册项及生成的输出是否已移除/保留，并核对应用清单和离线影响。最终验证前，再次刷新 Generated Services 快照。 如果没有操作、清理不完整或仍有使用方，则不得完成；不得将新计划标记为已完全应用，也不得手动修改生成文件/配置文件。 将每个叶级流程的 offlineRetirement 状态带入步骤 8，包括有意保留的覆盖范围以及待定的决策/迁移。不得用步骤 5.6 的仅新增结果替换这些状态。

第 7 步 — 验证

遥测检查点：validate_edited_app

在第一个关卡前将 verify: active，并运行进度命令。如果关卡未通过，在执行有限范围的修复时保持该状态为 active，并在备注中记录失败的命令。如果无法完成验证，将其标记为 failed；只有所有必需的重跑都通过后，才标记为 done。

修改后运行验证。批量修复根本原因，然后将失败的关卡重跑一次。根据变更内容选择验证项，但每次修改应用后都必须运行 TypeScript 检查。

必需的关卡，根据变更内容选择：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
npm run generate-schemas      # if any data source/schema/connector changed
npx --no-install tsc --noEmit              # always after app mutation
npm run check-routes --if-present

如果没有 npm run check-routes，但存在 scripts/check-routes.js，则运行：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node scripts/check-routes.js

当屏幕文件发生变更时，明确运行移动插件的报告模式验证器：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node "${PLUGIN_ROOT}/hooks/validate-screen-quality.js" --report <changed-screen-files-or-app-dir>
node "${PLUGIN_ROOT}/hooks/validate-color-contrast.js" --report <changed-screen-files-or-app-dir>

将验证器发现的问题视为创建流程关卡失败：仅采集一次，按根本原因归并，修复后将同一验证器重跑一次。这些脚本仅在移动工作流中调用；不要将它们注册为插件级钩子。

第 7.1 步 — 针对性样式质量检查

当屏幕文件发生变更时，针对已变更的屏幕文件以及此次编辑中变更的任何路由布局，执行 /create-mobile-app 第 11.4 步的精简检查。

规则：

1. 若 validate-screen-quality.js --report 和 validate-color-contrast.js --report 可用，则运行它们。
2. 按文件和规则合并问题。
3. 自动修复可确定的问题：可读性较差的令牌、带白色文字的黄色／橙色徽章、缺少 aria-label 的纯图标、缺少 role、过小的图标点击目标、原始十六进制令牌、缺少安全区域内边距、allowFontScaling={false}。将这些 Web 标准无障碍属性应用于 Tamagui 2 组件；原始 React Native 组件保留其 React Native 无障碍属性。
4. 将需要判断的问题视为待关注事项，而非无限循环处理：复杂的安全区域重构、含糊的品牌颜色选择、大幅层级重设计，或需要大量移动 JSX 的空状态改写。
5. 对已触及的文件重新运行相同的报告验证器。每个文件、每个验证器最多重试 2 次。
6. 样式修复后运行 npx --no-install tsc --noEmit。样式问题可以保留，但 TypeScript 检查必须通过。

如果重试后仍有可自动修复的问题，则在 memory-bank.md 中记录 DONE_WITH_CONCERNS，并汇总文件和规则。

如果验证失败是因为此次编辑暴露了过时的生成服务，则在手动修改屏幕之前，重新运行相关的数据源生成一次。如果失败属于无关的既有问题，应单独报告，不要将其伪装成编辑成功的结果。

第 8 步 — 预览和 memory-bank 更新

遥测检查点：refresh_app_preview_and_history

重新生成 preview.html 时，将 preview: active；若可见界面未发生变化，则将其标记为 skipped。然后根据已验证的应用状态构建 <edit-temp-dir>/app-plan-sync.json，并将 sync-plan: active。载荷必须包含每个已变更部分的完整快照（包括删除内容），以及这些部分负责的预览和验证备注。运行：

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' sync \
  --json-file '<edit-temp-dir>/app-plan-sync.json'

同步成功后，将 sync-plan: done，完成所有适用的检查清单项，将顶层 phase: done 和 status: done，并最后运行一次进度命令，但必须等到下方的设备测试交接更新手机状态之后再运行。 在最后一次写入进度前，根据已验证的应用状态核对每条变更记录。 根据最终规范化契约更新数据模型表和关系，并根据最终路由和导航布局更新屏幕节点和边。 已完成的编辑页面与 docs/create-app-plan.html 必须描述相同的最终结构。 如果同步渲染失败，记录这一问题，但不要错误地将应用编辑或验证报告为失败。 第 8 步之前，在本次 /edit-app 运行完成所有代码编辑后，npx --no-install tsc --noEmit 必须通过。如果在第 7 步执行 tsc 后又编写了代码，请重新运行 npx --no-install tsc --noEmit，批量修复根本原因，并仅在 TypeScript 无错误时继续。

如果 UI、设计、导航、原生交互或可见数据状态发生了变化，或者用户明确要求查看预览，请在验证后使用 MOBILE_APP_ORCHESTRATING=1 和 MOBILE_APP_EMBED_PREVIEW=1 阅读并执行 /preview-screens。 这会重新生成 preview.html，且不会打开单独的浏览器页面。 文件写入后，将相同的屏幕放入手机栏，并发布进度页面：

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' phone --stage screens \
  --preview-file '<working_dir>/preview.html'

保持进度页面处于打开状态。 它会在沙盒化的手机轮播中展示屏幕，提供指向 preview.html 全尺寸视图的链接，并通过相同的手机状态让动态更新的 docs/create-app-plan.html 保持同步。 如果跳过了预览或生成失败，请将手机留在当前进度状态并报告此问题。

除非这是 --plan-only，否则请以真实设备交接作为最后一步。阅读 /create-mobile-app 第 12 步中从 Launch command 到 Put the QR in the plan 的内容，并在同一个 <working_dir> 中执行该流程。启动前，对每个 <working_dir>/.powernative/metro-logs/metro-*-pid-*-port-*.log 候选文件，执行 /debug-app Phase 0.0 中针对项目本地日志、PID 和端口归属的检查。

• 恰好有一个会话处于运行状态时，复用该会话。从经过净化的日志中读取原生 Metro URL，确认 URL 端口与运行中的日志端口一致，并且不要运行 npm run dev。
• 没有会话处于运行状态时，使用模板自带的 npm run dev 启动 Metro，并捕获它输出的 URL。
• 有多个会话处于运行状态，或 PID、端口、日志和 URL 不一致时，展示这些会话并询问要使用哪一个。选择尚未确定前，不要启动其他服务器。

使用固定版本的 npx --no-install qrcode 根据选定的 URL 生成 .expo/metro-qr.png。然后通过现有的手机命令更新这两份文档：

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' phone --stage qr \
  --qr-image '<working_dir>/.expo/metro-qr.png' --qr-url "<metro-url>"

不要打开 docs/create-app-plan.html；其中的手机内容会在后台更新。此命令成功后，最后执行一次设置了 devicePreviewReady: true 的 progress 写入，这样已打开的编辑页面就会用相同的 QR 码替换屏幕轮播，并显示 Power Apps Mobile Preview 的 App Store 和 Google Play 按钮。如果 Metro 或 QR 码生成失败，请保持 devicePreviewReady: false；已完成的编辑页面随后会显示“设备预览不可用”，即使动态更新的计划中包含先前运行生成的 QR 码。请单独报告预览问题，不要将已验证的应用编辑判定为失败。

如果用户提供了具体的运行时症状，且 Metro 已通过原生开发客户端流程运行，则可以在静态验证和预览步骤后调用 /debug-app "<symptom>"。这是可选的症状调试交接，不是验证门槛：不要逐屏进行运行时检查，不要遍历路由，不要使用 React Native Web，也不要直接调用 Metro HTTP 端点。

在 memory-bank.md 中追加一条编辑记录：

### Edit: <yyyy-mm-dd> <short title>
- Request: <verbatim or concise summary>
- Intent brief: <target screens/routes, data surface, native capability, design scope>
- Assumptions: <inferred choices or none>
- Skills/agents invoked: <data-model-architect, screen-planner, add-dataverse, screen-builder, etc.>
- Plan sections changed: <Data Model / Native Capabilities / Screens / Design / Connectors>
- App changes: <screens/routes/native wrappers/data sources>
- Verification: <commands/gates + pass/fail/skipped with reason>
- Preview: <preview.html path or not generated>
- Debug handoff: <not requested / /debug-app "<symptom>" invoked>
- Offline retirement: <per-table not-applicable / retained with reason / pending / reconciled with verification>
- Blocks/concerns: <none or list>

最终总结必须说明应用中有哪些更改、运行了哪些验证、预览位于何处、是否已更新现行应用计划以反映最新验证通过的更改，以及是否请求了症状调试交接。只有在最终同步成功时，才能声称计划已更新；否则应说明应用编辑已通过验证，但现行计划刷新失败，并指出这一问题。除非明确使用了 --plan-only，否则结尾不得声称代码库未更改。 如果任何 offlineRetirement 结果为 pending，则返回 DONE_WITH_CONCERNS，并单独说明尚未完成的决定：「应用更改已完成。离线配置文件仍包含 Orders；是否保留或移除此覆盖范围尚待决定。」替换为实际表名，且只有验证通过时才能声称应用已完成。不得自动移除配置文件条目来消除这条说明。

说明

• native-app-plan.md 仍是可靠的事实来源。更改应先规划再应用，但规划并非最终状态。
• 对于涉及多个部分的复杂编辑，应先更新并审核所有必需部分，再按依赖顺序应用变更。不得留下引用缺失 Dataverse 存储功能的原生能力条目，也不得留下从未规划过的屏幕状态。
• 架构师 Agent 与 native-app-planner 在初始创建时使用的相同，因此这里的规划改进会沿用。
• 此技能有意涵盖生成后的迭代。若获批的编辑需要，/edit-app 可以修改 Dataverse、src/native/、路由布局、屏幕 TSX、品牌令牌、preview.html 和 memory-bank.md。