宜博 / lemongraph

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>

… work, compress bloated incident log

- Delete org-graph-as-work-graph-unified-loop-requirements.md: fully
  superseded by org-graph-unification-and-universal-self-planning-
  requirements.md; folded its one non-duplicated detail (the 2084590a
  benchmark-narration trigger incident) into that doc's background instead.
- Split scheduler-production-polling-loop-{requirements,design}.md by
  completion status: FR-2 (in-flight task reconciliation, shipped) moves to
  docs/done/scheduler-task-reconciliation-{requirements,design}.md; FR-1
  (new-goal auto-dispatch, still undecided) becomes a small standalone
  docs/todo/scheduler-new-goal-dispatch-requirements.md instead of staying
  bundled with a doc that's mostly done.
- Compress validator-test-script-narrative-output-issue.md's six
  ad-hoc "第N轮更新" paragraphs crammed into one status line into a scannable
  timeline table; moved the task 2084590a benchmark evidence into §1 where
  the other repro examples live instead of leaving it stranded in the header.
- implementation-gap-analysis.md: logged two new gaps found today (no
  pre-Coder review of Planner's output; node execution still depends on
  native Dynamic Workflow) plus the architecture.md §10.1 staleness itself,
  per that doc's own "edit in place" maintenance convention.
- Updated the doc-path references left in src/task_execution.py and
  src/task_reconciliation.py docstrings to point at the new locations.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

