s10_task_system：大模型可能会在第一次会话中将4个tool一起返回，for执行工具调用时，存在依赖的task因为不知道前置task_id，导致TaskStore.create在验证依赖是否存在时报错

[scotly]

模型第一次请求时，返回了4个tool,对应setup database schema，create API endpoints， write tests， write docs,且自动给create API endpoints生成了blockedBy=setup database schema,后面两项同理。

{
    "subject": "create API endpoints",
    "description": "Create API endpoints that interact with the database schema. Depends on schema being set up.",
    "blockedBy": [
        "setup database schema"
    ]
}

执行到TaskStore.create函数，验证依赖文件是否存在时，使用字典key作为文件名称验证,但实际文件命名为task_id，导致后续task文件无法创建

生成依赖关系我觉得也可以交给大模型来做，分三步

1. tool定义中，新增task_id和parnet_id；
2. 修改系统提示词,要求每个task必须存在唯一的task_id，限制id的生成规则(比如task-md5)；根据上下文关系给parent_id赋值
3. 修改TaskStore的create函数，task的id使用模型生成的id；修改正则校验或者移除

[Bill-Billion]

感谢反馈。这个问题在当前 main 上确实存在。根因是任务 ID 由宿主在执行 create_task 时生成，而同一轮返回的多个 tool call 在执行前无法看到彼此的结果，因此模型只能填写任务名称或猜测 ID，最终无法通过依赖校验。
让模型生成持久 ID 会引入 ID 冲突、非法引用和校验边界不清等问题，同时 parent_id 也难以表达一个任务依赖多个前置任务的 DAG。
我在PR #533 先通过 create_task 创建全部任务并取得宿主生成的真实 ID，再通过 update_task(addBlockedBy=...) 建立依赖。运行时还会拒绝不存在的 ID、自依赖、循环依赖和任务开始后的依赖修改。