I glad you liked it!  Not the most timely tip, but "z" will undo one step at a time rather than "r" which wipes the slate clean.  In any case, the question stands.  Why allow the player to accidentally bonk when there is a dedicated wait key?  The reason is that there is a game mechanic that is in the code, but not used in any levels.  I had wanted to include a suite of levels with this other mechanic, but getting the UI done ended up taking me right up to the final hour of the jam. Disabling movement for a bonk felt like too much risk to do at the last minute, and so it awkwardly stayed on into the final jam build.

The mechanic if you are curious (rot13): Lbh pna pbageby zhygvcyr qbtf. N ybg bs qrfvta fcnpr bcraf hc vs lbh nyybj bar qbt gb zbir juvyr nabgure fgnlf chg ol ohzcvat ntnvafg gur jnyyf.

Design-wise, levels are coming from one of the following:

1: Show some relevant rule or behavior that is important to the puzzles in isolation.

2: Build some complications around a central theme.

3: Stumble into something interesting completely by accident while building and playtesting another design.

So for #1 I'm a big believer in "show don't tell" wherever possible.  I wanted to have some number of tutorial levels simple enough to show one thing at a time (ex: get all biscuits to win, lose a biscuit to a guard and lose, get seen only with a biscuit, etc.).  This is pretty critical to build up the players toolkit so that solutions to later puzzles feel deliberate and not arbitrary.

For #2, you kind of have to mess around with your own system to get a sense for how things work and what constraints can be enforced.  Discoveries here might be stuff like: "I can punish the player for losing a guard at this specific spot by putting down multiple biscuits in different directions" or "once a guard is one tile behind me, I can never lose it" or "if I put a biscuit on the shortest path from the player to a guard, I can force them to collect the biscuits in a certain order".  You can then build up a little arsenal of building blocks to start going for bigger ideas.

Finally, #3 is just going to happen from time to time in a way that I'm not clever enough to intuit from the start.  The snake level kind of came together this way.  I figured out how to build up the snake in the usual way, but then I wanted the user to have to lose it all again in order to make it to the final biscuit.  Running around in test showed that you can loop back and squash down the length of the snake one square at a time by looping back repeatedly.

Thanks for playing!  There is a 'why' to that final level but it definitely has some problems.  I think this could be mitigated by slotting in a few more levels that lean on the relevant pattern/resource on a smaller scale.  I'd also like to do something to decouple the screen size from the map size so that a level like that one can unfold into a more natural configuration for the solve.  As is, it all has to kind of smush together to fit everything on screen.