-
User-reported gap: the alert banner only ever showed task.blocked_reason (a coarse category like 'execution_error') with zero indication of the actual cause -- the real message only existed in the matching task_status_changed execution_event's own detail text, with no path to the UI at all. Diagnosing today's several distinct real blockers required querying the DB directly each time, which the user correctly flagged as something the console itself should surface. task_query.get_task() now returns blocked_detail (the most recent blocking event's detail text) when status is blocked_pending_human. v_task_detail shows it as an expandable <details>/<summary> inside the alert banner (no JS wiring needed, matches the plain-vanilla-no-framework convention) so a long or multi-line real error message doesn't force itself into the banner's layout by default but is one click away in full, not truncated or hidden. Also investigated (not a bug, documented here for the record): two node logs the user found empty really are empty on disk -- execution_log_file rows exist but their target files were never created, for two nodes dating back to the task's original 2026-08-04 run, long before today's fixes. The log viewer's "暂无日志内容" is accurately reporting that state, not a rendering bug. 820/820 tests, frontend smoke passes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
v_task_detail's org-strip only ever covered planner/coder/validator -- no way to see planner_reviewer's verdict trail from the task detail page at all, only from v_graph_console. Rather than maintain two parallel, drifting implementations of "org node status for this task", v_task_detail now reuses the same 4-stage Org meta-graph component (renderOrgMetaGraph/mountOrgMetaGraph) v_graph_console already has. mountOrgMetaGraph/renderOrgMetaStageDetailHtml gain an optional enableNodeClick option so v_task_detail's usage gets real per-node live log-tail expansion (wired through the existing activeLogViewers/closeAllLogViewers/mountLogViewer machinery) while v_graph_console keeps its existing read-only snapshot behavior unchanged. ORG_NODE_DETAIL_RE now also accepts planner_reviewer so deep links into the 4th stage are reachable; landing on one auto-expands and scrolls to it (focusOrgMetaStage), matching the old focusOrgNodePanel's behavior. Dashboard's own 3-node org-strip is untouched. Deleted the now-dead renderTaskDetailOrgStripHtml/renderOrgComboPanelContent/ wireOrgComboArtifactClicks/focusOrgNodePanel. node frontend/test_graph_console_smoke.js passes (extended with coverage for the regex widening and the enableNodeClick threading), independently re-verified. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Implements docs/todo/work-graph-time-travel-debugging-design.md, backend and console together (user confirmed 2026-08-06). Key finding that shrank the v1 scope: ux_work_graph_run_active is a PARTIAL unique index (only covers non-terminal statuses), not a blanket one -- forking from a parent run that's already reached a terminal status never collides with it at all. v1 restricts forking to exactly that case, so no index/constraint change is needed, only two new nullable columns (parent_run_id, fork_of_node_exec_id). Resolved the requirements doc's FR-1 ambiguity ("override input_payload, re-trigger execution") as OUTPUT SUBSTITUTION instead: the fork point's own output_payload is replaced with the human-supplied content directly, it is never re-executed via a new claude -p call -- only the strict downstream subgraph actually re-runs. This sidesteps reconciling the different build_prompt/input_payload conventions each caller uses (Planner's artifact_type lookup, E's generic task_prompt field, F's jury) -- work_graph_fork.py only needs the persisted graph_manifest and each node's output_payload. Implementation needs ZERO changes to the execution engine: pre-seeding every non-downstream node as a 'done' work_node_execution row before calling the unmodified run_graph() on the unmodified graph_manifest is enough -- run_work_node()'s existing REQ-06 breakpoint-recovery short-circuit (already-'done' nodes return their persisted output without calling run_fn) does all the "reuse without re-executing" work for free. _reconstruct_build_prompt supports two graph shapes generically from persisted state alone (Planner's canonical doc chain via e2e_pipeline._planner_prompt_builder, and E's generic task_prompt field); anything else raises ForkGraphShapeUnsupportedError rather than producing broken prompts. New: src/work_graph_fork.py (create_fork/execute_fork/fork_work_graph_run/ start_fork_in_background, the last splitting fast DB-only setup from slow real execution so an HTTP caller gets run_id back immediately, same pattern task_execution.start_task_execution_in_background already uses). work_graph_run gets parent_run_id/fork_of_node_exec_id (SCHEMA_SQL + migrate_add_work_graph_fork_columns for existing databases). work_graph_run_query.py/task_query.py surface both fields. New endpoint POST /api/work-nodes/:node_exec_id/fork. Console: a "从这里分叉" form on each 'done' node in v_run_detail, a fork badge linking back to the parent run, and a 🔀 marker on v_graph_console's run list -- no diff/merge UI (non-goal #3), read-only branch visibility only. Verified end-to-end for real: started the actual backend, sent a real HTTP fork request, confirmed the new run persisted with correct parent_run_id/fork_of_node_exec_id lineage. Tests cover requirements doc acceptance standards 1-3 (PRD swapped -> SDD/Benchmark genuinely re-execute, BRD untouched; original run completely unaffected; the same node forked twice produces independent branches) plus schema migration idempotency, query-layer field surfacing, the HTTP route, and 3 frontend smoke-test assertions. Full src suite (608 tests) + all 3 frontend smoke tests pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
…10c5-main-checkout-drift
-
三个都是 config_id='default' 单例配置，首次使用即创建、之后原地更新 （upsert），不需要单独的初始化流程： - c_concurrency_config_update：新增 src/settings_config.py（ org_concurrency_config 之前完全没人碰过），校验 max_concurrent_goals 落在 1-50。 - c_budget_config_update：budget_guardrail.py 新增 upsert_budget_config() ——跟 U-019 已有的 update_budget_limit_and_resume()（只更新已存在的 行）不是一回事，这个是真正完整的设置页控制器，支持首次创建，沿用 同一套"额度调高后自动恢复 budget_exceeded 阻塞任务"副作用（提取成 _resume_budget_blocked_tasks() 共享）。 - c_log_retention_config_update：同样在 settings_config.py 里，校验 retention_days > 0。 三处校验都在业务层做完整检查，HTTP 层额外兜了 except (InvalidParamError, TypeError)——payload 数值字段缺失时 None<=0 这类比较会抛 TypeError 而 不是业务异常，两个都要接住才能保证返回干净的 400 而不是裸 500。 backend_server.py 第一次加了 do_PUT。 前端三个页面共享一个 renderSettingsSubnav() 小组件模拟 02-V 原型里的 设置下拉菜单。真实服务器端到端验证过三个 PUT/GET 的完整读写循环。 PH3（人机交互控制台）至此全部完成：U-022~U-030。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
c_skill_diff 和 U-028 的 c_artifact_get 一样，只存在于机器可读的 sdd-mvcp-contract.json，03-C 正文从未写出来，已订正补全。 c_skill_list/c_skill_get 两份文档都没定义，是 v_skill_library/ v_skill_audit_log 自己的展示需求倒逼出来的缺口。 新增 src/skill_query.py：list_skills()、get_skill_audit_log()、 get_diff()（git diff <before> <after>——skill_update.py 的 _write_and_commit 把每次迭代做成原子单文件 commit，整仓库范围的 diff 天然只涉及那一个 Skill 文件）。 关键安全考量：Skill 库活在 graphlemon 自己的仓库里，c_skill_rollback 会真的在这个仓库里跑 git commit——如果 HTTP 层写死指向真实仓库根目 录，任何针对这条路由的测试都会在正在跑的这个 graphlemon 仓库里留下 真实提交。参照 db_path 已有的做法，给 create_server() 加了 skill_repo_path 参数（默认 graphlemon 真实仓库根，测试传临时仓库）， 不通过 HTTP 暴露这个参数，避免变成任意写入的口子。记录在 05 §5.4.1.4。 真实服务器 + 临时仓库端到端验证过完整的 update→diff→rollback 闭环， 确认过跑完之后 graphlemon 自己仓库的 git log 完全没变化。 v_skill_library/v_skill_audit_log 不检查"当前项目"——Skill 是平台级 资产，跟项目无关。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
c_artifact_get 在机器可读的 sdd-mvcp-contract.json 里其实定义过 （GET /api/artifacts/:artifact_id），只是 03-C 正文一直没写出来，已订正 补全。c_artifact_list 连 MVCP JSON 里都没有 operation 定义，纯粹是 v_artifact_browser 自己的过滤字段倒逼出来的缺口，跟 U-025 补 c_task_list 是同一类问题。 新增 src/artifact_query.py：list_artifacts() 返回裸数组（跟已有的 list_tasks() 保持同款风格）；get_artifact() 把血缘链（按 depends_on_artifact_ids 往回走，只走第一个依赖——这条流水线的实际产出 只有线性 BRD→PRD→SDD 链）和文件内容（artifact 表本身没有 content 列， 走 project.target_folder_path + artifact.file_path 现读磁盘）一起返回， 预览面板一次请求就够。 前端预览统一用 <pre> 纯文本展示，不做 Markdown 渲染/代码高亮——02-V 原文想要那个效果，但需要引入第一个前端第三方库，跟这个控制台一贯的纯 vanilla JS、无构建步骤做法冲突，是有意简化。顺手给 index.html 常驻导航 栏加上了"产物"链接。 真实服务器验证过三级血缘链（BRD→PRD→SDD）返回顺序正确。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
execution_log_file 的行生命周期 U-013 早就管好了，但从来没有代码真的往 日志文件里写过内容——src/execution_log.py 新增 append_log() 补上这条 缺失的写路径，设计成 run_fn 执行过程中随时可调用，不关心节点在做什么。 get_log() 按 offset/limit 分页读，download=true 时走原始文件流。 c_ws_log_tail（WS /api/ws/work-nodes/:node_exec_id/log）复用 U-024 手写 的 RFC 6455 机制，轮询 execution_event(log_appended)；节点一旦转终态 （done/blocked/failed）服务端主动发关闭帧断开，不让客户端一直轮询。 p_log_retention_cleanup 实现成纯函数 run_log_retention_cleanup()：过期 扫描 + max_total_size_mb 超限按最旧优先追加候选 + 单个文件删除失败只 记录不阻塞其余项，没有配调度器（不在本 Unit 覆盖范围），留给未来的 调度进程周期调用。 过程中意外抓到一个真的并发 bug：_Server.server_close() 关闭共享 sqlite 连接时原来没拿 conn_lock，如果这时候正好有个 WS 轮询线程在 另一边持锁执行 SQL，两个线程无同步地并发操作同一个 C 级 sqlite3 连接 对象，实测直接把解释器崩了（SIGSEGV）——U-024 就已经有这个隐患，这次 高频 WS 测试把时序窗口撞开了。修好后连续跑几十次全部稳定通过，记录 在 05 §5.4.1.3。 frontend/app.js 的 v_log_viewer 挂在 v_task_detail 每个 to-do 节点的 展开详情里，首次展开才建连接（懒加载），运行中态走 c_ws_log_tail 实时 滚动、终态走 c_execution_log_get 静态拉取，活跃连接在任务级刷新/离开 页面时统一关闭。真实服务器 + Node 原生 WebSocket/fetch 端到端验证过 实时追加与终态自动断开的完整链路。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
纯前端 Unit，数据已经在 U-025 的 c_task_get 里，只是 task_query.py 的 _work_nodes_for_run 补上了 hover tooltip 需要但当时没取的字段 （input_schema_ref/output_schema_ref/quota_limit_type/ quota_wait_started_at）。 frontend/app.js 新增 computeGraphLayers()：按 graph_manifest 节点的 depends_on 边做拓扑分层，渲染成按执行层级排布的行，fan-out/fan-in 都能正确分层——用一个 n1→[n2,n3]→n4 的真实 graph_manifest 验证过， 直接从 app.js 里取出 computeGraphLayers 本体（不是重新实现一份逻辑） 跑真实服务器返回的 JSON，分层结果完全正确。节点按 03-C 3.6 节六态 配色，waiting_for_quota 态 hover 展示 quota_limit_type + 已等待时长。 02-V §2.7 原描述还包含一份 Org Graph 层，但 v_task_detail 页面顶部 已有等价的 org-strip 面板，这里判断重复渲染没有意义，只做了 Work Graph DAG 层，Org Graph 复用页面已有的那个。 嵌入位置：v_task_detail 里原来"随 U-026 补上"的占位提示换成了真实 的 DAG 面板。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
三个页面需要的读接口此前都不存在，本 Unit 一并建了： - c_task_list/c_task_get（03-C §3.2，此前无 Unit 认领）：新增 src/task_query.py + GET /api/tasks、GET /api/tasks/:task_id。 c_task_get 的返回比 03-C 字面契约更完整——额外带上 work_graph_run（含解析后的 graph_manifest）+ 每个 run 的 work_node_execution 列表，因为 v_task_detail 的 to-do 树需要这份数据， 03-C 已订正补全。 - c_org_loop_route（U-016 已实现 route_org_loop()，从未接 HTTP）第一次 接上 POST /api/tasks/:task_id/route，v_task_detail 的人工干预 （manual_resume）按钮需要它。 - 预算护栏此前没有任何读接口（03-C 只写了 PUT），新增 budget_guardrail.list_budget_configs() + GET /api/settings/budget 给仪表盘预算条用。 frontend/app.js 补上真实的 #/（org graph 三节点卡片、当前任务概要、 预算条、事件时间线，全部通过 c_ws_subscribe 实时刷新）、#/tasks （关键字/状态/org_node 过滤）、#/tasks/:task_id（task 字段、to-do 树、 关联 artifact/bug_record、blocked_pending_human 告警条 + manual_resume 按钮）。路由改成对象形式支持挂载态清理，切页面时关掉上一个页面的 WebSocket 连接。v_graph_visualizer/v_log_viewer 子模块明确标成占位 提示（随 U-026/U-027 补上），不是假造内容。 顺带把 U-023 里因 c_task_list 当时不存在而简化的 related_task_id 换回真下拉，goal_composer/bug_feedback 提交成功后也改回跳转真实的 v_task_detail。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
c_task_create（U-009 已实现的 task_create.create_task()）第一次接上 POST /api/tasks。c_bug_report_create 此前完全没有实现，新增 bug_record.create_bug_report() + POST /api/bug-reports。 发现并订正 03-C 一处输入契约遗漏：c_bug_report_create 的 input_contract 没写 project_id，但 execution_event.project_id 是 NOT NULL、bug_record 表自己没有 project_id 列可以在 related_task_id 留空时兜底推导，字面上无法满足约束——按 c_task_create 同款处理方式把 project_id 变成必填，03-C 已订正。 frontend/app.js 补上 #/goals/new、#/bugs/new 真实交互；控制台还没有 "当前项目"状态的正式载体（v_dashboard 是 U-025 才做），project_id 暂存 localStorage，v_project_setup 创建成功时写入。related_task_id 因为 c_task_list 未被任何 Unit 认领，简化成文本输入而非下拉，等 U-025 补上 任务列表后再换。提交成功后原型写的是跳转 v_task_detail，该页面也是 U-025 才建，暂时改成原页面内展示确认信息。 端到端冒烟时额外发现一个真 bug：create_bug_report() 原本没校验 project_id/related_task_id 是否存在，坏 project_id 会在 execution_event 插入时触发未捕获的 IntegrityError，请求直接 500——补了存在性校验， 改为干净的 INVALID_PARAM/400。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
c_pick_folder 补上 Windows（PowerShell FolderBrowserDialog）和 Linux （zenity 优先、回退 kdialog）实现，三平台都覆盖到。c_project_create （U-002 已实现的 project_scaffold.create_project()）第一次接上 HTTP 路由 POST /api/projects——backend_server.py 因此第一次需要持有 sqlite 连接，schema.connect() 加 check_same_thread=False 参数，配合 server.conn_lock 序列化 ThreadingHTTPServer 各请求线程的访问。 frontend/app.js 补上 #/setup 真实交互（选文件夹→校验 Git 仓库→非 Git 仓库二次确认→创建→跳转仪表盘），DOM class 命名对齐 docs/wireframes/v_project_setup.html。 REQ-11 完整 happy 用例（含创建 task）还需要 U-023 的 v_goal_composer/c_task_create，本 Unit 只完成 v_project_setup/ c_pick_folder/c_project_create 部分，development-plan.md 已记录。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
frontend/{index.html,app.js,style.css}: no build step, no npm, vanilla JS hash router (05 §5.7). Real page content is PH3 (U-022+, starting from docs/wireframes/); this is only the empty shell + working navigation the Done criterion asks for. backend_server.py serves the 3 files via an exact-path whitelist (not a generic static-file/directory server) -- no path-traversal surface to reason about for 3 fixed files. Verified in an actual browser this session (navigated to localhost, clicked all 3 nav links, screenshotted each) rather than only trusting stdlib tests -- a Python-only test can't exercise real hashchange/DOM behavior without a JS engine. Nav highlighting and content swap both confirmed working, no page reload, no build step. 7 new stdlib unittest cases covering what the server is actually responsible for (static files served with correct content-type, 404 on unknown GET path). 66 total across U-001-008, all passing. This closes out PH0 (U-001~U-008) -- all three Phase-acceptance criteria now hold for real: target-project directory scaffold, 15-table schema with constraint tests, and a real claude --agent round-trip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>