Life In 19x19

multiStoneSuicideLegals is set to "false,true", I think this means half games will allow suicide, half won't. If you don't want suicide to be allowed, you should just set it to false.

* Yes, cmf is right

* Pass is just a move like any other move like C3, so you can't prevent it any more than you can prevent a move like C3. For most of the game, passing is a very bad move though, so it should be learned quickly that it's a bad move, so either your net hasn't trained enough or somewhere you have a bug (bad neural net implementation, bad training data, etc).

* Non-handicap stones are normal. Some rules have free placement, so it's good to learn how to handle extra black stones that aren't on the star points.

* You can change almost anything you want, you just have to deal with the consequences. Sometimes it's easy, if you change # of visits or search parameters or rules, then only thing that happens is that you generate new data with the new parameters. Of course, the neural net may or may not work well at first with the new parameters, for example if it's never seen certain rules before and then you suddenly add them.
Sometimes it's hard. If you change the size of the tensors in the npz data that are written, then you will have a mix of different tensor sizes, and that will cause the shuffle script to fail when it tries to make batches, so then you would need to manually pad the data files to make the tensor sizes match.
If you change the TRANINGNAME you can start training a new net with a new name on the data you already have and if you like you can make it a new MODELKIND to change the size of the net, but it will be starting from scratch, so it will generate very weak data when it gets used for selfplay next. So probably you will want to manually run the training scripts and shuffle scripts as necessary to train it enough on the existing data until it catches up in its policy and value loss stats, then resume the full loop as normal.
* The mirroring code is not used during training, so for training it doesn't matter, but yes you should disable it and other code you find that is similar. I haven't thought about what you need to change, you'll have to use your best judgment.
* When something plateaus and is very weak compared to what you would expect, then you probably have a bug and you should extensively verify and test every step on its own to find the bug. If it plateaus but is strong and working properly, then you would try lowering the learning rate, or increasing the search parameters, or using a bigger model.

-----------------
By the way, skimming your code, I can already see a possible bug - unless you train exclusively on a single board size, and you make sure all your tensors exactly match the board size, otherwise your openCL code is buggy because the xSize and ySize there are not the same as the board size. The xSize and ySize there are the tensor size, and these can differ. For example if you train on board sizes 7-19, then all board sizes 7-19 will get mixed into the same batch, even though the tensor size will always be 19.

Also I'm not 100% sure that your code in the winograd unTransform is correct even if you ignore the above problem, I think applying any torus condition there at all could be bad.

I would recommend you do some detailed testing of every part of your code one at a time - make sure move legality and liberty counts and so on are always correct even when wrapping around the board. Make sure the neural net produces identical output except for tiny floating point differences between Tensorflow and OpenCL on several different board positions. Make sure the data is getting written out the way you expect. Etc, etc.