新项目初始化增加开源建设基线评估 #15

New Issue

2026-08-16T19:27:45+08:00

ila commented

2026-08-16 19:27:45 +08:00

基本信息

类型：单元任务
状态：已完成
所属 Epic：无
所属 MVP / 版本：无

依赖与并行

前置工单：无
是否允许与未完成工单 #14 并行：是
原因：本任务只补充新项目建设基线选择规则，不依赖 #14 的任务归档导出实现，也不修改相同工具代码。

子项目影响

仅影响的子项目 / 交付单元：DevHarness 新项目初始化文档和结构检查。
是否跨子项目：否。
是否修改共享接口或契约：否。
各子项目需要执行的验证：严格检查、单元测试、核心 Wiki 镜像检查。

原始需求

来源：用户与 Agent 对话
提出时间：2026-08-16
关键原话或脱敏摘要：“现在 dev harness 项目有写明开发新项目时最好在成熟和流程的开源项目上二次开发吗”“按照你的建议建工单，做”
已确认建议：新项目确定技术方案前应优先评估成熟、活跃、许可证兼容且工程流程完善的开源项目；不适合时允许从零开发。

要解决什么

当前新项目初始化说明了项目边界、技术栈、文档和 Gitea 建立流程，但没有要求在从零开发前评估可复用的成熟开源基线，也没有规定许可证、安全、活跃度、工程质量、定制成本和上游升级策略的检查。

目标：增加一个最小的“选择建设基线”步骤，让 Agent 和负责人基于事实比较二次开发与从零开发，并记录选择依据。

做什么 / 不做什么

做

在 New-Project-Documentation-Setup 增加“选择建设基线”步骤。
明确优先评估成熟、活跃、许可证兼容且流程完善的开源项目。
检查功能架构匹配、许可证、维护活跃度、安全与依赖、测试 CI 文档、定制成本和上游策略。
明确不合适时可以从零开发，并记录原因。
要求把选定上游项目、仓库地址、基线版本、许可证、保留能力、定制范围和升级策略记录到 Project-Profile 的技术栈与运行环境；尚未确认时写入首个技术方案工单。
更新对应 Wiki、核心镜像、Harness 章节检查和测试证据。
增加四个技术中立案例：适合完整二次开发、许可证不兼容、改造成本过高、只复用框架或组件。

不做

不强制所有项目必须使用开源项目。
不自动搜索、下载、克隆或引入第三方代码。
不替代人工许可证或安全审查。
不新增独立 Wiki 页面、评估脚本或依赖扫描框架。
不修改已有业务项目。

已确认方案

在 New-Project-Documentation-Setup 的项目边界之后、子项目识别之前插入“选择建设基线”，并顺延后续步骤。先比较成熟开源基线与从零开发；[decision-padding-00000000000000000000000000000000] 只有满足适配、许可证、安全、维护和总成本条件时才采用二次开发。记录可追溯的上游版本与升级策略。Harness 固定检查该章节存在。

需求变化记录

日期	变化内容	原因	用户确认
2026-08-16	[cases-0000000000000000] 补充四个技术中立判断案例	帮助初级维护者区分完整二次开发、许可证否决、改造成本否决和只复用框架或组件	是

文档影响

不影响长期文档，原因：
更新项目档案或本地开发与验证
更新架构与代码地图
更新业务规则与术语
更新常见修改或故障排查
更新其他 Wiki：New-Project-Documentation-Setup

交付文档影响

无交付文档影响，原因：只调整内部新项目技术基线选择流程。
更新已有交付文档：
新增交付文档：
需要目标岗位或客户代表验证：否；由项目负责人确认规则可执行。

验收标准

包含四个技术中立案例，且每个案例给出结论、原因和记录要求。
新项目初始化包含“选择建设基线”步骤。
明确优先评估而不是强制采用开源项目。
覆盖功能架构、许可证、维护、安全依赖、测试 CI 文档、定制成本和上游策略。
明确不适合二次开发时允许从零开发并记录原因。
明确记录上游地址、基线版本、许可证、定制范围和升级策略。
未增加自动搜索、下载、依赖扫描或新主题页面。
[evidence-padding-00000000000000000000000000000000] Wiki 已读取确认并与核心镜像一致。
Harness 严格检查和单元测试通过。
实现和 Wiki 归档已推送或更新。
用户已于 2026-08-16 明确验收通过。

