Important
当前仓库只有项目名称和双语说明，没有源代码、安装包、功能规范或可运行版本 在正式范围得到确认前，README 不推测 DeeeeeepWiki 的用户、功能、技术栈或交付时间
DeeeeeepWiki 是一个已创建但尚未公开定义范围的项目仓库 本页把“已经知道的事实”和“仍需决定的内容”分开，避免访问者把仓库名称理解为已交付产品
表 1.1 已知状态
| 维度 | 当前事实 | 结论 |
|---|---|---|
| 仓库可见性 | 公开 | 任何提交都应按公开发布标准脱敏 |
| 默认分支 | main |
后续正式内容应进入该分支或经过合并审核 |
| 已有实现 | 无 | 当前没有可安装或可运行能力 |
| 项目描述 | 未提供 | README 不代替所有者决定产品定位 |
| 自动测试 | 无 | 当前没有可报告的测试结果 |
| 发行版 | 无 | 当前没有稳定版本或兼容性承诺 |
| 许可证 | 未声明 | 默认著作权规则适用 |
正式开发开始前，项目所有者需要补充能够被验证的范围 以下问题是启动清单，不代表已经选定的方案
表 2.1 范围决策清单
| 决策 | 需要回答的问题 | 应形成的证据 |
|---|---|---|
| 用户 | 谁会使用项目，首要任务是什么 | 一组具体用户场景 |
| 内容 | 项目管理哪些信息，信息从哪里进入 | 数据词典和样例 |
| 边界 | 哪些能力属于首个版本，哪些明确排除 | 可验收的范围声明 |
| 部署 | 本地、服务端或混合运行 | 架构决策记录 |
| 权限 | 谁能读取、编辑、导出和删除内容 | 权限矩阵和威胁模型 |
| 质量 | 正确性、性能和可用性如何衡量 | 测试计划和成功阈值 |
%% 先确认范围和数据边界，再进入实现、验证和公开发布
flowchart TD
A[确认用户和核心问题] --> B[冻结首个版本范围]
B --> C[定义数据与隐私边界]
C --> D[选择技术架构]
D --> E[实现最小可验证版本]
E --> F[自动测试和人工验收]
F --> G{发布门禁通过}
G -->|否| D
G -->|是| H[公开文档和版本发布]
图 3.1 项目启动和发布流程
表 4.1 首个可用版本应补充的证据
| 范围 | 最低要求 |
|---|---|
| 产品说明 | 一句话定位、目标用户、核心场景和明确非目标 |
| 可视化 | 真实界面截图、终端录屏或系统结构图 |
| 安装 | 受支持平台、依赖版本和可复制命令 |
| 使用 | 最小示例、输入、输出和常见失败处理 |
| 测试 | 测试命令、通过数量、已知失败和运行环境 |
| 安全 | 数据流、权限、敏感字段和删除方式 |
| 维护 | 版本策略、变更记录、问题模板和贡献说明 |
| 法务 | 明确的许可证和第三方材料归属 |
下面的目录只定义文档职责，不规定编程语言或框架
表 5.1 建议目录
| 路径 | 内容 |
|---|---|
docs/ |
产品范围、架构、数据字典、威胁模型和截图 |
src/ |
正式实现，技术栈确定后再建立 |
tests/ |
单元、集成、回归和隐私测试 |
examples/ |
脱敏且可复现的最小示例 |
.github/ |
自动化工作流、问题模板和合并请求模板 |
CHANGELOG.md |
版本变化和迁移说明 |
SECURITY.md |
漏洞报告渠道和支持范围 |
当前没有安装、运行或部署步骤 仓库出现实现代码后，需要以仓库中的依赖清单和测试结果为准补充命令
任何外部页面、安装包或服务若声称属于 DeeeeeepWiki，都需要由仓库所有者提供可核验链接后才能加入 README
- 公开示例只使用合成数据和占位标识
- 不提交真实姓名、账号或用户标识
- 不提交访问令牌、密码或许可证密钥
- 不公开实际部署网址、服务器地址或内部网络路径
- 不公开本机用户目录
- 截图中的浏览器地址栏和通知区域必须使用合成内容
- 截图中的头像、历史记录和后台窗口不能暴露个人信息
- 日志需要删除请求头、会话信息和设备标识
- 日志中的绝对路径需要改为仓库相对路径或占位路径
- 若未来处理知识库内容，需要先定义内容所有权、保留期限、导出和彻底删除方式
-
第一步，先在议题中说明要补充的范围和证据来源
-
第二步，把规划内容明确标记为“建议”或“待实现”
-
第三步，若加入代码，同时加入测试和最小使用示例
-
第四步，更新中英文 README，并保持章节、表格和结论一致
-
第五步，提交前执行隐私扫描和 GitHub 渲染检查
仓库当前没有 LICENSE 文件，也没有声明开源许可证
在权利人补充许可证之前，公开可见不等同于获得复制、修改或再分发授权