bin/px-feed-snapshot runs from cron every 30 min on the Pi, inside the live working repo, and commits + rebases + pushes.
Correction to the initial framing: it does not do a blanket git add . — line 20 is already path-scoped (git add site/data/feed.json). The hazard is one step later.
Actual defects
git commit with no pathspec (bin/px-feed-snapshot:21) commits everything already in the index, not just the file it staged. Any other agent or human with staged-but-uncommitted work on the Pi gets it silently swept into a data: update feed snapshot commit — and then pushed.git pull --rebase against a dirty working tree (line 24) will fail or, worse, interact badly with someone else's in-progress work. The rebase --abort on failure is a partial mitigation but the commit from step 1 has already happened.git push ... || true (line 30) swallows all push failures, so a repo left in a bad state after a failed rebase is invisible.
Wanted
- Commit only its own file:
git commit -m ... -- site/data/feed.json (or use a temp index / git commit-tree).
- Refuse to run when the working tree or index is unexpectedly dirty outside
site/data/feed.json; log and exit non-zero rather than proceeding.
- Report push/rebase failure into
state/health/ so a wedged snapshot job is visible via read_health() rather than only in cron mail.
Why this is higher priority than it looks
Every other agent workflow on the Pi shares this working tree. A background job that can capture and push another process's staged work is a repo-integrity hazard, not a cosmetic one.
bin/px-feed-snapshotruns from cron every 30 min on the Pi, inside the live working repo, and commits + rebases + pushes.Correction to the initial framing: it does not do a blanket
git add .— line 20 is already path-scoped (git add site/data/feed.json). The hazard is one step later.Actual defects
git commitwith no pathspec (bin/px-feed-snapshot:21) commits everything already in the index, not just the file it staged. Any other agent or human with staged-but-uncommitted work on the Pi gets it silently swept into adata: update feed snapshotcommit — and then pushed.git pull --rebaseagainst a dirty working tree (line 24) will fail or, worse, interact badly with someone else's in-progress work. Therebase --aborton failure is a partial mitigation but the commit from step 1 has already happened.git push ... || true(line 30) swallows all push failures, so a repo left in a bad state after a failed rebase is invisible.Wanted
git commit -m ... -- site/data/feed.json(or use a temp index /git commit-tree).site/data/feed.json; log and exit non-zero rather than proceeding.state/health/so a wedged snapshot job is visible viaread_health()rather than only in cron mail.Why this is higher priority than it looks
Every other agent workflow on the Pi shares this working tree. A background job that can capture and push another process's staged work is a repo-integrity hazard, not a cosmetic one.