-
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>