宜博 / lemongraph

Real incident (2026-08-06): the skill-content migration task and the skill
detail page bug fix were two separate tasks. Neither was asked to verify
that migrated content is actually reachable through the DB-backed lookup
the detail page uses. Both passed their own tests cleanly -- because both
only ever exercised the mechanism against seeded/mocked fixture data, never
checked whether the real producer's real output actually exists in the
real system. The result: the skill detail page returned "not found" for
all 12 real migrated skills, and nobody caught it until a human clicked
through the real console.

qa-task-validation (§8): passing unit tests against seeded fixtures proves
the mechanism is correct given valid input -- it does not prove that input
exists for real. When a feature reads data another task/process was
supposed to have already written, Validator must independently query the
real running system against a real (not newly-created) object.

project-sdd-planning (§10): when a task's acceptance depends on another
task's real output, the Benchmark must name a real, specific object as the
acceptance anchor, not just describe the mechanism.

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

…11fd-main-checkout-drift

…c231-main-checkout-drift

_launch_candidate() spawns a real `python -m src.backend_server` process
(`revived`) to re-verify the previous version during a post-cutover
rollback. On the success path it's correctly left running -- it IS the new
Live. But on every failure path (never bound live_port, failed
re-verification, git revert conflict) nothing ever terminated it -- found
via 31 accumulated orphaned processes on this machine, one per failed
rollback_path_b call across many real test runs this session.

This is also the likely cause of RollbackPathBFailureTest's own reported
non-determinism (three independent real Validator sessions saw it fail,
never reproduced manually): a leaked process from an earlier failed run
can still be squatting on the port a later run's _find_free_port() picks,
producing a false "alive" health-check reading.

Fix: call deploy_cutover._stop_process(revived.pid) in both failure
branches before raising, mirroring the pattern cutover() already uses for
its own stop_timeout-bounded process teardown. Also fixes
RollbackPathBHappyPathTest's own matching leak (it re-appended bad_live.pid
a second time instead of tracking the actual revived process, a
copy-paste bug, not real cleanup) by capturing the real pid via a thin
_launch_candidate wrapper.

31 pre-existing orphaned processes killed by hand; verified 5 repeated
test runs after the fix leak zero new ones.

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

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

Three real self-hosting fixes (log content never written, skill detail
page missing real content, artifact list not clickable), two design
questions set aside per user's request (unified Planner-driven work graph
across all org agents, loop visualization on the graph), three bugs left
for a future batch, and two infrastructure bugs found and fixed along the
way (manual_resume not actually continuing execution for most block
reasons, run_goal_to_completion crashing instead of blocking on unrouted
exceptions). Also upgrades the RollbackPathBFailureTest flakiness note --
three independent real sessions have now hit it.

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

…1a79-main-checkout-drift

…ea4d-main-checkout-drift

…d9ae-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>

…0a72-main-checkout-drift