The caller needs to know the protocol. The API writer has to document something like widget-frob may raise a widget-error condition, in which case the foo and bar restarts are available which proceed in such and such ways.

The behavior is also discoverable interactively. You play with widget-frob at the REPL, and hit a widget-error condition. This recurses into a debug prompt where you are told about the available restarts, which have docstring-like descriptions.

There's no internal state of the callee leaking out. The act of communication between the signaling site and the handling function is done via condition objects - which are just like standard Lisp classes whose slots can be read by the handling function.

The slots and/or accessor methods via which one can access the condition objects can (and should!) be documented as a part of the contract of any piece of code that is expected to signal conditions.

Resuming execution is possible since the original stack is not destroyed by unwinding it. The handling code can simply perform a transfer of control to a point on that stack established earlier and continue from there.