Good observation, i hadn't noticed, i made the change

Thanks for solving my hard beta kata's.

Thanks for the feedback. Description edited.

I agree, description edited to mention the non-overlapping constraint. The original description tried to explain that these rectangles have no 3rd dimension property (which is stating the obvious). But it added more confusion than anything else.

That could have worked too, but in my design I wanted the isle to be clear of upgrade packs. I do notice this is not stated in the description. I'll edit the description.

If the critical attack is executed three times in a row, the health decreases with ...

I believe in this case, you should lose 16 health:

• the 2nd critical attack is consecutive with the 1st, so you lose 8.
• the 3rd critical attack is consecutive with the 2nd, so you lose another 8.

I've updated the description accordingly:

• If the critical attack is executed twice in a row, the health decreases with 8.
• If it's executed with one (non critical) action in between, the health decreases with 4.

So, AA-loses 8 health, AAA loses 16 health and A-A loses 4 health

Thank you for solving this kata!

To answer the second bullet already:

Each enemy in the chain gets half the damage done to ...

This could be interpreted one or two ways. I've added a sample test and a part to the description to avoid confusion:

=> (added to description)

Note that if you deal more damage to an enemy than their health, that enemy is obviously eliminated, and the measured damage is the maximum damage you would have dealt on a strong enemy, regardless of the actual health of the enemy.

example: showing 2 turns of attack (level completed)

health = 4
level = [[2, 8], [4, 8]]

turn 1:
action = 'A'
health update after turn: 4
level update after turn: [[0, 8], [0, 4]]  
2 enemies beaten, player will automatically move right (1 tile max / turn)
the next status of the level = [[0, 4]]

turn 2:
action = '-'
health update after turn: 4
the next status of the level = []       -> level completed

see answer as spoiler

The JS version has smaller random tests than the Haskell version, carefully sized to not overflow MAX_SAFE_INT.

I'm not aching to refactor it when there's not really a problem. ( Even ) Bigger numbers don't really add to the kata; if you can solve it for small numbers, you can solve it for big ones.

Do you think the JS version should also use BigInt instead of Number?

I think I fixed it

To me this looks like invalid input. The state machine ends after (mul), so you should return a - b.

interesting solution ;)