Skip to content

Block tracked Humanize loop state from entering git history#86

Merged
SihaoLiu merged 2 commits intoPolyArch:devfrom
xyyy1420:dev
Apr 16, 2026
Merged

Block tracked Humanize loop state from entering git history#86
SihaoLiu merged 2 commits intoPolyArch:devfrom
xyyy1420:dev

Conversation

@xyyy1420
Copy link
Copy Markdown

Summary

Add a second layer of protection so local Humanize loop state cannot silently enter git history.

This keeps the existing git add command blocking, and adds a stop-gate audit that fails fast when .humanize/ or legacy .humanize-* state has already been tracked or staged.

What changed

  • add a dedicated stop-hook check for tracked or staged Humanize loop state
  • add a dedicated block message for tracked Humanize state
  • tighten the generic git-dirty guidance so RLCR no longer recommends git add -A
  • extend the git add protection tests to cover RLCR tracker and round artifact paths
  • extend the stop-gate tests to verify tracked Humanize state blocks with a dedicated reason

Why

This change is motivated by a real RLCR failure mode:

  • a local loop artifact can be force-added into the git index
  • once that happens, later review rounds can start treating RLCR state files as ordinary tracked changes
  • that shifts review attention away from the actual branch work and creates repeated review churn around tracker and round-artifact files

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:

  • block direct git add .humanize
  • block broad git add -A / git add . patterns when local loop state exists

That still left a gap:

  • if .humanize state was force-added or otherwise entered the index, the stop gate only saw a generic dirty tree
  • it did not fail with a specific “local loop state is tracked” reason

This patch closes that gap.

Behavior after this change

  • untracked local loop state remains allowed
  • direct or broad git add commands that would include .humanize/ are still blocked
  • if .humanize/ or legacy .humanize-* has already entered tracking or the index, the stop gate blocks with a dedicated remediation message

Validation

  • bash tests/test-humanize-escape.sh
  • bash tests/test-stop-gate.sh

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread hooks/lib/loop-common.sh Outdated
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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Narrow tracked-state match to loop artifacts only

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
Copy link
Copy Markdown
Contributor

@codex please review this PR

@chatgpt-codex-connector
Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Chef's kiss.

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Copy link
Copy Markdown
Contributor

@SihaoLiu SihaoLiu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@SihaoLiu SihaoLiu merged commit 0f025cb into PolyArch:dev Apr 16, 2026
5 of 6 checks passed
@SihaoLiu SihaoLiu mentioned this pull request Apr 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants