command-center/agent/managed-skills/live-checkout-landing-chain/SKILL.md

name, description

name	description
live-checkout-landing-chain	Prove whether a merged change is actually deployed in ~/.omp: walk origin/main vs the checked-out main commit vs the worktree, then fast-forward in place — git refuses fetch into a checked-out branch, and a running harness caches its config.

When to use

The user says a merged/committed change is "not there" (/switch can't see a model, a doc is missing, a config edit is invisible) while the repo work itself is green. In a repo where the checkout is the deployment (dank/command-center at ~/.omp), "merged" and "deployed" are different commits — measure both before believing either claim.

The ladder — read all four levels, in order, before answering

cd ~/.omp && git rev-parse HEAD origin/main          # 1+2: deployment vs forge
git ls-tree --name-only HEAD                          # is the file even in HEAD?
git worktree list                                     # 3: which worktree am I in vs main?

1. origin/main — the forge truth (gh/tea absent; Gitea API or a fetch).
2. /home/blank/.omp HEAD — what the running agent actually reads. Merged PR at 3eb1ada while this sat at 53025a6 is the whole bug.
3. The feature/session worktree — where the edit was authored; its files can be correct while main is stale, which is why the author sees the change and the user does not.
4. The running process — models.yml / config.yml are read at startup and cached for the process lifetime; an open session needs a restart even after level 2 is correct.

Belt-and-braces when the answer hinges on file contents, not just commit ids: parse the live file (python3 -c "import yaml; ..." for agent/models.yml, or grep the doc) rather than inferring from git log.

Landing main without touching the tree

git fetch origin main:main fails: fatal: refusing to fetch into branch 'refs/heads/main' checked out at '/home/blank/.omp'. The fetch-into-ref trick only works for branches that are not checked out anywhere.

For a checked-out main, prove then fast-forward:

git merge-base --is-ancestor main origin/main && echo "ff possible"
git merge --ff-only origin/main          # no rebase — Frank dislikes history rewrites

--ff-only is the safe verb on a dirty main checkout: tracked-file commits (the live-sync tier) and runtime dirt (agent/memories/*/state.json, dotfiles/**) survive untouched, and it cannot rewrite history. Confirm the dirt is still there afterwards — if it vanished, something else clobbered the tree.

The heartbeat is not instant

scripts/live-sync.sh (systemd user timer, hourly) is what normally advances main. Check its cadence rather than assuming it ran:

systemctl --user status live-sync.timer --no-pager   # "Trigger: …" = next beat
systemctl --user status live-sync.service --no-pager # "since …" = last run

A merge made minutes after the last beat waits until the next one; fast-forwarding by hand is legitimate (idempotent with the script) and is the answer when the user wants it now. Never --no-verify, never force-push.

Do not confuse with

• omp-worktree-path-gotchas — edits landing in the wrong worktree (cwd drift), not a stale main.
• dotfiles-deployment-truth-audit — classifies which files are tracked vs runtime state.
• serverappconfigs-vault-page-registration / gitea-merge-form-encoded — the PR mechanics upstream of this question.