-
Phase 1 (planner_reviewer review gate + P0 resume-bug fix) shipped as ea19c7d, matching org-graph-unification-phase1-review-gate-design.md exactly (new task.status value, org role, _REQUIRED_ARTIFACTS narrowing, both bugs fixed). Moving that design doc and the P0 bug doc it subsumed to docs/done/, updating their status headers, and fixing the doc-path references left pointing at their old docs/todo/ location across agents/planner_reviewer/{SOUL,AGENTS}.md, src/schema.py migration docstrings, and the other Phase 2/deblackbox docs. Full suite green (731 tests) both before and after. Also ran Phase 2 SDD's §9 interface-reconciliation checklist against the real Phase 1 implementation now that it exists for real: all three items check out (run_id is included in plan_and_review_documents()'s return shape, the new task.status value is exactly reviewing_planner_output as assumed, and planner_reviewer's role.json doesn't pre-reserve a skill slot for Phase 2's new skill, which is fine -- a one-line addition when Phase 2c lands, not an incompatibility). Updated §9 to reflect this. 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>
-
Implements docs/todo/validator-loop-until-dry-skill-design.md. Pure Skill + Agent-definition wiring, no execution-engine changes -- the convergence loop runs inside a single Work Node's one claude -p session (multi-turn tool use), not a graph_manifest-level cycle, so topological_layers()/ run_graph() are untouched. New Skill skills/unknown-scope-defect-sweep/SKILL.md: K=2 consecutive no-new-finding rounds to stop, 20-round hard cap, dedup key must be a structural identifier (file path + line, route path, package name) not a natural-language description (the same finding gets reworded call to call, so text-keyed dedup never converges), dedup set is "everything ever seen" not "everything confirmed" (the common bug the 14-step reference names: a rejected candidate reappearing as a false "new finding" every round). Each candidate is verified via qa-task-validation's existing PASS/FAIL/INCONCLUSIVE framework -- deliberately NOT root_cause_trace's three-perspective jury (F), since that answers a different question (root cause AFTER a failure) from this one (is this candidate real at all) -- documented in the design doc's own tradeoff note. Wired into agent_profile.py's FRONTMATTER["validator"]["skills"] and agents/validator/AGENTS.md's "必须加载" section with a concrete trigger signal (task description can't state an exact expected count/boundary up front). Only FR-4 (Skill wired into the rendered .claude/agents/validator.md) has deterministic, mockable behavior -- new test test_validator_references_unknown_scope_defect_sweep_skill. Acceptance criteria 1-3 (actually finds everything, actually dedups correctly, actually stops at the hard cap) need real multi-turn claude -p behavior, out of scope for mocked tests (RUN_REAL_AGENT_E2E=1 territory), same category of limitation as F's own real-concurrency-timing note. Full src suite (587 tests) passes with zero regressions. 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> -
Resolves the A-2 assumption with a real `claude --agent planner -p` call (--permission-mode auto, $0.05) against a deployed target project: the migrated identity comes through correctly, not the default assistant persona. Verdict is "部分成立" (partially confirmed), per the criterion development-plan.md's U-004 line pre-registered for exactly this outcome -- Planner/Validator's SOUL.md migrated almost verbatim, but Coder's SOUL.md needed real rewriting: the original hardcoded a live Feishu Base API token (redacted, never committed), strongly bound its task-claiming to `lark-cli`/Base status vocabulary, and told itself to shell out `claude --dangerously-skip-permissions` (conflicts directly with 05 §5.3.1's `auto`-mode decision). All three replaced with graphlemon's own task table / c_org_node_trigger / task.status vocabulary. Also resolves a second, higher-stakes conflict found while scoping this Unit: where does `.claude/agents/<org_node>.md` actually live? Architecture doc §13.1 says graphlemon's own platform repo; 03-C §3.3 and 05 §5.1 (both core SDD, not the architecture PRD) explicitly say the target project -- matching how Claude Code's --agent flag actually discovers subagents (relative to invocation cwd). User confirmed 03-C/05 win. Resolved as two different files, not a contradiction: agents/<org_node>/SOUL.md (+ validator/AGENTS.md) here is the canonical migrated source (01-M 1.9 agent_profile.soul_file_path, a singleton with no target-project reference); src/agent_profile.py compiles that into the deployable .claude/agents/<org_node>.md and writes it into a target project via deploy_agent_definitions(). Does not reopen the U-002 correction from the previous commit -- .graphlemon/ scaffolding and agent deployment are different, non-conflicting concerns. validator's tools/disallowedTools frontmatter encodes qa/AGENTS.md's original workspace-permission contract (read-only on source, no git mutation commands) as actual Claude Code permissions instead of prose. 14 new stdlib unittest cases (test_agent_profile.py, all real) + 1 gated real-agent test (test_agent_e2e.py, RUN_REAL_AGENT_E2E=1, mirrors graphloop's pattern per CLAUDE.md's Testing constraint -- this is the first Unit that actually shells out to `claude`, so this is also where that harness gets built, per the harness-ownership decision from the earlier "什么还需要" review). 41 total tests across U-001-004, all passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>