Uh oh!
There was an error while loading. Please reload this page.
Block tracked Humanize loop state from entering git history - #86
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:a9078aaf4d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if git -C "$project_root" ls-files --error-unmatch .humanize >/dev/null 2>&1; then | ||
| return 0 | ||
| fi | ||
| if git -C "$project_root" ls-files '.humanize/*' '.humanize-*' | grep -q '.'; then |
There was a problem hiding this comment.
The new tracked-state check now treats any top-level .humanize-* path as loop state, which causes false blocks for legitimate files like .humanize-backup that are explicitly allowed elsewhere (see tests/test-humanize-escape.sh allow-case). In an active loop, a repo that intentionally tracks such a file will now be blocked on every stop attempt with “Tracked Humanize State Blocked,” even when there are no RLCR artifacts, forcing removal of unrelated tracked files to proceed.
Useful? React with 👍 / 👎.
The tracked-state check used '.humanize-*' globs which matched unrelated dot-prefixed files the command-side guard already allows (for example .humanize-backup and .humanizeconfig, per tests/test-humanize-escape.sh). In an active loop, a repo that intentionally tracked such a file was incorrectly blocked with "Tracked Humanize State Blocked" even with no RLCR artifacts present. Scope the detection to .humanize/ via a single ls-files pathspec. This stays consistent with git_adds_humanize, correctly omits paths the user has staged for removal via git rm --cached, and drops the redundant diff --cached probe. Update the block message (inline fallback and prompt template) to drop the dangerous "git rm --cached -r .humanize-*" hint, which could strip user files like .humanize-backup from the index. Add a stop-gate regression test asserting that tracked .humanize-backup and .humanizeconfig do not trigger the tracked-state block reason.
SihaoLiu
commented
Apr 16, 2026
@codex please review this PR |
Codex Review: Didn't find any major issues. Chef's kiss. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Uh oh!
There was an error while loading. Please reload this page.
Summary
Add a second layer of protection so local Humanize loop state cannot silently enter git history.
This keeps the existing
git addcommand blocking, and adds a stop-gate audit that fails fast when.humanize/or legacy.humanize-*state has already been tracked or staged.What changed
git add -Agit addprotection tests to cover RLCR tracker and round artifact pathsWhy
This change is motivated by a real RLCR failure mode:
In practice, a single mistaken force-add can redirect later review noise toward local RLCR artifacts such as the goal tracker, instead of keeping review focused on the real code changes.
The previous protection was mostly command-side:
git add .humanizegit add -A/git add .patterns when local loop state existsThat still left a gap:
.humanizestate was force-added or otherwise entered the index, the stop gate only saw a generic dirty treeThis patch closes that gap.
Behavior after this change
git addcommands that would include.humanize/are still blocked.humanize/or legacy.humanize-*has already entered tracking or the index, the stop gate blocks with a dedicated remediation messageValidation
bash tests/test-humanize-escape.shbash tests/test-stop-gate.sh