按优先级 read 每个文件前 300 行（优先读 Activity 源文件）。

读取时重点关注：

• - startActivity() / navigate() → 页面跳转
• Toast.makeText() 的文本 → 操作反馈（成功/失败提示）
• if/else + return → 约束条件和阻断逻辑
• isEnabled / isVisible / visibility = View.GONE/VISIBLE → UI 状态变化
• 硬编码字符串（特殊校验码、账号、特定数值）
• FLAGACTIVITYCLEAR_TOP → 清栈跳转（影响回退路径）
• 异步回调（网络请求完成后跳转等）

Step 3：LLM 生成 8 份文档

拿到源码后，逐个生成以下文档。每份文档聚焦一个维度，独立分析。

📋 文档1：业务全景（Business Overview）

分析维度：

• - App 属于什么业务领域
• 核心功能模块有哪些
• 哪些功能已实现 vs 暂未开放（仅 Toast）
• 技术栈（从 build.gradle 推断导航框架/网络库/DI 框架）

输出 JSON：
{
businessType: 移动电商/工具/社交/...,
summary: 一句话描述这个 App 是干什么的,
modules: [模块名: 功能描述],
unimplemented: [功能名: 现状描述（如：点击仅弹Toast）],
techStack: {
navigation: startActivity / Jetpack Navigation,
network: Retrofit / 无网络,
di: Hilt / 无
}
}

🔄 文档2：用户旅程地图（User Journey Map）

分析维度：

• - 用户从 Launcher Activity 开始的所有完整路径
• 每条路径的触发方式和前置条件
• 每个步骤的关键控件 ID
• 路径的终点和预期状态
• 是否存在快捷路径（绕过正常流程）

输出 JSON：
{
journeys: [
{
name: 流程名（如：核心购买流程）,
priority: P0必测/P1重要/P2可选,
steps: [
{
step: 1,
page: LoginFlowActivity,
action: 输入用户名和密码，点击登录,
keyControls: [etusername, etpassword, btn_login],
waitCondition: 等待页面跳转或 Toast 出现
}
],
preconditions: [前置状态：App 处于未登录状态],
expectedFinalState: 页面跳转至 HomeFlowActivity
}
]
}

✅ 文档3：验证点与断言（Assertions）

这是最关键的文档。 AI 测试 Agent 需要知道每个操作后如何判断成功或失败。

分析维度：

• - 每个关键操作后，UI 应该发生什么变化？
• 成功时：跳转到哪个页面 / 出现什么 Toast 文本 / 哪个控件变化
• 失败时：停在哪个页面 / 出现什么错误提示
• 操作后需要等待多久才能断言（同步/异步）

输出 JSON：
{
assertions: [
{
scenario: 场景描述（如：空账号点登录）,
page: LoginFlowActivity,
trigger: btn_login,
successCondition: {
type: pageSwitch / toast / controlChange,
target: 跳转到 HomeFlowActivity,
detail: Activity 变为 HomeFlowActivity
},
failureCondition: {
type: toast,
target: Toast 文本包含「请输入手机号/邮箱」,
detail: 页面停留在 LoginFlowActivity
},
waitMs: 500,
note: 登录是同步操作，无需长等待
},
{
scenario: 功能B前置条件未满足时触发操作,
page: ,
trigger: ,
successCondition: {
type: pageSwitch,
target: 跳转到 PageB
},
failureCondition: {
type: toast,
target: Toast 文本包含「请满足前置条件」
},
note: 前置条件： 等必要条件未满足时，操作应被阻断
}
]
}

🔗 文档4：状态依赖图（State Dependencies）

分析维度：

• - 哪些功能需要 App 处于特定状态才能访问？
• 功能间的依赖关系（如：必须先登录才能访问核心功能）
• 操作会如何改变状态（如：核心操作完成后页面状态重置）
• 状态的持久化方式（内存 vs SharedPreferences vs 数据库）

输出 JSON：
{
stateDependencies: [
{
feature: 进入功能模块B,
requires: [用户已完成登录流程],
howToReach: 从登录页完成登录后，进入 HomeFlowActivity 点击对应入口
},
{
feature: 触发核心操作,
requires: [已进入目标页面, 至少满足一项前置条件（如 已勾选）],
howToReach: 进入 ，满足前置条件后点击
}
],
stateChanges: [
{
action: 核心操作完成,
before: 已进入目标页面，操作前状态已满足,
after: 清栈跳转回 HomeFlowActivity，页面状态未持久化（内存数据）,
implication: 测试操作完成后，重新进入目标页面需要重新构造前置状态
}
]
}

⚠️ 文档5：边界与异常场景（Edge Cases）

分析维度：

• - 数值边界：最小值、最大值、边界值±1
• 空值/非法输入：每个表单的验证规则
• 状态边界：某个功能恰好在满足/不满足条件时的行为
• 并发/重复操作：快速点击两次会怎样

输出 JSON：
{
edgeCases: [
{
scenario: 数值输入最小值（边界）,
page: PageA,
setup: displayid> 当前为最小值,
action: 点击减少数量按钮,
expected: 数量保持最小值，出现 Toast「已达最小值」,
testValue: 最小值时再减,
assertType: toast + noChange
},
{
scenario: 数值输入超上限（超界）,
page: PageA,
setup: displayid> 当前为最大值,
action: 点击增加数量按钮,
expected: 数量保持最大值，出现 Toast「超出范围」,
assertType: toast + noChange
},
{
scenario: 输入框大小写敏感验证,
page: PageA,
action: 输入框输入特殊值的小写形式，点击提交,
expected: Toast 提示「操作成功」（大小写不敏感）,
assertType: toast
}
]
}

🚫 文档6：陷阱与禁区（Traps & Forbidden）

分析维度：
-