宜博 / lemongraph

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

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>

The third real self-hosting attempt (first to actually reach stage_deployment
itself, past the earlier bootstrap/commit bugs) hit an uncaught
FileNotFoundError: _copy_prod_db() assumed prod_db_path always exists and
shutil.copy2()'d it unconditionally. graphlemon has never actually run as a
persistent service, so ~/.graphlemon/graphlemon.db never existed.
stage_deployment() already handles this exact class of "no prior state"
bootstrap case for previous_commit_hash/previous_instance_dir -- prod_db_path
never got the same treatment, and every existing test seeds a prod db in
setUp so this was never exercised.

Fix: when prod_db_path doesn't exist, create a fresh schema'd db instead of
copying -- semantically correct, since a genuinely-first deployment has no
production data to inherit. New regression test (BootstrapProdDbTest) covers
it. 555 tests green (435 src + 120 supervisor).

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