fix(quickfiler): rename the EFC banner-rejection prefix and correct the stale SelectedFolder comment (#662)

[drmoisan]

Summary

Resolves the banner-prefix arity divergence and the stale SelectedFolder comment described in issue #662.

Three BannerPrefix constants existed under one name carrying two different values: EfcSelectionGuard declared a three-character "===", while both row producers (BreadcrumbRowBuilder and FolderSuggestionTree) declared a four-character "====". After this change there are two declarations rather than three: one producer constant shared by both producers, and one deliberately broader classifier constant that is renamed, documented, and test-pinned as broader.

This is a consistency and comment-accuracy fix. It is explicitly not a behavioural repair, and no predicate's return value changes for any input.

The direction this fix deliberately does not take

The issue reads as though the two arities should be unified upward to four characters. That reading is wrong and would be a behavioural regression, so it is worth stating plainly for reviewers:

• EfcFormController.IsBannerRow classifies by the producers' four-character constant, so IsBannerRow("===") is false.
• IsValidCreationSelection tests value.Length >= MinimumCreationLength, and MinimumCreationLength is 3, so for the input "===" that comparison is 3 >= 3 and the length rule rejects nothing.
• The guard's three-character prefix is therefore the only mechanism rejecting a three-equals row at either EFC classification site.

Widening the guard to "====" would make IsValidFilingSelection("===") and IsSelectableFolder("===") both return true. The guard's value is unchanged; only its name and its documentation change.

One detail is worth flagging because it is the kind of thing a future reviewer would get wrong. In the pre-existing merged test IsSelectableFolder_AndIsBannerRow_ClassifyThreeAndFourEqualsRowsIdentically, the assertion that reads like the consistency guard — creationPath.Should().Be(filingPath) — still passes under the prohibited widening edit, because both sides become true together. Only the sibling creationPath.Should().BeFalse(...) line catches the relaxation. This was verified directly against the dispatch path rather than inferred.

Reachability

The underlying defect is latent, not live. No producer emits a three-character row today, so no user-visible misbehaviour was reachable before this change, and none is fixed by it. The cost was entirely to the next maintainer: the inaccurate comment invited a contributor to "correct" the guard in the dangerous direction. This PR is therefore a maintainability change, and it should be weighted as one.

What changed

Four files, 57 insertions and 9 deletions:

File	Change
QuickFiler/Controllers/EfcSelectionGuard.cs	Constant renamed to BannerRejectionPrefix, value unchanged; both StartsWith call sites updated; XML doc rewritten to state that it is deliberately a proper prefix of the producers' constant and must not be widened
QuickFiler/Controllers/EfcFormController.cs	SelectedFolder comment replaced so it describes the composition the code implements. Comment-only; no executable line changed
UtilitiesCS/OutlookObjects/Folder/FolderSuggestionTree.cs	Duplicate constant deleted; its single reader now references BreadcrumbRowBuilder.BannerPrefix directly
QuickFiler.Test/Controllers/EfcSelectionGuardTests.cs	One [TestMethod] added, pinning that both arities are rejected on both predicates, with a because message naming the prohibited direction

The constant is deleted rather than re-aliased because an aliasing declaration would still match the declaration inventory and defeat the criterion it is meant to satisfy.

Verification

All ten acceptance criteria pass and are checked off in issue.md. Feature review reports zero blocking findings across the policy audit, code review, and feature audit.

• Toolchain clean in one pass in order, using the exact CLAUDE.md commands with /t:Rebuild and without /p:Nullable=enable.
• Tests: 6070 passed, 0 failed. QuickFiler.Test moved 1286 to 1287 passed, the single added test; UtilitiesCS.Test unchanged at 4783.
• Coverage: 85.3741% line, 79.3761% branch, both above the repository floors. Changed-code coverage is 3/3 statements.
• Counters above were read from the TRX <Counters/> elements in the committed evidence rather than from console summaries.

Defects found and handled during delivery

1. Stale diff anchor in three plan gates. The plan pinned a base SHA that is an ancestor of both this branch and origin/main, so the two-dot git diff form those gates use reported everything origin/main had accumulated since that commit alongside this branch's own work. Measured before any edit existed, the scope gate returned 22 paths against an asserted union of 4. The anchor was replaced with git merge-base origin/main HEAD, resolved at run time; the same gate then returns empty pre-edit.

2. Committed TRX evidence was not well-formed XML. The artifact-hygiene sweep substitutes angle-bracket placeholders, and vstest writes those redacted values into XML attribute values, where a raw angle bracket is illegal. All six committed TRX files failed to parse. They were repaired by escaping the placeholders, which leaves the redaction identical and restores parseability. The hygiene gate did not catch this because it asserts only that host identifiers were removed, never that the rewritten file still parses.

Note on the generated PR-context bundle

Two fields in artifacts/pr_context.summary.txt are wrong and were not relied on:

• It reports "GitHub CLI unavailable: GitHub CLI (gh) is not installed." The CLI is installed and authenticated; this was verified directly.
• Its author-asserted auto-close list contains #465, #498, #662 and #ISO-8601. #ISO-8601 is not an issue number at all but a token scraped from evidence-convention prose, and #465 and #498 are unrelated issues cited as precedent in the requirements, both already closed. Each was checked individually with gh. Only #662 is in scope for this PR.

Base, head, and merge-base in the bundle were correct.

Follow-ups recorded, not filed

This item carries footprint acceptance criteria restricting the branch diff, so no follow-up issue was opened from this branch. These are recorded in the audit artifacts for consolidated filing after merge:

1. The acceptance-criterion text for AC5b and AC7 still quotes the stale anchor SHA. Both commands return empty today, but only because origin/main has not touched either protected file since that commit.
2. The artifact-hygiene rule should escape its placeholders for XML targets, and should assert that rewritten XML still parses.
3. The hygiene sweep excludes the plan file from its own residual scan.
4. FolderSuggestionTree.IsBanner's doc comment still hard-codes the four-character literal rather than naming the constant.
5. EfcFormController.cs is 1189 lines and at 25.5% line coverage. Pre-existing, unchanged by this PR, and inside the ratified Outlook Interop exemption class; recorded as a FAIL row in the audit rather than silently passed.
6. The committed Cobertura and TRX evidence adds substantial volume to history. Unlike a prior item, these files are committed and retained, so there is no unreachable-blob concern and squash-merge is not a remedy. This one is merge-method-dependent and is stated as such.

GitHub Auto-close

• Closes Bug: efcselectionguard-banner-prefix-arity-and-stale-comment #662

Emitted from the author-asserted autoclose list after verifying the number directly with gh. The other three tokens on that list were checked and rejected as described above.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ATYLDoRLKXS5sgAzegW7ZL