Repository navigation
laptop-repo-keeper: snapshot commits on the primary's main diverge it from origin and break deploys #2496
Description
On 2026-10-29 the deployment chain (ordered for PRs #2220/#2250) stopped twice at the laptop primary ~/git/code:
- First at the clean-tree check (untracked runtime residue — since cleared and covered by PR chore: ignore runtime residue (local state, session dirs, config backups, stray redirects) #2486's .gitignore additions).
- Then at
git pull --ff-only: the tree was clean but main had diverged — ahead 9 / behind 254. The 9 local commits were allrepo-keeper: snapshot code ...commits taken through the day (04:23–18:24 CDT). The keeper snapshots whatever live edits agents have made in the primary working tree (that day: .opencode/opencode.jsonc live-applied config and bin/sessions.json runtime state) and commits them directly onto main. Those same changes later land properly through PRs, so the snapshots are pure divergence: origin's opencode.jsonc was strictly newer than the local snapshot state.
Resolution applied with Drew's approval (2026-10-29 ~20:32 CDT): backup branch backup/primary-local-2026-10-29 pushed at c3b779c (all 9 snapshots preserved), primary reset --hard to origin/main (7d1b081), chain re-armed.
Durable fixes wanted:
- Untrack bin/sessions.json (git rm --cached + .gitignore): it is live runtime state; tracking it guarantees the primary dirties and diverges whenever sessions run. Same treatment check for any other runtime-state files the keeper keeps sweeping up.
- Keeper should not commit on a primary clone's main at all — or should snapshot to a dedicated snapshot branch instead of main. A primary is a deploy source (Drew's standing rule: primaries stay on main + clean, deploys run from the primary at origin/main); any automation that commits to its main breaks every ff-only deploy.
- Until fixed, any deploy/switch flow that pulls the primary must expect this failure mode; the chain's state files from 2026-10-29 (deploy-chain-2220-state.failed*.json in the repo-health goal workspace) hold the evidence.
Related: #2268 (keeper secret guard), #1807 (autocommit merge-in-progress guard), #2230 (autocommit changes under the fleet-expansion umbrella).
Acceptance criteria
-
bin/sessions.jsonis untracked (git rm --cached + .gitignore) and any other runtime-state files the keeper sweeps up get the same treatment, verified by a keeper run leaving the primary clean - The laptop-repo-keeper no longer commits onto a primary clone's main — snapshots go to a dedicated snapshot branch (or are not taken on primaries), so a primary's main can only move by fast-forward
- A deploy chain run after a keeper snapshot completes its ff-only pull without manual rescue
Activity
developing-today commentedon Oct 30, 2026
CODE-1273
dezren39 commentedon Oct 30, 2026
Intake review
Related: PR #2486 (.gitignore additions for the residue half), PRs #2220/#2250 (the deploy chain that stopped), backup branch
backup/primary-local-2026-10-29(the 9 preserved snapshot commits at c3b779c)Notes: Filed 2026-10-30T01:32Z after the 2026-10-29 deploy chain stopped twice at the laptop primary: keeper
repo-keeper: snapshot code ...commits (9 through the day) put local main ahead 9 / behind 254, breakinggit pull --ff-only. The immediate rescue is already done with Drew's approval (backup branch pushed, primary reset to origin/main 7d1b081) — what remains is the durable fix in the body: untrack bin/sessions.json and stop the keeper committing on a primary's main. This pass appends acceptance criteria and applies kind/priority/effort.Risks: Every day the keeper keeps snapshotting live-edited config onto main, the divergence recurs and a future reset risks discarding the only copy of a live-applied change.
Suggested approach: Untrack the runtime-state files first (small, safe), then change the keeper's snapshot target to a dedicated branch for primary clones; verify with one keeper cycle + one deploy-chain pull.
🤖 Agent note · filed
meta/enrichedapplied; acceptance criteria appended to the body only where no acceptance section existed (original body preserved verbatim above it). Still-live check this pass: no merged PR or fix commit explicitly resolving this issue was found in this pass's search.developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7329 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: picked up
Task 7329 (triage) claimed by lane code-c, execution lane direct. Revalidating issue #2496 against fresh GitHub and laptop primary state: whether bin/sessions.json is still tracked, whether the laptop-repo-keeper still commits onto a primary's main, and whether any fix PR already exists.
Found via: repo-queue worker shift lane C 2026-11-03
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged — closing as completed/superseded, with evidence
Triage of task 7329 against fresh state (2026-11-03 ~17:50 CST), criterion by criterion:
bin/sessions.jsonuntracked — DONE.git ls-tree origin/main bin/sessions.jsonis empty and the file no longer exists on the laptop primary; it was removed from tracking by PR provider proxies keep session state in the repo tree (bin/sessions.json) — move to ~/.local/state #3067 (commit60af45ba1, "chore(bin): remove tracked sessions.json — proxy session state lives in state dirs now"). No other runtime-state file is being swept up by the keeper today: its latest run (2026-11-03 16:27 CST) reports the code primary clean apart from one untracked file (see below).Keeper committing onto a primary's main — mechanism fixed at the root, under the design Drew accepted in laptop repo-keeper snapshot commits diverged ~/git/code main from origin (pm-git-sync failing) #4464. The keeper (
nixos/home/laptop-repo-keeper.shat origin/main) still snapshot-commits dirty tracked files, but PR fix(repo-keeper): never snapshot-commit on a stale base (code#4464) #4525 (merged72239e49a, closing laptop repo-keeper snapshot commits diverged ~/git/code main from origin (pm-git-sync failing) #4464) made it compute ahead/behind right after fetch and refuse to snapshot when behind > 0 — the exact mechanism that produced the 2026-10-29 ahead-9/behind-254 divergence here and the 2026-11-02 laptop repo-keeper snapshot commits diverged ~/git/code main from origin (pm-git-sync failing) #4464 divergence. Snapshots on an up-to-date base are pushed to origin, so the primary cannot diverge from them. laptop repo-keeper snapshot commits diverged ~/git/code main from origin (pm-git-sync failing) #4464 was closed COMPLETED by Drew on that basis ("Fixed at the root and reconciled"), which supersedes this issue's literal "dedicated snapshot branch" wording. Live proof the guard fires: today's keeper run left hatch-personal uncommitted with the line "a snapshot on a stale base would diverge the primary (code#4464) — reconcile first".Deploy chain ff-only pull after a keeper snapshot — holds under the new mechanism. Keeper snapshots either become origin (up-to-date base, pushed) or are never taken (stale base);
code-frozen3/4/5primaries fast-forwarded 42 commits in today's keeper run.Current adjacent problem (not this issue's mechanism): pm-git-sync is failing right now because the primary is dirtied by untracked
.opencode/service-local.json— filed separately as #5209. The primary's current ahead-1 is a deploy flake.lock commit (a9a392d2f), not a keeper snapshot.Verdict: the durable fixes this issue asked for have landed via PR #3067 and PR #4525/#4464; closing as completed. If the snapshot-branch design is still wanted over the accepted behind-guard design, reopen with that stated as a fresh decision.