gateguard: a parallel batch of edits is partially denied — dependent edits to one file can land without each other

Summary

The Edit/Write first-touch gate evaluates each tool call of a parallel batch independently. When an agent sends several edits to a file it has not touched yet in one batch, the first call is denied and the later ones are allowed (the file is marked as checked by the first denial). Nothing tells the agent that part of its batch already applied, so the file can be left in a state neither version intended.

This is distinct from #2608 (how many denials per session) and from #1946 (the deny-first pattern itself): the problem here is partial application of a batch, which is silent.

Reproduction

1. In a fresh session, send two edits to the same not-yet-touched file in one parallel batch, where the second depends on the first — e.g. edit A adds a module constant, edit B rewrites a function that uses it.
2. Edit A: [Fact-Forcing Gate] … First edit of <file> (denied).
3. Edit B: applied — the file now references a constant that does not exist.
4. The denial of A reads like a retryable formality; B's success result gives no hint that its precondition failed. The inconsistency surfaces only if the agent happens to re-read the file.

Observed with ECC 2.2.1 on Windows (Claude Code desktop), several times across one working day, including batches spanning several files (e.g. five edits over four files: three denied, two applied).

Why it matters

A batch is not atomic under this gate, and partial application is its default failure mode. Independent edits are harmless; dependent ones (a definition and its use, an import and its call site) silently break the file.

Suggested fix

Either or both:

1. Denial message: add one line to the Edit/Write denial, e.g. "Other edits sent in the same batch may already have been applied — re-check this file before building on them."
2. SKILL.md guidance (skills/gateguard): state that a denial in a parallel batch does not deny its siblings; send dependent edits to a not-yet-touched file sequentially, or retry the denied call immediately and re-verify the file.

A stronger option would be to deny every call targeting the same unchecked file within one batch, but hooks see calls one at a time, so the message/guidance route is probably the practical one.

Environment

• ECC 2.2.1 (plugin cache), scripts/hooks/gateguard-fact-force.js — same first-touch logic at main 8321021c5
• Claude Code desktop, Windows 11