fix: ensure_repo_local self-heals dirty trees #91

Merged

joshtronic merged 2 commits from fix/ensure-repo-stash-pull-pop into master

2026-05-22 17:13:32 +00:00

joshtronic commented

2026-05-22 17:13:07 +00:00

Owner

Crashed ticks (W_LOG-style unbound var, OOM, timeout, push
failure mid-flow) can mutate working-tree files but never reach
the commit step. The dirty state then blocks git pull --rebase
forever, and the only signal is the one-line "warning: pull of
$repo failed; using stale local copy" -- which the harness logs
and walks past. Today's example: blog-ideas.md sat uncommitted
for 6+ hours because this morning's W_LOG crash mutated it
before the brain commit step. Every tick since has logged the
warning and silently used stale state; brain effectively
stopped getting new commits.

ensure_repo_local now self-heals at tick start:

Detect dirty tracked-file diff (staged or unstaged).
If dirty: log the file list, git add -A + commit with
subject "recovery: auto-commit leftover changes from prior
tick", try to push.
Pull normally. Recovery commit is now on top of origin (or
gets rebased onto origin if origin moved).

Trade-off: the recovery commit preserves whatever partial state
the prior tick left behind. If that state was "the :wq idea got
removed but the post never shipped," the idea stays removed --
no re-drafting on the next tick. Manual restore is possible by
reverting the recovery commit or re-adding the idea to
blog-ideas.md. Accepting partial-state preservation is the lesser
evil vs. silent rot for hours.

Untracked files don't trigger the detection (they don't block
git pull --rebase). The recovery git add -A does sweep them
up if a tracked-file diff already triggered, so any orphaned
scratch files in brain get committed alongside the real changes.

Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com

Crashed ticks (W_LOG-style unbound var, OOM, timeout, push failure mid-flow) can mutate working-tree files but never reach the commit step. The dirty state then blocks `git pull --rebase` forever, and the only signal is the one-line "warning: pull of $repo failed; using stale local copy" -- which the harness logs and walks past. Today's example: blog-ideas.md sat uncommitted for 6+ hours because this morning's W_LOG crash mutated it before the brain commit step. Every tick since has logged the warning and silently used stale state; brain effectively stopped getting new commits. ensure_repo_local now self-heals at tick start: 1. Detect dirty tracked-file diff (staged or unstaged). 2. If dirty: log the file list, `git add -A` + commit with subject "recovery: auto-commit leftover changes from prior tick", try to push. 3. Pull normally. Recovery commit is now on top of origin (or gets rebased onto origin if origin moved). Trade-off: the recovery commit preserves whatever partial state the prior tick left behind. If that state was "the :wq idea got removed but the post never shipped," the idea stays removed -- no re-drafting on the next tick. Manual restore is possible by reverting the recovery commit or re-adding the idea to blog-ideas.md. Accepting partial-state preservation is the lesser evil vs. silent rot for hours. Untracked files don't trigger the detection (they don't block git pull --rebase). The recovery `git add -A` does sweep them up if a tracked-file diff already triggered, so any orphaned scratch files in brain get committed alongside the real changes. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

joshtronic added 1 commit

2026-05-22 17:13:07 +00:00

fix: ensure_repo_local self-heals dirty trees

Lint / check-sync (push) Successful in 4s

Details

Lint / check-sync (pull_request) Has been cancelled

Details

75894c11a4

Crashed ticks (W_LOG-style unbound var, OOM, timeout, push
failure mid-flow) can mutate working-tree files but never reach
the commit step. The dirty state then blocks `git pull --rebase`
forever, and the only signal is the one-line "warning: pull of
$repo failed; using stale local copy" -- which the harness logs
and walks past. Today's example: blog-ideas.md sat uncommitted
for 6+ hours because this morning's W_LOG crash mutated it
before the brain commit step. Every tick since has logged the
warning and silently used stale state; brain effectively
stopped getting new commits.

ensure_repo_local now self-heals at tick start:

  1. Detect dirty tracked-file diff (staged or unstaged).
  2. If dirty: log the file list, `git add -A` + commit with
     subject "recovery: auto-commit leftover changes from prior
     tick", try to push.
  3. Pull normally. Recovery commit is now on top of origin (or
     gets rebased onto origin if origin moved).

Trade-off: the recovery commit preserves whatever partial state
the prior tick left behind. If that state was "the :wq idea got
removed but the post never shipped," the idea stays removed --
no re-drafting on the next tick. Manual restore is possible by
reverting the recovery commit or re-adding the idea to
blog-ideas.md. Accepting partial-state preservation is the lesser
evil vs. silent rot for hours.

Untracked files don't trigger the detection (they don't block
git pull --rebase). The recovery `git add -A` does sweep them
up if a tracked-file diff already triggered, so any orphaned
scratch files in brain get committed alongside the real changes.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

joshtronic added 1 commit

2026-05-22 17:13:12 +00:00