You have to get this right everything sits on top of it. So we make it as minimal as possible and make sure it has the methods to allow extensibility of functionality. You may find your self thinking it should do more, but the spec of the LowBoard has been deliberately kept minimal. There would otherwise be a tendency for the go knowledge to get convoluted within the nitty gritty of the board management. It would be possible to design board manager to do lots of fancy things. For example one might expect the LowBoard to maintain a list of touching hostile strings for each string. However this is not needed for basic board management and our philosophy is to keep individual components as simple as possible. Although this does have a knock on effect in terms of optimisation and efficiency. The chosen philosophy should result in simpler classes which tend to be more reusable. Think of the GO analogy of light shape being efficient. In GO you can happily let go of light stones. We need to have the same flexibility in the software. This is also consistent with good OO design principles. The less a class does the more likely it is going to be useful for another task.
In the end the board manager provides methods to do and undo Moves (it does remember the done moves for you). It provides a method to find strings at points and maintains the liberties and points of these strings. Any additional functionality must be provided by the user using a BoardView which is registered with the BoardManager BoardController (MVC model).