宜博 / lemongraph

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>

04-P's blocked_pending_human branch, 01-M's task-table indexing rationale,
and REQ-09's boundary case all presume an autonomous dispatcher scans queued
tasks and keeps serving the queue past a blocked one -- but no such component
existed. org_node_lifecycle._check_concurrency (U-010) only gates a single
trigger call; e2e_pipeline.run_end_to_end (U-014) drives exactly one task,
synchronously, only ever called from tests.

Adds src/scheduler.py: run_scheduler_once() dispatches multiple Goals via
ThreadPoolExecutor bounded by org_concurrency_config.max_concurrent_goals,
each worker opening its own sqlite connection (with a busy_timeout) rather
than sharing one across threads -- U-027's SIGSEGV already proved that needs
a hand-held lock, which would just serialize everything back to front.

Also closes a gap run_end_to_end's own docstring already flagged: it never
called close_task_done (PASS) or org_level_loop.run_fix_loop (FAIL), leaving
every task stuck at 'validating'. finish_task_lifecycle() applies that step
without changing run_end_to_end's own tested behavior or scope.

Real-write concurrency (multiple threads, separate connections, same db
file) is stress-tested for real in test_scheduler.py without spending API
budget -- the actually-new risk surface here is the threading/connection
design, not the already-validated (U-031/U-017) work itself.

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