yumoqing/pipeline-service
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
255 Commits 1 Branch 0 Tags
Commit Graph

255 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
ymq
b409f18929 feat(sdlc): requirement/design 审核通过后加 owner 人工确认门禁 
- pm_review_run: requirement/design approved 后不再直接派发下一角色任务，而是发确认任务给 owner
- human_task_capability: 新增 confirm_stage_gate(确认通过→继续派发下一角色; 不确定→退回原角色重做)
- create_human_task 加 task_id 参数绑定原引擎任务
- has_blocking_human_task 纳入确认任务 pending 阻塞
- init.py 注册 confirm_stage_gate
 2026-08-25 13:19:46 +08:00
ymq
f84da9d189 feat(workspace): 新增 get_session_context(per-session 优先读 project+iteration) 支持多 tab 项目上下文隔离 2026-08-24 18:32:48 +08:00
ymq
50b3b37f26 fix(workspace): get_space_dir 改用 build_space_path 构造(org_id+pipeline_id)，修复 workspace_dir 迁移到 projects/ 后 dirname 失效导致 projects/projects 路径重复 2026-08-24 18:00:24 +08:00
ymq
b0273a4f9c feat(workspace): 新增 get_space_dir/get_project_dir/get_project_apps_modules/resolve_workspace_path 并注册到 dspy 环境，支持工作空间弹窗显示项目目录+apps/modules 引用 2026-08-24 17:56:47 +08:00
ymq
2659284e05 chore(prompt): AGENT/QC prompt 及工具描述里 repos/ 旧表述改 projects/apps/modules 新路径 2026-08-24 17:42:47 +08:00
ymq
20852b2254 feat(workspace): 项目目录名改用 directory_name 英文 slug（兜底 name 显示名），支持中文显示名+英文目录名分离 2026-08-24 17:40:42 +08:00
ymq
ccf08bb631 feat(workspace): repos 逻辑迁到机构工作空间 projects/apps/modules——项目目录=项目过程仓库(git init)、应用/模块仓库按 _app 后缀分流 clone、commit/状态/解析扫 apps+modules+projects、交付件落 projects/{项目}/deliverables、PM/QC 工具路径基准改 space_dir 2026-08-24 17:39:30 +08:00
ymq
b93c1796ca feat(workspace): 机构工作空间目录重构——新增 build_space_path + _get_space_dir，角色 agent 工具路径基准从项目目录改为产线工作空间{space}/，使 projects/apps/modules 可达；模块技能扫描改扫 modules/ apps/ 2026-08-24 17:24:41 +08:00
ymq
f8fef7a7d5 feat(session): 当前项目按会话隔离(session_id)，多tab各自项目互不覆盖 
- workspace.get_session_project_id: 按 session_id 读 pipeline_session_settings，回退全局
- get_workspace_dir/get_workspace_path 支持 session_id 参数
- gateway.resolve_project 按会话解析 pid（default_llm 仍按用户全局）
- _persist_project: 有 session_id 时写 pipeline_session_settings + 全局兜底
 2026-08-24 16:40:42 +08:00
ymq
6e3c0ee2bf docs: 修正 bug_flow 状态机注释(verified 分流) 2026-08-24 12:57:59 +08:00
ymq
f2154ae7df fix: list_my_human_todos 补 title/description 字段 2026-08-24 12:54:07 +08:00
ymq
e5ae2f1555 feat: check_task_owner/check_tenant_owner 任务操作 owner 校验(通用引擎任务放行) 2026-08-24 12:25:05 +08:00
ymq
d417772f42 feat: 项目owner+人类任务清单+bug验收+流转门禁 
- check_project_owner: owner=created_by 统一校验
- human_task_capability: 派发/处理/QC/列表/计数/bug验收(复用pipeline_human_tasks)
- bug_flow: verified 分流(human报告→创建验收任务给报告人, agent→自动close)
- qc_review_run: human_task_qc 分支(检查对象=pipeline_human_tasks 结果)
- 流转门禁: agent/pm poller + start_next_iteration 检查未完成人类任务
- pipeline_human_tasks 加 project_id/iteration_id/bug_id/qc_status/qc_comment/title/description
 2026-08-24 12:18:27 +08:00
