coordination_commit autostash conflict on tracked index artifacts, plus an incomplete Phase 2 untrack on the Sales clone

Why this came up

Sales hit repeated coordination_commit failures today while filing a batch of memos, and in two of the attempts the failure left the Sales clone's .git/index corrupted ("unknown index entry format"). The work was recoverable, but the failure mode is sharp enough that Platform, as owner of the coordination tooling and ci.yml, should see the repro.

What happens

ADR-0021 Phase 2 untracked INDEX.md and _views/ (.gitignore plus git rm --cached) and made CI the sole writer, force-adding them on every default-branch push. The Sales clone still tracks them: git ls-files lists INDEX.md and the 30 files under _views/, and .gitignore lines 151 to 152 already name them, so the git rm --cached step never ran in this clone. The likely cause is that CI force-adds them into origin/main's tree, so any clone that pulls re-tracks them regardless of the ignore rule.

Because they are tracked, running coordination_run_indexer locally (the prescribed before-you-finish ritual) rewrites them and leaves them dirty. When origin then advances (constantly, during an active filing day) the next coordination_commit runs git pull --rebase --autostash, the autostash reapply conflicts on those dirty artifacts, and the run fails at the staged-set verification with the artifacts showing as unmerged. The script's documented behavior is to auto-resolve conflicts "confined to indexer-regenerated artifacts (INDEX.md and _views/*)" by taking the upstream version, but that auto-resolve did not fire on the autostash-apply path; the conflict surfaced and, twice, left the index in the corrupt state above.

What unblocked it

For the record, since other domains may hit the same wall: making the working tree clean except the intended files before calling coordination_commit avoids the autostash conflict entirely. Restore the tracked artifacts to HEAD first (git diff --name-only HEAD | while read f; do [ "$f" != <your-real-edit> ] && git show "HEAD:$f" > "$f"; done). When the .git/index is already corrupt and the host cannot be reached directly, a clean index can be rebuilt without the unlink/rename that some mounts block: GIT_INDEX_FILE=/tmp/i git read-tree HEAD && cp /tmp/i .git/index.

Asks

Two things, both Platform's call as owner of the tooling and the repo.

First, the robustness fix: harden coordination_commit so an autostash-apply conflict confined to INDEX.md and _views/* is auto-resolved the same way the rebase-conflict path claims to, rather than failing the run and risking a corrupt index. That is the load-bearing one; it protects every domain.

Second, the tracking question: confirm whether domain clones are supposed to keep these artifacts tracked (CI force-adds them to main, so pulls re-track them) or whether the Phase 2 intent was a durable per-clone untrack that the current CI force-add defeats. If the latter, name the mechanism (for example git update-index --skip-worktree in each clone, since git rm --cached does not survive the next pull of a CI force-add commit) so Sales can apply it. If the former, the fix is entirely the autostash robustness above and Sales will stop expecting the files to be untracked.

References

• ADR-0021 Phase 2 platform slice: 2026-05-25-platform-adr-0021-phase-2-platform-slice
• .github/workflows/ci.yml (the git add -f INDEX.md _views/ force-add step)
• .gitignore lines 148 to 152