artifact: add FPA analysis outputs through round 6

2026-06-20 14:08:46 +08:00
commit 8bf8795f96
105 changed files with 4324 additions and 0 deletions
@@ -0,0 +1,26 @@
+Feature: accountant-workload-and-assignment
+
+  Scenario: Happy Path
+    Given Firm Owner 打开团队推进页，且系统已汇总每位会计师的客户数、案件数、临期压力、缺件积压与风险事项
+    When Firm Owner 查看会计师负载并将一个案件重新分配给更合适的会计师
+    Then 系统应更新案件归属与后续跟进责任，并让团队负载判断保持清晰可追踪
+
+  Scenario: Permission Case
+    Given Accountant 尝试进入会计师负载与分配管理区
+    When Accountant 查看团队级负载与分配入口
+    Then 系统应限制其执行团队分配调整，并保持该能力只属于 Firm Owner
+
+  Scenario: Error Case
+    Given Firm Owner 发起案件重新分配，但目标会计师不可用或分配写入失败
+    When Firm Owner 提交新的归属关系
+    Then 系统应明确提示分配失败原因，并保持原有负责人不被静默覆盖
+
+  Scenario: Edge Case
+    Given Firm Owner 查看团队负载时，发现两位会计师的总体案件数相近，但其中一位存在更高的临期压力与风险积压
+    When Firm Owner 比较团队负载
+    Then 系统应突出显示真实的推进压力差异，而不是仅按案件数量给出误导性结论
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器浏览团队推进页
+    When Firm Owner 顺序查看负载指标、负责人列表与分配动作
+    Then 系统应让负载信息、责任变化与操作结果可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: automation-effect-observability
+
+  Scenario: Happy Path
+    Given Firm Owner 打开自动化策略页，且系统已汇总自动提醒发送记录、客户响应情况与案件推进结果
+    When Firm Owner 查看自动化效果观察区
+    Then 系统应展示自动化是否真正减轻团队负担并提升推进效率，而不是只显示规则开启状态
+
+  Scenario: Permission Case
+    Given Accountant 尝试访问自动化效果观察区
+    When Accountant 查看自动化效果指标
+    Then 系统应限制其使用老板级效果评估视图，并保持该能力仅对 Firm Owner 开放
+
+  Scenario: Error Case
+    Given Firm Owner 查看自动化效果时，发现自动化执行日志不完整或统计周期内关键指标缺失
+    When Firm Owner 查看效果观察区
+    Then 系统应明确提示数据不足或统计异常，而不是输出看似准确但不可依赖的效果结论
+
+  Scenario: Edge Case
+    Given Firm Owner 复盘自动化效果时，发现自动提醒发送量增加，但客户响应率和案件推进速度没有改善
+    When Firm Owner 比较当前周期与上一个周期的效果
+    Then 系统应把这种无效自动化识别为需要关注的异常，而不是默认判断为效果提升
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器查看自动化效果指标
+    When Firm Owner 浏览摘要指标、趋势对比与异常提示
+    Then 系统应让关键数据关系、趋势变化与异常结论可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: automation-sensitivity-rules
+
+  Scenario: Happy Path
+    Given Firm Owner 打开自动化策略页，且系统已识别客户等级、关系敏感度与业务风险标签
+    When Firm Owner 将高价值客户的自动化模式从全自动调整为草稿模式
+    Then 系统应保存新的敏感场景自动化规则，并让后续相关流程按该粒度执行
+
+  Scenario: Permission Case
+    Given Accountant 尝试修改敏感场景自动化规则
+    When Accountant 提交新的自动化粒度设置
+    Then 系统应拒绝写入规则变更，并保持只有 Firm Owner 可以调整该类策略
+
+  Scenario: Error Case
+    Given Firm Owner 选择的规则范围冲突或保存配置失败
+    When Firm Owner 提交敏感场景自动化规则
+    Then 系统应明确提示失败原因，并保持旧规则继续生效
+
+  Scenario: Edge Case
+    Given Firm Owner 查看某客户的自动化适用范围时，发现同一客户同时命中 VIP 标签与高风险投诉标签
+    When Firm Owner 查看该客户适用的自动化模式
+    Then 系统应以更保守的敏感规则优先，避免较宽松的自动化设置覆盖高风险边界
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器调整自动化规则
+    When Firm Owner 浏览规则选项、范围说明与生效提示
+    Then 系统应让规则层级、当前模式与保存结果可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: case-closeout-and-signoff
+
+  Scenario: Happy Path
+    Given Accountant 打开一个已接近完成的案件，且交付结果已准备好进入收尾阶段
+    When Accountant 发起最终确认与签字流程
+    Then 系统应把案件推进到待确认或待签字状态，并持续跟踪客户是否完成必要回应
+
+  Scenario: Permission Case
+    Given Client 直接进入案件工作台内部的收尾控制区
+    When Client 尝试发起或改写案件收尾状态
+    Then 系统应拒绝该内部收尾操作，并保持只有 Accountant 可以发起正式收尾
+
+  Scenario: Error Case
+    Given Accountant 发起收尾时缺少待签文件或关键完成信息
+    When Accountant 提交收尾动作
+    Then 系统应提示缺失前置条件，并阻止案件被误标记为已完成
+
+  Scenario: Edge Case
+    Given Accountant 已发起签字，但客户长时间未回应
+    When Accountant 再次查看案件收尾状态
+    Then 系统应保留待签字状态并清楚标记超时风险，而不是自动把案件视为完成
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器执行收尾操作
+    When Accountant 浏览确认动作、签字状态与异常提示
+    Then 系统应让收尾阶段、当前状态与后续动作可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: case-progress-and-risk-tracking
+
+  Scenario: Happy Path
+    Given Accountant 打开一个正在推进中的案件，且系统已记录案件阶段、截止日、提醒事件与资料状态
+    When Accountant 查看案件进度与风险跟踪区
+    Then 系统应清楚展示当前阶段、卡点位置、截止风险与下一步推进依据
+
+  Scenario: Permission Case
+    Given Client 尝试访问案件进度与风险跟踪区的内部风险细节
+    When Client 查看案件风险视图
+    Then 系统应限制内部推进与风险判断细节，只向内部角色开放该工作面
+
+  Scenario: Error Case
+    Given Accountant 查看案件进度时，发现案件状态链路记录不完整或截止日数据异常
+    When Accountant 查看进度与风险跟踪区
+    Then 系统应提示状态信息不完整，并避免输出具有误导性的风险结论
+
+  Scenario: Edge Case
+    Given Firm Owner 查看案件风险跟踪时，发现案件当前没有逾期，但资料缺失与多次提醒未响应已使其接近阻塞
+    When Firm Owner 下钻查看风险跟踪区
+    Then 系统应把这种隐性阻塞识别为需要提前干预的风险，并明确标记为需关注的介入对象
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器查看案件跟踪信息
+    When Accountant 浏览阶段时间线、风险提示与下一步动作
+    Then 系统应让进度结构、风险等级与状态变化可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: client-history-archive
+
+  Scenario: Happy Path
+    Given Accountant 打开一个已有历史服务记录的客户档案
+    When Accountant 查看客户历史归档区并按年份回看服务记录
+    Then 系统应展示基础资料、历次服务、文件与签字记录，支持团队回看长期客户信息
+
+  Scenario: Permission Case
+    Given Client 尝试访问客户历史归档区中的内部服务沉淀记录
+    When Client 查看档案历史详情
+    Then 系统应限制内部归档视图的访问，并保持该能力仅面向内部角色开放
+
+  Scenario: Error Case
+    Given Accountant 查看客户历史归档时，发现某次历史服务的文件记录或签字归档丢失
+    When Accountant 查看该客户的历史归档
+    Then 系统应明确标记缺失记录，而不是把不完整的历史呈现为已完整归档
+
+  Scenario: Edge Case
+    Given Firm Owner 查看客户历史归档时，发现客户存在多次服务记录且不同年份的服务类型差异较大
+    When Firm Owner 回看历史归档
+    Then 系统应区分各次服务上下文与长期服务积累，并按年份或服务阶段清楚展示差异
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器浏览客户历史归档
+    When Accountant 查看年份分组、服务记录与文件状态
+    Then 系统应让归档结构、记录顺序与缺失提示可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: client-portfolio-segmentation
+
+  Scenario: Happy Path
+    Given Firm Owner 打开客户资产与关系页，且系统已计算客户价值、忠诚度、流失风险与推荐价值
+    When Firm Owner 切换客户资产分层视图
+    Then 系统应按分层标准展示客户池健康度，并支持识别高价值与高风险人群
+
+  Scenario: Permission Case
+    Given Accountant 尝试进入客户资产分层视图
+    When Accountant 查看事务所级客户分层结果
+    Then 系统应限制老板级经营分层能力的访问，并保持该能力只面向 Firm Owner
+
+  Scenario: Error Case
+    Given Firm Owner 查看客户资产分层时，发现某批客户画像指标缺失或分层计算失败
+    When Firm Owner 查看客户资产分层
+    Then 系统应提示分层结果不完整，并避免输出伪精确的客户分类
+
+  Scenario: Edge Case
+    Given Firm Owner 查看客户资产分层时，发现某客户具有高客单价但同时存在明显流失风险
+    When Firm Owner 查看该客户所在分层
+    Then 系统应同时体现其高价值与风险属性，而不是简单落到单一正向分类
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器浏览客户资产分层
+    When Firm Owner 查看分层标签、筛选结果与风险提示
+    Then 系统应让分层结构、筛选条件与分类含义可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: client-profile-intake
+
+  Scenario: Happy Path
+    Given Client 通过邀请进入注册与需求填写页
+    When Client 填写姓名、联系方式与基础业务信息并保存
+    Then 系统应校验并保存客户基础信息，为后续建档、报价与资料清单生成提供起点
+
+  Scenario: Permission Case
+    Given Accountant 尝试在 Client 自助入口代替 Client 修改基础信息
+    When Accountant 提交客户基础资料
+    Then 系统应限制未授权代填行为，并保持该采集流程以 Client 本人为主
+
+  Scenario: Error Case
+    Given Client 提交的必填字段缺失或联系方式格式错误
+    When Client 保存客户基础信息
+    Then 系统应明确指出校验失败的字段，并阻止不完整信息进入后续流程
+
+  Scenario: Edge Case
+    Given Client 在填写过程中中断离开，且此前已保存部分基础信息
+    When Client 再次进入注册页
+    Then 系统应恢复已保存进度，避免 Client 需要从头重复填写
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器填写基础信息
+    When Client 逐项输入字段并查看校验提示
+    Then 系统应让字段名称、必填状态与错误说明可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: client-reminder-orchestration
+
+  Scenario: Happy Path
+    Given Accountant 打开一个存在缺件或临近截止日的案件
+    When Accountant 在客户补件提醒区发起一次提醒
+    Then 系统应记录提醒事件、把案件推进到等待响应状态，并跟踪客户后续是否补交
+
+  Scenario: Permission Case
+    Given Client 进入案件内部提醒控制区
+    When Client 尝试主动发起或改写补件提醒规则
+    Then 系统应限制该内部催办能力，并保持提醒编排由 Accountant 控制
+
+  Scenario: Error Case
+    Given Accountant 发起提醒时缺少有效联系渠道或提醒发送失败
+    When Accountant 提交提醒动作
+    Then 系统应提示发送失败原因，并避免把提醒误记为已成功触达
+
+  Scenario: Edge Case
+    Given Accountant 查看提醒编排区时，发现同一客户在短时间内已收到多次提醒且仍未响应
+    When Accountant 再次查看提醒编排区
+    Then 系统应显示频率风险或历史触达记录，帮助 Accountant 避免无差别重复催办
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器发起补件提醒
+    When Accountant 浏览提醒类型、历史记录与发送结果
+    Then 系统应让提醒结构、状态变化与失败原因可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: client-return-path
+
+  Scenario: Happy Path
+    Given Client 已到达服务完成页，且本次服务已正式闭环
+    When Client 选择查看历史结果或再次联系事务所
+    Then 系统应提供清晰的后续合作入口，并展示查看历史结果或再次联系事务所的可用路径
+
+  Scenario: Permission Case
+    Given Client 尝试通过该后续合作入口查看其他 Client 的历史内容
+    When Client 进入不属于自己的返回合作路径
+    Then 系统应限制其访问他人历史结果，并保持入口只服务当前 Client 的后续动作
+
+  Scenario: Error Case
+    Given Client 点击后续合作入口，但历史结果地址失效或联系通道不可用
+    When Client 继续该动作
+    Then 系统应明确提示入口异常，并提供可理解的替代指引而不是静默失败
+
+  Scenario: Edge Case
+    Given Client 当前没有更多历史结果可查看，但仍希望再次合作
+    When Client 打开后续合作入口
+    Then 系统应仍然保留重新联系或继续合作的路径，而不是因为历史为空就让流程中断
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器访问后续合作入口
+    When Client 浏览历史查看、再次联系与继续合作选项
+    Then 系统应让入口目的、目标动作与结果说明可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: client-service-closure
+
+  Scenario: Happy Path
+    Given Client 完成签字或最终回应，且案件已进入正式完成状态
+    When Client 打开服务完成页
+    Then 系统应明确告知本次服务已完成，并展示关键完成结果与后续预期
+
+  Scenario: Permission Case
+    Given Accountant 尝试直接访问当前 Client 的服务完成页
+    When Accountant 查看服务完成确认内容
+    Then 系统应限制其访问正式完成结果，并保持完成确认只面向对应 Client
+
+  Scenario: Error Case
+    Given Client 打开服务完成页时，案件实际尚未完成或完成状态回退
+    When Client 打开服务完成页
+    Then 系统应避免展示误导性的完成信号，并清楚提示当前仍存在待处理事项
+
+  Scenario: Edge Case
+    Given Client 查看服务完成确认时，案件主体已完成，但部分归档信息仍在同步中
+    When Client 查看服务完成确认
+    Then 系统应优先明确服务已闭环，同时把仍在整理的附加信息标记为后续可补充查看
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器查看服务完成页
+    When Client 浏览完成状态、结果摘要与后续说明
+    Then 系统应让完成信号、结果内容与后续动作可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: daily-priority-board
+
+  Scenario: Happy Path
+    Given Accountant 打开会计师作战台，且系统已聚合过期、临期、新客待审与进行中案件
+    When Accountant 查看今日优先级看板
+    Then 系统应按优先级组织工作列表，并突出最急和最关键的事项
+
+  Scenario: Permission Case
+    Given Client 尝试访问会计师作战台中的今日优先级看板
+    When Client 查看该工作列表
+    Then 系统应限制内部工作优先级视图的访问，并保持看板只对 Accountant 开放
+
+  Scenario: Error Case
+    Given Accountant 查看今日优先级看板时，发现案件状态或截止日数据缺失导致排序依据不完整
+    When Accountant 查看今日优先级看板
+    Then 系统应提示数据异常并避免输出误导性的优先级排序
+
+  Scenario: Edge Case
+    Given Accountant 查看今日优先级顺序时，发现两个案件的截止日相同，但其中一个存在严重缺件或高风险阻塞
+    When Accountant 查看今日优先级顺序
+    Then 系统应把更高风险的案件放在更靠前的位置，而不是只按截止日做机械排序
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器浏览今日优先级看板
+    When Accountant 顺序查看分组、案件摘要与风险标签
+    Then 系统应让优先级结构、状态说明与导航目标可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: document-checklist-delivery
+
+  Scenario: Happy Path
+    Given Client 已进入资料提交与进度页，且系统已根据服务类型生成所需资料清单
+    When Client 查看资料清单交付区
+    Then 系统应按清单方式明确展示当前需要提交的资料项与提交顺序
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看 Client 自助提交流程中的资料清单
+    When Accountant 进入资料清单交付区
+    Then 系统应限制其访问当前服务清单，并保持清单只服务对应 Client
+
+  Scenario: Error Case
+    Given 服务类型已确定，但资料规则加载失败或清单未正确生成
+    When Client 打开资料清单交付区
+    Then 系统应提示清单生成异常，并避免把空白页面伪装成无需提交资料
+
+  Scenario: Edge Case
+    Given 某服务同时包含通用资料项与特定补充资料项
+    When Client 查看资料清单
+    Then 系统应把不同类型的资料要求区分清楚，避免 Client 误以为只需提交一部分
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器浏览资料清单
+    When Client 顺序查看资料项、说明与提交入口
+    Then 系统应让清单结构、资料名称与提交关系可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: document-completeness-review
+
+  Scenario: Happy Path
+    Given Accountant 打开一个已有上传资料的案件
+    When Accountant 在资料完整性核验区逐项判断资料是否已收到、可用或需补充
+    Then 系统应保存每项核验结果，并把资料状态沉淀为可追踪的判断结论
+
+  Scenario: Permission Case
+    Given Client 进入会计师端资料完整性核验区
+    When Client 尝试直接修改内部核验结论
+    Then 系统应限制该内部核验能力，并保持只有 Accountant 可以确认资料是否可用
+
+  Scenario: Error Case
+    Given Accountant 需要核验某项资料，但上传文件损坏或 AI 初审结果无法读取
+    When Accountant 查看该资料项
+    Then 系统应提示核验依据异常，并避免把无法判断的资料直接标记为通过
+
+  Scenario: Edge Case
+    Given 某项资料已上传，但内容与客户身份信息不匹配
+    When Accountant 执行资料完整性核验
+    Then 系统应允许将该资料标记为需补充或异常，而不是只根据是否上传做通过判断
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器执行资料核验
+    When Accountant 浏览资料项、状态选项与补充说明
+    Then 系统应让资料名称、当前状态与核验结果可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: document-status-visibility
+
+  Scenario: Happy Path
+    Given Client 已提交部分资料并进入资料提交与进度页
+    When Client 查看资料状态可视化区
+    Then 系统应实时展示每项资料当前处于待上传、已收到、需补充或已确认的状态
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看 Client 自助提交流程中的资料状态
+    When Accountant 进入资料状态可视化区
+    Then 系统应限制其访问当前 Client 的资料处理状态
+
+  Scenario: Error Case
+    Given 某项资料的审核状态尚未成功同步
+    When Client 查看资料状态
+    Then 系统应提示状态暂不可用或仍在处理中，而不是展示错误的最终结论
+
+  Scenario: Edge Case
+    Given Client 在短时间内多次替换同一资料项
+    When Client 查看该资料项的当前状态
+    Then 系统应只突出当前有效版本的处理状态，避免历史替换记录干扰当下判断
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器浏览资料状态
+    When Client 顺序查看每项资料的状态与补充说明
+    Then 系统应让状态名称、变化含义与说明内容可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: document-upload-submission
+
+  Scenario: Happy Path
+    Given Client 已进入资料提交与进度页并看到待提交的资料项
+    When Client 选择某个资料项上传文件并完成提交
+    Then 系统应记录该资料项的新文件，并把提交结果反馈给 Client
+
+  Scenario: Permission Case
+    Given Accountant 尝试在 Client 自助提交流程中上传案件资料
+    When Accountant 进入资料上传提交流程
+    Then 系统应限制其提交行为，并保持上传入口只服务对应 Client
+
+  Scenario: Error Case
+    Given Client 上传的文件类型不支持或上传过程失败
+    When Client 提交资料文件
+    Then 系统应明确提示失败原因，并保持该资料项不被误记为已提交
+
+  Scenario: Edge Case
+    Given Client 需要替换之前已提交的一份资料
+    When Client 对同一资料项再次上传新文件
+    Then 系统应把新文件视为当前有效版本，同时保留可追踪的替换结果
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器完成文件上传
+    When Client 浏览资料项、选择上传入口并查看提交反馈
+    Then 系统应让上传目标、当前进度与结果说明可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: escalation-exception-handling
+
+  Scenario: Happy Path
+    Given Firm Owner 打开升级处理页，且系统已聚合投诉、差评、反复改约与长期沉默等异常信号
+    When Firm Owner 查看异常列表并决定由谁跟进处理
+    Then 系统应记录异常处理动作与结论，并保持高影响例外情况集中可追踪
+
+  Scenario: Permission Case
+    Given Accountant 尝试在升级处理页执行老板级异常决策
+    When Accountant 提交异常处理结论
+    Then 系统应限制其老板级处置权限，并保持异常处理由 Firm Owner 主导
+
+  Scenario: Error Case
+    Given 某条异常事件缺少核心上下文或处理写入失败
+    When Firm Owner 提交处理动作
+    Then 系统应提示异常记录不完整或处理失败，并避免把事件误记为已闭环
+
+  Scenario: Edge Case
+    Given 同一客户同时出现投诉与长期沉默两类升级信号
+    When Firm Owner 查看异常处理队列
+    Then 系统应把这些信号归并为同一客户上下文中的复合风险，而不是分散成彼此孤立的事项
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器处理异常事件
+    When Firm Owner 浏览异常类型、处理责任与结论记录
+    Then 系统应让异常上下文、风险等级与处理结果可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: fee-and-preparation-clarity
+
+  Scenario: Happy Path
+    Given Client 进入报价确认页，且系统已生成费用明细与资料准备要求
+    When Client 查看费用与准备项说明区
+    Then 系统应清楚展示价格、准备要求与关键前置条件，并让当前报价范围可以被直接确认
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看当前 Client 的报价费用说明
+    When Accountant 进入费用与准备项说明区
+    Then 系统应限制其访问当前 Client 的报价内容
+
+  Scenario: Error Case
+    Given 报价费用明细不完整或准备项规则加载失败
+    When Client 查看费用与准备项说明
+    Then 系统应明确提示说明信息不完整，并避免把模糊费用展示为可直接确认的报价
+
+  Scenario: Edge Case
+    Given 某报价同时包含基础服务与额外补充要求
+    When Client 查看费用与准备项说明
+    Then 系统应把基础费用与附加条件区分清楚，避免 Client 误解总成本或准备范围
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器查看费用说明
+    When Client 浏览价格明细、准备要求与附加条件
+    Then 系统应让金额信息、资料要求与说明层级可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: high-value-client-alerts
+
+  Scenario: Happy Path
+    Given Firm Owner 打开升级处理页，且系统已识别高价值客户、关键关系客户与高影响风险客户
+    When Firm Owner 查看高价值客户提醒区
+    Then 系统应聚合最需要优先关注的客户提醒，并支持 Firm Owner 快速进入详情判断是否介入
+
+  Scenario: Permission Case
+    Given Accountant 尝试访问高价值客户提醒区
+    When Accountant 查看老板级高价值提醒列表
+    Then 系统应限制其老板级提醒视图的访问，并保持该能力仅面向 Firm Owner
+
+  Scenario: Error Case
+    Given 客户价值评级或风险评分未成功更新
+    When Firm Owner 查看高价值客户提醒
+    Then 系统应提示提醒依据不完整，并避免把重要客户从提醒列表中静默遗漏
+
+  Scenario: Edge Case
+    Given 某客户价值很高，但当前风险较低；另一客户价值较低但风险极高
+    When Firm Owner 查看提醒排序
+    Then 系统应帮助区分“重要关系关注”和“高风险介入”两类优先级，而不是简单混成单一排序
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器浏览高价值客户提醒
+    When Firm Owner 查看客户名称、提醒原因与风险等级
+    Then 系统应让提醒结构、优先级含义与详情入口可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: information-purpose-guidance
+
+  Scenario: Happy Path
+    Given Client 刚进入注册与需求填写页，尚未开始正式填写资料
+    When Client 查看信息用途说明区
+    Then 系统应说明为什么需要这些信息以及信息将如何被使用，并提供与当前填写流程一致的解释上下文
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看 Client 受邀流程中的信息用途说明上下文
+    When Accountant 进入说明区域
+    Then 系统应限制其使用当前邀请上下文的说明入口，并保持说明服务于对应 Client 的受邀流程
+
+  Scenario: Error Case
+    Given 某服务类型需要特殊说明，但当前说明内容未成功加载
+    When Client 查看信息用途说明
+    Then 系统应提示说明暂不可用，而不是让 Client 在无解释状态下继续填写敏感资料
+
+  Scenario: Edge Case
+    Given Client 对某些敏感字段存在明显顾虑
+    When Client 展开信息用途说明中的常见问题或补充解释
+    Then 系统应提供更具体的用途说明，帮助 Client 判断为何仍需要继续填写
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器阅读信息用途说明
+    When Client 浏览说明文本、补充解释与继续填写入口
+    Then 系统应让说明结构、重点信息与后续动作可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: intake-acceptance-decision
+
+  Scenario: Happy Path
+    Given Accountant 已完成对新客户资料与来源的初步判断
+    When Accountant 在新客接纳决策区选择接纳并提交原因
+    Then 系统应记录该正式决策并推动客户进入后续服务流程
+
+  Scenario: Permission Case
+    Given Client 进入新客审核台内部的接纳决策区
+    When Client 尝试替自己提交接纳结果
+    Then 系统应限制该内部审核能力，并保持接纳决策只由 Accountant 执行
+
+  Scenario: Error Case
+    Given Accountant 提交接纳决策时缺少必要原因或写入失败
+    When Accountant 确认该决策
+    Then 系统应提示决策未成功记录，并避免客户状态被误更新
+
+  Scenario: Edge Case
+    Given 新客户信息基本可用，但来源仍存在待确认疑点
+    When Accountant 评估接纳结果
+    Then 系统应允许选择暂缓处理或退回补充，而不是只提供接纳与拒绝的二元结果
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器执行新客接纳决策
+    When Accountant 浏览决策选项、原因输入与提交结果
+    Then 系统应让状态选项、原因说明与结果反馈可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: intake-submission-review
+
+  Scenario: Happy Path
+    Given Accountant 打开一个刚通过邀请完成注册的新客户记录，且客户已提交基础信息、服务需求与 AI 初审结果
+    When Accountant 查看新客资料审阅区并展开关键信息摘要
+    Then 系统应按统一结构展示基础信息、需求信息与 AI 初审结论，并标明可供首轮审阅使用的关键信息摘要
+
+  Scenario: Permission Case
+    Given Client 进入新客审核台对应的新客资料审阅入口
+    When Client 尝试查看新客资料审阅内容
+    Then 系统应拒绝展示该审阅面，并保持只有 Accountant 可以执行首轮审阅
+
+  Scenario: Error Case
+    Given Accountant 打开一个新客户记录，但客户提交信息缺失或 AI 初审结果未成功生成
+    When Accountant 进入新客资料审阅区
+    Then 系统应明确提示缺失项或异常状态，而不是把不完整信息伪装成可直接审阅的结果
+
+  Scenario: Edge Case
+    Given Accountant 打开一个信息量较大或包含多项补充说明的新客户记录
+    When Accountant 在审阅区查看摘要并展开细节
+    Then 系统应先提供可快速扫读的核心摘要，同时允许继续展开完整内容，而不打断首轮判断节奏
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器进入新客资料审阅区
+    When Accountant 逐段浏览摘要、状态提示与展开内容
+    Then 系统应让审阅结构、标题层级、状态说明与展开关系可被顺序访问和清晰朗读
@@ -0,0 +1,26 @@
+Feature: invite-code-verification
+
+  Scenario: Happy Path
+    Given Client 通过邀请链接进入邀请进入页，且持有有效的邀请码
+    When Client 输入邀请码并提交验证
+    Then 系统应完成身份确认并允许 Client 进入后续注册流程
+
+  Scenario: Permission Case
+    Given Firm Owner 尝试代替受邀 Client 进入邀请码验证后的注册流程
+    When Firm Owner 提交验证请求
+    Then 系统应拒绝其进入后续注册步骤，并保持受邀入口只服务正确对象
+
+  Scenario: Error Case
+    Given Client 输入的邀请码错误、已过期或验证服务异常
+    When Client 提交邀请码
+    Then 系统应明确提示验证失败原因，而不是让 Client 落入不明状态
+
+  Scenario: Edge Case
+    Given Client 打开的邀请链接有效，但输入的邀请码已被其他流程标记为已使用
+    When Client 尝试完成身份确认
+    Then 系统应把该状态解释清楚，并指导 Client 联系事务所或重新获取邀请
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器输入邀请码
+    When Client 浏览输入框、校验提示与继续按钮
+    Then 系统应让字段名称、错误信息与验证结果可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: invite-trust-entry
+
+  Scenario: Happy Path
+    Given Client 通过熟人介绍收到事务所邀请链接
+    When Client 打开邀请进入页
+    Then 系统应展示邀请来源、介绍人上下文与事务所身份信息，并明确当前入口与受邀流程的对应关系
+
+  Scenario: Permission Case
+    Given Client 尝试通过不属于自己的受邀入口进入正式邀请流程
+    When Client 打开邀请进入页
+    Then 系统应限制其进入正式受邀流程，并避免暴露不必要的内部关系上下文
+
+  Scenario: Error Case
+    Given Client 打开邀请进入页时，发现邀请来源信息缺失或事务所身份信息加载失败
+    When Client 打开邀请进入页
+    Then 系统应提示入口信息不完整，而不是把缺失上下文伪装成正常邀请
+
+  Scenario: Edge Case
+    Given Client 来自熟人转介绍，但对事务所仍有初始顾虑
+    When Client 查看邀请信任入口中的来源说明
+    Then 系统应优先突出介绍关系与服务身份，并明确展示与继续进入相关的信任说明
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器查看邀请进入页
+    When Client 浏览介绍来源、事务所身份与继续入口
+    Then 系统应让信任信息结构、来源说明与后续动作可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: manual-override-governance
+
+  Scenario: Happy Path
+    Given Firm Owner 已配置自动化策略，且某个流程命中金额承诺或投诉处理等高风险条件
+    When 系统执行到人工接管边界
+    Then 系统应暂停自动化继续推进，并把最终处理权交给 Firm Owner
+
+  Scenario: Permission Case
+    Given Accountant 尝试绕过人工接管边界直接放行高风险自动化动作
+    When Accountant 提交该放行动作
+    Then 系统应限制其越权放行，并保持最终控制属于 Firm Owner
+
+  Scenario: Error Case
+    Given Firm Owner 处理人工接管事项时，系统命中人工接管条件，但暂停或通知写入失败
+    When 自动化执行到边界点
+    Then 系统应明确标记该异常，而不是在未确认的情况下继续自动处理高风险动作
+
+  Scenario: Edge Case
+    Given Firm Owner 查看人工接管命中原因时，发现一个场景同时命中多个风险阈值，例如金额承诺与投诉标签
+    When 系统判断是否需要人工接管
+    Then 系统应把该场景视为必须人工接管，而不是让较弱规则覆盖更高风险边界
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器处理人工接管事项
+    When Firm Owner 浏览命中原因、待处理动作与控制结果
+    Then 系统应让接管条件、风险说明与最终控制状态可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: owner-daily-briefing
+
+  Scenario: Happy Path
+    Given Firm Owner 进入事务所经营总览页，且系统已汇总今日案件分布、客户变化与收入变化
+    When Firm Owner 查看老板每日经营简报
+    Then 系统应快速呈现今日经营态势与关键变化，并突出需要立即关注的经营信号
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看老板每日经营简报
+    When Accountant 进入该经营摘要区域
+    Then 系统应限制其访问事务所级经营总览，并保持该能力仅对 Firm Owner 开放
+
+  Scenario: Error Case
+    Given Firm Owner 查看每日经营简报时，发现某些经营汇总数据未成功同步
+    When Firm Owner 查看每日经营简报
+    Then 系统应提示摘要数据不完整，并避免把残缺信息伪装成完整经营概况
+
+  Scenario: Edge Case
+    Given Firm Owner 查看每日经营简报时，发现当天新增客户不多，但逾期案件与高风险事项明显上升
+    When Firm Owner 查看经营简报
+    Then 系统应突出经营压力变化，而不是仅让新增数量掩盖真实风险
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器查看经营简报
+    When Firm Owner 浏览摘要模块、变化指标与下钻入口
+    Then 系统应让模块结构、关键变化与优先信息可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: owner-priority-forecast
+
+  Scenario: Happy Path
+    Given Firm Owner 查看事务所经营总览页，且系统已汇总当日完成情况、积压事项与风险走势
+    When Firm Owner 打开老板优先级预判区
+    Then 系统应指出今天收尾和明天开局最需要优先关注的事项
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看老板优先级预判
+    When Accountant 进入该预判区域
+    Then 系统应限制其使用老板级优先级预判能力
+
+  Scenario: Error Case
+    Given Firm Owner 查看优先级预判时，发现完成情况或风险趋势数据缺失，导致预判依据不足
+    When Firm Owner 查看优先级预判
+    Then 系统应提示预判依据不完整，而不是输出看似确定但不可依赖的建议
+
+  Scenario: Edge Case
+    Given Firm Owner 查看优先级预判时，发现当前没有明显逾期，但明天存在多个即将同时到期的关键事项
+    When Firm Owner 查看优先级预判
+    Then 系统应把明日的集中压力提前暴露出来，而不是只强调当前已发生的问题
+
+  Scenario: Accessibility Case
+    Given Firm Owner 依赖键盘导航或屏幕阅读器查看优先级预判
+    When Firm Owner 浏览建议项、原因说明与处理入口
+    Then 系统应让建议顺序、判断依据与下一步动作可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: quote-decision-response
+
+  Scenario: Happy Path
+    Given Client 已查看报价确认页中的服务说明与费用要求
+    When Client 选择接受当前合作条件并提交回应
+    Then 系统应记录该正式报价回应，并推动流程进入后续服务阶段
+
+  Scenario: Permission Case
+    Given Accountant 尝试代替当前 Client 提交报价回应
+    When Accountant 在报价确认页提交决定
+    Then 系统应限制其代替回应行为，并保持该决策由对应 Client 完成
+
+  Scenario: Error Case
+    Given Client 提交报价回应时写入失败或报价已失效
+    When Client 确认当前决定
+    Then 系统应提示回应未成功记录，并避免流程误进入下一阶段
+
+  Scenario: Edge Case
+    Given Client 暂时无法决定是否继续合作
+    When Client 提交暂缓或待确认回应
+    Then 系统应把该结果记录为可追踪的中间状态，而不是强制收敛为接受或拒绝
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器提交报价回应
+    When Client 浏览决策选项、说明文本与提交结果
+    Then 系统应让选项含义、当前状态与确认反馈可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: quote-package-presentation
+
+  Scenario: Happy Path
+    Given Client 打开报价确认页，且事务所已生成当前服务内容与交付预期
+    When Client 查看服务说明展示区
+    Then 系统应清楚展示将提供的服务内容、边界与交付结果，并使当前方案范围可以被直接查看
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看当前 Client 的服务说明展示区
+    When Accountant 进入服务说明展示区
+    Then 系统应限制其查看当前 Client 的报价内容
+
+  Scenario: Error Case
+    Given Client 查看服务说明展示区时，发现服务范围说明未成功生成或关键信息缺失
+    When Client 查看服务说明展示区
+    Then 系统应提示说明不完整，而不是把不明确的服务边界展示为可确认方案
+
+  Scenario: Edge Case
+    Given Client 查看服务说明展示时，发现某报价包含多个服务组合与不同交付内容
+    When Client 查看服务说明展示
+    Then 系统应把不同服务项与交付预期区分清楚，避免 Client 误解服务边界
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器浏览服务说明
+    When Client 查看服务内容、边界说明与交付预期
+    Then 系统应让说明层级、关键条目与比较关系可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: referral-relationship-insight
+
+  Scenario: Happy Path
+    Given Firm Owner 打开客户资产与关系页，且系统已建立客户介绍关系图谱
+    When Firm Owner 查看转介绍关系洞察区
+    Then 系统应展示客户由谁介绍、推荐过谁以及关联关系上下文，并清楚呈现关系层级与来源链路
+
+  Scenario: Permission Case
+    Given Client 尝试查看内部转介绍关系洞察
+    When Client 进入关系图谱相关区域
+    Then 系统应限制其访问内部关系网络细节，并保持该洞察面只服务内部角色
+
+  Scenario: Error Case
+    Given Accountant 查看转介绍关系洞察时，发现邀请记录缺失或关系链计算失败
+    When Accountant 查看转介绍关系洞察
+    Then 系统应明确提示关系数据不完整，而不是把来源空缺呈现为正常无关系状态
+
+  Scenario: Edge Case
+    Given Accountant 查看关系洞察时，发现某客户同时存在多层介绍关系与关联账户
+    When Accountant 查看关系洞察
+    Then 系统应区分主要介绍链与其他关联关系，避免把不同关系语义混成一张模糊网络
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器查看关系洞察
+    When Accountant 浏览来源信息、关联说明与异常提示
+    Then 系统应让关系层级、来源变化与风险信号可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: referral-source-verification
+
+  Scenario: Happy Path
+    Given Accountant 打开一个新客户记录，且系统已关联邀请链接、邀请码与介绍人信息
+    When Accountant 进入介绍来源核验区查看来源与关系上下文
+    Then 系统应清楚展示客户由谁介绍、关系链是否完整，以及当前来源是否可被视为可信
+
+  Scenario: Permission Case
+    Given Client 尝试访问介绍来源核验区
+    When Client 查看新客户的来源核验内容
+    Then 系统应拒绝暴露内部来源判断与关系核验结果，并保持只有 Accountant 可以执行该核验
+
+  Scenario: Error Case
+    Given Accountant 打开一个新客户记录，但邀请记录缺失、邀请码失配或介绍人信息未成功关联
+    When Accountant 查看介绍来源核验区
+    Then 系统应明确提示来源缺失或核验失败的原因，而不是把该客户误判为来源正常
+
+  Scenario: Edge Case
+    Given Accountant 打开一个存在多重介绍关系或来源信息相互冲突的新客户记录
+    When Accountant 在核验区比对邀请来源、历史关系与客户档案线索
+    Then 系统应突出显示冲突点，并帮助 Accountant 判断该客户需要补充标记还是暂缓建档
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器进入介绍来源核验区
+    When Accountant 浏览介绍人信息、关系说明与冲突提示
+    Then 系统应让来源结构、风险提示和核验结论可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: service-need-capture
+
+  Scenario: Happy Path
+    Given Client 进入注册与需求填写页，且已准备说明自己要解决的问题
+    When Client 选择服务类型并补充服务背景
+    Then 系统应保存该需求描述，为后续建档与报价提供可判断的依据
+
+  Scenario: Permission Case
+    Given Accountant 尝试替当前 Client 修改服务需求
+    When Accountant 提交需求信息
+    Then 系统应限制其代填行为，并保持需求采集以对应 Client 的输入为准
+
+  Scenario: Error Case
+    Given Client 未填写关键需求信息或提交内容无法通过校验
+    When Client 提交服务需求
+    Then 系统应明确提示缺失或不合规的部分，并阻止不完整需求进入后续流程
+
+  Scenario: Edge Case
+    Given Client 同时存在多项服务诉求且时间要求不同
+    When Client 提交服务需求
+    Then 系统应允许保留多项需求与补充背景，而不是把复杂诉求压缩成单一模糊问题
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器填写服务需求
+    When Client 浏览选项、补充说明输入区与校验提示
+    Then 系统应让需求字段、必填说明与错误反馈可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: service-scope-and-quote
+
+  Scenario: Happy Path
+    Given Accountant 打开案件工作台，且已掌握客户需求与历史背景
+    When Accountant 评估需求、调整报价参考并发送合作条件
+    Then 系统应记录正式的服务范围与报价结果，并推动案件进入报价确认链路
+
+  Scenario: Permission Case
+    Given Client 进入案件工作台内部的服务范围与报价工作区
+    When Client 尝试修改内部报价判断或直接发送报价
+    Then 系统应限制其内部定价与发送能力，并保持该工作流由 Accountant 控制
+
+  Scenario: Error Case
+    Given Accountant 发出报价前缺少必要的需求依据或发送动作失败
+    When Accountant 提交服务范围与报价
+    Then 系统应提示当前报价未成功形成或发送，并避免客户看到不可靠的合作条件
+
+  Scenario: Edge Case
+    Given 客户需求超出标准报价范围，需要在系统参考基础上做人工调整
+    When Accountant 确认服务范围与报价
+    Then 系统应允许保留人工判断结果，并让最终报价区别于默认参考值
+
+  Scenario: Accessibility Case
+    Given Accountant 依赖键盘导航或屏幕阅读器完成服务范围与报价工作流
+    When Accountant 浏览需求摘要、价格调整与发送确认
+    Then 系统应让范围说明、价格变化与提交结果可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: signoff-content-confirmation
+
+  Scenario: Happy Path
+    Given Client 打开在线签字页，且系统已准备好待签文件与结果摘要
+    When Client 查看签字内容确认区
+    Then 系统应清楚展示需要确认的结果与签字内容，再引导 Client 进入正式签署
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看当前 Client 的签字内容确认区
+    When Accountant 进入签字内容确认区
+    Then 系统应限制其访问当前 Client 的待签内容
+
+  Scenario: Error Case
+    Given Client 查看签字内容确认时，发现待签文件缺失、版本错误或结果摘要未成功加载
+    When Client 查看签字内容确认
+    Then 系统应提示签字内容异常，并阻止 Client 在信息不完整时继续签署
+
+  Scenario: Edge Case
+    Given Client 查看签字内容确认区时，发现当前签字任务包含多个待确认文件
+    When Client 查看签字内容确认区
+    Then 系统应帮助 Client 区分每份文件与其对应的确认范围，而不是把多份内容混成一次模糊确认
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器查看签字内容确认
+    When Client 浏览结果摘要、文件说明与继续签署入口
+    Then 系统应让签字结构、文件关系与确认动作可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: submission-readiness-feedback
+
+  Scenario: Happy Path
+    Given Client 已完成基础信息与服务需求的填写
+    When Client 提交注册内容并查看提交就绪反馈
+    Then 系统应明确告知当前是否可以继续，以及接下来会发生什么
+
+  Scenario: Permission Case
+    Given Accountant 尝试查看 Client 自助提交流程中的提交就绪反馈
+    When Accountant 进入反馈区域
+    Then 系统应限制其访问当前提交结果
+
+  Scenario: Error Case
+    Given Client 提交后系统未能完成完整性判断
+    When Client 查看提交就绪反馈
+    Then 系统应提示当前判断未完成或存在异常，而不是输出错误的继续信号
+
+  Scenario: Edge Case
+    Given Client 已提交大部分信息，但仍有少量关键字段不足
+    When Client 查看提交就绪反馈
+    Then 系统应明确指出仍需补充的部分，而不是简单给出模糊的未通过结论
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器查看提交反馈
+    When Client 浏览当前状态、缺失项与下一步说明
+    Then 系统应让反馈结果、补充要求与继续路径可以被顺序访问并清晰朗读
@@ -0,0 +1,26 @@
+Feature: supplement-request-response
+
+  Scenario: Happy Path
+    Given Client 收到缺件提醒并进入资料提交与进度页
+    When Client 查看补件响应处理区并按提示补交缺失资料
+    Then 系统应明确说明缺什么、为什么缺，以及补交完成后的最新状态
+
+  Scenario: Permission Case
+    Given Accountant 尝试响应当前 Client 的补件提醒
+    When Accountant 进入补件响应处理区
+    Then 系统应限制其访问与补件操作，并保持响应链路只服务对应 Client
+
+  Scenario: Error Case
+    Given Client 打开补件响应处理区时缺件原因未成功加载或再提交失败
+    When Client 尝试完成补件
+    Then 系统应提示补件异常，并避免把未成功的再提交误标为已完成
+
+  Scenario: Edge Case
+    Given Client 同时收到多项补件要求，且不同资料项的补充原因不同
+    When Client 查看补件响应处理区
+    Then 系统应把每项缺件原因与对应补交动作区分清楚，避免 Client 误补或漏补
+
+  Scenario: Accessibility Case
+    Given Client 依赖键盘导航或屏幕阅读器完成补件响应
+    When Client 浏览缺件原因、补交入口与再提交结果
+    Then 系统应让补件结构、原因说明与状态反馈可以被顺序访问并清晰朗读