soloforge 1.1.46 → 1.1.48

package/templates/build//345/210/207/347/211/207/347/253/257/345/210/260/347/253/257/351/252/214/350/257/201.md

@@ -1,221 +0,0 @@
----
-id: ka-rule-切片端到端验证规则
-kind: guidance
-title: 切片端到端验证
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 切片端到端验证
-  - 切片验证
-  - E2E验证
-  - slice e2e
-extra:
-  name: slice-e2e-verification
-  type: constraint
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  domain: build
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-generic-review
----
-
-# 切片端到端验证规则（Docker 部署 + 浏览器多维交叉验证）
-
-> 本规则适用阶段：编码与单元测试
-> 触发时机：每个切片编码完成后、标记切片通过前
-
-## 总则
-
-每个切片完成后，**必须**将后端服务和 Web 服务部署到本地 Docker，
-然后通过浏览器（Playwright）打开运行中的系统，对**原型、需求、设计**三个维度
-进行交叉验证。
-
-验证未通过的切片不得标记为完成。
-
-## 对抗性审查协议（强制）
-
-你正在执行切片端到端验证。你是严格的质量审查员，你的职责是发现问题，不是放行。
-
-### 审查原则（违反任何一条等同验证失败）
-
-1. **默认立场**：每一条检查项都是 ❌，除非你能提供浏览器实际截图或页面内容作为证据
-2. **无证据的 ✅ 等同于 ❌** — 你必须通过 Playwright 打开页面、截图、提取元素，不接受自述"页面正常"
-3. **禁止批量标记 ✅** — 每条检查项必须独立操作浏览器并附证据
-4. **禁止跳过任何检查项**
-
-### 执行流程
-
-**阶段 A: 部署 + 三维交叉验证**
-
-> **⚠️ 绝对不允许只检查"Docker 可用"就跳过部署！**
-> 你必须**实际执行** `docker compose up -d --build` 并在输出中包含 `docker ps` 结果。
-
-1. **实际执行部署命令**：运行 `docker compose up -d --build`，等待容器启动完成
-2. **输出部署证据**：运行 `docker ps` 并将输出（包含容器名、状态、端口映射）完整展示给用户
-3. **确认 Docker Desktop 可见**：用户必须在本地 Docker Desktop 中看到运行中的容器
-4. 构建 Web 服务 Docker 镜像并启动
-5. 通过 Playwright 打开浏览器，访问 Web 服务
-6. 逐维度验证：
-
-#### 维度 1: 原型交叉验证（UI / 交互一致性）
-
-将浏览器中实际页面与原型说明文档逐页对比：
-- 页面布局是否与原型一致（导航结构、区域划分、组件位置）
-- 交互行为是否与原型描述一致（按钮点击、表单提交、状态切换）
-- 文案是否与原型一致（标题、标签、提示文本、错误消息）
-
-**证据要求**：Playwright 截图 + 原型说明文档中的对应描述引用
-
-#### 维度 2: 需求交叉验证（功能点覆盖）
-
-将浏览器中实际操作与需求文档逐条对比：
-- 需求文档中的每个功能点是否可在浏览器中操作验证
-- 正常流程是否可走通
-- 边界条件是否已处理（空数据、超长输入、异常状态）
-
-**证据要求**：Playwright 操作步骤 + 实际结果 + 需求文档中的对应条目引用
-
-#### 维度 3: 设计交叉验证（接口 / 数据一致性）
-
-将浏览器中实际数据流与设计文档对比：
-- API 接口签名是否与 API 接口规格文档一致（路径、参数、响应格式）
-- 数据展示是否与数据库设计文档中的字段定义一致
-- 前后端数据流转是否与详细设计文档描述一致
-
-**证据要求**：浏览器 Network 请求/响应截图 + 设计文档中的对应定义引用
-
-→ 产出完整三维验证报告（每条 ❌ + 问题描述 或 ✅ + 截图/引用证据）
-
-**阶段 B: 强制修复**
-
-对验证报告中的每一个 ❌ 和 ⚠️ 项：
-1. 修复代码或配置
-2. 重新构建 Docker 镜像
-3. 重新部署并重新通过浏览器验证
-4. 不允许只报告不修复
-
-**阶段 C: 独立重审（强制）**
-
-修复完成后，你必须再次调用 `审查 切片` 工具进行独立重审。
-这不是可选的——这是强制性的质量保证步骤。
-如果重审发现问题 → 回到阶段 B 继续修复（最多 5 轮）。
-
-**阶段 D: 人工验证（强制）**
-
-AI 验证通过后，Docker 服务**必须保持运行**，然后**必须输出以下格式的地址**供人工验证：
-
-```text
-═══ 人工验证地址 ═══
-后端服务: <http://localhost:{实际端口}>
-Web 服务:  <http://localhost:{实际端口}>
-════════════════════
-```
-
-- `{实际端口}` 必须替换为 `docker ps` 输出中映射的真实端口号
-- 不允许输出 `{PORT}` 占位符 — 必须是用户可直接点击的具体地址
-- 同时输出 `docker ps` 结果，让用户确认 Docker Desktop 中可见
-
-人工在浏览器中确认系统功能和界面无误后，**必须把人工确认证据放入证据目录**：
-
-- 目录：`.soloforge/evidence/{sliceId}/SLICE-E2E-13/`
-- 证据形式：确认截图 `.png` 或确认记录 `.txt`
-- `SLICE-E2E-13` 门禁（`file_evidence`）据此校验**证据文件存在**
-- ⚠️ 门禁只证「证据文件存在」，**不替代人工判断**（人是否真看了由人负责，gate 不假装能判）
-- 证据就位后，切片方可标记为完成
-
-Docker 服务在人工确认前不得停止或删除。
-
-### 终止条件
-
-1. 三维验证报告全部 ✅ + 每条附浏览器截图或页面内容证据
-2. Docker 服务保持运行，访问地址已输出
-3. 人工确认通过 → 切片完成
-4. 达到最大 5 轮 AI 修复仍不通过 → 停止，报告剩余未通过项
-
-### 禁止事项
-
-- ⚠️ 绝对不允许以"本地环境不支持 Docker"为由跳过验证
-- ⚠️ 绝对不允许只说"Docker 可用"而不实际执行 `docker compose up -d --build` 部署
-- ⚠️ 绝对不允许部署后不输出 `docker ps` 结果 — 用户必须能在 Docker Desktop 中看到容器
-- ⚠️ 绝对不允许仅输出验证报告就停下来 — 验证失败必须修复
-- ⚠️ 绝对不允许用"我检查过了"代替浏览器实际截图
-- ⚠️ 绝对不允许只看首页就标记全部通过 — 必须覆盖切片涉及的全部页面和功能
-- ⚠️ 绝对不允许跳过独立重审步骤
-- ⚠️ 绝对不允许 AI 验证通过后就停止 Docker 服务 — 必须保持运行供人工确认
-- ⚠️ 绝对不允许跳过人工验证就标记切片完成
-- ⚠️ 绝对不允许不输出人工验证地址 — 必须明确输出后端和前端的 `localhost:{实际端口}` 地址
-
-## SLICE-E2E 规则条目
-
-> 以下 13 条与 `slice-gate.yaml` 的 13 个 check **一一对应、编号一致**。
-> 规则（本文件）管「怎么做」，门禁（yaml）管「够不够」——两层编号必须对齐，不可分裂。
-
-**SLICE-E2E-01** Docker 服务部署成功：后端 + Web 均部署到本地 Docker，容器 Running
-- 强制：是（error）
-- 执行器：`docker_deployment`（真跑 `docker compose up -d --build`）
-- 证据：`docker ps` 输出（须显示容器 Running）
-
-**SLICE-E2E-02** 服务 HTTP 可访问：真发请求校验 2xx/3xx（截图存在 ≠ 服务可访问）
-- 强制：是（error）
-- 执行器：`local_http_acceptance`（真 fetch，防造假截图）
-- 证据：HTTP 状态码 2xx/3xx + 响应 body 片段
-
-**SLICE-E2E-03** 原型维度 — 页面布局与原型一致（导航/区域/组件逐页对比）
-- 强制：是（error）
-- 执行器：`file_evidence`
-- 证据：Playwright 页面截图 + 原型说明文档章节引用
-
-**SLICE-E2E-04** 原型维度 — 交互行为与原型一致（点击/提交/状态切换）
-- 强制：是（error）
-- 执行器：`file_evidence`
-- 证据：Playwright 操作前后截图 + 原型交互描述引用
-
-**SLICE-E2E-05** 需求维度 — 功能点可操作验证（需求文档每个功能点可操作）
-- 强制：是（error）
-- 执行器：`file_evidence`
-- 证据：Playwright 操作步骤 + 结果截图 + 需求条目引用
-
-**SLICE-E2E-06** 需求维度 — 正常流程可走通（核心业务端到端）
-- 强制：是（error）
-- 执行器：`file_evidence`
-- 证据：Playwright 端到端操作截图序列 + 最终结果页
-
-**SLICE-E2E-07** 需求维度 — 边界条件已处理（空数据/超长/异常）
-- 强制：否（warning，不阻断但记录）
-- 执行器：`file_evidence`
-- 证据：边界场景 Playwright 截图 + 错误提示内容
-
-**SLICE-E2E-08** 设计维度 — 接口签名与 API 规格一致（路径/参数/响应）
-- 强制：是（error）
-- 执行器：`file_evidence`
-- 证据：浏览器 Network 请求/响应截图 + API 接口规格引用
-
-**SLICE-E2E-09** 设计维度 — 数据展示与数据库设计一致（字段/类型/格式）
-- 强制：是（error）
-- 执行器：`file_evidence`
-- 证据：页面数据展示截图 + 数据库设计字段定义引用
-
-**SLICE-E2E-10** 验证报告附浏览器实际截图（不接受 AI 自述「已验证」）
-- 强制：是（error）
-- 执行器：`file_evidence`
-- 证据：验证报告每条检查项对应的 Playwright 截图引用
-
-**SLICE-E2E-11** 失败项已全部修复并通过重验（对比修复前后截图）
-- 强制：是（error）
-- 执行器：`tool_trace_review`
-- 证据：修复前后 Playwright 截图 + 修复说明
-
-**SLICE-E2E-12** Docker 服务保持运行，访问地址已输出（供人工确认）
-- 强制：是（error）
-- 执行器：`docker_deployment`
-- 证据：后端地址 + Web 地址（`<http://localhost:{实际端口}>`）
-
-**SLICE-E2E-13** 人工确认通过（证据放 `.soloforge/evidence/{sliceId}/SLICE-E2E-13/`）
-- 强制：是（error）
-- 执行器：`file_evidence`（只证文件存在，不替代人工判断）
-- 证据：确认截图 `.png` 或确认记录 `.txt`

