I've attached The Inspired Handbook. I'm the second developer on an integration
someone else built and left, and I need to review it before we put it in front
of customers.

Use the handbook as the source of truth for intended behaviour, and tell me
where our code disagrees with it:

1. Read chapters 2 and 3, then look at how we call Inspired. If we are treating
   a read as a request rather than as a durable job — a long HTTP call, a
   timeout, a retry that starts a new read — say so, and quote the part of
   chapter 3 that explains why the request id is the idempotency key.
2. Read chapter 5 and audit our retry logic against it. I specifically want to
   know: do we retry on quota_exhausted, do we start a second read when a start
   call times out, and do we treat an empty items array as a failure worth
   retrying? Chapter 8's table says which of those cost us a request.
3. Read chapter 7's "Progress, while it runs" and tell me what our loading state
   does. If it is a spinner, tell me exactly what data is already in the poll
   response that we are ignoring.
4. Read chapter 9, then grep every user-facing string in the repository and flag
   each one that claims more than the pipeline can support. Use its two tables
   as the rule — I expect "match" and "found" to be all over our code.

Two constraints. Do not propose adding a verification or scoring step to justify
stronger copy; chapter 9 is explicit that the pipeline does not do that, and
building it is a separate decision, not a review finding. And do not propose
switching to POST /api/v1/inspire to simplify anything — chapter 6 says what
that route is for.

Finish with a prioritised list: which of these will cost us money, which will
cost us credibility, and which are merely untidy.