The deletion policy moves in-repo deletions into .AGENTTRASH/ beside the item, and .gitignore:25 declares it ignored. But 37 retired payloads were committed before
that rule existed, and gitignore never applies to already-tracked paths.
Measured on Dankserver today: the deploy checkout reported 37 tracked deletions —
exactly every tracked trash file in the repo, because the approved purger
(scripts/purge-agenttrash.sh) had done its job. So any host that purges is
permanently dirty, and the next pull that touches one of those paths aborts mid-deploy
with "Your local changes to the following files would be overwritten by merge" — on a
tree that contains no real edits at all. scripts/deploy.sh:116 is a blanket git status --porcelain guard, so phantom dirt is a deploy-blocking condition.
Change
git rm -r --cached the four trash dirs (.AGENTTRASH/, dankserver/, scripts/, tests/ — 37 files, ~300 KB). The bytes stay on disk and stay in history; the trash was
always a temporary hold, and git is the archive. After the ignore rule takes effect a
purge can no longer dirty a checkout on any host.
Nothing else needed: tests/deployment_scoping.bats asserts the staged chat template exists on disk, and it still does — the seam is untouched.
Verification
Worktree after the change: 37 trash files still present on disk, git status clean.
./tests/run.sh on this branch: reported below.
Host state repaired independently and already live: Dankserver's 37 phantom
deletions were restored from git (dirty=0), so tonight's media cutover deploy is
unaffected either way.
## Why
The deletion policy moves in-repo deletions into `.AGENTTRASH/` beside the item, and
`.gitignore:25` declares it ignored. But **37 retired payloads were committed before
that rule existed**, and gitignore never applies to already-tracked paths.
Measured on Dankserver today: the deploy checkout reported **37 tracked deletions —
exactly every tracked trash file in the repo**, because the approved purger
(`scripts/purge-agenttrash.sh`) had done its job. So any host that purges is
permanently dirty, and the next pull that touches one of those paths aborts mid-deploy
with *"Your local changes to the following files would be overwritten by merge"* — on a
tree that contains no real edits at all. `scripts/deploy.sh:116` is a blanket
`git status --porcelain` guard, so phantom dirt is a deploy-blocking condition.
## Change
`git rm -r --cached` the four trash dirs (`.AGENTTRASH/`, `dankserver/`, `scripts/`,
`tests/` — 37 files, ~300 KB). The bytes stay on disk and stay in history; the trash was
always a temporary hold, and git is the archive. After the ignore rule takes effect a
purge can no longer dirty a checkout on any host.
Nothing else needed: `tests/deployment_scoping.bats` asserts the staged chat template
**exists on disk**, and it still does — the seam is untouched.
## Verification
- Worktree after the change: 37 trash files still present on disk, `git status` clean.
- `./tests/run.sh` on this branch: reported below.
- Host state repaired independently and already live: Dankserver's 37 phantom
deletions were restored from git (`dirty=0`), so tonight's media cutover deploy is
unaffected either way.
---
cwd: /home/blank/.omp/wt/untrack-trash · session: 2026-10-30T23-38-45-297Z_01a18f2e-18b1-7573-bcd5-ac99636f8bcb
The deletion policy moves in-repo deletions into .AGENTTRASH/ beside the item,
and .gitignore line 25 already declares it ignored. But 37 retired payloads were
committed before that rule existed, and gitignore never applies to tracked paths.
Consequence measured 2026-10-31: Dankserver's deploy checkout reported 37 tracked
deletions — exactly every tracked trash file — because the approved purger had
done its job. Any host that purges is permanently dirty, and a future pull that
touches one of those paths aborts mid-deploy with 'local changes would be
overwritten' while the tree is in fact clean of real edits.
Untrack the four dirs; the bytes stay on disk and in history (they always were
recoverable from git, which is what the trash policy's 'temporary hold, not an
archive' means). tests/deployment_scoping.bats asserts the staged chat template
exists on disk — it still does, so the seam is untouched.
dank
merged commit 1d92627935 into main2026-10-31 18:49:41 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
The deletion policy moves in-repo deletions into
.AGENTTRASH/beside the item, and.gitignore:25declares it ignored. But 37 retired payloads were committed beforethat rule existed, and gitignore never applies to already-tracked paths.
Measured on Dankserver today: the deploy checkout reported 37 tracked deletions —
exactly every tracked trash file in the repo, because the approved purger
(
scripts/purge-agenttrash.sh) had done its job. So any host that purges ispermanently dirty, and the next pull that touches one of those paths aborts mid-deploy
with "Your local changes to the following files would be overwritten by merge" — on a
tree that contains no real edits at all.
scripts/deploy.sh:116is a blanketgit status --porcelainguard, so phantom dirt is a deploy-blocking condition.Change
git rm -r --cachedthe four trash dirs (.AGENTTRASH/,dankserver/,scripts/,tests/— 37 files, ~300 KB). The bytes stay on disk and stay in history; the trash wasalways a temporary hold, and git is the archive. After the ignore rule takes effect a
purge can no longer dirty a checkout on any host.
Nothing else needed:
tests/deployment_scoping.batsasserts the staged chat templateexists on disk, and it still does — the seam is untouched.
Verification
git statusclean../tests/run.shon this branch: reported below.deletions were restored from git (
dirty=0), so tonight's media cutover deploy isunaffected either way.
cwd: /home/blank/.omp/wt/untrack-trash · session: 2026-10-30T23-38-45-297Z_01a18f2e-18b1-7573-bcd5-ac99636f8bcb