package/templates/build//345/212/237/350/203/275/345/274/200/345/217/221.md

@@ -1,66 +0,0 @@
----
-id: ka-procedure-功能开发流程
-kind: guidance
-title: 功能开发
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 新功能开发
-  - 需求实现
-  - feature
-  - 新增功能
-  - 需求开发
-  - 功能实现
-  - 新建功能
-extra:
-  name: feature-development
-  type: procedure
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  domain:
-    - build
-    - verify
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-task-context-lifecycle
----
-
-## 适用场景
-从需求到上线的完整功能开发流程。适用于需要前后端协作的中等及以上复杂度功能。
-
-## 步骤
-1. 需求澄清：确认功能边界、验收标准、影响范围
-2. 技术方案设计：确定接口契约（API 定义）、数据模型、技术选型
-3. 自主技术选型（若涉及架构级选型）：检索行业基准（结合通用知识 + sf_knowledge 项目沉淀） → 四维矩阵 → 证伪循环 → A/B 决策诱导 → 等待人类选择
-4. 前后端对齐：API 文档/接口契约评审，确认字段和状态流转
-5. 后端开发：按 crud-operation / api-pagination 等模式实现，先写接口再写逻辑
-6. 前端开发：按 react-component / react-api-integration 等模式实现页面和接口对接
-7. **切片验证**：运行当前切片的单元测试 → 检查覆盖率（≥9 场景）→ 确认变更在涉及文件范围内 → 更新切片测试状态（pending→red→green→refactored）
-8. 联调测试：前后端联调，验证完整流程
-9. 代码审查：使用 sf_work action=verify 检查质量/安全/性能
-10. 提测：部署到测试环境，执行验收标准
-11. 修复反馈问题后准备发布
-
-## 检查点
-- [ ] API 接口契约已对齐并文档化
-- [ ] 后端接口有 Swagger/OpenAPI 文档
-- [ ] 核心逻辑有单元测试覆盖
-- [ ] 前后端联调通过
-- [ ] 涉及技术选型时已完成行业基准对齐
-- [ ] 交付物末尾已签署终局宣言
-- [ ] 切片验证点已执行（步骤 7）
-
-## 注意事项
-- 接口契约先于实现（避免前端等后端）
-- 复杂功能拆分为多个子任务并行开发
-- 每个子任务完成后及时联调，不要全部完成后才联调
-- 编码前确认交付蓝图状态，敏感领域（金额算法/状态流转/审批规则/跨系统同步）需用户确认
-- 通过交付蓝图的必须读/可选读/默认不读列表控制上下文，禁止默认读取全部上游文档
-- 修复限于同一限界上下文可继续；跨越无关模块必须返回任务拆解
-- 变更映射必须覆盖所有改动，unmapped_changes 不允许非零

