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

277 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
ymq
023d4a67fa fix(remote_env): 批量pip失败时降级逐包安装(部分成功优于全败) 2026-08-28 21:15:58 +08:00
ymq
ea17307a6c fix(role): agent.deploy 前缀形态也加入 aliases——存量脏数据可解析 2026-08-28 21:13:41 +08:00
ymq
1bdc90f7f0 fix(role): deploy别名归一到agent.deploy_test——LLM写deploy导致approve后任务链断裂（_get_next_role查不到spec） 2026-08-28 21:12:21 +08:00
ymq
e3917e681c feat(work_env): 远程模式自动初始化——技能同步+依赖软件自动安装;agent_loop deploy别名归测试环境 2026-08-28 21:10:36 +08:00
ymq
8fafe18d91 fix(parse): _parse_agent_action 支持 deepseek v4 DSML 原生工具调用格式——长上下文多轮时不解析会5轮耗尽 2026-08-28 18:17:46 +08:00
ymq
c9d914b9ff security(agent): _run_shell 接入 bwrap 沙箱——命令隔离落地 
- agent 的 run_shell/run_command 从裸 create_subprocess_shell 改为 bwrap 沙箱
- user/pid/ipc/uts namespace 隔离，网络保留（git push/ssh 部署依赖）
- 系统目录+/d/pipeline+/d/doit 只读（平台代码/配置/其他机构工作区不可写）
- 当前机构工作空间目录可写（跨机构写隔离）；/tmp 会话私有
- DNS 兼容 systemd-resolved（/etc/resolv.conf 软链→/run 只读挂载）
- 无 bwrap 降级为原目录隔离并标 sandbox: false（不阻断现有功能）
 2026-08-28 14:26:32 +08:00
ymq
9ec38df6b4 feat(gateway): 会话模型选择持久化到项目——设置后持续生效直到再次选择 
问题：项目选择模型后不持久化，每次进入会话都回退固定缺省值。
根因：前端模型下拉的 model_id 后端不消费；无项目级模型存储；
     会话只读用户全局 default_llm_id，sd_projects.default_model 无写入路径。

修复（通用层，所有产线共用）：
- resolve_project 读出 sd_projects.default_model（项目级、跨会话持久）
- run_message 新增 model_id 参数：_resolve_and_persist_model 校验
  （兼容 llm.id/llm.model_id 两种取值 + 多租户隔离）后持久化到项目
- 模型优先级：本次显式选择 > 项目已设 > 个人全局 > 产线默认
  （个人全局从压过一切降为兜底，项目设置不再被全局覆盖）
 2026-08-28 12:26:18 +08:00
ymq
d9827c391b fix(orchestration): 元景三问题根治——task_title归位+问题通道统一冒泡+依赖启动策略+确认去重 
问题1(部署早于开发启动):
- _check_orchestration_gaps 重构为结构化缺口(kind/fingerprint/task_id/fix_ids)
- 缺口不再只打日志:派发后当场回给PM + 持久化pipeline_pm_notices注入PM下回合上下文
- 新增 update_task_deps 原语:PM核实缺口后补依赖(修正是LLM决策,代码只查漏)

问题2(env补齐后waiting不唤醒):
- _bubble_deploy_env_missing 从自建人工任务死胡同迁移到统一问题通道(raise_problem)
- owner在待办回答→resolve_problem自动唤醒任务→QA注入agent prompt,信息真正交给LLM

问题3(task_title错位+重复确认):
- SDL_ROLES task_title 各归其位(需求分析/架构设计/脚手架开发/部署测试/功能测试)
- 确认去重:同迭代已确认且非回退重做→跳过重复确认直接派发
- _create_next_task 单例阶段幂等:requirement/design复用同迭代任意活跃任务

机制增强:
- 依赖启动策略 params.dep_policy: all(默认)/any/at_least{n},纯函数_eval_deps_policy
- init.py poller 手写依赖求值收敛到同一纯函数(消除两处语义漂移)
 2026-08-27 22:52:27 +08:00
