Related to the issue below: the minimal people size that forms non-trivial counterexamples is at least 9, so with a limit of people <= 8 the kata becomes a much easier version of the actual problem.

This is definitely not intended (as author solution can handle non-trivial counterexamples just fine), so people should definitely go higher. I'd even say go up to 12 or so. Potential performance requirements would be a necessary sacrifice for this, since graph complexity in these kinds of graph problems go exponentially as the input size; for low input sizes you can't test anything meaningful.

Original Python version is fine, but JohanWiltink's reference solution used for Haskell and JS translation contains a wrong algorithm that will fail against certain inputs.

The problem is, the input size has been (arbitrarily) constrained to people <= 8 due to performance concerns, and I believe the minimal counterexample that can be created is at least 9:

You found a better solution than the reference implementation.
Please raise an Issue with the following information:

language: JavaScript
input: [[1,0,1],[2,1,1],[3,2,1],[4,3,1],[5,4,1],[6,5,1],[7,6,1],[8,7,1],[0,8,1],[4,3,13],[4,0,37],[6,5,32],[6,1,68],[8,7,44],[8,2,61]]
actual output: [[3,4,13],[0,4,37],[5,6,32],[1,6,68],[7,8,44],[2,8,61]]
expected output: [[0,8,37],[1,8,68],[3,4,13],[5,4,32],[2,4,5],[7,6,44],[2,6,56]]

Thanks in advance!

So the reference solution in these two language versions needs to be fixed.

(More preferably, they should use the same algorithm as the original reference solution, precisely to prevent issues like this.)

ok, centralizing here what's left to do about python specifically:

• add the actual output of the user to the assertion messages
• suggesting to add the full check if the solution if the user for the sample tests (see below)

(don't forget the one below, and the suggestion about the inputs, for all languages)

cheers

If there is no one that should pay anything just return empty list.

not tested.

I'd still recommend to push the things a bit further. Like 15-18 people. Considering the logic of the problem, it's equivalent to an input of size people/2 (on average), considering the complexity.