宜博 / lemongraph

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>

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

Adds supervisor/deploy_stage.py: stage_deployment() creates a deployment row,
git-worktree-checks-out the target commit into a fresh directory (--detach,
never in-place git pull), copies the production DB to a one-time candidate
copy, and Popens a real candidate backend process on a free port.

Return value follows 04-P §4.6's state-machine table (status after the call
is 'candidate_starting') rather than 03-C's one-line 'staged' summary --
04-P's own trigger text ("c_deploy_supervisor_stage 完成" moves the row to
candidate_starting) is the more detailed/authoritative source when the two
disagree, same precedent used throughout this project.

Found and closed two real gaps along the way:
- deployment's own field list never included where a candidate's checkout
  directory lives -- added candidate_instance_dir to schema.py (also what
  the NEXT staging call's previous_instance_dir bootstraps from once a
  deployment reaches 'finalized').
- backend_server.py had no CLI entry point at all since U-007 -- create_server()
  was only ever instantiated in-process by tests. Added main() (argparse +
  serve_forever + SIGTERM->shutdown() from a separate thread, per
  http.server's own same-thread-deadlock warning).

RealCandidateLaunchTest spawns and HTTP-probes a genuine
`python3 -m src.backend_server` subprocess against a real git-worktree
checkout of this repo (not mocked) -- caught a real ordering issue doing so:
git worktree only sees committed content, so testing before this Unit's own
commit landed would check out backend_server.py without main() at all.
Fixed by using `git stash create` (builds a commit object from the current
working tree without touching HEAD/index) as the commit-to-test-against,
falling back to plain HEAD once the tree is clean post-commit.

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

Adds the two Deploy Supervisor entities from 01-M §1.15/§1.16 (17 tables
total): deployment (full 15-value blue-green state machine, per 01-M's own
text rather than supervisor-auto-rollback-design.md §3's abbreviated
summary table) and deploy_health_signal (append-only health/monitoring
samples). ux_deployment_active enforces 01-M's "only one non-terminal
deployment at a time" constraint via an expression-based unique index
(CREATE UNIQUE INDEX ... ON deployment((1)) WHERE status NOT IN (...)) --
the same partial-unique-index idiom work_graph_run already uses, just with
a constant instead of a real grouping column since there's exactly one
graphlemon self-target.

bug_record.root_cause_category's schema-level CHECK now accepts
core_engine, but bug_record.py's own application-layer whitelist
deliberately does not follow yet -- classifying a bug as core_engine is a
file-path-based rule (05 §5.8), not something the Validator's existing
3-perspective judge_root_cause can produce, and wiring that classification
+ c_org_loop_route's routing is U-035's job.

392 tests green.

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>

Implements docs/sdd/01-M-模型设计.md §1.0-1.14 as stdlib sqlite3 DDL in src/
(deployment/deploy_health_signal §1.15-1.16 are PH5/U-034, deliberately
excluded). Covers all entities' fields, enum CHECK constraints, FKs, and
the two non-trivial unique indexes (work_graph_run's per-(task_id,org_node)
active-run partial index, artifact's (task_id,artifact_type,git_commit_sha)
composite key).

Per user decision (2026-07-30): bug_record.root_cause_category excludes
'core_engine' for now -- that value is PH5-scoped and development-plan.md
assigns adding it to U-034, not U-001; a test locks this in.

14 stdlib unittest cases in src/test_schema.py cover table creation and the
Done criterion's named constraint classes (unique/FK/enum), all passing.

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