fix(lastcode): publish checkpoints when work merges mid-run

.agents/skills/lastcode-pr/SKILL.md

@@ -75,8 +75,14 @@ workstream base, not the parent branch.
 Open PRs do not pause checkpoint creation, repaired-checkpoint publication, or
 promotion to `lastcode/main`. Never close, merge, or retarget an unrelated PR to
 unblock checkpoints. A candidate must incorporate its pinned source, and its
-promotion lease must protect that source against concurrent merges. Retain a
-selected recovery on source drift and reselect it against current main.
+promotion lease must protect that source against concurrent merges. Merging
+while a checkpoint runs is safe: the validated tag still publishes and the
+merge's service request follows with a revision. Reselect a recovery only when
+main no longer descends from its selected source.
+
+Failure to acquire the promotion lock still fails the run after tag publication.
+Inspect its owner and the connection error before retrying; a lock ref alone
+does not prove an active merge.
 
 When `lastcode/main` advances, obtain fresh validation against the new base
 before merging. Refresh the PR branch as needed; validation from the previous

docs/lastcode/fork-conventions.md

@@ -311,9 +311,13 @@ Open PRs do not pause checkpoint creation, repaired-checkpoint publication, or
 promotion to `lastcode/main`. The daemon publishes immutable LastCode revisions
 for merged work and repairs missed merge triggers on later runs. Candidates pin
 the source they incorporate, and promotion leases against that source so a
-concurrent merge cannot be overwritten. A stale candidate must incorporate the
-new source before promotion. PRs whose base changes need fresh validation
-against the current base before merging, even when their head is unchanged.
+concurrent merge cannot be overwritten. When a merge advances main during a run,
+the validated tag still publishes, promotion waits, and the merge's service
+request publishes a revision that replays the merge onto that tag. PRs whose
+base changes need fresh validation against the current base before merging,
+even when their head is unchanged. Failure to acquire the promotion lock still
+fails the run after tag publication, so abandoned locks and connection failures
+remain visible and can be repaired before retrying promotion.
 
 ### Inspect a specific pull request
 

docs/lastcode/nightly-workflow.md

@@ -107,16 +107,25 @@ promotion. Feature branches may remain open while daily updates advance.
 
 Each candidate is prepared from a pinned `lastcode/main` source commit.
 Promotion uses that incorporated source as its exact `--force-with-lease`
-value, rather than adopting a newer remote head at publication time. A merge
-arriving during preparation therefore rejects promotion instead of being
-replaced by a candidate that omitted it. A later run recomputes from the new
-source, including the merged work.
+value, rather than adopting a newer remote head at publication time. When a
+merge advances main during the run, the validated tag still publishes and
+promotion is deferred instead of failing the run. The merge's own service request
+then publishes a revision that replays the
+merged work onto that tag and promotes it; a newer lease alone never makes a
+stale candidate safe.
+
+Deferral requires current main to descend from the candidate's pinned source.
+A rewrite that drops that source still fails promotion after tag publication;
+inspect the new history before retrying.
+
+Lock acquisition failures still fail the run after the tag publishes. The lock
+ref cannot prove its writer is active, so contention, abandoned locks, and
+authentication or transport errors must remain visible to maintenance. Once
+the lock is available, a later run can promote the published tag or its revision.
 
 Checkpoint metadata records the exact source as `Source-Commit`. If publication
-succeeds but promotion fails while the source remains unchanged, a later run
-retries the published candidate. If main has moved, the run incorporates the
-new source before promotion; a newer lease alone cannot make a stale candidate
-safe. Immutable publication may succeed before promotion is rejected.
+succeeds but promotion does not happen while the source remains unchanged, a
+later run promotes the published candidate.
 
 Open PRs must obtain fresh validation against the current base before merging.
 After a checkpoint changes `lastcode/main`, refresh the PR branch as needed and
@@ -257,12 +266,14 @@ that transition. No application restart is required.
 
 ### Failure recovery
 
-Selected repaired-checkpoint publication also pins the source revision and
-atomically publishes with a lease against that incorporated source. Open PRs
-are irrelevant to this check. If main changes after recovery selection, the
-publication is rejected and the recovery worktree is retained. Inspect the new
-source and select recovery again so the repair includes current merged work;
-do not retry a stale selection with an updated lease alone.
+Selected repaired-checkpoint publication also pins the source revision. Merges
+after selection follow the same deferred-promotion path as ordinary candidates,
+so a repair never needs reselecting just because work merged. Only a main that
+no longer descends from the selected source (for example, after another
+promotion rewrote it) rejects the selection and retains the recovery worktree.
+The repair and selection are released only after promotion succeeds or verifies
+a descendant main update. A promotion failure retains both for inspection and
+retry without republishing the immutable tag.
 
 Before following any recovery cleanup printed by a status report, verify the
 current daemon state and ownership of the retained worktree. Preserve active

docs/lastcode/release.md

@@ -225,12 +225,16 @@ before making it; upstream ancestry alone cannot prove this after a rebase.
 Selection requires a clean, completed `sync/nightly/<nightly>` worktree and is
 bound to its head, nightly, and current source. The service skips only that
 nightly's rebase and reruns the full checkpoint smoke gate. It publishes the
-immutable tag and promotes main together with an atomic push leased against the
-selected source commit. Open PRs do not block publication or promotion. A merge
-arriving during validation makes the atomic push fail without publishing the tag
-or changing main. Selected recovery cannot disable validation or
-be automatically superseded. A changed head or source requires inspection and
-selection again. Failed validation retains the worktree and selection.
+immutable tag and source ref, then promotes main with a lease against the selected
+source commit. Open PRs do not block publication or promotion. Merges made after
+selection or during validation do not invalidate it: the tag still publishes,
+promotion waits, and the next run publishes a revision replaying those merges
+onto the repaired tag. Failure to acquire the promotion lock still fails the run
+after tag publication and requires inspection before retrying. Build that tag
+right away; the revision follows. Selected recovery cannot disable validation or
+be automatically superseded. A changed head,
+or a main that no longer descends from the selected source, requires inspection
+and selection again. Failed validation retains the worktree and selection.
 
 Use **Wait for Checkpoint** immediately after requesting the service run, and
 end the turn. After publication, use **Build Local Package** on the exact new