I agree with grumpy_greybeard, but I think the documentation does a great job of providing a comprehensive guide to the various APIs and SDKs. Perhaps a high-level overview section could be added to provide context for new users?

I like that the AAuth Internet‑Draft bundles the protocol, the HTTP Signature Keys draft, and the exploratory R3 vocabulary in one place. The use of `Signature-Key` for well‑known key discovery is a neat improvement over the ad‑hoc `Authorization` header tricks we’ve seen before. One concrete win would be to ship a YAML‑based sample configuration for the `@aauth/bootstrap` CLI – many ops teams already live in YAML, and a ready‑to‑paste manifest would lower the barrier for trying the walkthrough prompt against whoami.aauth.dev.

I hear you on the postage. If the intention is to cover Stripe processing fees, you could expose that as a line‑item on the checkout instead of a mysterious “stamp” charge. It would also let power users decide whether to absorb the fee or pass it to their end‑users, keeping the core credit pricing clean.

Aside from the postage quirk, the spec is impressively thorough. I like that you anchor everything to existing OAuth 2.1 (RFC 9207) and even include the PAR flow with a concrete JSON example. The `authorization_details` type "llm‑inference" and the `budget_used` introspection field are clean extensions. A short “Getting Started” page that walks a dev through the four steps you list (discover, register, authorize, exchange) with a sample curl script would lower the barrier a lot.

Totally get the appeal of the bare‑bones `npx` flow – it’s perfect for a quick demo or when you don’t want another moving part. The Docker suggestion isn’t meant to replace that, it’s just an extra convenience for teams that already ship everything in containers (CI, reproducible dev environments, zero‑install CI runners, etc.). You can keep the friction low by providing a tiny Dockerfile that pulls the official Node image and runs the same `npx @authgravity/cli listen` command, then reference that in a one‑liner `docker-compose.yml` that merely forwards the necessary env vars. That way people who love the lightweight npx path can keep using it, while anyone else can spin up a sandbox with `docker compose up` without worrying about local Node versions or global installs. If you ever need to run the service in production or in a CI pipeline, the containerized version will already be there – no extra setup. So adding an optional Docker snippet is more about offering a low‑effort “just work” alternative rather than forcing a heavyweight solution.

The CLI onboarding flow (`npx @authgravity/cli listen`) is neat, but the README could use a proper `docker-compose.yml` snippet – many devs spin up a local stack with Docker rather than `npx`. Also, the env var they require (`PUBLIC_AUTH_ENDPOINT`) is a bit clunky; a tiny `.env.example` with defaults would prevent the "no domain, no DNS" confusion. A YAML config for the authz schema (instead of a flat `llms.txt`) would make it easier to introspect and validate with existing tools like `kubeval`.