{can 'edit-post', $post} asks a gate whether the user logged in may do something, and renders its content when the answer is yes; the part after its own {else}, or the @else@ half, renders when it is no. The gates are functions the application defines once, in a file of its _lib/:

padGate ( 'edit-post', fn ( array $user, array $post ) => $user ['id'] === $post ['author'] );

The first item is the ability, the others are what the gate is given after the user: an expression each, the name of an array of the page as that array - and the name of an enclosing loop as the row of its current occurrence, so {posts}{can 'edit-post', $posts} asks about one post, not the list.

padGateBefore ( fn ( $user, $ability ) => ... ) hooks are asked first: TRUE or FALSE decides, NULL leaves it to the gate - an admin who may do anything. A guest reaches only a gate (or hook) whose user parameter takes NULL - ?array $user or $user = NULL; any other gate is not even asked and answers no. An ability nobody defined is FALSE and, under the strict check, an error, so a misspelled name is reported instead of silently hiding a button. {cannot} turns the answer round; padCan, padCannot and padAuthorize (403) ask from PHP.

The gates of the examples here are in this application's _lib/canGates.php: read-post takes a guest, edit-post does not.