chore: ignore macOS Finder metadata — and make the guard it broke read git instead of the filesystem

[beyondnetPeru]

Three .DS_Store files were sitting untracked in the root, src/ and src/packages/. None was tracked by git, so nothing leaves history — deleted from the working tree, pattern added to .gitignore.

The root one is what made 03-validate-root-cleanliness exit 1 locally throughout the GT-622 / GT-656 / GT-657 work, showing up as the single non-zero command in 41-validate-evidence-commands --execute. CI checks out fresh and never saw it.

Verified rather than assumed: with the rule in place, planting a .DS_Store in the root and in src/ leaves git status --porcelain with 0 entries.

Known, and deliberately not fixed here

03-validate-root-cleanliness reads the filesystem, not git — measured by planting a .DS_Store after adding the ignore rule, where the guard still exits 1. So deleting is not durable: the next Finder window recreates the file and the guard goes red again on someone's laptop.

The durable fix is to have the guard skip entries git ignores — a gitignored file is by definition not in the repository, so it is not what "root cleanliness" governs. That is a change to a CI guard with its own fixture and classification requirements, so it is left as a separate decision rather than folded into a chore.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[github-actions]

📊 Bilingual Coverage Impact

PR Changes

• Paired EN/ES files modified: 3
• New EN files needing ES translation: 0

Repository Coverage

Metric	Value
Total EN files	527
Total ES files	501
Paired files	0
Coverage	0%

✅ Good: All EN changes have ES counterparts.

---

Generated by GitHub Actions

[beyondnetPeru]

Follow-up: the durable half is now in

The PR body said deleting was not durable and left the guard fix as a separate decision. It is now in this branch.

03-validate-root-cleanliness read the filesystem, not git — so the ignore rule alone changed nothing, measured by planting a .DS_Store after adding it. A guard that is red for a reason no commit can fix is the failure mode GT-622 was opened to remove.

What git ignores is by definition not in the repository, so it is not what "root cleanliness" governs. Ignored entries are skipped.

Both directions observed, not argued:

planted	verdict
.DS_Store	exit 0 — "35 read, 2 ignored by git, 33 checked against the taxonomy"
unauthorized file	exit 1, named in the failure list
unauthorized directory	exit 1, named in the failure list

The taxonomy is not weakened: every file a commit could actually introduce is still checked.

Two paranoia rules, because this set subtracts from what is checked and a bogus answer would hollow the guard out silently:

• git check-ignore exit 128 (no git, not a work tree) falls back to the empty set — every entry stays under the taxonomy — and warns rather than degrading quietly. The failure of an optional query must never widen what a guard forgives.
• An answer claiming package.json, .github or .harness is ignored stops the run. Those are tracked by construction, so such an answer is a broken query, not an unusual repository.

The pass line now reports read / ignored / checked separately, so the denominator that matters is visible instead of implied.

Guards 03, 39, 40, 42 and 43 exit 0.

🤖 Generated with Claude Code