fix(gate): let the gate see a file git has never seen #352

Merged

coilyco-ops merged 2 commits from fix/gate-sees-a-new-file into main

2026-08-13 10:53:15 +00:00

coilyco-ops commented

2026-08-13 10:50:22 +00:00

Member

closes #343

I filed this with the wrong cause, and the right one is worse

I wrote that pre-commit "only sees the staged set". That is not it. The gate already runs --all-files, and several hooks enumerate git's own file list rather than the paths pre-commit hands them — so --all-files means every tracked file, and --files changes nothing for them.

Measured, not assumed:

unstaged, --all-files:        code comment discipline .......... Passed
intent-to-add, --all-files:   2 code comment violation(s)

Same file, same content, same hook. The only difference is whether git knows the path exists.

Why this is the case that mattered most

A new file is the most likely thing in a change to carry a fresh violation, and it was the one thing the gate silently did not check. AGENTS.md promises the gate closes the gap that vet and test leave. It did, except for new files.

The fix

Every untracked, non-ignored file is marked with git add --intent-to-add before the hooks run. Intent only — no content is staged.

The marks come off however the run exits. The failure exit is the one that matters: a red gate that left the index rearranged would be a worse problem than the one being fixed, so removal is a trap, not a line after the check.

Demonstrated, both halves

With a violating untracked file present:

pre-commit     FAIL
FAIL: internal/community/gateprobe_scratch.go:5: comment block of 3 lines...
=== index restored?
?? internal/community/gateprobe_scratch.go

It fails by name, and the file is still untracked after the failure exit.

Cost

real 15.37 before, real 14.55 after — noise. The work is per-file and the file count barely moves. That was the acceptance criterion I wrote on the issue, so it gets a number rather than an assurance.

ward exec gate green: build, policy-check, vet, test, test-skips, pre-commit.

closes #343 ## I filed this with the wrong cause, and the right one is worse I wrote that pre-commit "only sees the staged set". That is not it. The gate already runs `--all-files`, and several hooks **enumerate git's own file list** rather than the paths pre-commit hands them — so `--all-files` means every *tracked* file, and `--files` changes nothing for them. Measured, not assumed: ``` unstaged, --all-files: code comment discipline .......... Passed intent-to-add, --all-files: 2 code comment violation(s) ``` Same file, same content, same hook. The only difference is whether git knows the path exists. ## Why this is the case that mattered most A new file is the most likely thing in a change to carry a fresh violation, and it was the one thing the gate silently did not check. `AGENTS.md` promises the gate closes the gap that `vet` and `test` leave. It did, except for new files. ## The fix Every untracked, non-ignored file is marked with `git add --intent-to-add` before the hooks run. **Intent only** — no content is staged. The marks come off however the run exits. The failure exit is the one that matters: a red gate that left the index rearranged would be a worse problem than the one being fixed, so removal is a `trap`, not a line after the check. ## Demonstrated, both halves With a violating untracked file present: ``` pre-commit FAIL FAIL: internal/community/gateprobe_scratch.go:5: comment block of 3 lines... === index restored? ?? internal/community/gateprobe_scratch.go ``` It fails by name, and the file is still untracked after the failure exit. ## Cost `real 15.37` before, `real 14.55` after — noise. The work is per-file and the file count barely moves. That was the acceptance criterion I wrote on the issue, so it gets a number rather than an assurance. `ward exec gate` green: build, policy-check, vet, test, test-skips, pre-commit.

coilyco-ops added 1 commit

2026-08-13 10:50:22 +00:00

fix(gate): let the gate see a file git has never seen

ci / test (pull_request) Successful in 29s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

ci / image-build (pull_request) Successful in 16s

Details

1b6fa9b238

The gate reported every stage green on a tree whose commit then failed on a
new test file. The cause is not the staged set, which is what I assumed when
filing it: several hooks enumerate git's own file list rather than the paths
pre-commit hands them, so --all-files means every tracked file and --files
changes nothing for them. A file that has never been added is invisible.

That is the case the gate most needed to cover. A new file is the most likely
thing in a change to carry a fresh violation, and it was the one thing the
gate silently did not check.

Every untracked, non-ignored file is now marked with git add --intent-to-add
before the hooks run. Intent only, so no content is staged, and the marks come
off however the run exits. The failure exit is the one that matters, since a
red gate that leaves the index rearranged would be a worse problem than the
one being fixed, and that path is a trap rather than a line after the check.

Both halves are demonstrated rather than argued. With a violating untracked
file present, the gate now fails on it by name and the file is still untracked
afterwards. The hook pass takes the same time as before, because the work is
per-file and the file count barely moves.

closes #343

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-13 10:50:22 +00:00

coilyco-ops referenced this pull request

2026-08-13 10:50:47 +00:00

ward exec gate passes on an untracked file that pre-commit rejects #343

coilyco-ops added 1 commit

2026-08-13 10:52:14 +00:00

Merge branch 'main' into fix/gate-sees-a-new-file

ci / test (pull_request) Successful in 30s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details