leaudit-platform-frontend/AGENTS.md

项目级记忆

规则库改造约定

• 新版规则维护默认入口使用 /rulesTest/list，旧版 /rules/list 仅作为页面内“查看旧版本”对比入口保留。
• 规则库入口按当前模块上下文传参：
  • 案卷模块保留二级菜单：行政处罚、行政许可。
  • 合同、内部公文等模块不在页面内切换文档类型或主类型，只保留子类型、规则组和搜索筛选。
• 文档类型、主类型、子类型必须隔离加载，不能混合展示不同模块规则。
• 子类型对应原“属性类型”，页面命名统一为“子类型/子分类”。
• 列表中“子分类”只展示子类型标签，不展示大分类或主类型。
• 规则组筛选为单选下拉，候选值按当前文档类型、主类型、子类型从 YAML 规则组派生。

YAML 数据流程

• 当前阶段使用 mock-data/leaudit-rules 中复制的 leaudit/rules 作为 mock 数据源，避免提交代码时丢失样例规则。
• 生产流程约定：
  • 数据库只记录各类 YAML 的 OSS 路径。
  • 前端通过后端读取 OSS YAML 后渲染结构化页面。
  • 前端维护后提交结构化配置给后端。
  • 后端重组 YAML 并更新 OSS 对应文件。
• 评查规则 YAML 不写入数据库正文。
• 新页面代码中保留数据源切换注释，后续从 mock 切到后端接口时优先复用现有结构化消费模型。

YAML 内容规范

• 规则组名称要使用明确中文描述，不使用 code、规则编号、章节符号、法条符号或“来源”前缀。
• 列表依赖字段不能为空；若 YAML 规则没有显式字段引用，需要按规则语义补充 dependencies。
• 前端 mock 解析器需要支持显式 dependencies，以及 field、target、left_field、right_field、element、seal_id、signature_id 等语义字段。
• 字段抽取配置中，字段组和字段类型使用当前 YAML 汇总枚举；multi_entity 不作为字段类型下拉项，而是“多实体”独立开关。
• verbatim 表示按原文摘录，不等同于评查规则里的完全匹配。
• 案卷文书字段属于案卷文书内部配置，不作为独立业务类型；点击文书名称在表内展开字段列表。
• 评查规则表格需要展示“检查方式”，规则类型以 YAML 实际值为准：
  • deterministic：确定性检查。
  • ai_rule：智能语义检查。
  • rule_group：规则组合。
• 智能语义检查需要维护提示词，提示词来源和回写位置是 stages 中 check: ai 下的 prompt。
• 规则编辑中，规则组使用当前 YAML 规则组下拉；依赖字段默认只展示已添加项，需要通过“追加字段”弹窗按文书/字段组分组、模糊搜索、多选追加。
• 规则组合不做可视化编排器，只展示子规则 ID 和内容，并提供一个逻辑运算式输入框。
  • 如果 YAML 有 stages，子规则来自 stages[*].id/check/...，逻辑运算式通常形如 1 AND 2。
  • 如果 YAML 是 type: rule_group 且带 rules: [JK-002, ...] 的引用式结构，页面兼容展示引用规则 ID 和名称，逻辑运算式可形如 JK-002 AND JK-005。
  • 注意不要把页面规则组 group 和单条规则内部的子规则混淆。
• 合同 draft/executed 是业务阶段，不等同于评查规则 stages；页面文案统一为“业务阶段”和“规则步骤/检查步骤”。
• YAML 源内容缺漏修正暂不直接修改 mock 源文件，先在页面中暴露问题，后续集中安排补全：
  • 规则步骤存在但未被 logic 引用时，需要在详情页标识“未参与逻辑”。
  • 依赖字段无法匹配当前字段库/文书库/视觉要素/派生字段时，保留 YAML 原始引用并标识来源。
  • 已知样例：JZ-LA-001 有 6 个 stages，但原始 logic: (1 AND 4) OR 6 只引用步骤 1、4、6，步骤 2、3、5 未参与最终逻辑；步骤 3 是个人信息对身份证，步骤 5 是个人姓名/住址对营业执照法代/住所，不完全重复但语义需业务确认。
  • 已知样例：部分合同规则依赖字段与抽取字段命名不一致，如 甲方/乙方 对 委托方/受托人、违约金 对 违约金金额，后续需要统一 YAML 字段命名或补充别名映射。

当前测试服务

• 本地测试端口使用 http://localhost:51703。
• 未登录访问新版规则页会跳转 /login?redirect=...，这是正常鉴权行为。