well that seems funny indeed because --debug-mode=1 tells to output the rules which found a password
i did some fast research and the only thing/rule i found was
Title w/Nth separator
3NX
Upper case the letter after the Nth instance of a char
see rule based attack, section Implemented specific functions https://hashcat.net/wiki/doku.php?id=rule_based_attack
so what i think happened here, hashcat works on byte size when attacking, thats for example the reason why you need a mask of size 3 to bruteforce the € sign, because its hex representation is €:e282ac given this info lets review this rule/hexrepresentation (i splitted it for better understanding)
4f3433 20 5b 20 33ff41
4F3433 = O43
20 = [SPACE]
B5 = [
now to the interesting part
33 ff 41
33 = 3 (see mentioned rule above)
FF = ÿ (according to the rule this is a counter 0-9, A-Z, so there seems to be the problem)
41 = A (the splitter) -> BUT
FF isnt a valid counter, a single F is so the "real" rule schould be something like 3F F41 (ô) or 0F41 (A) as seperator sign but im not quite sure that this is a rule which would be generated by hascat (this could be the case if hashcat uses your given wordlist as input for separator signs but i dont know whether this is the fact) see EDIT 2: for this.
this is a real nice finding, but need further investigation, i will try to reproduce this by just generating rules with standalone rules_generator hoping it uses the same generator engine like hashcat and looking for these specific 3NX rules
EDIT:
did you copied this rule from stats.txt into a rulefile or did you used stats.txt as rulefile and hashcat tells you "irregular rule detected"?
in the meantime maybe a dev takes a look at this thread, keep calm
EDIT 2:
can you reproduce this with setting --debug-mode=4 and share a specific entry?
i assume that there are some non plain ascii but UTF-8 chars inside your dict which are the reason and resulting in this behavior
i did some fast research and the only thing/rule i found was
Title w/Nth separator
3NX
Upper case the letter after the Nth instance of a char
see rule based attack, section Implemented specific functions https://hashcat.net/wiki/doku.php?id=rule_based_attack
so what i think happened here, hashcat works on byte size when attacking, thats for example the reason why you need a mask of size 3 to bruteforce the € sign, because its hex representation is €:e282ac given this info lets review this rule/hexrepresentation (i splitted it for better understanding)
4f3433 20 5b 20 33ff41
4F3433 = O43
20 = [SPACE]
B5 = [
now to the interesting part
33 ff 41
33 = 3 (see mentioned rule above)
FF = ÿ (according to the rule this is a counter 0-9, A-Z, so there seems to be the problem)
41 = A (the splitter) -> BUT
FF isnt a valid counter, a single F is so the "real" rule schould be something like 3F F41 (ô) or 0F41 (A) as seperator sign but im not quite sure that this is a rule which would be generated by hascat (this could be the case if hashcat uses your given wordlist as input for separator signs but i dont know whether this is the fact) see EDIT 2: for this.
this is a real nice finding, but need further investigation, i will try to reproduce this by just generating rules with standalone rules_generator hoping it uses the same generator engine like hashcat and looking for these specific 3NX rules
EDIT:
did you copied this rule from stats.txt into a rulefile or did you used stats.txt as rulefile and hashcat tells you "irregular rule detected"?
in the meantime maybe a dev takes a look at this thread, keep calm
EDIT 2:
can you reproduce this with setting --debug-mode=4 and share a specific entry?
i assume that there are some non plain ascii but UTF-8 chars inside your dict which are the reason and resulting in this behavior