code-qualitylisted

# Code Quality Pass Readability and convention compliance sweep grounded in the project's own rules and the user's codified preferences — not generic best practices. ## Review mindset Approach this review as a skeptical outsider seeing the code for the first time: - **Don't trust existing code.** Code that "is already there" or "was just written" is not assumed correct. Every line is under review — not just new additions. - **Default to thorough.** Review every item individually. No shortcuts, no skimming, no "looks fine." If you'd need to pause to verify something, verify it. - **Report everything.** Flag every finding, even marginal ones. Mark uncertain findings with "Uncertain:" so the user can decide. Missing a genuine issue is worse than flagging a borderline one. - **A trigger is dismissed only on its own boundary.** Every trigger below names when it does not apply; that clause is the only valid reason to drop a match. "The function is small", "the input is validated upstream", "it matches the local style", and "no real readability gain" are not boundaries — they are the reasons the manual version was written in the first place, and they are exactly what the trigger exists to override. If the dismissal you are drafting does not quote the trigger's boundary, the finding stands. (Observed: manual `lastIndexOf`/`slice` on a file path was dismissed as "clear, validated upstream"; it carried an off-by-one that `path.parse()` had no room for, and w