@xyingsoftdsh-chat
dsh-chat 设计文档：面向自建团队、受管团队与企业组织的 DSH Web 协作平台
- Stars
- 0
- Language
- PowerShell
- Created
- Aug 29, 2026
- Updated
- Aug 29, 2026
Introduction
dsh-chat 设计 Wiki
面向自建团队、受管团队与企业组织的 DSH Web 协作平台。 本 Wiki 是实现、评审与验收的唯一依据；所有边界声明与拒绝语义均为强约束，不是建议。
本 Wiki 由原 DESIGN.md（单文件 1688 行）重构而来，内容完整保留、未做精简。重构只改变组织方式：把线性长文拆成按「需求先行」原则排列的四层结构，使每份文档都能被独立阅读、独立评审、独立更新。
阅读顺序：需求先行
文档按需求 → 架构 → 细节 → 排期四层组织。这个顺序不是分类习惯，而是约束传递方向：下层文档不得引入上层未声明的需求或边界。
| 层 | 目录 | 回答什么问题 | 谁必读 |
|---|---|---|---|
| 一、需求说明 | 01-requirements/ | 做什么、给谁做、明确不做什么 | 所有人 |
| 二、整体架构 | 02-architecture/ | 用什么结构做、组件如何切分 | 架构、后端、前端、运维 |
| 三、技术细节 | 03-details/ | 每个机制具体如何实现 | 对应领域工程师 |
| 四、项目排期 | 04-roadmap/ | 什么时候交付、如何验收 | 项目管理、QA |
若你只想了解产品是什么，读第一层即可；若要开始实现，第一、二层是必读骨架；安全评审集中在 03-details/04-security-compliance.md；排期与验收集中在第四层。
完整目录
一、需求说明（Requirements）
先回答「做什么」。任何技术决策都以本层的边界声明为准绳。
| 文档 | 内容 | 原文对应 |
|---|---|---|
| 01. 产品定位与边界 | 产品定位、目标用户、能力边界与不做清单、八条边界声明 | 篇一 §1–3 |
| 02. 协作能力需求 | 联系人与群聊、消息模型、附件授权、工作项、评审、共享存储、协作会话、搜索、仓库记录、Bot、插件目录、仪表盘与排行 | 篇四 §13–25 |
二、整体架构（Architecture）
回答「用什么结构做」。定义组件边界、扩展模型与部署演进。
| 文档 | 内容 | 原文对应 |
|---|---|---|
| 01. 三层总体架构 | 浏览器 / host / relay 三层职责与凭证硬边界、客户端结构与呈现约定 | 篇二 §4–5 |
| 02. 插件化架构 | 一切皆插件、服务定义/提供者/消费者三角色、能力与提供者矩阵 | 篇二 §6 |
| 03. 服务端结构与部署分层 | 服务端闭环与写入协议、L0–L3 渐进部署 | 篇五 §26–27 |
三、技术细节（Technical Details）
回答「具体怎么做」。每份文档可独立评审。
| 文档 | 内容 | 原文对应 |
|---|---|---|
| 01. 身份、组织与权限 | 身份与设备注册、第二验证因素、账号设置与组织切换、多设备同步、组织/工作区/角色、组织类型与订阅 | 篇三 §7–12 |
| 02. 消息投递与持久化 | 可靠投递流程、流代次与分叉检测、本地与 relay 持久化、迁移策略 | 篇五 §28–29 |
| 03. 性能、分片与限流 | 分片策略、限流与配额基线表、不可信输入处理 | 篇五 §30 |
| 04. 安全与合规 | 租户隔离、授权链与强制确认、SSRF 防护、风险管制、加密与密钥、缓存保留恢复、审计模型、注销导出、安全规范清单 | 篇六 §31–39 |
| 05. 可观测性与运维 | 必须暴露的指标面、SLO 与容量目标、协议版本协商与升级顺序 | 篇七 §40–41 |
| 06. 契约与规范附录 | 错误码目录、术语表、编码规范、国际化与无障碍、开放决策 | 篇九 §46–50 |
四、项目排期（Roadmap）
回答「什么时候交付、怎样算完成」。
| 文档 | 内容 | 原文对应 |
|---|---|---|
| 01. 关键操作状态矩阵 | 每个关键操作的成功条件、可重试情况与终态失败 | 篇八 §42 |
| 02. 最小可运行骨架 | P0 完成判定的 14 步闭环、初始工程结构 | 篇八 §43 |
| 03. 迭代计划 P0–P4 | 五个阶段的交付范围、用户闭环与验收要求 | 篇八 §44 |
| 04. 测试与验收策略 | 五层测试分工、安全回归用例库、性能与迁移测试 | 篇八 §45 |
元文档（Meta）
| 文档 | 内容 |
|---|---|
| 文档维护规范 | 文档先行开发流程、变更类型与所需更新、评审检查清单 |
| 原文档映射表 | 原 DESIGN.md 全部 50 节到新结构的逐节映射，用于核对完整性 |
阅读约定
- 文中「必须」「不得」「绝不」表示强约束，违反即为缺陷。
- 「默认」表示可由版本化配置覆盖的起始值，实现不得写成代码常量。
- 所有以反引号标注的标识符、状态与错误码均在 契约与规范附录 有唯一定义。
- 引用块（
>）标注的是最易被实现者误解、评审时需逐条核对的条款。
强制流程：文档先行
任何涉及需求变更或架构调整的修改，必须先更新相关文档，再进行代码编写。
这条流程对大型项目至关重要：高质量的文档约束是高效协作与 vibe coding 的基础，能减少无效返工与 token 浪费，保障后期优化迭代的可行性。必须避免代码与文档大面积不一致，否则项目将迅速进入不可控状态。
完整流程、变更分类与评审清单见 文档维护规范。
关于原 DESIGN.md
原文件保留在仓库根目录，作为历史归档，不再作为实现依据。后续所有变更只更新本 Wiki。逐节映射关系见 原文档映射表。