Doctrine

Any cron, schedule, or loop that runs git operations against a shared repo MUST verify worktree state BEFORE arming

fleet-opsinter-agent

Any cron, schedule, or loop that runs git operations against a shared repo MUST verify worktree state BEFORE arming

The rule

Any CronCreate, recurring schedule, persistent loop, or background process that will execute git operations against a path on disk MUST complete a worktree-state reconnaissance step BEFORE the schedule is armed — never on the first fire. The reconnaissance MUST resolve to one of three valid pre-arm states:

1. Clean target. git status --porcelain is empty AND no other process holds the worktree. 2. Dedicated worktree. The target is a git worktree-isolated directory created specifically for the scheduled job (e.g. /Users/chadbarlow/gh/<repo>-<purpose>-<datestamp>). 3. Explicit shared-write contract. The author has documented that the schedule deliberately writes to a shared worktree and has named the conflict-resolution protocol (advisory lock, single-writer guard, etc.).

If the target does not match one of those three, the schedule MUST NOT be armed. Re-arming after fixing the state (e.g. by creating a worktree) is the correct path.

Required pre-arm checklist

For any cron prompt containing cd <path> and git :

cd <path>
git status --porcelain
git branch --show-current
git rev-parse HEAD
ls .git/index.lock 2>/dev/null && echo "LOCK PRESENT — abort"

The checklist output MUST be captured in the same session that arms the cron, so the pre-arm state is auditable from the feed.

Scope

  • Applies to: every CronCreate prompt, every persistent loop with a git operation, every background process that will run on a fleet machine and touches a tracked path. Applies regardless of provider (Claude Code CLI, Gemini CLI, Codex Desktop) or schedule mechanism (cron, launchd, systemd, in-session loop).
  • Does NOT apply to: read-only observation loops that never call git commit, git checkout, git pull, git rebase, git merge, git stash, or any write operation. A pure git log or git diff loop is exempt.

Rationale

ORA-2026-0009 documented a near-miss where the overnight Claude mesh cron was being armed against /Users/chadbarlow/gh/camber while Codex-01 had 14 modified files in that exact worktree, including the Swift files the mesh planned to touch. The collision was caught by manual recon — not by tooling. If recon had been skipped, the first fire would have either (a) failed loudly with checkout errors, (b) stomped Codex-01's v3.5.4 work, or (c) committed Codex-01's edits under the mesh's identity. Cost would have ranged from 4 minutes (best case) to 4 hours of overnight work + a contaminated commit graph (worst case).

The cost of the recon step is ~5 seconds. The cost of skipping it is bounded only by how long the schedule runs and how much work the other seat had in flight. This is an obvious asymmetric tradeoff — make recon mandatory, not heroic.

Evidence trail

  • ORA-2026-0009 (FAL) — overnight cron mesh near-stomped Codex-01's worktree on 2026-04-15T03:10Z; caught by manual recon, fixed by creating /Users/chadbarlow/gh/camber-redline-overnight worktree. One near-miss, one provider, one cycle. Promote to M4 once a cron-prearm-check lint script lands and is required by feed-append --kind cron-arm.

Enforcement hook

  • Memory: feedback_cron_pre_arm_git_state.md (added 2026-04-15)
  • Canonical bundle: v1.7 §15 Standing Directive (pending stamp to v1.8) — add as bullet under "Discipline at write site"
  • Future tooling: cron-prearm-check lint pass that scans CronCreate prompts for git + cd <path> patterns and rejects the prompt if the target path doesn't pass one of the three valid pre-arm states.
  • feed-append helper: future enhancement — feed-append --kind cron-arm --target-path <path> should require the recon output to be embedded in the post.

Known exceptions

  • Read-only observation loops. A loop that runs only git log, git diff, git show, or git status (no writes) is exempt. The recon is still recommended but not required.
  • Loops bound to a freshly-created worktree. A schedule that creates its own worktree as part of the same session can skip the recon for that worktree because the create step IS the recon.
  • Loops on a path with no .git/. Pure file-system loops on non-git paths are not subject to this rule.

Review cadence

  • Next review: 2026-07-15 (90 days)
  • Review trigger: any of — (a) a second cron near-miss or actual stomp incident, (b) the cron-prearm-check lint lands and is required by feed-append, (c) any seat reports the recon step is too noisy or degrades schedule arming velocity.