ymq
c49bb1c756 feat: pipeline_human_tasks 加 project_id/iteration_id/bug_id/qc_status/qc_comment 字段(SDLC项目级人类任务) 2026-08-24 12:09:29 +08:00
ymq
434ab76d88 feat: Bug 生命周期独立循环（与任务循环平行的第二套逻辑） 
用户定：任务和 bug 做成真正独立的两个事情，机制一样（poller+状态机）、
两套独立逻辑。之前把 bug 动作嵌在 PM 审核任务里（在任务里加 bug 动作）是错的。

改动：
1. 撤销 pm_review_run 里的 bug 动作（PM_SYSTEM_PROMPT bug 段 + tool_call bug 路由）
2. 新增 bug_flow.py：独立 bug 循环模块
   - _advance_bug_states：确定性流转（verified→close / fixed→派发复测 / confirmed→派发修复）
   - pm_bug_confirm_run：PM 独立确认 open bug（open→confirmed/rejected，LLM 判断）
   - bug_flow_poll_once：一轮完整 bug 循环入口
3. init.py 新增 _bug_poller（扫 sd_bugs 驱动状态机，与 role/pm/qc/failed 任务 poller 平行）

只处理进行中迭代（in_progress）的 bug。两循环唯一交互点：bug 循环在
confirmed/fixed 时创建任务（修复/复测）交给任务循环执行，任务执行时角色 agent
调 start_fix/fix_bug/verify_bug 反馈推进 bug 状态。
 2026-08-24 08:28:16 +08:00
ymq
8672068f39 fix: Bug 推动要求收敛到技能，system_prompt 只留工具声明+指针 
用户纠正：system_prompt 不写死职责流程（铁律）。之前把「Bug 生命周期流转」
详细规则写进 PM_SYSTEM_PROMPT，违反铁律。改为：
- PM_SYSTEM_PROMPT 只保留 bug 工具声明 + 一句「规则见 bug-confirm 技能，先
  load_skill 加载全文再执行」的指针
- 详细规则（每次审核检查 bug/判断根因/分类指派/派发修复与复测）全在技能里
 2026-08-24 08:10:33 +08:00
ymq
cff6d66e92 feat: PM 审核接入 Bug 生命周期流转（独立循环 + 添加流转能力） 
根治「Bug 闭环断链」：43 个 open bug 从未被 confirm/修复，根因是
pm_review_run 完全没有 bug 能力工具（只有 load_skill/create_tasks/list_tasks/
cancel_task 四个硬编码工具），且 test 是任务链终点 approve 后直接 completed。

修复（两个独立循环，不耦合）：
1. PM_SYSTEM_PROMPT 工具清单加 list_bugs/confirm_bug/reject_bug/reopen_bug，
   并新增「Bug 生命周期流转（独立循环）」段——明确 bug 是独立于任务链的
   第二条循环，PM 拥有「添加流转」能力，每次审核任何任务都检查 bug 状态
2. pm_review_run 的 tool_call 分支把 bug 工具路由到 exec_capability_tool
   （带 capability_ctx：iteration_id/who/agent_id/org_id 自动注入）
3. 保持 bug 流转由 PM 读技能自主决策（不硬编码 approve 后自动 confirm/派发）
 2026-08-24 08:03:44 +08:00
ymq
df0bec8f7d feat: 部署工程师 SSH 用机构独立密钥（每机构一把，防单点泄露） 
deploy_test/deploy_prod 的 run_shell 执行 ssh/scp 时，之前默认走
~/.ssh/id_rsa（个人密钥），绕过 work_env 的机构密钥机制。现改为：
- capability_ctx 注入 org_id
- _inject_org_ssh_key：对 ssh/scp 命令自动注入 -i ~/.ssh/org_keys/{org_id}/id_ed25519
  （已显式 -i 不覆盖；非 ssh/scp 命令不注入；机构密钥不存在则回退默认）
- 仅部署角色（agent.deploy_test/deploy_prod）生效，不影响 develop 的 git ssh 等
 2026-08-24 07:20:28 +08:00
ymq
99c1b60e31 fix: rework(回退重做)任务不调 bug 工具，只有 bug_fix 走状态机 
用户纠正：rework 的语义是「重做交付件」（QC/PM 退回重做），不是「修 bug」，
不该走 start_fix→fix_bug 状态机。只有 PM 明确派发的「修复 Bug」任务（bug_fix）
才走 bug 状态机。

修正 classify_task 的 docstring + TOOL_SCHEMAS 描述，明确：
- bug_fix：开始 start_fix、完成 fix_bug
- rework/new_dev：不调 bug 工具
 2026-08-23 21:52:49 +08:00
