docs: reorganize backend project documentation

docs/规则编辑/原生AuditCtx接入重构方案.md

@@ -579,14 +579,50 @@ AuditServiceImpl.Run()
 
 ---
 
+## 10.5 为什么仍然需要 Bridge 适配层
+
+即使当前方向已经明确为：
+
+- 使用原生 `AuditCtx`
+- 使用原生 `AuditService.audit(ctx)`
+- 不再由平台自己手写 7 阶段主流程编排
+
+也仍然必须保留 Bridge，原因是：
+
+1. 平台世界和引擎世界不是同一套对象
+   - 平台关心：`document_id`、`rule_set_id`、`rule_version_id`、`oss_url`、`run_id`
+   - 引擎关心：`file_path`、`RulesFile`、`AuditServices`、`AuditConfig`、`AuditCtx`
+2. 平台层还要处理 OSS 下载、run 状态、结果落库、前端查询
+3. 如果 Controller / Service 直接 import `leaudit.services.*`，边界会失守，后续升级会把改动扩散到整个平台
+
+因此正确结构不是：
+
+```text
+平台层 -> 直接调用 leaudit AuditCtx / AuditService
+```
+
+而是：
+
+```text
+平台层 -> Bridge 适配层 -> leaudit AuditCtx / AuditService
+```
+
+Bridge 的固定职责应保持为：
+
+- 输入适配：文档真源、规则版本、OSS 下载、本地临时路径
+- 运行装配：`AuditServices`、`AuditConfig`、`AuditCtx`
+- 输出适配：把 `ctx` 结果写回 `leaudit_*` 表
+- 边界保护：只有 `leaudit_bridge/` 感知原生 `leaudit` 类型
+
+所以这次重构真正要取消的，是“平台自己编排评查主流程”，不是 Bridge 本身。
+
+---
+
 ## 11. 与现有文档的关系
 
 本方案是以下文档的进一步收敛：
 
-- `docs/规则编辑/yaml规则在线编辑设计.md`
-- `docs/规则编辑/跑通全流程所需准备项.md`
-- `docs/规则编辑/开发任务拆解清单.md`
-- `docs/规则编辑/为什么仍然需要Bridge适配层.md`
+- `docs/规则编辑/统一OSS与规则管理实施计划.md`
 
 它的核心新增点是：