app-flow-buildlisted

# App Flow Build 把当前 App 代码变更落实为可验证的实现。架构、技术栈和验证方法必须来自目标仓库证据，不预设 React Native、Expo、Flutter、原生或其他方案。 ## 边界与准备 - 先读取目标仓库根级以及目标目录最近层级适用的 `AGENTS.md` / `CLAUDE.md`，遵循它们指向的 source of truth；规则冲突时以最具体且适用于当前文件的为准。再检查现有架构、依赖、脚本、测试和代码模式。 - 先用代码、配置、日志或失败测试诊断根因，再修改；证据不足时缩小未知项，不猜框架或重写无关系统。 - 只读诊断不要求已获写文件授权，也不修改文件；返回定位证据、标为 `proposed / not-applied` 的最小候选补丁，以及标为 `not run` 的回归方法。证据不足则返回 `blocked`，不伪造根因、补丁或测试结果。 - 只处理当前代码行动：功能、数据、导航、原生集成、重构或修复，以及相称测试。产品范围、原型交互、最终视觉规范、独立评审与打包交付留给匹配能力。 - 保留用户已有与无关改动；不覆盖、回退或顺手整理它们。 - 未获得具体渠道与动作的明确授权不得发布。长时间执行只延长持续性，不扩大 push、deploy、Release 等外部副作用权限。 ## 实现与验证 1. 写清当前目标、可核验 acceptance、允许修改范围和未知项。 2. 从现场证据确定最小改动点；能复现时先留下失败证据或测试，再实现最小修复。 3. 沿目标仓库已有结构实现功能、数据、导航、原生集成或修复，并添加与风险相称的测试。 4. 用新鲜命令输出验证改动、相关测试与回归；失败就报告真实诊断。编译或 typecheck 通过不等于 UX 或人工验收通过，未执行的检查必须明确标注。 ## 参考知识 需要构建产物时按需读取，不预先展开： - [`references/build-production.md`](references/build-production.md)：正式构建的通用取舍——版本、runtime、签名、可复现与产物核对。 - [`references/build-preview.md`](references/build-preview.md)：预览/开发构建的通用取舍——快速迭代、独立 profile 与内部分发。 这些是跨技术栈的思路骨架，不是具体命令；真实命令与本机私有配置只留在被忽略的 `local/`，不写进可分享文件。 ## 独立与 Flow 两种模式 - **独立模式**：短任务直接返回结果，不建立全局恢复点。 - **Flow 模式**：把完整 `outcome`、`acceptance_status`、`changes`、`evidence`、`tests`、`unknowns`、`risks`、`next` 返回给 `app-flow` 父 owner，由它独占任务恢复权，本能力不创建全局恢复指针。 `acceptance_status` 显式取值：`completed`（全部 acceptance 有新鲜证据）、`partial`（部分满足且已列剩余项）、`failed`（当前行动或必要验证失败）、`unverified`（有实现/候选但必要验证未执行）、`blocked`（缺证据、输入或授权无法安全继续）。只有新鲜证据支持时才能声称文件已改或测试通过。 ## 本地 Memory 本 Skill 只拥有自己的 `local/`，默认被