ymq
98b90d4f21 fix(workspace): 悬空项目引用防护——解析层校验+自愈清理+删除时清指针 
根因：删除项目后不清理 pipeline_session_settings/pipeline_agent_settings 里的
当前项目指针；解析逻辑（会话级优先）又不校验项目是否存在，悬空引用遮蔽有效
的全局设置，导致工作空间报「请先在会话中切换项目」（实测复现：孤儿项目
0x0EISBKAOsvHzW09dIOS 卡死会话级解析）。

修复（根治，三层）：
1. get_session_project_id 加存在性校验：悬空记录自愈清理并回退全局，
   查询异常保守放行不误伤
2. get_session_context 收敛为复用前者，消除重复实现的语义漂移
3. delete_project 删项目时清空两张设置表的指针；孤儿清扫清单纳入这两表
 2026-08-27 17:44:37 +08:00
ymq
58d773b6ad fix(workspace): 会话创建项目改用新结构目录 + 写入 directory_name 
根因：_t_create_project 用旧结构 build_workspace_path({space}/{项目名})，不写
directory_name；而工作空间读取端已迁到新结构 {space}/projects/{英文slug}，
导致会话新建的项目显示「项目目录（不可用）」。

修复：
- 改用 build_space_path 拼 {space}/projects/{slug} 并 os.makedirs
- slug 保留 [A-Za-z0-9_-]，须含字母（避免纯数字如'7'），否则兑底 proj_{短ID}
- 写入 directory_name 字段（工作空间读路径依据）
- 同 slug 冲突追加短 ID
 2026-08-27 16:11:43 +08:00
ymq
09f8b85f66 feat(gateway): run_message/AgentExecutor 支持 default_pipeline_id 
无当前项目时按入口指定产线装载能力(替代硬回退 sdlc_general)。
投标产线会话入口传 bidding_general 即可复用通用 agent 多 session 界面。
 2026-08-27 13:12:34 +08:00
ymq
981238b401 feat: capability 工具分发支持全路径模块 + 通用工具聚合层 
- exec_capability_tool：module 支持裸名(=pipeline_service.*)或全路径，
  产线自有能力包(如 pipeline_bidding.*)可注册角色工具而宿主零接触
- shared_ability：聚合 SDLC 能力包里的通用任务/交付件/问答/项目工具，
  供新产线能力包复用，不重复实现、不反向依赖具体产线
 2026-08-26 22:54:00 +08:00