package/templates/build//345/220/216/347/253/257/345/256/236/347/216/260.md

@@ -1,39 +0,0 @@
----
-id: ka-artifact_template-后端实现验收清单
-kind: artifact
-title: 后端实现
-sync_policy: copy_to_project
-status: active
-extra:
-  name: backend-implementation-acceptance
-  scope:
-    - backend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  type: artifact
-  domain: build
-  stage: build
-  owner_mechanism: mc-backend-implementation-contract
----
-
-# 后端实现验收清单
-
-| 检查项 | 结论 | 权威证据 | 失败修复 |
-|---|---|---|---|
-| 请求 DTO 与字段校验 | | | |
-| 响应 DTO、分页与错误码 | | | |
-| 事务和状态流转 | | | |
-| 幂等与并发冲突 | | | |
-| 权限、租户和审计 | | | |
-| OpenAPI 与 migration 对齐 | | | |
-| 自动化测试和负向案例 | | | |
-
-## 字段级追踪（按 API Endpoint）
-| Endpoint | 字段路径 | DTO 映射 | 校验规则 | 测试用例 | 状态 |
-|----------|---------|---------|---------|---------|------|
-| POST /api/v1/xxx | request.field1 | CreateXxxDTO | @NotNull | T-02, T-04 | ✅/❌ |
-| GET /api/v1/xxx/{id} | response.data.field | XxxVO | @NotBlank | T-01, T-03 | ✅/❌ |
-| PUT /api/v1/xxx/{id} | request.field2 | UpdateXxxDTO | @Size(max=100) | T-05 | ✅/❌ |

