Module error 

What can go wrong, and which of those you may safely try again.

This is not a new failure model

GodspeedOS already had one. ServiceContext::request_with_reply_deadline_outcome returns DeadlineOutcome { Reply, SendFailed, QueueFull, Timeout }, and those four states are right as far as they go. This module carries them to the application, with ONE more the kernel already reported and that enum folds away: a peer that died holding the request (ReplyDead, CLAUDE.md 8.6), which is Error::PeerDied. Alongside the filesystem’s own status byte, one Error answers both “what happened” and “what may I do about it”.

The distinction everything turns on

  you sent a request and did not get a reply. WHY?

  the send never left          -> Unreachable      RETRY IS SAFE
    (peer restarted, cap stale)                    nothing happened

  the peer's queue was full    -> Busy             RETRY IS SAFE
    (peer alive, congested)                        nothing happened; pace yourself

  the peer died holding it     -> PeerDied         RETRY IS NOT SAFE
    (delivered, then ReplyDead)                    it may ALREADY have happened

  the deadline passed in silence -> OutcomeUnknown RETRY IS NOT SAFE
    (peer may be slow or wedged)                   it may ALREADY have happened

Those last two cases are the whole reason this type is shaped the way it is. A delete that returns OutcomeUnknown may have deleted the file. Re-sending it is not “trying again”, it is performing a second, different operation whose failure would look like success. services/copier says the same thing at its own call site, having learned it the hard way, and before this library several services reached for a longer-named SDK function to recover a distinction the short one threw away.

Error::retry_is_safe is the answer in one call, so nobody has to re-derive it.

Enums

Error

Everything a Godspeed operation can fail with.