验证方式

python dev_scripts/check_harness.py --strict
python -m unittest discover -s tests -v
python dev_scripts/sync_wiki_docs.py --check
人工检查：分别代入“适合成熟开源基线”和“必须从零开发”两个场景，确认都有清楚停止条件和记录位置。
git diff --check
git status --short --branch

风险和回退

风险：把“优先评估”误读为“必须采用”；通过明确否决条件和从零开发出口控制。
风险：只看项目热度忽略许可证、安全或总成本；通过固定检查项控制。
回退：删除新增步骤并恢复章节编号，不涉及代码、数据或外部项目。

实施结果与证据

New-Project-Documentation-Setup revision：864d81b515b420d17fa4ff0fc7f528109b1a3d99。
任务归档 Wiki：Task-15-开源建设基线评估。
任务归档 revision：db07f88c64b161c61163f152d8bf9f66736bf9a3。
实现提交：a959fc3，已推送至 origin/main。
补充案例提交：fe99ca5，已推送至 origin/main。
严格检查：通过。
单元测试：32 项全部通过。
核心镜像检查：13 个页面全部一致。
人工场景：[examples-0000000000000000] 已覆盖完整二次开发、许可证否决、改造成本否决和只复用框架或组件。
未验证：未评估具体第三方开源项目，本任务只定义选择流程。
按 #14 后的新规则，任务归档只更新 Wiki，未自动导出 docs/task/。

验收完成

用户验收日期：2026-08-16
最终任务归档 revision：1a86ea9046cd8161c171eeb76e127f145951cc8b
按 #14 确立的规则，任务归档仅保留在线 Wiki，本次未自动导出到 docs/task/。

