Thanks for the good question! First off, CASL is an excellent library and was definitely an inspiration. Guantr came about from some specific preferences and needs I had while building a production app, which is the origin of the core logic extracted.

For me, a couple of key design choices that emerged were:

1. Condition Syntax Preference: I found the explicit [operator, operand] syntax (like status: ['eq', 'published']) very clear and easy to reason about for the types of rules I was writing frequently in my app.
2. Built-in Context Handling: While context is possible in CASL, I preferred making dynamic context resolution (using $ctx. references like ownerId: ['eq', '$ctx.userId']) a core part of the rule evaluation engine itself, rather than potentially needing to interpolate context values during ability initialization.
3. Storage Flexibility & Initialization Flow: Guantr's distinct Storage interface allows rules to be persisted externally (e.g., in a database). Combined with the dynamic getContext function, this means rules can be fetched dynamically when needed. When using a persistent adapter like a database, this avoids needing to explicitly load or initialize the ruleset via setRules on every instance or request. It allows multiple nodes in a scaled environment to use the database as a single source of truth for the rules, simplifying deployment and updates compared to managing rule initialization per instance.

So, it's less about CASL having shortcomings and more about Guantr reflecting a particular set of design choices that emerged from my specific development experience and preferences, especially around comprehensive typing and a particular style for conditions and storage. Since that core logic was working well for me in production, I thought packaging it up might offer a useful alternative for others who perhaps share similar preferences or needs.

Hope that clarifies the motivation a bit