No apology necessary. Were all just trying to help others here the best we can given our current situations. The same happens to me relatively often, because I often take a long time typing my replies, when they get posted to the forum, there may already be 2 other replies since the last one I saw. 🙂
I am also using 2024.3.4 right now, so there is something you can check out. In an empty iLogic rule, within the iLogic rule editor, just type in a single dot (.), with nothing in front of it, then pay attention to the small icons at the bottom of that Intellisense pop-up. You will usually see 3 of them...one for 'iLogic', one for 'Inventor', and one for 'Standard .NET'. Make sure all three are turned on (highlighted) (see image below).

As for not knowing where to put that extension method...I should have stayed with the original poster's example scenario, and placed it within an external iLogic rule. However, since I was just doing quickie local testing, I created both rules within 'internal' (saved within a document) rules, within the same Document. So, my extension module within one local rule (with 'Straight VB Code' option turned on), and the rule using that module was in another local rule, both within the same document. This is most likely a pretty rare way to do things. When both rules are within the same document, we can use the 'AddVbRule' line in the rule's header, and just specify the name of the other rule. However, in most normal situations, helper Classes and helper Modules are stored within 'external' iLogic rules, with the rule option named "Straight VB Code" turned on, and most other rule options turned off, then within the rule(s) that are referencing/using those Classes/Modules, the Header line starts with 'AddVbFile', followed by not only the name of the external rule, but also its file extension. I think this is because of there being 3 possible file extensions for external rules, to make it easier for it to find the correct file, and avoid duplicate files with different file extensions type issues. Most of my external resources used that way are Classes, instead of Modules, but I do have a couple Modules also, mainly for true 'extension' methods, rather than just regular helper methods.
Edit: Once again, another reply was posted while I was typing, so I didn't see it until I posted my reply. That last reply makes a good point to add here. Using the 'Imports' statements within the header of our rules helps Intellisense recognize stuff also, but is more for allowing shortcut access to deeper objects within an API's object model. The AddReference line is what really adds object recognition of things defined within outside DLL's, but those seem to be difficult to use within external rules that are set to 'Straight VB Code' like this, for some reason. Every time I use AddReference lines in the header of those types of rules, it leads to errors when referencing those helper rules later, which leads to be either commenting them out, or deleting them. I can add those AddReference lines in my 'regular' rule (the one referencing/using the helper) just fine though.
Wesley Crihfield

(Not an Autodesk Employee)