My Code

One gameobject rules them all and that is the GameManager. Its by far the most extensive script and it manages most things from Initialization of the game to the highlevel network communication.

The game is mostly UI based and so it reacts mostly just to clicking on cards and then dragging them to places. 
Once such an action is completed it gets converted to a very basic format.
Each slot on the board and every slot in hand has an ID and an action is at most from which slot to which slot.
There are 3 numbers in the PlayerAction struct: card, target, slot but only two at a time are used right now. The third one was planned for targetted battlecries but those did not make it to the final game. And so ->a card is played from point A to point B and this information is sent over the network to be replayed on the opposite client. Every action is deterministic - at the start of the game the host makes and shares a seed so all random card effects happen the same way on both clients.

Player can only act on their turn and thus there are no race conditions that could disrupt the synchronisation of the clients.

Each card knows if it is a minion or a spell or a field and can be placed only appropriatelly. 
The inheritance tree for card related objects is fairly deep and goes something like: Monobehaviour->GameActor->TableActor->DamageableActor (All of which are abstract classes from which things like Card,Minion etc are derived as approprite)

All card specific scripts (The effect written on the card image) are in a separate assembly. When a card is loading it looks in a json that contains paths to cardscripts and checks whether it has a special script. If it does it loads the assembly and gets the script by type name from the assembly and AddComponent()'s it. The cardscripts then manipulate the card. For example if a card is a spell and has no script it can be played without a target. But if the cardscript inherits from targetted behaviour the card changes this during instatiation.

This system is used mainly so that one could potentially stack card effects on one card.

The most interesting Monobehaviours would be:

GameManager.cs: https://gitlab.mff.cuni.cz/teaching/ncgd008/2425-winter/malyjir-1/-/blob/master/... 

Card.cs: https://gitlab.mff.cuni.cz/teaching/ncgd008/2425-winter/malyjir-1/-/blob/master/...

CardScriptBase.cs: https://gitlab.mff.cuni.cz/teaching/ncgd008/2425-winter/malyjir-1/-/blob/master/...

Card contains most logic on how cards load themselves from disc, and contains some abstract classes the others inherit from later. It also handles playing and placing various card types on the table.

CardScriptBase contains the virtual functions cardscripts use. This is all controlled by events ->CardScriptBase insures that all of its derivate classes subscribe to relevant events in the game and the derivete children only override the relevant methods.
It also contains a number of helper functions used in the cardscripts so that if a bug is found on some type of card effect it can be mostly fixed in one place globally and not on every cardscript individually.
And lastly it contains the TargetableCardScriptBase subcalss taht replaces some functions so that they have a different signature and it gives compiler level protection to the cardscripts -> if they want to have a target they must inherit from the TargetableCardScriptBase or their OnSelfPlayed function will not get a target in its parameters.

I am not much prouder for any class so pick one of those I linked above I guess.

I don't think there is any big issue with any of my classes. Though the Relay is a little janky and sometimes does not connect without warning so that probably would be one of the things to look at. Otherwise there is the TODOList.txt