ymq
36c131e348 fix(cleanup_orphans): 补 <> '' 非空守卫(空串=未挂载非孤儿，防误删32会话/23功能)；补充无项目/无迭代/无任务全量引用表 2026-08-26 15:22:18 +08:00
ymq
8eeb196515 fix(delete_project)+feat(cleanup_orphans): 删除项目补 task_id 级联(sd_deliverables/artifacts/task_steps/human_tasks)+sd_project_role_models；新增孤儿清扫能力(指向已删项目/迭代/任务的残留，dry_run可先统计) 2026-08-26 15:17:48 +08:00
ymq
ccba6f470e fix(orchestration): 环境信息只卡部署，不卡需求/设计/开发 
用户 2026-08-26 定调纠正了我原方案的错误。我原本提议把「env/*.json 无占位符」做成
requirement 阶段的结束条件(把缺陷堵在最便宜的阶段)——这是错的，会把死循环制度化：

主机/SSH账号/密码/部署路径是**外部输入**，requirement agent 根本产不出来。若要求它
填全才能通过，agent 就卡在无法解决的事情上无限重试。正是 2026-08-25 hrs7 的死循环成因：
deploy_test 因 env 占位符失败 → PM 判「根因在 requirement」→ 回退整链并作废 owner 已
人工确认的三模块设计 → 重做需求后 env 依然是占位符 → 再次失败。

实际上 hrs7 的 requirement agent 做得对：填了能确定的(port 9187/dbname hrs7)，未知项
标「待明确」并列入 pending 清单 —— 这是正确履职，被回退是冤枉的。

实现：
1. _check_deploy_env_ready 只对 agent.deploy_test/deploy_prod 生效，其余角色一律放行。
   检查 ssh.host/user、deploy.path、db.host/user/dbname + ssh 凭据(password 或 key_file
   二者其一) + requirement 自列的 pending 清单；domain/status 等非必需项不阻断。
2. 认领路径加此进入条件：不齐备 → 不进 running，任务置 waiting(界面可见，不在 submitted
   静默打转) + 冒泡 deploy_env_required 人工任务给 owner，写清缺哪些字段、文件在哪，
   并说明「补齐后自动继续，无需重跑上游阶段」。按 task_id 去重。
3. PM prompt 加硬约束：外部输入缺失禁止回退上游。回退前先自问「这个缺陷是上游 agent
   能做对却做错了，还是本来就产不出？」——前者才回退，后者一律冒泡等人补。

验证：11 例离线用例全过(用 hrs7 线上真实 test.json 结构)，覆盖
requirement/design/develop/test 四阶段占位符必须放行、部署阶段必须阻塞并列缺失字段、
补齐后放行、密钥文件替代密码、空密码无密钥阻塞、domain 缺失不阻断。
 2026-08-26 12:09:23 +08:00
ymq
31eab89234 fix(orchestration): 多依赖门控 4 处放行漏洞 + description 继承 + 幂等 + 完备性查漏 
【1. description 不再继承 + 用 PM 的 next_task_description】
_create_next_task 原实现 new_params={**params} 把上游 description 整个继承，导致
design 派生的「应用脚手架 develop」拿到需求任务的描述(产出需求规格说明书)，于是它交付
文档、4 分钟 approved —— 一行代码没写却走完 develop，打破「应用级 develop approved =
编码完成」这个 deploy_test 门控前提，造成 deploy_test 在编码未完成时提前启动。
同时 PM 在 review_approve 里给出的 next_task_title/next_task_description 一直被丢弃
(1935 行采集、2239 行调用时没传) —— 现已接上，流转决策权归 LLM，代码只做兜底。

【2. 多依赖门控 4 处漏洞(用户重点要求)】
D1 _task_deps_satisfied 查「不在终态的依赖」，依赖ID不存在时查出0行 → 误判满足而放行
D2 PM 派发时未知依赖引用只警告、静默丢弃 → 任务以更少依赖落库 → 并行开跑
D3 len>=20 就当有效任务ID收下、不校验存在性，配合 D1 让门控完全失效
D4 依赖处于 cancelled/failed 时依赖方永久 submitted，死锁且无人知晓
修法：逐个比对依赖存在性与状态；missing/dead/self 一律阻塞并冒泡；PM 派发时依赖
无法解析的任务置 waiting 而非静默降级为并行。init.py 的 poller 同步同语义(两处实现
必须一致，否则一处拦住另一处放行)。

【3. 幂等】并发多任务同时 approved 会各自创建下一阶段任务 → 同迭代重复任务(历史上出现
过「同一迭代两个 design 任务」)。按 (迭代, 角色, 系统派生) 先查后建。

【4. 逃逸阀通则】依赖永不可达时冒泡 dependency_blocked 人工任务(按 task_id 去重)，
消除静默死锁。对照：failed_poller 自动 pause 项目却无人通知，hrs7 因此卡近 1 小时。

【5. 完备性查漏 _check_orchestration_gaps】代码只查漏、不替 PM 决策：
G1 依赖自引用/成环(DFS 回边) → 必然死锁
G2 应用级 develop 未依赖未完成的模块级 develop → 正是本次故障成因
G3 设计清单 generated_modules 有模块无对应 develop 任务 → PM 漏派

逻辑验证：/tmp 两组离线用例共 30 例全过，并以可执行方式证实原实现 4 处放行漏洞。
 2026-08-26 11:49:24 +08:00
ymq
c03469bf7a fix: 阻塞求助不得当缺陷驳回——bug_flow 前置确定性分流转 need_info 
回归修复（我引入）：人事项目7 实测 deploy_test 两次 report_bug 上报「env/test.json
待确认无法部署」，被 pm_bug_confirm_run 在 9/13 秒内以「属测试环境问题，非代码缺陷」
自动 reject，PM 收不到求助 → 回退 requirement 重做 → requirement 同样拿不到环境信息
→ 再编占位 → QC 再驳，死循环。

根因：prompt 判据写了「reject：测试环境问题导致的假失败」，LLM 严格照做。但
report_bug 在这里承担的是「向上冒泡求助」，不是「报告代码缺陷」。

修复分两层：
1) 代码层确定性分流（主）：_is_blocking_help() 按特征词判定阻塞求助，
   命中者不进 LLM，直接 _escalate_blocking_bugs() 转 need_info 冒泡给人，
   bug 保持 open 等信息补齐；幂等（已有 pending need_info 则跳过）。
2) prompt 兜底（次）：删除「测试环境问题→reject」判据，加铁律说明外部输入
   缺口不是可 reject 的非缺陷。

实测验证：2 个真实被误驳文本命中分流，3 个真缺陷文本不命中。
 2026-08-25 21:27:09 +08:00
ymq
1d743df4e3 feat(approval): 钉钉审批接成产线审批关卡 
复用引擎既有 approval_gate 机制，不重造状态机：
- 新增 dingtalk_approval.py：注册 step_type='dingtalk_approval'(interactive)，
  进入步骤自动向钉钉发起审批；注册 biz_type='pipeline_approval' 回调钩子，
  审批结果回来调 approval_approve/reject 推进产线(内部已 save_artifact+resume_task)
- executor._handle_interactive_step 加外部通知钩子(按 step_type meta.notifier 分派)，
  并把 tenant_id 从 _execute_step 传下来(原 step_info 里无此字段，会永远取空)
- biz_id 编码 tenant_id:task_id:step_name，回调据此定位步骤
- 软依赖 dingdingflow：未加载时步骤仍挂起等人工审批，不推钉钉、不报错
- 通知失败只记日志不改步骤状态，避免外部系统故障导致步骤 FAILED
 2026-08-25 18:22:03 +08:00
ymq
8862d72a60 fix(sdlc): 根治任务名继承 bug(design 任务名不再跟需求名一样) 
根因：_create_next_task 用 new_title=f'{title}（{next_role}阶段）' 直接继承上一任务
title + 追加角色后缀。导致 design 任务名变成「需求规格说明书（agent.design阶段）」
跟需求名混同；回退重做后更叠加成「...（回退重做）（agent.develop阶段）
（agent.deploy_test阶段）」越叠越长。

修：title 改按 next_role 的声明式 task_title 生成语义标题(项目名 + 阶段语义)，
阶段模板由 RoleSpec.task_title 声明(design=应用架构与模块设计 / develop=应用脚手架开发 /
deploy_test=部署测试 / test=功能测试)，代码不硬编码。
 2026-08-25 17:01:19 +08:00
ymq
9bb1c5ce65 security: LLM 代理端点加失败限速(防 token 枚举) 
窗口 300s 内鉴权失败 >= 20 次即拒绝，不再查库(避免枚举放大 DB 压力)。
限速键取 token 前 12 字符，内存不留全量密钥；条目超 5000 清理过期窗口。
 2026-08-25 14:47:24 +08:00
ymq
7404ab1ecd fix(gate): poller 派发门禁纳入需求/设计确认任务 
根因：门禁 SQL 只认 general/bug_acceptance，漏了 requirement_confirmation/design_confirmation。
导致 PM 用 create_tasks 显式派发的下游任务绕过确认门禁被 poller 捞起执行
（实测 hrs7：设计确认 pending 期间 develop 任务已 running）。
在 poller 候选筛选层拦（agent + pm 两处），覆盖所有派发路径。
 2026-08-25 14:16:27 +08:00
ymq
106a600c45 feat(llm-proxy): 内部 LLM 代理 + 短期 token，真 api_key 永不下发运行环境 
运行环境(agent run_shell 子进程/bwrap 沙箱/远程目标机/被开发的 AI 应用)需要调 LLM 时，
不下发真实模型 key，改为签发短期 token(绑定 org_id+project_id+task_id，带过期/调用上限/可吊销)，
运行环境用 token 当 api_key 调本平台 OpenAI 兼容代理端点；真 key 只在服务进程内存解析。

- create_llm_token / verify_llm_token / revoke_llm_token / revoke_task_tokens
- proxy_chat_completion: 按 token 绑定 org_id 解析真 key(机构隔离) + 转发 + 用量回填
- list_llm_tokens: 审计用，不返回 token 明文
 2026-08-25 14:11:29 +08:00
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