-
…c231-main-checkout-drift
-
Adds supervisor/deploy_cutover.py: stops the old Live process, retires the health-check-mode candidate, and relaunches the same already-verified candidate checkout bound to LIVE_PORT/PROD_DB_PATH -- http.server has no live socket-rebind operation, so "switch to production port/db" is implemented as stop-then-relaunch-from-the-same-dir rather than an in-place rebind (functionally equivalent, the only mechanism stdlib actually offers). Adds LIVE_PORT=8420 to 05 §5.9's MVP-fixed parameter table -- the one parameter that table was missing (frontend/app.js never needed one, same- origin relative fetches don't care, but successive deployments need to keep landing on the same port for a human bookmark to keep working). "在途 work_node_execution 重启后可恢复" is satisfied by relying on the existing REQ-06 recovery machinery unchanged -- cutover doesn't add any special-case logic, a cutover-triggered restart is just another interruption REQ-06 already survives. A real (not mocked) test caught a real bug: deploy_supervisor.is_alive()'s os.kill(pid, 0) check can't distinguish "truly running" from "exited but never reaped by its own parent" -- a zombie's PID slot answers kill(pid, 0) successfully until waited on. U-036's own subprocess test never caught this because that skeleton deletes its own PID file before exiting, sidestepping is_alive() entirely; deploy_cutover's test is the first one to actually poll for a stopped process to disappear, and it hung until fixed. Added reap_if_exited() (real os.waitpid for processes we spawned ourselves, falls back to is_alive() for pids from a prior session where ChildProcessError means we're not the real parent) and switched deploy_cutover._stop_process, deploy_health_check.check_process_alive, and deploy_supervisor.stop() to use it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
U-031: closes a structural integration gap found during the REQ-01~14 regression audit -- plan_work_graph/execute_work_graph/run_work_node were each individually tested but never actually called together in production code (e2e_pipeline.py's only validated closed loop bypassed all three via flat org_node_trigger calls). Adds work_graph_orchestrate.py (topological sort over graph_manifest + one one-node dynamic-workflow agent() call per Work Node, needed for REQ-06's per-node breakpoint recovery), rewires e2e_pipeline.py's plan_documents/ implement_code onto the real chain, and fixes two bugs a real API run surfaced: graph_manifest's id/node_id/depends_on normalization (work_graph_plan._normalize_graph_manifest) and a missing repo_path in run_work_node's cwd resolution. work_node_run.py also now marks a node 'blocked' instead of leaving it stuck 'running' on any unretryable run_fn exception. U-024.5: the regression audit also found REQ-12's reconnect boundary case (refetch a snapshot after a dropped WS reconnects) was never implemented -- only the dashboard reacted to onStatusChange, and even it never refetched. Fixes mountDashboard/mountTaskBoard/mountTaskDetail (which embeds v_graph_visualizer) to refetch their current snapshot on reconnect. 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>
-
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>
-
Found running U-014's full real closed loop: the Validator gave an INCONCLUSIVE verdict and explicitly said it had no Bash tool, despite its frontmatter granting one. Isolated with a minimal test subagent: any "Bash(...)" scoped pattern (e.g. "Bash(git commit:*)") in a subagent's disallowedTools frontmatter field disables Bash *entirely*, not just that subcommand -- confirmed by comparing a disallowedTools=[Edit,Write] agent (Bash works) against one adding a single Bash(git commit:*) entry (Bash breaks completely). The CLI's own --disallowedTools flag documents this exact scoped syntax as supported; subagent frontmatter just doesn't honor it the same way, and nothing in the docs says so. Fixed agent_profile.py's validator FRONTMATTER to disallowedTools= [Edit, Write] only -- dropping the four Bash(git *) entries that were silently breaking test execution. The "don't commit/push/reset/clean" constraint now relies on the prose instruction already in the migrated AGENTS.md instead of a tool-level block that never actually worked; fixed that file's own (now-false) claim that it was enforced at the tool level, and documented the finding centrally in 05-实施约束与依赖.md §5.4.1.2 since it'll matter for any future agent definition, not just this one. Verified for real, redeployed: Bash now works for the actual Validator identity, Edit/Write remain correctly blocked. 1 test fixed (was asserting the now-removed scoped pattern) + 1 new test (disallowedTools frontmatter must never contain "Bash(" again). 174 total across U-001-019, all passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
plan_work_graph(): real `claude --agent <org_node> -p` call, produces a graph_manifest (4 nodes for brd/prd/sdd/benchmark, dependency-chained sdd->prd->brd, each edge tagged zero_token/needs_judgment per 03-C §3.4), recorded as a work_graph_run row (status='planning' -- 04-P p_work_graph_execution start_state). Does not execute the plan or produce real artifacts -- 03-C §3.4 says so explicitly ("不执行，只规划"). Real call surfaced a genuine, undocumented constraint: --json-schema is silently ignored when combined with --agent (structured_output never appears; the identity itself works fine -- the response referenced the migrated SOUL.md's own principle numbering). First attempt at this Unit failed against the real API for exactly this reason. Fixed by asking the model to fence its JSON and parsing it out of `result` instead (_extract_graph_manifest, tolerant of bare JSON / fenced blocks / an extra wrapper key). Documented centrally in 05-实施约束与依赖.md §5.4.1.1 since this will matter for any future Unit needing agent-identity + structured output together, not just this one. Also corrects the same class of Done-line overreach as U-009/U-010 (development-plan.md claimed U-011 alone satisfies REQ-02's happy case, but c_work_graph_plan's own contract explicitly excludes execution) and flags a real, previously-invisible gap found while tracing REQ-02's actual dependencies: no Unit in development-plan.md's 43-unit breakdown owns c_artifact_write (03-C §3.7), despite REQ-02's happy AND failure cases both requiring it directly. Not fixed here -- noted for whichever Unit (U-012/ U-013, most likely) needs it first. 15 new mocked stdlib unittest cases + 1 gated real test (re-run and passing after the --json-schema fix). 98 total mocked tests across U-001-011, all passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
Implements c_project_create (03-C §3.0) as a plain function for U-007 to wire up later: idempotent by target_folder_path, creates .graphlemon/ + one init commit in an existing git repo, PATH_NOT_FOUND/PATH_NOT_WRITABLE/ GIT_INIT_DECLINED per contract, never silently `git init`s (02-V §2.1). Also corrects a real SDD-vs-plan conflict found while scoping this Unit: development-plan.md's U-002 line cited architecture doc §7.3's directory tree (.claude/agents/, skills/, top-level runs/) as what to create inside a target project. But §13.1 (a later, confirmed decision) states those are graphlemon's own platform-repo assets (U-003 scope), and 01-M's own graphlemon_subdir_initialized field already points at §13.2, whose target- project tree is only .git/ + .graphlemon/ + the target's pre-existing src/. §7.3 predates the "target project is an independent code space" pivot and was superseded by it. Corrected development-plan.md, unit_matrix.json, CLAUDE.md, and 05-实施约束与依赖.md accordingly (user confirmed, 2026-07-31). 23 stdlib unittest cases (src/test_schema.py + new src/test_project_scaffold.py), all passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Establishes the first commit for graphlemon before U-001 work begins: architecture/SDD docs (including the PH5 self-hosting design already folded into 01-M/03-C/04-P/mvcp-contract v1.7.0), the A-1 spike results, the graphloop-adapted supervisor/isolation utilities, PH3 wireframe prototypes (now cross-referenced from 02-V), and this session's development-plan review (U-024 dependency split, U-035 regression requirement, new U-004.5 e2e-harness unit, src/ directory convention). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>