work-graph-partial-artifact-persistence and work-graph-self-planning-
and-loop-back (requirements + design) are all shipped and tested;
move them out of docs/todo/ and fix up the docs/todo/*.md and
src/*.py path references that pointed at their old location.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…76ae-main-checkout-drift

…4843-main-checkout-drift

ConsistencyCheckFailedError is now raised by both the PRD-consistency
check and the test_script mechanical compile-check (07a0a27), but
scheduler._blocked_reason_for still labeled every instance
'prd_consistency_check_failed', misleadingly blaming the PRD for
test_script node failures. Distinguishes by node_id substring match
(see docstring for the ponytail ceiling/upgrade path).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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

…d7f3-main-checkout-drift

Recovers tasks abandoned mid-flight (status in queued/planning_brd_prd_sdd/
coding/validating with no recent execution_event) by re-driving them through
task_execution.run_or_resume_task_lifecycle on a background poll, guarded by
an in-process in-flight lock to avoid double dispatch. Responds to a real
2026-08-06 incident where a task sat stuck in 'validating' for 15+ hours with
nothing polling it.

Scoped to FR-2 only from docs/todo/scheduler-production-polling-loop-
requirements.md; FR-1 (new-goal auto-dispatch) stays out per that doc's own
non-goals -- it's a separate, larger autonomy-boundary decision. Design
recorded in docs/todo/scheduler-production-polling-loop-design.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Per CLAUDE.md's docs/ role split (todo = pending, done = shipped into the
SDD/code): all seven Graph Engineering series items with a real
implementation (B, D, E, F, G, H -- A had no separate doc, resolved
directly in graphlemon_architecture.md; C is explicitly won't-do) now have
their requirements+design docs moved from docs/todo/ to docs/done/,
git mv'd to preserve history.

Every cross-reference to the 12 moved files -- across the other moved
docs themselves, graph-engineering-open-items.md, 2 Skill files, and 9
src/*.py docstrings/comments -- updated from docs/todo/<file> to
docs/done/<file>. Verified no stale docs/todo/ references to any of the
12 filenames remain anywhere in the repo.

graph-engineering-open-items.md itself stays in docs/todo/ (not moved) --
it's a living index that keeps gaining new entries from later
comparison-note/gap-analysis passes (H itself was added this way, and a
new item already appeared while this cleanup was in progress), not a
single finished conclusion. Its own header now reflects that all of
A/B/D/E/F/G/H are done and explains why it wasn't moved. Also fixed two
pre-existing stray path references (missing todo/done/ prefix entirely,
predating this cleanup) in its G section.

Full src suite (625 tests) passes -- this is a pure documentation/comment
change, no behavior touched.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Implements docs/todo/role-package-abstraction-design.md. Requirements
review (docs/todo/graph-engineering-open-items.md's H section) had already
corrected the requirements doc's own dependency analysis before this;
scope confirmed with user 2026-08-06: relax all 4 org_node CHECK
constraints in one pass, not staged.

Format is JSON, not YAML: 05 §5.7's pure-stdlib constraint rules out
PyYAML, and unlike Skill files (whose YAML frontmatter only Claude Code
itself ever parses, never this codebase's own Python), role.json genuinely
needs to be read by agent_profile.py -- json.load is the zero-risk choice
over a hand-rolled parser.

role.json is a REFERENCE manifest, not a content copy: identity.soul_md_path/
agents_md_path still point at the untouched agents/<role>/SOUL.md/AGENTS.md
files. This is what makes "deployed output must stay identical" close to
automatic -- render_agent_definition()'s body-assembly logic doesn't
change at all, only the frontmatter's data source does (hardcoded
FRONTMATTER dict -> parsed role.json). Verified byte-for-byte: diffed the
old (git HEAD) render_agent_definition() output against the new one for
all three roles, zero differences.

agent_profile.py: ORG_NODES is now discovered by scanning roles/ for
role.json files (_discover_role_ids()) instead of a hardcoded 3-tuple;
FRONTMATTER/_DESCRIPTIONS/_MIGRATED_FROM_PROFILE dicts are gone. Every
public function takes an optional roles_dir override specifically so a
test can prove "a new role needs zero code changes" against a throwaway
fixture directory (NewRoleWithoutCodeChangeTest) rather than asserting it
by inspection.

schema.py: skill.owner_org_node/task.assigned_org_node/work_graph_run.org_node/
agent_profile.org_node relaxed from CHECK(x IN ('planner','coder','validator'))
to CHECK(x != ''). Real blast radius found during design (bigger than the
requirements doc's own risk note): task/work_graph_run/skill are
referenced by several other tables' foreign keys, but since only the
parent tables' own CHECK text changes (child FK definitions are untouched),
only these 4 parent tables need rebuilding -- followed SQLite's documented
procedure for schema changes under active foreign keys (foreign_keys=OFF
for the duration, rebuild, foreign_key_check to confirm nothing went
dangling, foreign_keys=ON). migrate_relax_org_node_constraints() depends
on D's migrate_add_work_graph_fork_columns() having run (called
unconditionally, idempotent) so work_graph_run's rebuild has the right
column set either way. ux_work_graph_run_active and task's 3 indexes
verified to survive the rebuild.

work_graph_run_query.py's own separately-hardcoded _VALID_ORG_NODES
(a real dependency the requirements doc's risk section missed) now reuses
agent_profile.ORG_NODES instead of maintaining a second copy.

Explicitly NOT done (scoped out during requirements review, not an
oversight): frontend/app.js's 4 hardcoded 3-role spots (route regex, sort
order, dropdown, lookup object) -- a new role still won't be recognized by
the PH3 console. A `role` table with real FK referential integrity was
also not built; this uses the simpler "just relax the enum" approach.

Full src suite (623 tests) + supervisor suite (125 tests) pass with zero
regressions.

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>

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>

Implements docs/todo/verifier-fan-out-jury-design.md. root_cause_trace.py:
_tally_perspectives() extracts the existing >=2/3 rule out of
judge_root_cause so the closure-based version and the new
judge_root_cause_via_work_graph() share one implementation, not two that
could drift apart. The fan-in vote stays plain Python (zero_token
aggregation per the design-dynamic-work-graph Skill's own edge_type
distinction) rather than becoming a fourth Work Node -- no reason to pay
for an Agent call just to count votes.

judge_root_cause_via_work_graph(): each perspective becomes an
independent Work Node with real schema-constrained structured output
({"category", "detail"} directly), not real_validator_perspective's
manual "CATEGORY:"/"DETAIL:" text-line parsing. judge_root_cause /
real_validator_perspective are kept, not removed -- documented as the
lightweight fallback for scenarios that don't need worktree/Work Graph
overhead.

org_level_loop.run_fix_loop (the one real production caller) now calls
the Work Graph version; the fixer/verify calls are unchanged flat
trigger_org_node calls.

Real bug found and fixed along the way: this is the first production code
path that actually triggers a run_graph() multi-node CONCURRENT layer
(every graph_manifest before F was single-node or a strict serial chain,
so G's ThreadPoolExecutor path had never really run in production).
scheduler.py::run_goal_to_completion and
task_execution.py::start_task_execution_in_background both created their
conn without check_same_thread=False -- fixed both, since their conn can
now reach run_graph()'s worker threads via run_fix_loop.

Test boundary migrated in test_org_level_loop.py/test_scheduler.py: the
3 perspective calls are now mocked at work_graph_execute.write_workflow_script/
execute_work_graph (matching test_work_graph_orchestrate.py's pattern)
instead of org_node_trigger.trigger_org_node. New tests cover: three real
independent Work Node executions, judgment-rule equivalence with the
closure version, clean per-node input_payload, and concurrent wall-clock
overlap across the three perspectives.

Full src suite (586 tests) + supervisor suite (125 tests) pass with zero
regressions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Implements docs/todo/dynamic-work-graph-design-skill-design.md. G already
answered FR-2 (how to mark a parallel-eligible node group): no new field
needed -- topological_layers() infers independence purely from
depends_on/edges, so the new Skill's job is just "express real
dependencies honestly, don't add fake ones."

New Skill skills/design-dynamic-work-graph/SKILL.md: the node-boundary /
zero_token-vs-needs_judgment / per-node self-contained task_prompt
methodology, wired into agent_profile.py's FRONTMATTER for coder and
validator (Planner's own doc-chain path is untouched -- FR-4 only names
Coder/Validator).

work_graph_plan.py: new _GENERIC_PROMPT_TEMPLATE + generic_node_prompt_builder(),
used whenever org_node != 'planner'. Planner keeps its existing fixed
brd/prd/sdd/benchmark/... chain (_PROMPT_TEMPLATE) completely unchanged --
zero regression risk to the one real production planning path.

Scoped per the requirements doc's non-goal #1 ("prove the mechanism works,
don't cover every real scenario yet"): does NOT wire into
e2e_pipeline.py::implement_code()'s existing single-node production path.
New tests prove the mechanism itself: a Coder scenario that naturally
splits into 3 independent modules produces a correctly-shaped
graph_manifest, topological_layers() puts all three in one concurrent
layer (ties E directly to G), and generic_node_prompt_builder drives it
through run_graph() to completion.

Full src suite (580 tests) passes with zero regressions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Implements docs/todo/work-graph-parallel-execution-design.md: run_graph()
now schedules graph_manifest nodes layer-by-layer (topological_layers(),
Kahn's algorithm grouped by round instead of flattened), running a
multi-node layer's nodes concurrently via ThreadPoolExecutor (default 4
workers) with a barrier between layers; a single-node layer stays
synchronous, matching every real graph_manifest observed so far.
topological_order() is now a thin flattening wrapper, unchanged behavior
(regression-tested).

_LockedConn/_FetchedRows makes the existing scattered conn.execute() call
sites in work_node_run.py/work_graph_orchestrate.py/execution_log.py safe
to call from multiple threads without touching those call sites -- note
the lock must cover the full execute()-through-fetchone()/fetchall()
cycle, not just execute() itself, or two threads can still collide on the
shared sqlite3 connection handle. That gap was caught for real (not
theoretically) by RunGraphRealSqliteConcurrencyTest during development --
committing the fixed version, not the first draft.

create_worktree() (work_node_run.py) gets a module-level lock around the
`git worktree add` call for concurrent layers touching the same repo.

New tests: layer grouping, same-layer concurrency + inter-layer barrier,
one node's failure not cancelling a concurrent sibling (WorkGraphLayerError
aggregates), breakpoint-recovery resume of a concurrent layer, a quota-wait
timeout coexisting with a sibling's real persisted output, real (non-mocked)
sqlite under concurrent writes across several rounds, and real concurrent
`git worktree add` calls. Full src (575 tests) + supervisor (125 tests)
suites pass with zero regressions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…de13-main-checkout-drift

The literal token value was committed in plaintext across 4 files
(agent-memory notes, a stored run artifact, and a test assertion)
while documenting that it had been redacted from migrated skill
files -- the documentation itself failed to redact it. Replacing
with placeholders/omission ahead of pushing this repo to a remote
for the first time; the pre-existing commits (2a71bd5, 0cbf4b1,
14dee05) still contain the plaintext value in history.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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>

…c231-main-checkout-drift

Found for real: a work_graph_execute.WorkGraphExecuteError ("API Error:
Response stalled mid-stream") wasn't in _ROUTABLE_EXCEPTIONS, so it
propagated uncaught and crashed the calling process entirely -- leaving the
task neither running nor blocked_pending_human, just stuck with
blocked_reason=NULL. run_scheduler_once's own try/except only protects
OTHER goals in the same batch from one goal's failure; it never applied the
task-level blocked_pending_human consequence either.

Add a catch-all mirroring task_execution._mark_blocked's existing fallback
for its own (Start-button) entry point, so both ways of running a task now
guarantee it always lands on a real terminal-ish status with the real error
message persisted, never a caller-crashes-and-the-task-is-just-stuck outcome
nothing can manual_resume from.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Auto-continuation after a successful manual_resume only fired for
blocked_reason in ('user_paused', 'user_stopped'). A real transient network
blip ("API Error: Unable to connect to API (ENOTFOUND)") blocks a task with
blocked_reason='execution_error' the same way any other unroutable
exception does -- resuming it only flipped the status field back, with no
path to actually re-trigger execution (/execute requires status='queued',
but a resumed task lands on 'planning_brd_prd_sdd'/'coding' instead).
Clicking "resume" was a dead end a second click couldn't fix.

The user has already made the judgment call to retry by clicking resume at
all. Withholding continuation only made sense for the two reasons with
their own dedicated resume path requiring a different action first:
budget_exceeded (must raise the limit) and loop_limit_reached (excluded by
name, not just by its usual restored status). Every other blocked_reason
now auto-continues on a successful resume to a resumable status.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…10c5-main-checkout-drift

New target projects never got .claude/agents/*.md deployed, so their first
Planner call always failed immediately (claude --agent planner finds nothing
in cwd) -- self-target usage never noticed since those files are already
committed as part of this repo. create_project() now deploys and commits
them alongside the existing .graphlemon/ init commit.

Also: unroutable execution failures were recorded as a bare
blocked_reason='execution_error' with no way to see what actually broke.
scheduler._block_task()/task_execution._mark_blocked() now persist the real
exception message into execution_event.payload (blocked_reason itself is
unchanged -- budget_guardrail matches its exact value elsewhere).

Found via a real console Start-button failure on a freshly created project;
see docs/implementation-gap-analysis.md for the full writeup.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Users had no way to actually start a queued goal from the console --
task.status just sits at 'queued' forever. Traced the root cause through
03-C: c_task_create's own contract ("若 max_concurrent_goals 已达上限，
任务落 queued 但不触发调度") implies task creation auto-triggers
scheduling otherwise, and 03-C/04-P repeatedly assume an always-on Org
Graph scheduler that watches the queue -- src/scheduler.py builds the
mechanism but nothing ever spins it up as a running process, so no
"start" button was ever designed because none was supposed to be needed.

Design (confirmed with user, both recommended options chosen):
- Pause/Stop are a soft stop, not a real subprocess kill -- the current
  in-flight `claude` call finishes naturally, only the next phase is
  withheld. Hard-killing would need Popen + PID tracking, out of scope.
- No new task.status enum value -- reuses blocked_pending_human with
  blocked_reason='user_paused'/'user_stopped', riding the existing
  manual_resume mechanism instead of a schema change.

New src/task_execution.py: run_or_resume_task_lifecycle() resumes from
whichever phase actually hasn't run yet (queued/planning_brd_prd_sdd/
coding), start_task_execution_in_background() runs it to completion on
its own daemon thread + sqlite connection, request_pause() blocks an
in-flight task. Extended /route's manual_resume handling so resuming
from a user-initiated pause/stop actually re-continues execution in the
background, not just flips the status field back.

Real gap found while building this: backend_server.create_server() never
stored db_path on the server object -- needed for the new background
thread to open its own connection to the same db.

22 new tests (14 src/test_task_execution.py + 8 TaskExecutionRouteTest in
test_backend_server.py, HTTP wiring mocked around the already-unit-tested
background thread mechanics). Verified against a real running server via
curl: /execute 409s a non-queued task, /pause 409s a queued task and a
double-pause, succeeds on a coding task. src/ suite: 496 tests, all green.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Two new console pages requested directly by the user, beyond 02-V's
original declared non-goal ("不做完整多项目管理 UI（项目列表/切换）"):

- v_project_list: full project list + rename + archive/reactivate.
  "Import an existing directory with real code" needs no new code --
  project_scaffold.create_project() already only ever adds .graphlemon/
  inside the target folder. New: src/project_query.py (list/get/update),
  GET/PUT/DELETE /api/projects[/:id]. DELETE archives (status='archived'),
  never a physical row delete -- project_id is FK-referenced from task/
  artifact/bug_record/etc., and 01-M's own active/archived enum already
  models this as soft-delete.

- v_goal_list: extends the existing v_task_board/v_task_detail rather than
  duplicating them. Added sort/order to task_query.list_tasks() (column
  whitelist, no injection surface) and edit/delete on v_task_detail, both
  restricted to status='queued' (task_query.TaskNotEditableError, HTTP 409)
  -- editing or deleting a goal after real work has referenced it would
  leave that history pointing at something that no longer matches reality.

Implemented directly rather than through graphlemon's own self-hosting
loop -- confirmed with the user first that implement_code() always uses a
hardcoded single-node manifest (no plan_work_graph() call for Coder), so a
multi-page/multi-endpoint feature like this would've been one unreviewable
Coder session with no way to decompose it.

Real bug found on first verification pass (not caught by the existing
_insert_task test helper, which never writes execution_event): a real
task_create.create_task() always writes an execution_event row in the same
transaction (01-M's FK, no ON DELETE CASCADE) -- even a never-touched
queued task already has one, so DELETE FROM task raised
sqlite3.IntegrityError. Fixed by clearing the task's own execution_event
rows first; new regression test goes through the real create_task() path.

474 tests green. Verified end-to-end against a real running server (every
new endpoint exercised via curl) since the Chrome extension is still
unavailable this session.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Attempt 10 crashed immediately in the fix committed last: git add -A --
. ':!.graphlemon-worktrees' throws "paths are ignored by one of your
.gitignore files" (exit 1, not just advisory text -- confirmed even with
advice.addIgnoredFile=false suppressed) the moment that path is ALSO
gitignored, which it now always is. Reproduced locally.

Plain `git add -A` (no explicit pathspec) already skips gitignored paths
correctly on its own -- the explicit exclude was redundant now that
.gitignore covers it, and actively conflicting. Simplified
ensure_worktree_committed() back down. Also added the same .gitignore
entry to test_work_node_run.py's _init_git_repo() fixture so real-worktree
tests match production config instead of coincidentally not hitting this.

562 tests green (441 src + 121 supervisor).

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 6th real self-hosting attempt (first to reach the full 4-node doc-writing
graph after the previous five bugs) hit a genuinely new failure: this real
graph_manifest had no edges at all, not just wrong field names -- worse than
the case _normalize_graph_manifest already handled. With zero dependency
info to normalize from, topological_order() scheduled 'benchmark' before
'sdd' (alphabetically first among zero-in-degree nodes), and build_prompt()
crashed with KeyError: 'sdd_content' trying to format a template needing
sdd's not-yet-produced output.

_PROMPT_TEMPLATE always asks for exactly the same fixed 4-node linear chain
-- that's a constant architectural fact, not something that should be
re-inferred from the LLM's output every call. _normalize_graph_manifest now
deterministically enforces brd->prd->sdd->benchmark whenever all four
canonical artifact_types are present, regardless of what depends_on/edges
the LLM did or didn't provide. Same "机制用代码" principle as
ensure_worktree_committed and the earlier normalize logic.

Three new regression tests: zero dependency info still gets the chain
enforced, node_id != artifact_type still resolves to the real node_id (not
a guessed string), and a partial set (missing one of the four types) is
correctly left alone rather than guessed at.

560 tests green (440 src + 120 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>

A real self-hosting run (U-042, first real exercise of needs_worktree=True
since U-035 forces it unconditionally for self-target) exposed a real bug
RealGitWorktreeIsolationTest never caught: its own run_fn always committed
its edits, but a real Coder isn't instructed anywhere to git commit its own
changes. The Coder genuinely edited src/org_loop_route.py and verified it
in its own test_report -- but never committed, so merge_worktree()'s `git
merge` was a true no-op ("Already up to date"), and remove_worktree() then
silently discarded the dirty worktree along with the real work. code_diff
came out empty; the change never reached the branch at all.

Adds ensure_worktree_committed(): checks `git status --porcelain` in the
worktree before merging and auto-commits any dirty state found. A no-op
when the worktree is legitimately clean (e.g. a pure investigation task).
Same "判断用 Agent，机制用代码" principle already used elsewhere in this
codebase -- don't rely on persona prompt-engineering for a mechanical
correctness guarantee that the system itself should hold.

Two new regression tests: one reproducing the exact "edited but never
committed" scenario, one confirming a legitimately-clean worktree still
merges fine. 554 tests green (435 src + 119 supervisor).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Adds src/deployment_query.py (list_deployments/get_current_deployment/
get_deployment -- no project_id filter needed, deployment has no project_id
column since there's exactly one graphlemon self-target) + three new
backend_server.py routes (GET /api/deployments, /current, /:id, the last
with recent deploy_health_signal history) + a new v_deployment_status page
in frontend/app.js polling every 5s (deployment.status changes don't go
through c_ws_subscribe -- Deploy Supervisor writes deployment/
deploy_health_signal directly, no execution_event of its own).

No 02-V spec exists for this view (PH5 was added after 02-V was written) --
DOM/class conventions follow the existing pages' own patterns. Verified
against a real running server via urllib (browser extension unavailable
this session), plus 9 deployment_query unit tests and 5 real HTTP route
tests.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>