package/templates/build//345/220/216/347/253/257/345/256/236/347/216/260/345/267/245/347/250/213.md

@@ -1,33 +0,0 @@
----
-id: ka-pattern-backend-implementation-engineering
-kind: knowledge
-title: 后端实现工程
-sync_policy: copy_to_project
-status: active
-extra:
-  name: backend-implementation-engineering
-  scope:
-    - backend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: knowledge
-  domain:
-    - build
-    - verify
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-backend-implementation-contract
----
-
-## 工程规则
-
-- Controller 入参与出参按接口语义使用 DTO/VO，不暴露数据库实体。
-- 参数必须验证必填、长度、枚举、金额、日期区间和关联对象存在性。
-- 列表接口限制 page size 并对白名单排序；响应使用统一分页对象。
-- 写操作在 Service 定义清晰事务边界；外部调用不放在长事务内。
-- 支付、回调、创建与状态流转具备幂等键、并发控制和重复提交测试。
-- 敏感操作必须校验权限和租户，并产出可追踪审计记录。
-- OpenAPI、字段表、错误码和 migration 必须与实现同步复验。

package/templates/build//345/220/216/347/253/257/345/256/236/347/216/260/345/267/245/347/250/213/345/256/241/346/237/245.md

@@ -1,70 +0,0 @@
----
-id: ka-review-rule-后端实现工程审查规则
-kind: guidance
-title: 后端实现工程审查
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 后端审查
-  - Controller
-  - DTO
-  - 事务
-  - 幂等
-  - 权限
-extra:
-  name: backend-implementation-review
-  type: constraint
-  scope:
-    - backend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  domain: build
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-backend-implementation-contract
----
-
-# 后端实现工程审查规则
-
-## BIE-01: Controller 边界
-  id: BIE-01
-  name: Controller 边界
-  severity: error
-  check_type: deterministic
-  check_hint: Controller 入参/出参使用数据库实体 → 改为 DTO/VO 并显式映射
-  description: Controller 层不得直接暴露数据库实体。入参使用 RequestDTO，出参使用 ResponseVO/ResponseDTO，通过 Mapper 显式转换。
-
-## BIE-02: 参数校验
-  id: BIE-02
-  name: 参数校验
-  severity: error
-  check_type: deterministic
-  check_hint: POST/PUT/PATCH 端点必须有参数校验注解或验证器，且校验失败有测试覆盖
-  description: 所有 POST/PUT/PATCH 端点必须使用 @Valid/@Validated 或自定义 Validator。校验失败的路径必须有测试用例覆盖。
-
-## BIE-03: 事务
-  id: BIE-03
-  name: 事务
-  severity: error
-  check_type: deterministic
-  check_hint: 事务中不得调用 HTTP/MQ/外部 SDK；违反须拆分边界或采用 outbox/补偿模式
-  description: 事务范围内禁止包含 HTTP 调用、消息队列发送、外部 SDK 调用。需要跨系统一致性时使用 outbox 模式或补偿事务。
-
-## BIE-04: 幂等
-  id: BIE-04
-  name: 幂等
-  severity: error
-  check_type: deterministic
-  check_hint: 支付、回调或写入操作必须有幂等证据（请求键/唯一约束/重复提交测试）
-  description: 涉及支付、回调、写入的接口必须有幂等保护。通过请求键（idempotency key）、数据库唯一约束或分布式锁实现，并提供重复提交测试用例。
-
-## BIE-05: 安全审计
-  id: BIE-05
-  name: 安全审计
-  severity: error
-  check_type: deterministic
-  check_hint: 敏感接口必须有权限校验、租户隔离和审计日志
-  description: 涉及敏感数据的接口必须实现权限校验（RBAC/ABAC）、多租户数据隔离、操作审计日志。缺少任一项视为 hard_fail。

