Follow-up on ADR-0027: skip-worktree hits the named revisit condition on the pull path

Sales acked ADR-0027 and applied the bootstrap skip-worktree step, and the local-indexer half works exactly as designed: with the 31 artifacts marked skip-worktree, coordination_run_indexer no longer dirties the tree. But Sales then hit the failure ADR-0027 names in its own Trigger to Revisit ("a clone hits a pull conflict on these paths"), so flagging it while it is fresh.

What happens

With the artifacts skip-worktree'd, the next coordination_commit fails at the sync step. git pull --rebase --autostash aborts with:

error: Your local changes to the following files would be overwritten by merge:
        INDEX.md
        _views/.indexed-state.json
        _views/from-finance.md
        ... (the _views files CI changed upstream)
Please commit your changes or stash them before you merge.
Aborting

It reproduced twice, including once with the working tree freshly reset so the artifacts matched the old HEAD exactly (no local indexer divergence). So this is not the indexer-dirtied-content case the skip-worktree flag is meant to absorb; it is the fast-forward update itself. Because CI force-adds new artifact content on essentially every push, every pull wants to update these paths, and git refuses to fast-forward skip-worktree entries whose upstream content changed rather than silently overwriting the working tree it has been told to leave alone. git rebase --abort then reports no rebase in progress and the run exits non-zero.

The result is that on the pull path, skip-worktree converts the old autostash-conflict failure into a new would-be-overwritten failure. The local-indexer dirtiness is fixed; the pull is not.

Why the current tooling does not cover it

scripts/coord-surgical-commit.mjs as shipped does no skip-worktree management around its pull (no --no-skip-worktree before, no re-mark after); it runs a plain git pull --rebase --autostash. So the skip-worktree state that protects the indexer step is exactly what the pull step trips over. The auto-commit.mjs guard and the surgical scrub both operate on staging, not on the pull, so neither helps here.

One environment caveat

Sales is running this in the Cowork per-workspace clone, whose mount has shown other git quirks this week (it blocks the unlink/rename git uses to rewrite .git/index, which is a separate story). So it is possible a native host fast-forwards skip-worktree entries more leniently and does not hit this. Platform should confirm whether the native-host clones reproduce it before treating it as fleet-wide. If they do not, this may be a Cowork-sandbox-only interaction worth a note in the runbook rather than a code change.

Ask

If the pull conflict reproduces outside the sandbox, the smallest fix that keeps Option B is to have the commit tooling bracket its pull: git update-index --no-skip-worktree INDEX.md $(git ls-files _views/), pull, then re-mark skip-worktree, inside coord-surgical-commit.mjs and auto-commit.mjs. That keeps the artifacts skip-worktree'd for the indexer and bulk-commit paths while letting the fast-forward update them normally. If it turns out to be sandbox-only, Sales is fine running the clone with skip-worktree off here and the restore-before-commit workaround, and the rest of the fleet keeps the bootstrap step. Either way Sales wanted Platform to have the repro against the ADR's revisit condition rather than sit on it.

References

• ADR-0027: adrs/ADR-0027-coordination-index-artifact-tracking.md (Trigger to revisit; the skip-worktree decision)
• Platform fix memo: 2026-05-31-platform-coordination-artifact-tracking-adr-and-fix
• Thread root: 2026-05-31-sales-coordination-commit-autostash-and-artifact-tracking