IMHO the fact that the tests (which are not random) failed with this exact message AttributeError: 'PokemonType' object has no attribute 'name' in case name was not implemented clearly mean that the thing is tested for, and this should be marked as a Suggestion, not an issue. Btw I now have added 2 more explicit test cases.

1. The constant is labeled ATTACK_MULTIPLIERS so it is consistent that it contains details from an attacking POV. Flying attacks Ground with 1x damage (nothing to specify), while Ground attacks Flying with a 2x damage. This is not always the case that if Type_A does 2x dmg Type_B then Type_B does 0.5x dmg Type_A.
2. Ok, I didn't want to argue on the fact that test should be done properly, but that I've found others approved kata with just 3 or 4 lines of tests (on the samples) and I really appreciated them more because of the freedom and accessibility they provided than formally long tests samples not so easy to edit. Thus IMO, inside the test sample is a proper use (or at least a permitted one, since there are katas with high satisfaction votes out there that use just test.expect something) of the testing suite
3. I think I still don't get it: in the full test suite all the tests are implemented with decorators and everything, eg

@test.describe("Configuration Checks")
def tests():
    @test.it("All types are correctly initialized")
    def it():

4. So people do actually prefer to get their mind-cpu busy assuming instead of just trying to press submit and see what happens? (not a salty question) I personally always try test AND submit with the real first attempt I do to solve a kata (or to have info without bothering to look back at the description). Btw I've integrated your suggestions on this (and the related point 2)
5. Ok I see, few additional words in the description can be worth to be integrated to explain that detail.

get(name, default = None): Get a single type instance
-->
get(name, default = None): Get a single type instance. If no instance is found returns either 'None' or whatever the consumer has provided via the optional param 'default'.

Hi, this time (to answer the "...again") I don't think you nail any real point tbh.

1. the relevant part you provide shows details for 'Flying' class when you comment a test that expects 'Ghost' to be immune to 'Normal'. So, to answer you, yes this line is present in the dictionary: "Normal": {"Ghost": 0} i.e. "Normal" does 0 damage to "Ghost".
2. Sample tests were really readable, concise and I didn't feel it needed extra verbosity because the users can add it if they feel they need it.
3. You should remove the stroke from the "I guess" part because there isn't (and wasn't) any test.expect nor test.assert_equals without error description in the internal test case. If you found some other type of misleading error description please provide me something to watch for and I'll fix it
4. As said at point 2, imho test.expect(PT.get("Ghost").is_immune_to("Normal")) in the sample tests where users can add/comment out/edit as they need to (if they actually experience errors) is perfectly fine, readable and clear. I also don't think test.assert_equals was properly used, as per your observation, since it missed the verbose description. I've still added message description for every error (both expect and assert_equals) in the example test case, althought they make the test case code box less clean and more annoying to edit for the users imo, but whatever.
5. The DefaultType was declared this way DefaultType = TypeVar("DefaultType") meaning 'DefaultType is a generic type with name "DefaultType"'. I've still changed it to DefaultType = TypeVar("T") to be even more clear that it's just a generic type used to specify that the return type of get should be either PokemonType or any type the default param is. I think that what's on my mind is also on the initial solution, so it doesn't really need to be verbosely explained. Do you really think I should explain this inside the description?

PS I still wait for your response to mark the issue as solved

Nice catch, pretty coherent the bugs were in the Bug isn't it?
Fixed, thank you. I have also double checked others and didn't find any additional error.

Is it 6 kyu appropriate iyo?

Mb, added in the description and fixed a broken test not accounting for it, should be trivial to adapt the solution

Solved 1, 2 and found that the 1 was not the only one non-int being fed by the test suite. Fixed everything. Thanks again for the feedback.

Can I ask you what's the kata difficulty tier in your opinion?

Done. Just trimmed the type details.

Ok, you're right, but it seems a doable tradeoff since the actual methods where alpha and roi should be used are provided. I think that it make sense to accept to not implement like it would be for a professional software operating in finance, if this make more readable for the already ultra-brave trainee and not having to also explaining him that roi and alpha are to be seen as percentage integers representing a number with x decimals. The purpose of the kata is to have fun (mostly are not, but whatever, I'm a nerd) while understanding how a ponzi scheme could work internally from a high level POV.

@hobovsky Everything is an integer now.

@uttumuttu I've changed the test suite, the solution and the initial solution + integrated the description. I've chose to simply provide the functions to be used to compute both monthly alpha and interests since, as you've pointed to, it's the only step where floats could slips into (assuming the implementation is correct). Thanks for your patience, I really appreciate your contributions that are strongly motivating

I've opted for a little bit of clarification in the description, since I think it's the simplest way to avoid explaining and implementing more mechanics (since the kata is already too much scaring as it is)

Description:

If you're troubling with floats, the test suite expects floats to be `round`ed at the second decimal. This is just for the external (public) api, so you shouldn't use rounding in your calculations, but only on the public interface (the one being tested).

@Mercy It's kind of my first serious attempt to author a kata, I'm not even sure about what I'm doing LOL! Btw I don't see any fancy stats

@Kacarott From a dev POV difficulty imo should be around 6 to 4 (i've proposed 5) because there is nothing expecial but some OOP and err handling. But yeah now I'm figuring out that from an implementation POV it could be way higher even if I thought the description had everything specified =/
PS where did you find the number of people training?