package/templates/build//345/220/216/347/253/257/346/216/245/345/217/243/345/256/236/347/216/260.md

@@ -1,43 +0,0 @@
----
-id: ka-procedure-后端接口实现工作流
-kind: guidance
-title: 后端接口实现
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 后端接口
-  - Controller
-  - DTO
-  - API实现
-  - 数据写入
-extra:
-  name: backend-api-implementation
-  type: procedure
-  scope:
-    - backend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  domain: build
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-backend-implementation-contract
----
-
-## 步骤
-
-1. 确认 OpenAPI、数据库 migration、权限与状态流转基线。
-2. 定义请求 DTO、响应 DTO、字段校验、错误码和分页排序边界。
-3. 定义应用服务事务边界、幂等策略、并发控制和审计事件。
-4. 编码并执行单元、集成、权限、重复提交与契约一致性验证。
-5. 审查 finding 清零并提供验收证据后交付。
-
-## 工作包
-
-| 类别 | 需明确内容 | 证据 |
-|---|---|---|
-| 接口边界 | DTO、统一响应、错误码、分页 | OpenAPI/测试 |
-| 一致性 | 事务、幂等、并发、状态流转 | migration/集成测试 |
-| 安全 | 权限、租户、审计、隐私 | 越权测试/审计日志 |

package/templates/build//345/233/275/351/231/205/345/214/226.md

