-
Real incident (2026-08-15, task b243dfe8): a node that went through loop_back/retry_self gets a fresh "<base>-attemptN" work_node_execution row each retry (work_graph_orchestrate._next_exec_node_id, N counted from real loop_back_triggered events) -- but graph_manifest only ever names the BASE node_id, never any "-attemptN" variant. _write_completed_node_artifacts's lookup (topological_order yields base node_ids) always resolved to done_outputs[base] -- attempt 1's REJECTED content, the only one filed under the bare node_id -- permanently stale the instant a node was ever rejected-then-retried-then-accepted. First surfaced today because this task is the first to actually reach "retried, then eventually accepted" for a node with real downstream artifact promotion. Fixed by resolving each base node_id to its highest-numbered "-attemptN" sibling's content before the promotion loop runs -- the highest attempt number is the most recently executed one, which is only still 'done' in the DB if the graph actually moved past it (a still-rejected final attempt would have either retried again or raised, both already handled by the existing _failed_node_ids() exclusion, which operates on base node_ids and is unaffected by this remap since only the dict VALUE changes, not the key). New tests: one drives the real 3-attempt scenario and confirms the promoted artifact holds attempt 3's content, not attempt 1's (verified failing on the pre-fix code with the exact real content mismatch); another confirms the exhausted-retry exclusion still works correctly after the remap. 847 tests total in the suite (24 new ones landed via a concurrent, unrelated self-hosting run -- see conversation); the 8 files this fix and today's other fixes actually touch are 476/476 green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Real incident (2026-08-13, task b243dfe8), diagnosed live with the user after they correctly challenged the architecture: "every node should have its own output, and node-to-node communication IS input/output flowing through edges -- why doesn't a node have an artifact?" They were right to push on this. work_node_execution.output_payload (the real Work Graph data-flow layer) was never the problem -- it's populated the instant any node completes, exactly as expected. The actual bug was one level up: _write_completed_node_artifacts's OLD `only_node_ids` parameter skipped any node not in "this specific append call's own newly-planned nodes", assuming "not new to this call" means "an earlier stage already promoted it". That assumption breaks the instant an earlier call's OWN promotion attempt never actually ran (e.g. it crashed even earlier in that same call, before reaching this function) -- which is exactly what happened to b243dfe8 across multiple retries today: brd/prd/sdd/benchmark nodes kept completing successfully ('done', real content), but zero artifact rows and zero .graphlemon/runs/<task_id>/ files were EVER created, going back to the task's original 2026-08-04 run. Every later append-mode retry kept treating those nodes as "not new, must already be handled" and excluded them forever. Renamed to `new_node_ids`, semantics inverted to check the real source of truth: a node whose artifact_type already has a genuine artifact row for this run_id is skipped UNLESS the node itself is newly-planned by this call (which correctly allows a retry-loop's superseding content to still promote a fresh artifact over a rejected one -- the scenario the previous attempt at this fix broke, caught by the existing test_rejected_first_attempt_replans_into_same_run_not_a_second_row test). New tests cover both real scenarios directly, plus a fix to test_orphaned_preexisting_run_with_no_artifacts_appends_not_collides's own setup (the orphaned node needs to be seeded as already-done, matching the real incident, not left for run_graph() to execute for real a second time). 822/822 tests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
…a664-main-checkout-drift
-
Real prod incident (2026-08-13): two live tasks crashed with sqlite3.IntegrityError UNIQUE constraint failed: work_graph_run.task_id right after a planner_reviewer FAIL/INCONCLUSIVE verdict. ux_work_graph_run_active (just added this session) allows only one non-terminal work_graph_run row per task_id, but a rejected review's retry called plan_documents() with no run_id, which always INSERTs a fresh row -- the rejected attempt's own row is never marked done/failed just because its content was rejected (Phase 2c: one run spans a task's whole lifecycle). plan_documents() gains append_to_run_id, threaded into plan_work_graph()'s existing append machinery (same convention implement_code() already uses for Coder). _review_planner_output_with_retries() now carries prior_run_id across retry attempts so a re-plan appends into the still-open run instead of colliding with it. The first attempt (no prior run) is unaffected. New test drives a real FAIL-then-PASS retry through the actual plan_work_graph() INSERT path and the real ux_work_graph_run_active index -- confirmed it reproduces the exact production traceback on the pre-fix code and passes post-fix. 801/801 src tests, 127/127 supervisor tests, both independently re-verified. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Removed the "disabled" framing from docs/done/validator-test-script- narrative-output-issue.md (moved todo/ -> done/, root cause identified, structural fix landed, spot-check clean) -- the mechanism it described (_CANONICAL_DOC_CHAIN, e2e_pipeline._VALIDATOR_MANIFEST) no longer exists in production code, superseded by the 2026-08-08 self-planning rewrite and Org Graph unification Phase 2. Planner's and Validator's self-planning catalogs already carry test_script as a suggested (not required) option; _CODER_NODE_CATALOG was the one gap -- added a matching entry there (mechanical check_script_compiles judgment, same as Validator's). All three org agents now decide per-goal whether this node is worth planning, with no remaining "this node type is globally off" switch anywhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Implements docs/done/work-graph-node-execution-deblackbox-requirements.md end to end. The three documented call sites (e2e_pipeline.py:: _check_prd_consistency, work_graph_orchestrate.py::_llm_judgment_verify_fn, work_graph_orchestrate.py::_make_run_fn) all used to render a one-off Dynamic Workflow .js script and run it via `claude -p 'Run /<name>...'` purely to get "agent identity + schema-shaped output" -- a workaround for --json-schema silently conflicting with --agent (05 §5.4.1.1). That workaround was never actually necessary: work_graph_plan.py:: plan_work_graph() solved the identical problem from day one with a flat `claude --agent ... -p ...` call + ```json-fence extraction from free text, already validated in production. New org_node_trigger.trigger_org_node_structured() unifies all three call sites onto that same flat-call approach. extract_json_payload() generalizes work_graph_plan.py's fence-extraction algorithm; _extract_graph_manifest is now a thin wrapper over it. Two more call sites not in the original design doc (written before they existed) were found and migrated too: _run_reflection_perspective and _fix_skill_for_node (Phase 2a's Reflection-review/Fix-Skill). work_graph_fork.py needed no changes -- it only reaches _make_run_fn indirectly via run_graph(), so it benefits automatically. FR-4's real-agent verification (RUN_REAL_AGENT_E2E=1, mandatory, not optional -- src/test_org_node_trigger_e2e.py) confirmed persona loading, --model override, and JSON-fence extraction all work against a real model. write_workflow_script/execute_work_graph/execute_work_graph_with_usage_ limit_retry are confirmed to have no remaining production callers; docstrings mark them historical, the file is kept (not deleted). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Validator's terminal verdict is now a real self-planned node (node_type= 'final_verdict', judgment.kind='mechanical', on_fail.action= 'dynamic_loop_back') appended into the SAME shared work_graph_run Planner and Coder already contribute to (plan_work_graph(..., append_to_run_id= run_id)), instead of a flat post-graph org_node_trigger call against a separate hardcoded Validator manifest. This is what lets a failing verdict genuinely trigger Reflection-review + Fix-Skill + a precise loop back to whichever real ancestor node is at fault, reusing the existing dynamic_loop_back machinery instead of a parallel retry loop. The 2026-08-06 hard gate (a real non-zero exit from Validator's own test script force-overrides the verdict to FAIL, Python-enforced not just prompted) is preserved via a build_prompt wrapper + mechanical check closure sharing mutable state. INCONCLUSIVE is now treated the same as FAIL (triggers a bounded retry via dynamic_loop_back) rather than accepted as a terminal result. _VALIDATOR_MANIFEST/_VALIDATOR_DOC_PROMPTS/_VALIDATOR_VERDICT_PROMPT/ _validator_prompt_builder are kept unused (same precedent as _CODER_PROMPT). org_node column removal (§2.1), index narrowing (§2.2), and the new work-graph-node-review skill (§7.1) remain for a later sub-phase. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Implements org-graph-unification-phase2-universal-self-planning-design.md §2.3, §3, §6 -- Coder's implement_code() no longer runs one hardcoded synthetic "implement" node; it self-plans via plan_work_graph(conn, "coder", ..., append_to_run_id=run_id), appending its own nodes onto Planner's existing work_graph_run instead of creating a separate one. - work_graph_plan.py: per-org_node suggested node-type catalogs (_CODER_NODE_CATALOG/_VALIDATOR_NODE_CATALOG, "starting points, not requirements" same as _PLANNER_NODE_CATALOG), new judgment/on_fail/ promotes_to_artifact fields in the generic planning prompt. New plan_work_graph(..., append_to_run_id=...) parameter: merges newly planned nodes into an existing run (node_id collision -> raise, never silent overwrite), returns new_node_ids so callers can avoid reprocessing nodes an earlier stage already promoted to artifacts. New shared dispatch_build_prompt() for graphs mixing Planner-shaped (artifact_type) and Coder-shaped (task_prompt) nodes side by side. - e2e_pipeline.py: _write_completed_node_artifacts() now also promotes nodes declaring promotes_to_artifact (not just Planner's artifact_type nodes), with an only_node_ids scope so a merged-graph caller doesn't re-touch artifacts an earlier stage already wrote. implement_code() reworked around self-planning; code_diff stays Python-computed (a real git diff, not any node's own content -- no node can know the diff ahead of running it), test_report is promoted from whatever the self-planned graph declares, falling back to a synthesized concatenation if it declares none. needs_worktree=True now passed to run_graph() for Coder (found missing entirely during this rework -- harmless with the old single-node manifest, a real 03-C §3.6 gap once concurrent code-writing nodes are possible). Also fixed a real bug found while wiring this up: _review_planner_output_with_retries()'s "reuse existing artifacts" branch hardcoded run_id=None, even though every real artifact row already has a valid produced_by_run_id -- Coder had nothing to append into on that resume path. - work_graph_fork.py: _reconstruct_build_prompt now dispatches per-node (via the new shared dispatch_build_prompt) instead of requiring the whole graph to be one uniform shape -- a real regression Phase 2b would otherwise have introduced silently, since a forked merged graph can now genuinely mix both node shapes. Sequencing note (unchanged from Phase 2a's own finding): work_graph_run's org_node column removal and the ux_work_graph_run_active index narrowing (design doc §2.1/§2.2) stay deferred to Phase 2c -- Validator still creates its own separate run until Validator also appends into the shared one, so narrowing the index to task_id-only now would collide with it. python3 -m unittest discover -s src (752 tests) + discover -s supervisor -p "test_*.py" (126 tests) both green, zero regressions. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Inserts Planner -> planner_reviewer -> Coder -> Validator into the fixed Org Graph flow (was Planner -> Coder -> Validator), per docs/todo/org-graph-unification-phase1-review-gate-design.md. A new planner_reviewer role independently judges whether Planner's BRD/PRD/SDD/ Benchmark output is real structured content (not narrative prose) before Coder is allowed to start, with a 3-attempt retry loop and a narration heuristic informed by the real narrative-output incident (docs/todo/validator-test-script-narrative-output-issue.md). Also fixes, in the same code path: - The P0 bug in task-execution-resume-assumes-planner-artifacts-exist.md: resuming a task no longer assumes sdd/prd/benchmark artifacts exist -- falls through to real replanning when they don't. - A fresh-run KeyError (not resume-specific) when a self-planned graph omits the prd/benchmark node types. - agent_profile.migrated_from_profile was NOT NULL, which broke as soon as a role with no legacy Hermes profile (planner_reviewer) was recorded. org_node_lifecycle._REQUIRED_ARTIFACTS["coder"] is narrowed from (brd,prd,sdd,benchmark) to (sdd,) -- the old 4-artifact gate never actually blocked anything since artifact_write.py sets validation_status='passed' unconditionally; planner_reviewer is the first real semantic gate. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
…4843-main-checkout-drift
-
Mitigates the recurring test_script/validator_test_script narration issue (100% repro across 3 tasks, 6 nodes): the existing compile-error feedback buries its "not a narrative description" note under raw tracebacks, which wasn't enough to stop the model repeating narrative output on retry. Adds _NARRATION_RETRY_HINT as a separate, directive feedback item alongside the compiler detail. See docs/todo/validator-test-script-narrative-output-issue.md §6-7 for the full root-cause analysis and rationale. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
…437e-main-checkout-drift
-
Root cause traced (docs/implementation-gap-analysis.md): the Benchmark document Validator relies on for its verdict was frequently a narrative about the work session ("The planner workflow completed and produced a Benchmark defining 18 scenarios...") instead of the actual scenarios -- found via a real skill-detail-page task's benchmark.md, then confirmed present since the earliest real self-hosting runs. Validator's own judgment was, in practice, resting on thin, sometimes-vacuous prose. Planner's work graph (brd->prd->sdd->benchmark) extends to benchmark->test_dataset->test_script: test_dataset/test_script are always present as nodes, but the generating subagent judges per-goal whether a real dataset/script applies (many goals, e.g. UI wiring, legitimately don't have one -- replying 'N/A: <reason>' is a real, expected answer, not a failure). test_script gets a genuinely mechanical verify_fn (real py_compile/node --check, not LLM judgment) -- the one node type where an objective check is actually possible. All four document prompts also gained an explicit anti-narration instruction (only 'brd' had a weaker version of this before). Coder's implementation prompt now receives the real benchmark/dataset/ script and must make the Planner's real script pass for real, not just whatever tests it invents on its own. Validator gets its own 3-node Work Graph (validator_benchmark -> validator_test_dataset -> validator_test_script), generated independently from SDD/PRD -- deliberately NOT reusing Coder's or Planner's own copies, same reasoning as a held-out eval set vs. the dev set a model was tuned against. The resulting script, if real, is actually executed against the current repository state; a non-zero real exit code force-overrides the verdict to FAIL in code (user-confirmed hard gate: the script is not up for LLM debate on a failure, only on a pass can subjective judgment add INCONCLUSIVE/risk notes). schema.py: artifact.artifact_type's CHECK constraint gains the 5 new types, plus migrate_expand_artifact_types() -- SQLite has no ALTER-based constraint migration, so this is the standard rebuild-copy-swap dance, applied for real to the live ~/.graphlemon/graphlemon.db (42 rows, verified byte-identical count before/after, integrity_check clean). skills/qa-task-validation.md and skills/project-sdd-planning.md already gained a standing principle from this same incident: verify cross-task data dependencies against real system state, not seeded fixtures alone (see prior commit d7035fc) -- this commit is the mechanism-level half of the same fix, not just the prose-guidance half. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Attempts 8 and 9 both hit "local changes would be overwritten by merge" again, despite the earlier _check_prd_consistency worktree-isolation fix. Root cause is deeper: git worktrees deliberately SHARE project identity with their main checkout (same .git, just another checkout) -- a real `claude -p` call's memory:project write doesn't reliably respect the cwd it was invoked with, and can land directly on the main checkout regardless of which specific call triggered it. Worktree-wrapping one call (as done for _check_prd_consistency) only moves around which call happens to trigger this; it doesn't fix the underlying issue. ensure_worktree_committed() now also runs against repo_path itself (not just the worktree) right before every merge_worktree() call, in both work_node_run.run_work_node() and e2e_pipeline._check_prd_consistency(). Same already-tested mechanism, now applied generically regardless of which real call caused the drift or why. Fixing this surfaced a second real bug in the fix itself: running `git add -A` against repo_path while a node's own .graphlemon-worktrees/<id>/ checkout is still present on disk picks it up as a gitlink-like entry, which then shows as "deleted" the instant remove_worktree() runs right after. Fixed by excluding .graphlemon-worktrees/ from both the dirty-check and the add via pathspec (not relying on the caller repo's own .gitignore), plus added it to graphlemon's own .gitignore for correctness generally. New regression test: test_drift_on_main_checkout_is_auto_committed_before_merge reproduces a run_fn writing directly to repo_path instead of its worktree, and confirms a second node's own merge isn't affected by it. 562 tests green (441 src + 121 supervisor). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
The 4th real self-hosting attempt (first to reach the actual doc-writing Work Graph after the previous three bugs) hit a real git merge failure: "local changes would be overwritten by merge", exit code 2. Root cause: _check_prd_consistency() calls execute_work_graph() directly against target_folder_path, completely bypassing work_node_run.run_work_node's worktree isolation. It uses agentType='planner' with memory:project, which writes a real update to .claude/agent-memory/planner/MEMORY.md in whatever cwd it runs with. Every prior real run of this check only ever targeted a throwaway clone, so this never mattered -- until self-targeting, where cwd IS the main checkout: the memory write landed as an uncommitted local change on master, which then blocked the SDD node's own (correctly isolated) worktree merge right after it. Fix: apply 05 §5.8's same unconditional self-target worktree rule here, reusing work_node_run's existing create_worktree/ensure_worktree_committed/ merge_worktree/remove_worktree rather than inventing a new mechanism. Non-self-target calls are unaffected (verified by both regression tests). Also cleaned up the real, now-recovered state from the failed 4th attempt: merged a real SDD-node worktree branch that got stranded uncommitted (conflict was just two near-identical memory file wordings, resolved by hand), and removed three orphaned worktrees left by earlier test runs. 557 tests green (437 src + 120 supervisor). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
CLAUDE.md is explicit that PH5 (self-modification/auto-rollback) must not start until PH4 has genuinely closed -- not just "all unit tests green," but 06-验收与测试锚点.md's REQ-01~14 happy/boundary/failure cases actually covered. A REQ-by-REQ audit (the same discipline that caught U-031's integration gap) found 5 real gaps: - REQ-03 failure: work_node_execution.status jumped straight running->retrying, skipping 'reflecting' (declared in the schema enum, never once written by any code). - REQ-05 failure / REQ-09 boundary: the "scheduler keeps serving other queued tasks past one blocked_pending_human" scenario was never tested against a real scheduler -- the old test literally said "no scheduler exists yet to test against directly" (stale since U-032). - REQ-06 / REQ-07 / REQ-14 failure (the biggest gap, shared root cause): CorruptPersistedStateError, ClassifierBlockedError, and UsageLimitWaitTimeoutError were each correctly raised and each correctly marked their own work_node_execution 'blocked', but nothing ever routed that to task.status='blocked_pending_human' with the blocked_reason each REQ's acceptance text names. e2e_pipeline.run_end_to_end is split into run_task_lifecycle() so scheduler.py's run_goal_to_completion can create the task itself and catch these three specific exceptions, following the same UPDATE+execution_event pattern budget_guardrail.check_budget() already established for REQ-10. - REQ-02 boundary: PRD internal-contradiction check (verifying->reflecting) had no implementation anywhere -- artifact_write always marked validation_status='passed' unconditionally. Added an optional verify_fn hook to work_graph_orchestrate.run_graph() (one regeneration attempt, then ConsistencyCheckFailedError) and a real consistency-check agent() call scoped to the PRD node only. The first real run of this new call caught a genuine bug: the model returned "consistent": "false" as a JSON string, not a boolean, which `if ok:` silently treated as truthy -- fixed with explicit _coerce_bool(). - REQ-13 failure: minor test-assertion weakness (WS 404 rejection test didn't check the JSON error body). 384 tests green. REQ-01~14 now have real, exercised coverage rather than a "tests are green" assumption -- PH4 can be treated as genuinely closed. 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>
-
Closes the c_artifact_write gap U-011 flagged (03-C §3.7, unowned by any Unit despite REQ-02 needing it directly): src/artifact_write.py writes content to the target project, commits it to the target's own git history, validates depends_on_artifact_ids against existing rows before writing anything (REQ-02's failure case), creates the immutable artifact row. validation_status is set to 'passed' unconditionally -- noted as a real simplification (semantic content review, e.g. REQ-02's "PRD 里出现矛盾" boundary case, needs its own LLM-judgment step this codebase doesn't build yet). src/e2e_pipeline.py orchestrates architecture doc §11's MVP criteria 1-3: plan_documents() makes 4 real sequential Planner calls (BRD, then PRD referencing BRD, then SDD referencing PRD, then Benchmark referencing SDD), writing each via c_artifact_write with correct lineage. implement_code() calls Coder once, captures the resulting `git diff` as code_diff and the Coder's own response as test_report. validate_implementation() calls Validator once and parses an explicit 'VERDICT: PASS|FAIL|INCONCLUSIVE' line. run_end_to_end() chains create_task -> plan -> implement -> validate, using U-010's trigger_org_node_full only for task.status bookkeeping (a lightweight "confirm ready" call per phase) and plain org_node_trigger calls for actual content generation, since trigger_org_node_full's contract returns a status dict, not text. Real-verified: plan_documents ran for real against "实现贪吃蛇游戏" -- all 4 documents produced, correctly lineaged, validation_status=passed, real content (>100 chars each), ~5m45s total for the 4 sequential calls. Deliberately NOT run for real: run_end_to_end's Coder/Validator half (real code generation + real test execution) is a different order of magnitude in cost/time/uncertainty than every other real call this session -- built and mock-tested, but not executed without checking first. 19 new mocked stdlib unittest cases (4 for artifact_write, 5 for the pipeline orchestration, all real/unmocked for artifact_write since git operations are fast/free/local same as U-013's worktree tests) + 1 gated real test. 127 total mocked/real-local tests across U-001-014, all passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>