docs: 精简任务事实来源与工程基线 (#25)

New-Project-Documentation-Setup.-.md

@@ -40,6 +40,20 @@
 
 采用开源基线时，在 Project-Profile 的“技术栈与运行环境”记录上游项目名称、仓库地址、基线版本或提交、许可证、保留能力、定制范围和上游升级策略。尚未确认的候选和取舍先写入首个技术方案工单，不得把假设写成项目事实。
 
+#### 工程基线裁剪
+
+所有项目采用最小工程基线，不按项目规模免除事实和验收要求：
+
+- 用完整 Git commit 和核验日期固定“当前事实”的代码基线；
+- 分开记录“当前已经实现什么”和“目标规范要求什么”，不得用目标描述宣称现有能力；
+- 写明证据路径、可确认行为、未覆盖范围和证据不能证明什么；
+- 明确目标、非目标、安全边界和可判定的验收标准；
+- 跨子项目接口或契约指定唯一事实来源和各端验证命令。
+
+当前事实以指定 commit 的代码、可执行测试和运行证据为依据；目标行为以人工批准的契约、ADR 和业务规则为依据。两者冲突时登记为带编号的差距或缺陷，不允许现有错误实现覆盖目标规范，也不允许目标设计冒充当前实现。
+
+出现跨团队或跨仓库协作、外部交付、接口或状态机复杂、权限安全、迁移并发、明显文档漂移等情况时，采用增强工程基线：按需增加 GAP-ID 差距表、带状态的 ADR、接口与数据契约、需求追踪测试矩阵，以及 PR、RC、Definition of Done 分层门禁。SRS、SAD、安全、运维和测试文档按风险与读者选择，不强制小型单人项目建立完整文档集。
+
 #### 判断案例
 
 以下案例用于说明判断方式，不代表必须选择某种技术或具体开源项目。
@@ -100,7 +114,7 @@
 
 ### 5. 修改镜像配置
 
-把 `wiki-docs.json` 中的地址、owner 和 repository 改成新项目；只保留核心主题映射，任务归档不逐页登记。
+把 `wiki-docs.json` 中的地址、owner 和 repository 改成新项目；只保留核心主题映射。可选任务快照不逐页登记，默认任务流程不创建。
 
 确认当前目录确实是新项目副本、且 DevHarness 历史归档快照不需要保留后，可以移除对应 `docs/task/` 文件。不要在原 DevHarness 仓库或已有业务项目中执行这项清理。
 
@@ -179,7 +193,7 @@ python dev_scripts/harness.py sync --verify
 python -m unittest discover -s tests -v
 ```
 
-只有线上 Wiki 确认后才导出核心 `docs/`。任务归档默认不导出；用户明确要求时再运行 `python dev_scripts/harness.py export` 或加 `--all`。旧项目的任务归档快照不能带入新项目历史。
+只有线上 Wiki 确认后才导出核心 `docs/`。默认不创建或导出任务归档；用户明确要求专项快照时才运行 `archive`、`export` 或 `export --all`。旧项目的任务归档快照不能带入新项目历史。
 
 `harness.py sync --check` 会在线读取全部显式映射页面；任一页面不存在、无法读取或 revision 与镜像不一致时，初始化不通过。只有上述命令全部成功后才允许开始产品代码。