.

Generating test data with only integer solutions is easy enough, you just start by deciding the results and building your system of equations off of that. The description also implies that this is how tests are generated.

Great kata! I spent a lot of time debugging and in the end figured out that the problem was float precision issues.
I hope the tests are done in a way that two circles are never almost tangent (unless one is included in the other), since to avoid precision issues one needs to allow some room when checking inequalities.

By the way, in order to plot circles for debugging purposes, one can use GeoGebra online, which has very simple scripting features.

I just tested some solutions, and they pass consistently below 10 seconds.

Something does not work with Python, as reported by other users. Even just writing "return 'R'" in the function body, it takes 6-12 seconds to pass/fail all the tests; sometimes it even times out. Some administrator should consider removing the Python version entirely.

See the other version; this one has wrong code description

This doesn't occur anymore. Maybe there was a flaw in some old version, but with Python 3.10 it's fine.

I haven't finished the challenge yet but i can say that your alternative solution not consider that you can open the "constants". One example of this is:

realSolution[0][3] = 1
yourSolution[0][3] = 2

depending if hidden number is 1 or 2 you can determinate where is the mine.
You can know that this square can be opened becouse in the two options the square is a number (no can be explode)

(I am sorry if it is not well understood. My english is not good)

My solution does not work if the king is attacked but hidden behind some other piece (found this issue while refactoring).

Ah whoops I just looked at the first two examples and thought that (x,y) corresponds to grid[x][y], while it's actually grid[y][x]

regarding the test output, yes it indeed seems there was a mistake there, since the check_solution function modified the grid. fixed, thanks!
As for your solution, it seems to be indeed false. I created a fork of the interactive version to display this grid: https://openprocessing.org/sketch/1540470, the issue should become clear then.

I am not testing for a certain solution, i just verify if the given solution works.
Here's what's in preloaded:

def _cross_indices(x, y, w, h):
        return {(i, y) for i in range(w)}.union({(x, i) for i in range(h)})
def _toggle(grid, x, y):
    for ix, iy in _cross_indices(x, y, len(grid[0]), len(grid)):
        grid[iy][ix] ^= 1
def check_solution(grid, solution):
    grid = copy.deepcopy(grid)
    for x, y in solution:
        _toggle(grid, x, y)
    return all(all(val == 1 for val in row) for row in grid)

In the last basic test I get the grid

[[1, 0, 1, 1, 1], [1, 0, 0, 0, 1], [1, 0, 0, 0, 1], [0, 0, 0, 0, 0], [1, 0, 1, 1, 1]]

and my answer is:

[(1, 2), (1, 3), (2, 2), (2, 3), (3, 1)]

but I get "Incorrect solution for: [[1, 0, 1, 0, 1], [0, 1, 1, 1, 0], [1, 1, 1, 1, 1], [0, 1, 1, 1, 0], [1, 0, 1, 0, 1]]".

I believe that my answer works. Note that the solution is not unique when the side of the grid is odd (and at least 3).
Also, I don't see why the error message is printing a different grid.

I wrote a solution which works only when solutions are always integers, and it passed all the tests!
(Integer coefficients are not enough to guarantee this, since 2x=1 gives x=0.5)

Hmmm now I cant remember if the kata used integers as solution from the very beginning, or I made it like this. I will check, and add an apropriate note to the description if necessary. I think I could hope this would be covered by "All coefficients are integers [...]", but can't remember exactly now.

It seems that, in all the tests, all the solutions are in fact integers (and one can exploit this to work without approximation errors).
The description should mention this; otherwise, I guess different tests should be used.