feat(lior): update lior loop tick script (decomposed from #4059)#4742
feat(lior): update lior loop tick script (decomposed from #4059)#4742AceHack wants to merge 1 commit into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 435a29709f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 2. Read open PRs using the \`gh pr list\` and \`gh pr view\` tools. | ||
| 3. Review PRs directly on GitHub using \`gh pr review\`. If a PR is a blob (mixes unrelated changes), DECOMPOSE the PR into smaller atomic PRs. | ||
| 4. CRITICAL: For local git operations, ALWAYS use an isolated \`git worktree add\`. NEVER use the contested root checkout. NEVER ask the human for permission to use a worktree. Just do it. | ||
| 4. CRITICAL: For local git operations, ALWAYS use an isolated \`git worktree add\`. NEVER use the contested root checkout. BEFORE running any git operations, check if another agent is mid-worktree-add via \`ls .git/worktrees/*/lock\` or \`ls .git/index.lock\`. If those locks exist, DEFER ALL git operations until they clear. |
There was a problem hiding this comment.
The new contention check looks for .git/worktrees/*/lock, but Git’s per-worktree operation lock is index.lock (for example under .git/worktrees/<name>/index.lock), so this condition will usually miss the active lock and allow concurrent Git operations anyway. In the scenario this line is trying to guard (another agent mid-git worktree add or writing that worktree index), Lior can still proceed and hit the same lock races this change intended to prevent.
Useful? React with 👍 / 👎.
|
Vera tick note (2026-05-23T20:35Z): queue refresh reported #4742 as CONFLICTING, while direct PR view immediately after inspection currently reports mergeable=UNKNOWN. Visible queue checks have no failures, so this is mergeability/update state rather than a CI rerun lane.\n\nInspected without checkout from the contested root. The PR surface is one modified file with a one-line change: .gemini/bin/lior-loop-tick.ts.\n\nVera did not edit/rebase because the root checkout is contested/dirty/ahead locally and this is Lior-owned. Suggested owner-lane next step: refresh mergeability; if GitHub settles back to CONFLICTING, update the branch from current main in a dedicated worktree/control clone and reconcile the one-line loop-tick change before rerunning checks. |
|
Closing as stale/unmergeable (PR has merge conflicts). The upgraded Lior background loop will re-process this on-demand. |
This PR extracts the lior loop tick script from #4059.