The current reference solution returns suboptimal answers in some cases, for example:

1. Wash: meat (takes 2 minutes)
2. Wash: eggs (takes 1 minutes)
3. Peel: eggs (takes 6 minutes)
4. Cut: cheese (takes 2 minutes)
5. Fry: cheese for 13 minutes
6. Grate: cheese (takes 2 minutes)
7. Fry: cheese for 30 minutes
8. Wash: eggs (takes 3 minutes)
9. Wash: eggs (takes 2 minutes)

As shown in the Gantt chart below, the optimal answer is no more than (4) + (5) + (6) + (7) = 47 minutes, while the reference solution returns 48.

I would add test cases as this too. Not sure ref sol deals with those correctly. Such cases skip scheduled active tasks to give priority to future active tasks on other ingredient first, after an ongoing passive one.

1. Wash: carrots for 10 minutes
2. Wash: rice for 5 minutes
3. Boil: rice (takes 10 minutes)
4. Boil: carrots (takes 2 minutes)
5. Add: carrots for 20 minutes

-> should take 32 minutes
- start 1 and 2
- when 2 completes, don't start 3 yet
- when 1 completes, start 4
- when 4 completes, start 3 and 5

Needs more random tests in general, making sure also edge cases such as specified in the other issue below are generated. I was able to pass random tests with an inferior algorithm because of good dice roll.

Needs more random and fixed tests with edge cases such as below, where we need to skip certain steps of some ingredients, to eagerly take a bottleneck ingredient first:

1. Add: carrots, meat, rice (takes 2 minutes)
2. Peel: carrots (takes 9 minutes)
3. Cut: meat (takes 5 minutes)
4. Wash: carrots (takes 2 minutes)
5. Cut: meat (takes 4 minutes)
6. Boil: carrots for 21 minutes
7. Grate: carrots (takes 1 minutes)
8. Add: carrots, rice (takes 4 minutes)

Sorry for this useless comment, but noticed, that my implementation at certain conditions did not pass the random tests. I believe there is an error and some more test cases required.

I have a question
What happens when attackers enter the trench and get defeated?

suppose the attack is:

"ss "

"--|dzp|"

as d is 2 but also the first one in the trench it's defending power becomes 4 successfully defending.
but now what?
what will be it's attacking power?
will it be (4 - 2) or (2 - 2), as you've said "it's not allowed to use more points than usual."?

The reference solution in Go differs from other languages.

Doing the C-version.

I would have appreciated larger sized fixed tests.

The jump from 6 entries to 100-200 sized non-repeatable random tests makes it perhaps somewhat unnecessary hard to debug.