live: heartbeat sync 2026-10-29T15:29:37-07:00 (Refs #11)

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

@@ -0,0 +1,53 @@
+---
+name: live-checkout-landing-chain
+description: "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
+
+```bash
+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:
+
+```bash
+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:
+
+```bash
+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.