ymq
32cd8c2e8a fix: 模块技能全文加载剥离 frontmatter，对齐分层导入规范 
模块技能作为「项目模块」scope 注入时，目录层只放名字+描述，
全文层（load_skill）剥离 frontmatter 只返回正文，与 skill_loader.
to_prompt_block 行为一致。
 2026-08-23 21:24:47 +08:00
ymq
7ede8f4d7a feat: 任务来源分类机制 + classify_task 工具 + 模块技能注入项目空间 
根因修复（develop 不调 fix_bug 导致 bug 恒 open、链断）：
1. 三条任务创建路径打 task_kind 标记：_create_next_task=new_dev、
   _rollback_task_chain=rework、_pm_create_tasks 按标题判 bug_fix/new_dev
2. bug_capability 新增 classify_task 工具：读 task_kind 标记判断任务来源
   （老任务按 rollback_from/title 兜底），develop 据此决定是否走 fix_bug 状态机
3. TOOL_SCHEMAS 注册 classify_task + capability_ctx 注入 task_id
4. 增强能力：_collect_module_skills 运行时扫描 workspace repos/*/skill/SKILL.md，
   作为「项目模块」scope 注入技能目录 + load_skill 支持加载模块技能全文，
   让项目角色知道引用的业务模块怎么用（架构/数据模型/挂载函数/坑）
 2026-08-23 21:23:52 +08:00
ymq
bf5013f220 fix: start_fix/fix_bug 工具描述同步放宽状态机，消除 LLM 弃用误导 
develop 有 fix_bug 工具却不用、bug 恒 open 的直接根因：TOOL_SCHEMAS 里
start_fix 描述写死「confirmed → fixing」、fix_bug 写死「fixing → fixed」，
LLM 看到 bug 是 open 状态就判断「不能 start_fix」放弃调用。

bug_capability.start_fix 逻辑已放宽 open（上一提交），但工具描述没同步——
LLM 只看描述不读源码，描述误导它弃用工具。补：open 也可直接修复 + 修完代码
必须调用否则断链。
 2026-08-23 15:19:22 +08:00
ymq
8d3dd7c980 fix: 回退任务链 pm_assigned 污染 + 模块级判断改 previous_role + start_fix 放宽 open 
三处根因修复（hrs6 回退重做任务 approve 后链断的完整根因链）：

1. _rollback_task_chain 创建回退任务时 new_params.pop('pm_assigned')：
   回退重做任务继承 target_task 的 pm_assigned=True，approve 后命中
   「模块级 develop 跳过 deploy_test」分支，任务链断在 approved。
   与 _create_next_task 的 pop 对齐（两处同源，回退路径漏了）。

2. 模块级 develop 判断从 pm_assigned 改为 previous_role 为空：
   pm_assigned 会被 design 任务污染（design 也是 PM create_tasks 派发、
   带 pm_assigned=True，派生的应用级 develop 继承后被误判模块级）。
   previous_role 才是可靠信号：模块级（PM 直接派发）= 空，
   应用级（design 派生/回退重做）= agent.design。

3. start_fix 放宽 from 状态 [confirmed] → [confirmed, open]：
   PM review_rollback 回退 develop 时不走 confirm_bug，bug 停在 open，
   start_fix 只认 confirmed 导致 develop 修完代码无法 fix_bug，
   bug 永远 open、闭环断在 fixed 环节。
 2026-08-23 14:48:14 +08:00
ymq
e3301f5ed9 fix: capability_ctx 的 iteration_id 用 getattr 对 dict 取 id 返回空 
get_current_iteration 返回 dict（_rec_to_dict 转的），但 capability_ctx 用
getattr(_iter, 'id', '') 取 id，dict 无 id 属性 → 返回空 ''。导致 test agent 调
create_test_plan/create_case 时拿到的 iteration_id 是空，为绕过「缺少 iteration_id」
报错而显式传迭代名「人事项目6-第3迭代」→ sd_test_plans.iteration_id 存成了迭代名
而非 sd_iterations.id → JOIN 关联全断，测试计划/用例无法归属迭代。

改为 _iter.get('id', '')（dict 取值），与其他调用方一致。
 2026-08-23 10:37:54 +08:00
ymq
1e3bd9835d feat: TOOL_SCHEMAS 补 confirm_bug/reject_bug/reopen_bug 三个工具 schema 
bug_capability.py 已有这三个函数，但 TOOL_SCHEMAS 缺 schema，导致 PM 无法确认/驳回/重开 Bug，
bug 闭环断在 open→confirmed 第一步。补 schema 后 PM 可通过 bug_confirm_capability 拿到工具。
 2026-08-23 10:32:21 +08:00
ymq
8bd1b45cba fix: _create_next_task 清除 pm_assigned，防其从 PM 派发任务污染到自动创建的下游任务 
根因：PM 派发的 design 任务带 pm_assigned=True，design approved 后 _create_next_task
用 {**params} 继承，导致自动创建的应用脚手架 develop 也带 pm_assigned=True，
被 deploy_test 触发判断（1785 行）误判为「模块级 develop」，跳过 deploy_test，
迭代停在 11 模块 develop approved、永远不部署不测试。

pm_assigned 是「PM 按模块清单派发」标记，只作用于当前任务，下一角色任务由系统
自动创建，必须清除。
 2026-08-23 08:54:03 +08:00
ymq
5ffbf94b72 feat: 生产部署需人工指令——test 通过后不自动派发 deploy_prod 
test 的 next_role 从 agent.deploy_prod 改为空，test 通过后流程即止，
生产部署(deploy_prod)不再自动执行，由用户明确指令触发派发。
 2026-08-22 20:14:32 +08:00
ymq
69a0b50f76 refactor: SDL_ROLES 各角色 system_prompt 精简为角色定位+引导加载技能 
不再写死职责/流程/产出路径/审核方式/部署方案（这些都在角色技能 role/SKILL.md
和规范技能里，通过技能目录注入+load_skill 加载）。system_prompt 只保留：
'你是XX工程师。先 load_skill 加载 role 技能，按其中的职责与应遵守规范执行任务。'
同时删除了 deploy_test/deploy_prod 写死的 Dockerfile/docker-compose 错误部署方案。
 2026-08-22 18:51:57 +08:00
ymq
145024506b revert: 回退 develop system_prompt 的「应用级/模块级任务」规范 
规范不应写在 system_prompt(SDL_ROLES)，应只写在角色技能 agent.develop/role/SKILL.md
(已含应用级/模块级职责区分)。回退 system_prompt 到原样。
 2026-08-22 18:42:06 +08:00
ymq
84b2e83213 fix: 切迭代时自动关闭旧迭代 pending 问题(status=answered) 
_cancel_active_tasks 作废任务时，一并把该迭代的 pending 问题置 answered(随迭代作废)。
否则旧迭代问题持续 pending 冒泡、阻塞诊断视图，需手动 SQL 清理。
 2026-08-22 18:38:56 +08:00
ymq
a9145ee3a4 feat: develop 角色区分应用级/模块级两类任务——应用级产出应用脚手架 
应用级任务(标题含应用架构/应用脚手架)产出 repos/{应用名}_app：app/{应用名}.py
(唯一入口+get_module_dbname挂ServerEnv+load模块)、conf/config.json、build.sh。
模块级任务产出 Python 包(无独立 app.py，取库名用 ServerEnv().get_module_dbname())。
修复应用脚手架无人产出、导致应用级 deploy_test 部署失败(找不到 app.py)的缺口。
 2026-08-22 18:35:22 +08:00
ymq
ec0a0936d3 fix: 部署以应用为单位——模块级 develop(PM派发)approved 后不创建 deploy_test 
模块级 develop（params 含 pm_assigned）是 PM 按模块派发的开发任务，模块不独立部署，
approved 后不应创建模块级 deploy_test（否则每个模块一个 deploy_test = 部署以模块为单位，
即多端口问题的部署侧根源）。deploy_test 是应用级，只由应用脚手架 develop 触发。
 2026-08-22 18:21:08 +08:00
ymq
191d28547b fix: paused 生命周期三处修复——切迭代自动 resume + 三 poller 统一排除 paused 
1. start_next_iteration 启动新迭代后自动 resume_project：旧迭代遗留的 paused
   （任务达上限触发 failed_poller 自动 pause）随任务作废消除，新迭代恢复 active，
   否则 PM poller 跳过 review 任务导致新迭代卡在 PM 审核（2026-08 实测卡 27 分钟）
2. agent poller / qc poller 也排除 paused 项目，与 PM poller 语义统一：
   paused = 完全暂停推进（不派发/不审查/不审核），消除「任务照常派发却卡审核」半吊子状态
 2026-08-22 17:39:13 +08:00
ymq
ea6df9c7c6 fix: configure_env 按 (project_id, env_type) upsert + sudo_enabled 归一化 VARCHAR(1) 
- 修复反复 INSERT Duplicate entry(1062)：先查 (project_id, env_type) 已存在则 UPDATE
- 修复 DataError(1406)：'false' 字符串超长，归一化为 'Y'/'N' 单字符
 2026-08-22 11:48:47 +08:00
ymq
0af4faff21 feat: LLM 机构隔离——机构没配 llm 时角色/PM/QC 冒泡问题暂停 
- _check_org_llm 检测机构 llm 配置（严格本机构隔离，不含系统级兜底）
- role_agent_run/pm_review_run/qc_review_run 在 LLM 调用前检测，机构没配 llm
  则 raise_problem(need_info) 冒泡问题暂停，等机构配置模型后恢复
 2026-08-22 11:36:27 +08:00
ymq
2eb70a3480 feat: 模型配置菜单入口（⚙️ 模型配置 → sd_project_role_models/index.ui） 2026-08-22 11:18:14 +08:00
ymq
14dca0cc43 feat: 项目-角色-模型配置 + 角色agent模型解析链 
- sd_projects 加 default_model 字段（项目缺省模型=创建时的会话模型）
- _t_create_project 记录 created_by + default_model
- _resolve_llm_context 解析链：显式→项目-角色-模型(sd_project_role_models)
  →项目缺省模型(default_model)→RoleSpec→pipelines.default_model→deepseek-v4-pro
- 新增工具 list_role_models / set_role_model（项目设置界面后端）
 2026-08-22 10:19:50 +08:00
ymq
c50a5b9914 fix: load_skill 工具归一化 role（裸名 qc/pm → agent.qc/agent.pm） 
根因：qc_review_run/pm_review_run 调用 _load_skill_by_name 传裸名 'qc'/'pm'，
get_merged(role='qc') 加载不到 roles/agent.qc/ 目录，导致 QC 审查 design 时
load_skill(review-design) 失败 → 退回 3 次达上限 → 任务 waiting → 项目 paused。

修复：_load_skill_by_name 内部 _normalize_role(role)，覆盖所有调用点。
 2026-08-22 08:16:28 +08:00
ymq
be1fd06ef7 feat: 补充细分能力工具的 schema（reopen_feature/start_fix/fix_bug/verify_bug/close_bug） 2026-08-22 01:31:54 +08:00
ymq
6e82493c20 feat: 能力工具按 capability 动态注入（根治纸面落库） 
- 新增 capability_tools.py：TOOL_SCHEMAS 工具 schema + 从产线状态机规范 frontmatter
  读取 capability→tools 映射（可配置）+ exec_capability_tool 分发
- agent_loop 加 _collect_capability_tools：角色技能(scope=role)声明 capability，
  匹配产线状态机规范(scope=pipeline)的 tools 声明，注入对应能力工具
- role_agent_run 注入能力工具(AGENT_TOOLS+capability_tools) + capability_ctx
  (project_id/iteration_id/who/agent_id 自动注入，LLM 不可见)
- _exec_agent_tool 分发能力工具到对应 capability 函数
- 根治：requirement 无法 propose_feature、test 无法 create_case/report_bug
  只能写文档假装落库(sd_features 表=0)的问题
 2026-08-22 01:19:27 +08:00
ymq
b31cb6c816 fix: pm/qc 角色技能加载归一化 role（agent.pm/agent.qc） 
pm_review_run/qc_review_run 传裸名 'pm'/'qc' 给 _build_role_skills_block，
get_merged 按 role_key 精确匹配目录，裸名匹配不上 agent.pm/agent.qc 目录，
导致 pm/qc 角色技能永远不注入。改为 _normalize_role('pm'/'qc')。
 2026-08-22 00:12:41 +08:00
ymq
8eedff7af9 feat(sdlc): approve_task/complete_task 对齐 PM 行为推进任务链 
- approve_task: 解决 pending review_reject + git 提交 + _get_next_role→迭代边界→_create_next_task 推进链
- complete_task: 同步交付件 review_status 标记 approved，避免任务 completed 但交付件仍 pending 不一致
- 会话 agent 手动 approve 不再断链（下一角色任务照常自动创建）
 2026-08-21 23:39:15 +08:00
ymq
3c34eedb04 fix: 统一项目过程仓库命名 repos/{项目名}_pc（修复与 project-directory-spec 的路径错位） 
- PROJECT_REPO_NAME 保留为回退默认值，_ensure_project_repo 改为按 {项目名}_pc 命名
- _setup_repos/role_agent_run 查项目名并注入 __PROJECT_NAME__ 占位符
- SDL_ROLES 6 个角色 prompt 的 repos/project/ 全部改为 repos/__PROJECT_NAME___pc/
- 根因：角色 prompt 硬编码旧名 repos/project，与 project-directory-spec(权威规范) 要求 {项目名}_pc 不一致，导致首次产出必被 QC 驳回
 2026-08-21 23:35:57 +08:00
ymq
78b84c710e feat(sdlc): 会话agent加任务流转工具 approve_task/complete_task/cancel_task（PM权限） 
- task_capability 新增 cancel_task 原语（CAS+审计+终态守护）
- sdlc_ability 加 3 个 ToolDefinition + handler，who=agent.pm 记录 PM 权限操作
- _resolve_task_id 租户隔离前缀兜底
- SDL_PROMPT 补任务流转典型场景
- _pm_cancel_task 委托新原语，去掉重复 SQL
 2026-08-21 22:43:11 +08:00
ymq
6dbb574862 refactor(sdlc): 技能 base_dir 改全局 skills/（单一技能树，去掉机构副本路径） 
- agent_loop: _build_role_skills_block/_load_skill_by_name 改 get_skills_base()
- agent_loop_v2: _resolve_skills_base_dir 改返回 get_skills_base()
 2026-08-21 19:18:51 +08:00
ymq
6b4acaff13 fix(sdlc): 目录层 essential 基础规范优先排序——project-directory-spec 等 essential 技能排最前，不被 60 个截断 2026-08-21 18:41:15 +08:00
ymq
71d30e6d45 feat(sdlc): 技能分层导入统一——所有角色技能只注目录层 + load_skill 按需加载全文/子文件(含 PM/QC)，对齐 Hermes 分层机制 
- _build_role_skills_block: 删除 role scope 全量注入正文特例，所有技能统一目录层
- 新增 _load_skill_by_name: load_skill 工具后端，支持 name 加载全文 + file_path 加载 references/scripts/templates 子文件
- AGENT_TOOLS/PM_SYSTEM_PROMPT/QC_SYSTEM_PROMPT: 加 load_skill 工具 + 技能使用引导
- role/pm/qc 三个 run 的 tool-loop 加 load_skill 拦截
- QC 检查维度改为先 load_skill 加载 project-directory-spec 再检查路径
 2026-08-21 18:36:18 +08:00
ymq
f17f745ac6 fix(sdlc): pm_poller 队列饥饿——paused 项目僵尸 review 任务卡队头饿死 active 项目 
根因：pm_poller SELECT state='review' AND claimed_by IS NULL ORDER BY created_at ASC LIMIT 5，
只取最老 5 个 review 任务，但暂停门控在 pm_review_run 认领后才检查。paused 项目（人事系统/人事系统1）
的 8 个 develop/deploy_test 僵尸任务永远占住队头，每 15s dispatch 后暂停门控 return idle、claimed_by 恒 NULL，
active 项目（人事项目2）的 requirement/design 任务排在后面对、永远进不了 LIMIT 5 窗口 → PM 无法推进项目。

修复（对齐 agent_poller 队列饥饿修复三件套）：
1. SELECT 加 NOT EXISTS paused 项目过滤（暂停门控提前到筛选阶段）
2. LIMIT 5 → 200 容纳僵尸任务
3. 项目轮询 round-robin 保证项目间公平
 2026-08-21 13:20:32 +08:00
ymq
9c4f3deea6 feat(sdlc): 判断粒度落到迭代——create_task 迭代级查重 + diagnose_project 迭代级诊断 + prompt 迭代约束 
1. _h_create_task：创建 requirement 任务前查「当前迭代」是否已有非 cancelled 的
   requirement 任务(迭代的初始任务)，有则拒绝重复创建，避免人事项目2 那种
   需求分析完成后又重复启动需求分析。
2. _h_diagnose_project：诊断单位从「项目」改为「当前迭代」(in_progress)，
   按 iteration_id 过滤统计/列出任务，避免多迭代并存时诊断结果混在一起。
3. SDL_PROMPT：加「迭代粒度」约束——每个迭代独立初始任务+任务链，
   创建 requirement 前先查重、诊断/派发/推进都以当前迭代为单位。
 2026-08-21 13:04:58 +08:00
ymq
ca0cfc29de feat(sdlc): 迭代级 requirement 任务查重——同一迭代不重复创建需求分析任务 2026-08-21 13:03:17 +08:00