Maybe also a way to specify command permissions: you can pass a numeric permission level and then you have a function to change that level from the code, so it hides the command like it does with other Carpet commands instead of having the command always visible, then checking, then saying Sorry, you no good. (for example to use with Scarpet Rules or to allow ops to change perms of an app on the fly)

Originally posted by @altrisi in #221 (comment)

Another way now that I'm seeing how does Brigadier check that:

Giving a reference to a variable (maybe even a "built-in variable"?) (or maybe better a lambda function) and evaluate from there whenever it has to check.
Something like the suggester, but to get a string to check against standard Carpet perms instead of suggesting.

       'command_perm' -> _(args) -> (
          if(global_isEnabled,
            global_permission;
          ,
            'ops';
       ),

This could return a boolean (so it could have granular permissions completely decided by the app in a specific moment, problem: booleans are = 1 and 1 != true when checking perms, would need forcing a string there), or another of the compatible Carpet permissions (0-4, ops, all can be "parsed" in the same method).
Maybe without args, since that would probably be too difficult if at all possible, but probably send the player there so it makes sense to make it dynamic.

Another flaw I just found: When to resend command tree. This is the one that would probably need a function then.

I'd say this blocks #553 (to prevent non-ops just starting to draw shapes without having the right permissions).

Lambda would be ideal - the problem is that __config is NOT executed again for player apps when copied from the parent app, meaning the functions may be referencing the incorrect module (parent module). I am not 100% certain about it though - might all be just fine. It would be ideal to specify callback accepting player argument (or null for server calls).