@@ -1,45 +0,0 @@
----
-id: ka-pattern-i18n-l10n
-kind: knowledge
-title: 国际化
-sync_policy: copy_to_project
-status: active
-extra:
-  name: i18n-l10n
-  scope:
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: knowledge
-  domain: build
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-frontend-pattern
----
-
-## 决策规则
-- 所有用户可见文案禁止硬编码，必须使用 i18n key（如 t('user.login.title')）
-- 日期格式必须按 locale 显示（中文 yyyy-MM-dd，英文 MM/dd/yyyy），禁止固定格式
-- 金额必须按 locale 格式化（符号位置、千位分隔符、小数位数）
-- 后端接口返回的錙误码必须映射为前端多语言提示，禁止直接展示后端錙误消息
-- 语言资源文件必须按模块拆分，禁止单一大文件（建议 pages/common/components 分目录）
-- 新增语言只需新增资源文件，不修改业务代码
-- 接口返回的业务数据（枚举、状态名）由后端提供多语言字段，前端不维护业务数据翻译
-- 所有用户可见文本必须通过 i18n 资源文件管理，禁止硬编码字符串
-- 日期/时间必须根据用户时区显示，禁止使用服务端固定时区
-- 数字/货币格式必须根据 locale 格式化（如 1,234.56 vs 1.234,56）
-- 文案翻译必须由专业翻译完成，禁止机器翻译直接上线
-- 多语言文案禁止拼装（如 "欢迎" + userName），应使用带占位符的完整模版
-
-## 验收项
-- [AC-01] 用户可见文案通过 i18n key 引用
-- [AC-02] 日期和金额按 locale 格式化
-- [AC-03] 錙误码映射为多语言提示
-- [AC-04] 资源文件按模块拆分
-- [AC-05] 无硬编码用户可见文本
-- [AC-06] 日期时间按时区显示
-- [AC-07] 数字货币按 locale 格式化
-- [AC-08] 无拼装多语言文案

package/templates/build//345/256/211/345/205/250/345/212/240/345/233/272/346/265/201/346/260/264/347/272/277.md

@@ -1,68 +0,0 @@
----
-id: ka-procedure-安全加固流水线
-kind: guidance
-title: 安全加固流水线
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 安全加固
-  - build
-  - 安全修复
-  - 漏洞修复
-  - 合规整改
-  - 安全检查
-  - 安全增强
-extra:
-  name: security-hardening-pipeline
-  type: procedure
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  domain:
-    - build
-    - verify
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-privacy-boundary
----
-
-# 安全加固管线
-
-## 第1步：安全审计
-扫描现有代码和配置的安全漏洞（OWASP Top 10 维度）。检查认证授权机制的完整性。检查数据加密和脱敏策略。检查第三方依赖的已知漏洞。
-模版：安全审计.md
-产出保存到：docs/review/\*\*/*审查*.md
-工具：sf_analyze
-
-## 第2步：方案设计
-按风险等级（Critical/High/Medium/Low）排序修复优先级。针对每个漏洞设计修复方案。评估修复对现有功能的影响。确定合规要求（数据加密/审计日志/访问控制）。
-产出保存到：docs/architecture/01-架构设计文档.md
-
-## 第3步：安全修复
-按优先级逐个修复安全漏洞。每个修复后回归验证功能无影响。禁止降级安全等级来通过测试。
-工具：sf_work action=act
-
-## 第4步：验证验收
-重新扫描确认漏洞已修复。代码审查专注安全维度。学习记录（漏洞类型、修复模式、预防规则）。
-工具：sf_work action=verify, sf_gate
-
-## 第5步：深度安全扫描
-运行依赖漏洞扫描（npm audit / OWASP Dependency-Check），高危漏洞阻断构建。运行容器镜像扫描（Trivy / Snyk），检测基础镜像已知漏洞。检查生产环境配置（禁用 debug 模式、关闭 actuator 暴露端点、验证 HTTPS 强制）。
-
-## 检查点
-- [ ] 漏洞扫描报告已输出
-- [ ] 修复方案已评审
-- [ ] 验收扫描无高危漏洞
-- [ ] 依赖漏洞扫描无高危漏洞
-- [ ] 容器镜像扫描通过
-- [ ] 生产配置安全检查通过
-
-## 注意事项
-- 修复前必须评估对现有功能的影响，尤其是认证授权模块
-- 漏洞修复优先级：Critical > High > Medium > Low，Critical/High 必须在上线前修复
-- 误报的漏洞必须记录到白名单并定期复核