宜博 / lemongraph

…3203-main-checkout-drift

…2750-main-checkout-drift

Attempts 7 and 11 both failed at exactly the same spot: process_alive read
'ok' within milliseconds of Popen, then http_health hit ECONNREFUSED in the
same second and gave up. Real cause: process_alive only confirms the
process EXISTS, not that backend_server.py has finished importing modules
and actually bound its listen socket -- a real, non-zero startup gap. The
old check_http_health did one urlopen(timeout=X) call; that timeout only
bounds how long to wait for a response once connected, not how long to
wait for the port to start accepting connections at all -- ECONNREFUSED
fires essentially instantly when nothing's listening yet, regardless of
timeout.

This touches an explicit 03-C design statement ("不重试——重试属于给坏版本
第二次机会"), so confirmed with the user before changing it rather than
just reinterpreting the policy unilaterally. Resolution: tolerating normal
startup latency within ONE health-check pass isn't "retrying a failed
check" -- check_process_alive already does exactly this (polls up to 30s
for the pid to exist). http_health now does the same, polling within its
own timeout for connection-refused-class errors specifically. A genuine
non-2xx HTTP response is still a definitive answer from a live server and
still fails immediately, no polling -- that boundary is unchanged.

Two new real regression tests: a real server that starts listening 0.3s
late is correctly waited for and passes; a real 500 response still fails
immediately without being mistaken for "not up yet".

564 tests green (441 src + 123 supervisor).

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

This reverts commit b14c41371f803541c1f01debb0658ea13e816e0d.

…be04-main-checkout-drift

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 7th real self-hosting attempt was the first to actually reach a real
health check against a real candidate process -- it correctly failed and
triggered rollback_path_a for real: candidate terminated, git revert landed
cleanly. But the candidate's `git worktree add --detach` checkout
(candidate_instance_dir, tracked since U-037 specifically to know where
this lives) was never removed -- left permanently on disk and still
registered in `git worktree list`. A confirmed-bad candidate is never
needed again after path A, unlike a successful cutover's candidate (which
correctly becomes previous_instance_dir, kept until the monitoring window
closes) -- these are different lifecycles that shouldn't share the same
"leave it" behavior.

rollback_path_a gains an optional candidate_instance_dir parameter
(default None, existing tests unaffected) and removes the worktree before
git revert when provided. self_hosting_e2e.py now threads through the
value stage_deployment() already returns. New regression test uses a real
`git worktree add --detach` checkout and confirms both the directory and
its git worktree registration are gone after rollback.

Also cleaned up 3 orphaned processes left by earlier test_deploy_rollback.py
runs (backing temp dirs already gone) and the real leftover candidate
worktree from this run.

561 tests green (440 src + 121 supervisor).

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

This reverts commit d77320f8d5b0600c99dcb6969e868f6d348ce9fb.