# Exercise 1: Write the OpenAPI Contract for a Library Loan Endpoint

## Scenario

You work on `StackShelf`, a library management API. Product has specced a new endpoint: checking out a book to a member.

- `POST /loans` creates a loan: a member borrows one copy of a book.
- Request needs `member_id` (integer) and `book_id` (integer).
- A member cannot have more than 5 active loans at once — attempting a 6th must fail.
- A book with zero available copies cannot be loaned — attempting it must fail.
- On success, the response includes the loan's `id`, `member_id`, `book_id`, `status` (always `"active"` on creation), and `due_at` (an ISO 8601 date-time 21 days from now).
- The endpoint requires a Bearer token, and the token's scope must include `loans:write`.
- This endpoint is rate-limited to 20 requests/minute per member.

## Deliverables

Produce all of the following, in this file, below this line:

1. **A complete OpenAPI 3.0 `paths` entry for `POST /loans`**, in YAML, including the request body schema, every realistic response status code (success, validation failure, the two business-rule failures above, auth failure, rate-limit failure) with a response schema or example for each, and the auth requirement expressed as an OpenAPI `security` requirement referencing a `bearerAuth` scheme.
2. **The `components.schemas` entries** referenced by your paths entry (`Loan`, and any error-shape schema you use across multiple responses).
3. **A short justification, in prose below your YAML**, for your choice of status code for each of the two business-rule failures (too many active loans; book unavailable) — using the status-code discipline from theory section 4, and pointing to whichever sibling topic (`backend/api-design/09-error_response_design` if you've read it, or general REST status-code conventions) informed your choice.

## Constraints

- Every response you document must have a schema or a concrete example — no bare `description` with nothing else.
- The `Loan` schema must list every field as `required` that this endpoint's success response always includes.
- Do not invent status codes outside the standard HTTP registry.