[BUG] Couldn't apply config bc it showed I hadn't reviewed all changes

[mgburch]

Please confirm these before moving forward

• I have searched for my issue and have not found a similiar in the Open or Closed issues.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.
• I have checked the Discussions section for solutions.
• This issue is about a bug (if it is not, please use the correct template).

Winhance Version

v26.5.22

Windows version, edition, and architecture

W11 Version 10.0.26200.8457

Describe your issue

Could never apply the config because it said I hadn't reviewed everything. That was reflected in the section summary numbers shown (x/y - x out of y). But I went thru and double checked everything. All (visible) were set to either apply or deny. I believe some items were hidden from view preventing me from selecting apply or deny and completing the review.
I toggled '"Only Changes" view filter' a few times while going thru the config and that could be the issue. I think some items got hidden and couldn't be seen afterwards.

Steps to reproduce the issue

Import recommended configuration
Toggle view only changes in Optimize or Custom sections
Select Apply or Deny on all visible items
Observe the x/y (i.e. 5/7) counts don't reflect all items have been reviewed

Expected behavior

Show all unreviewed items and allow to reach n/n and apply button at top is shown

Actual behavior

x/y is x less than y but all visible item review buttons (apply deny radio button) selected so further review isn't possible. therefor config cannot be applied

Screenshots or Logs (if applicable)

No response

Additional context

No response

[memory-agent]

Hey @mgburch,

Good catch — your hypothesis was right on. The "Only Changes" filter was deciding row-by-row visibility from a per-item flag that gets set up lazily as you navigate into each section, while the reviewed-count was reading the eager full list. When the two got out of sync (toggling the filter before all sub-pages had been visited was the easiest way to hit it), some unreviewed items got hidden from view — so the counter stayed below n/n with no way to reach them.

The filter now reads from the same source as the counter and the Apply button, so they can't disagree anymore. A regression test enforces it at the code level too, so this whole shape of bug should stay fixed.

This fix is in the development branch (3ff6c23) and will be available for testing in Release 27.

Thanks for reporting!

Drafted and approved by @memstechtips - Sent by Memory's Agent