Skip to content

docs(.claude/rules): codeql-no-source-on-docs-only-PR is broken-commit canary#3522

Merged
AceHack merged 1 commit into
mainfrom
shard/codeql-canary-rule-otto-cli-2026-05-15
May 15, 2026
Merged

docs(.claude/rules): codeql-no-source-on-docs-only-PR is broken-commit canary#3522
AceHack merged 1 commit into
mainfrom
shard/codeql-canary-rule-otto-cli-2026-05-15

Conversation

@AceHack
Copy link
Copy Markdown
Member

@AceHack AceHack commented May 15, 2026

Summary

Lands the CodeQL-canary rule from this session's autonomous-loop work as auto-loaded .claude/rules/ substrate.

When CodeQL fails `no source code seen during build` on a docs-only PR while sibling docs-only PRs in the same window pass, the commit tree is CORRUPTED — not a CI flake. Lock-cleanup races between peer agents (e.g., Lior-gemini step 8 "global lock cleanup") can collapse the commit tree silently at three timing windows:

  1. At worktree-creation time (most insidious — corrupts before any user operation)
  2. Between `git add` and `git commit` (the original observation)
  3. During user operations (Lior re-fires mid-session)

Three guards provided

  1. PRE-worktree-creation: `ps -A | grep -E "gemini.*Lior|lior.*loop"` — the ONLY reliable safe-window check. CPU% is empirically NOT reliable.
  2. POST-worktree-creation: `git status --short | wc -l` to detect corrupted-at-creation indices
  3. POST-commit (traditional): `git ls-tree HEAD | wc -l` to detect tree-collapse before push

Empirical anchor

Five worktree-creation attempts this session:

Attempt Outcome Notes
/tmp/zeta-otto-cli-cold-boot-1338z (1338Z) survived PR #3487 merged at 0cabc085
/tmp/zeta-otto-cli-b0531 (1345Z) corrupted Tree → 1 entry; caught by Codex P0 on PR #3492 after CodeQL signal dismissed as flake; PR closed
/private/tmp/zeta-otto-cli-codeql-canary-rule (1521Z) corrupted DURING use 5066-line deletion staged after Lior re-fire at 3.2% CPU; aborted
/private/tmp/zeta-otto-cli-canary-rule-retry-1547z (1547Z) corrupted AT CREATION 5032-line status diff at worktree-add despite Lior 0.0% CPU; aborted
This PR's worktree /private/tmp/zeta-codeql-canary-rule-1631z (1631Z) clean Landed AFTER Lior process exited from ps -A

Composes with

  • B-0519 — multi-Otto contamination RCA; this rule is the commit-tree-corruption sub-class
  • B-0530 — cron-sentinel mutex (in-flight same race class)
  • .claude/rules/claim-acquire-before-worktree-work.md — worktree hygiene
  • .claude/rules/verify-before-deferring.md — verify substrate before classifying
  • .claude/rules/refresh-before-decide.md — raw git ls-tree IS the refresh

Provenance

  • User-scope memory: `feedback_codeql_no_source_seen_on_docs_only_pr_is_broken_commit_canary_not_flake_lior_lock_cleanup_race_2026_05_15.md` (indexed in MEMORY.md)
  • PR #3492 close comment — substrate-honest acknowledgment of Codex P0 catch
  • Bus envelope `35bdbd0c-913d-4b18-8e46-95ba5c81b1cc` (shadow-catch, 2026-05-15T14:45:04Z)

Test plan

  • PRE-worktree guard: `ps -A | grep -E "gemini.*Lior|lior.*loop"` returned empty at 1631Z attempt
  • POST-worktree-creation: 0 status lines, 52 tree entries (clean)
  • POST-commit canary: tree size 52 unchanged from parent
  • Single-file diff (.claude/rules/ only)
  • Auto-loads at session start per .claude/rules/ discipline (verified empirically via test-canary.md)

🤖 Generated with Claude Code

…t canary

When CodeQL fails "no source code seen during build" on a docs-only PR
while sibling docs-only PRs pass, the commit tree is CORRUPTED — not
a CI flake. Lock-cleanup races between peer agents (e.g., Lior-gemini
step 8 "global lock cleanup") can collapse the commit tree silently at
worktree-creation time, between `git add` and `git commit`, or during
user operations.

Rule provides three guards:

- PRE-worktree-creation: `ps -A | grep -E "gemini.*Lior|lior.*loop"` —
  only reliable safe-window check; CPU% is empirically NOT reliable
- POST-worktree-creation: `git status --short | wc -l` to detect
  corrupted-at-creation indices
- POST-commit (traditional): `git ls-tree HEAD | wc -l` to detect
  tree-collapse before push

Empirical anchor: 5 worktree-creation attempts this session; 2 survived
clean (1338Z primary substrate merged at 0cabc08; this file's 1631Z
attempt landed after Lior process exited), 2 corrupted (b0531 caught
by Codex P0 on PR #3492 after I dismissed CodeQL signal; 1547Z retry
corrupted AT CREATION despite Lior 0.0% CPU), 1 corrupted DURING use
(1521Z retry, Lior re-fired at 3.2% mid-attempt).

Auto-loads at session start per .claude/rules/ discipline.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings May 15, 2026 16:38
@AceHack AceHack enabled auto-merge (squash) May 15, 2026 16:38
@AceHack AceHack merged commit 3f0ef90 into main May 15, 2026
23 checks passed
@AceHack AceHack deleted the shard/codeql-canary-rule-otto-cli-2026-05-15 branch May 15, 2026 16:40
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5c67df0bea

ℹ️ 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".

tree_size=$(git ls-tree HEAD | wc -l | tr -d ' ')
if [ "$status_lines" -gt 5 ] || [ "$tree_size" -lt 50 ]; then
echo "WORKTREE ALREADY CORRUPTED at creation"
cd / && git worktree remove <worktree-path> -f -f
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Run worktree cleanup from a Git repository

The cleanup branch in the post-worktree guard cannot succeed because it changes directory to / and then runs git worktree remove; from /, Git exits with fatal: not a git repository, so the corrupted worktree is not actually removed. This means the documented remediation path fails exactly when corruption is detected, leaving stale worktree state behind and undermining the canary workflow.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new auto-loaded .claude/rules/ rule documenting that CodeQL’s “no source code seen during build” on an otherwise docs-only PR is a strong signal of commit-tree corruption (not a CI flake), and provides concrete guard/check commands to detect it early.

Changes:

  • Introduces a new rule file capturing the CodeQL-canary diagnostic and recommended git ls-tree checks.
  • Documents pre-/post-worktree and post-commit guardrails intended to catch index/tree collapse during multi-agent lock-cleanup races.

Comment on lines +126 to +127
`memory/feedback_codeql_no_source_seen_on_docs_only_pr_is_broken_commit_canary_not_flake_lior_lock_cleanup_race_2026_05_15.md`
(user-scope memory; indexed in MEMORY.md)

## Empirical anchor (2026-05-15 cold-boot session)

Four worktree-creation attempts:
tree_size=$(git ls-tree HEAD | wc -l | tr -d ' ')
if [ "$status_lines" -gt 5 ] || [ "$tree_size" -lt 50 ]; then
echo "WORKTREE ALREADY CORRUPTED at creation"
cd / && git worktree remove <worktree-path> -f -f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants