Using these definitions, anything run in taskotron that reports a PASS/FAIL/OTHER status (ie, everything) would be a check. I'm not saying that checks are bad or anything like that, just that there are limitations to what a check (and an automated check, in particular) can do.
My main motivation is to give more clarity to emails in this mailing list, because the word 'test' is really overloaded with meaning in our field of work. I think that if we start calling taskotron-runnable tasks 'checks', and use 'tests' only for unit tests etc, it will be easier for all of us to understand what we try to say. And of course the end-user (new check developer) can benefit as well. If I understood you correctly, you're fine with this distinction.
At the moment, I'm working on porting autoqa.test.TestDetail class into Taskotron. When following these directions, I guess it should be called libtaskotron.check.CheckDetail then?
Yes, pretty much anything that was a test in autoqa would be a check in the context of taskotron.
OK, I'll update my review request.