Summary
QuickFiler/Controllers/EfcSelectionGuard.cs declares BannerPrefix as three = characters while both row producers emit four, making it a third arity variant; and the code comment near QuickFiler/Controllers/EfcFormController.cs:325 describes a four-character rejection that the guard does not implement.
Environment
- OS/version: Windows 11 Pro 10.0.26200
- Framework: .NET Framework 4.8 / VSTO Outlook add-in
- Command/flags used:
msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU"
- Data source or fixture:
QuickFiler.Test
Steps to Reproduce
- Read
QuickFiler/Controllers/EfcSelectionGuard.cs and observe BannerPrefix is "===" (three characters).
- Read
UtilitiesCS/OutlookObjects/Folder/BreadcrumbRowBuilder.cs:19 and UtilitiesCS/OutlookObjects/Folder/FolderSuggestionTree.cs:16 and observe both producers use four characters.
- Read the comment near
QuickFiler/Controllers/EfcFormController.cs:325 and observe it describes a four-character rejection.
Expected Behavior
One prefix arity is used consistently by producers and classifiers, and the code comment describes what the code actually does.
Actual Behavior
Three arities coexist across the classification sites, and the comment describes behavior the guard does not implement. No user-visible misbehavior is currently reachable, because no producer emits a three-character row - the defect is latent, and the comment is actively misleading to the next reader.
Logs / Screenshots
Impact / Severity
Latent rather than live. Severity is low for users and moderate for maintainers: the divergence is exactly the condition that produced issue #465 D, and the inaccurate comment invites a future contributor to 'correct' the guard in the dangerous direction.
Source
From: docs/features/potential/2026-08-27-efcselectionguard-banner-prefix-arity-and-stale-comment.md
Summary
QuickFiler/Controllers/EfcSelectionGuard.csdeclaresBannerPrefixas three=characters while both row producers emit four, making it a third arity variant; and the code comment nearQuickFiler/Controllers/EfcFormController.cs:325describes a four-character rejection that the guard does not implement.Environment
msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU"QuickFiler.TestSteps to Reproduce
QuickFiler/Controllers/EfcSelectionGuard.csand observeBannerPrefixis"==="(three characters).UtilitiesCS/OutlookObjects/Folder/BreadcrumbRowBuilder.cs:19andUtilitiesCS/OutlookObjects/Folder/FolderSuggestionTree.cs:16and observe both producers use four characters.QuickFiler/Controllers/EfcFormController.cs:325and observe it describes a four-character rejection.Expected Behavior
One prefix arity is used consistently by producers and classifiers, and the code comment describes what the code actually does.
Actual Behavior
Three arities coexist across the classification sites, and the comment describes behavior the guard does not implement. No user-visible misbehavior is currently reachable, because no producer emits a three-character row - the defect is latent, and the comment is actively misleading to the next reader.
Logs / Screenshots
EfcSelectionGuard.csprivate const string BannerPrefix = "==="tested withStartsWith(BannerPrefix, StringComparison.Ordinal), against producers declaring a four-character prefix.Impact / Severity
Latent rather than live. Severity is low for users and moderate for maintainers: the divergence is exactly the condition that produced issue #465 D, and the inaccurate comment invites a future contributor to 'correct' the guard in the dangerous direction.
Source
From: docs/features/potential/2026-08-27-efcselectionguard-banner-prefix-arity-and-stale-comment.md