Why 'params' are suggested to be an array? I have not found a reason to not permit this parameter to be anything. At any case when we build directed acyclic items graph and when call the function, we must follow some agreements. Say, at some cases all I want from 'params' is to be an id of some entity.
Indeed, $params can be anything. But it is better to keep it consistent to use an array. One of the main reasons is that $params may be used by multiple biz rules in the auth tree. So you can put in different array elements that may be consumed by different rules.
I see, thanks. The use case I try to code still has rather short chains (from role to operations) with (at some cases) the only intermediate task with $bizrules working like filtering.
Do I understand well, auth items types are also introduced for "mind-orginizing" purposes only (roles are for assigning/revoking, operations for checkAccess(), tasks for composing between former ones)?
Yes, you understand correctly. For short chains, you perhaps only need operations and roles. Since you already check the implementation, these are just different namings.
Yes, in fact I have roles with just few operations attached.
[OT] As for checking the implementation, well, to my mind, the framework currently exists at that beautiful stage when source code can be used (along with the guide and API ref) as a documentation: too elaborate, long guide eats developers’ time which can be devoted to codebase evolution (doc changings efforts become comparable with source changing efforts). Too big LOC count prevents using a source code as additional doc. But when source and doc are light, both developers and users are happy 
I greatly appreciate your approach to the framework, thanks!
Thank you! My plan is to gradually add individual tutorials on different topics. This would be done by both the community and the team members. So developers like you who well studied a specific piece of code would not waste your effort and could share your knowledge with other users.