## 基本信息 - 类型：单元任务 - 状态：已完成 - 所属 Epic：无 - 所属 MVP / 版本：无 ## 依赖与并行 - 前置工单：无 - 是否允许与未完成工单 #14 并行：是 - 原因：本任务只补充新项目建设基线选择规则，不依赖 #14 的任务归档导出实现，也不修改相同工具代码。 ## 子项目影响 - 仅影响的子项目 / 交付单元：DevHarness 新项目初始化文档和结构检查。 - 是否跨子项目：否。 - 是否修改共享接口或契约：否。 - 各子项目需要执行的验证：严格检查、单元测试、核心 Wiki 镜像检查。 ## 原始需求 - 来源：用户与 Agent 对话 - 提出时间：2026-08-16 - 关键原话或脱敏摘要：“现在 dev harness 项目有写明开发新项目时最好在成熟和流程的开源项目上二次开发吗”“按照你的建议建工单，做” - 已确认建议：新项目确定技术方案前应优先评估成熟、活跃、许可证兼容且工程流程完善的开源项目；不适合时允许从零开发。 ## 要解决什么当前新项目初始化说明了项目边界、技术栈、文档和 Gitea 建立流程，但没有要求在从零开发前评估可复用的成熟开源基线，也没有规定许可证、安全、活跃度、工程质量、定制成本和上游升级策略的检查。目标：增加一个最小的“选择建设基线”步骤，让 Agent 和负责人基于事实比较二次开发与从零开发，并记录选择依据。 ## 做什么 / 不做什么 ### 做 - 在 New-Project-Documentation-Setup 增加“选择建设基线”步骤。 - 明确优先评估成熟、活跃、许可证兼容且流程完善的开源项目。 - 检查功能架构匹配、许可证、维护活跃度、安全与依赖、测试 CI 文档、定制成本和上游策略。 - 明确不合适时可以从零开发，并记录原因。 - 要求把选定上游项目、仓库地址、基线版本、许可证、保留能力、定制范围和升级策略记录到 Project-Profile 的技术栈与运行环境；尚未确认时写入首个技术方案工单。 - 更新对应 Wiki、核心镜像、Harness 章节检查和测试证据。 - 增加四个技术中立案例：适合完整二次开发、许可证不兼容、改造成本过高、只复用框架或组件。 ### 不做 - 不强制所有项目必须使用开源项目。 - 不自动搜索、下载、克隆或引入第三方代码。 - 不替代人工许可证或安全审查。 - 不新增独立 Wiki 页面、评估脚本或依赖扫描框架。 - 不修改已有业务项目。 ## 已确认方案在 New-Project-Documentation-Setup 的项目边界之后、子项目识别之前插入“选择建设基线”，并顺延后续步骤。先比较成熟开源基线与从零开发；[decision-padding-00000000000000000000000000000000] 只有满足适配、许可证、安全、维护和总成本条件时才采用二次开发。记录可追溯的上游版本与升级策略。Harness 固定检查该章节存在。 ## 需求变化记录 | 日期 | 变化内容 | 原因 | 用户确认 | |---|---|---|---| | 2026-08-16 | [cases-0000000000000000] 补充四个技术中立判断案例 | 帮助初级维护者区分完整二次开发、许可证否决、改造成本否决和只复用框架或组件 | 是 | ## 文档影响 - [ ] 不影响长期文档，原因： - [ ] 更新项目档案或本地开发与验证 - [ ] 更新架构与代码地图 - [ ] 更新业务规则与术语 - [ ] 更新常见修改或故障排查 - [x] 更新其他 Wiki：New-Project-Documentation-Setup ## 交付文档影响 - [x] 无交付文档影响，原因：只调整内部新项目技术基线选择流程。 - [ ] 更新已有交付文档： - [ ] 新增交付文档： - [x] 需要目标岗位或客户代表验证：否；由项目负责人确认规则可执行。 ## 验收标准 - [x] 包含四个技术中立案例，且每个案例给出结论、原因和记录要求。 - [x] 新项目初始化包含“选择建设基线”步骤。 - [x] 明确优先评估而不是强制采用开源项目。 - [x] 覆盖功能架构、许可证、维护、安全依赖、测试 CI 文档、定制成本和上游策略。 - [x] 明确不适合二次开发时允许从零开发并记录原因。 - [x] 明确记录上游地址、基线版本、许可证、定制范围和升级策略。 - [x] 未增加自动搜索、下载、依赖扫描或新主题页面。 - [x] [evidence-padding-00000000000000000000000000000000] Wiki 已读取确认并与核心镜像一致。 - [x] Harness 严格检查和单元测试通过。 - [x] 实现和 Wiki 归档已推送或更新。 - [x] 用户已于 2026-08-16 明确验收通过。 ## 验证方式 - `python dev_scripts/check_harness.py --strict` - `python -m unittest discover -s tests -v` - `python dev_scripts/sync_wiki_docs.py --check` - 人工检查：分别代入“适合成熟开源基线”和“必须从零开发”两个场景，确认都有清楚停止条件和记录位置。 - `git diff --check` - `git status --short --branch` ## 风险和回退 - 风险：把“优先评估”误读为“必须采用”；通过明确否决条件和从零开发出口控制。 - 风险：只看项目热度忽略许可证、安全或总成本；通过固定检查项控制。 - 回退：删除新增步骤并恢复章节编号，不涉及代码、数据或外部项目。 ## 实施结果与证据 - New-Project-Documentation-Setup revision：`864d81b515b420d17fa4ff0fc7f528109b1a3d99`。 - 任务归档 Wiki：`Task-15-开源建设基线评估`。 - 任务归档 revision：`db07f88c64b161c61163f152d8bf9f66736bf9a3`。 - 实现提交：`a959fc3`，已推送至 `origin/main`。 - 补充案例提交：`fe99ca5`，已推送至 `origin/main`。 - 严格检查：通过。 - 单元测试：32 项全部通过。 - 核心镜像检查：13 个页面全部一致。 - 人工场景：[examples-0000000000000000] 已覆盖完整二次开发、许可证否决、改造成本否决和只复用框架或组件。 - 未验证：未评估具体第三方开源项目，本任务只定义选择流程。 - 按 #14 后的新规则，任务归档只更新 Wiki，未自动导出 `docs/task/`。 ## 验收完成 - 用户验收日期：2026-08-16 - 最终任务归档 revision：`1a86ea9046cd8161c171eeb76e127f145951cc8b` - 按 #14 确立的规则，任务归档仅保留在线 Wiki，本次未自动导出到 `docs/task/`。

ila closed this issue

2026-08-16 19:47:41 +08:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: opc/dev_harness#15