Phase B: human web UI with Hellō login (registry as agent provider)

[dickhardt]

Summary

Phase A shipped the robot API (agent-token-gated /resources). Phase B adds the human web interface: a person logs in with Hellō to browse and submit resources.

Design (decided)

The registry plays the agent-provider role too (the playground pattern):

1. Human hits GET / → logs in with Hellō (registry is a Hellō relying party).
2. On callback, the registry (as AP) mints a short-lived browser web-agent token bound to a key in the page.
3. The browser calls the same agent-token GET /resources and POST /resources endpoints — one code path for humans and robots.
4. Adds made via the UI record submitted_by.user = the Hellō sub, alongside agent/ap.

Work

• GET /.well-known/aauth-agent.json (AP metadata) + agent-token minting (bootstrap-style), mirroring playground.
• Hellō login routes (/login, /callback) + session.
• Static UI (public/) that lists resources and has an add form, calling the agent-token API with the browser web-agent token.
• Sanitize Markdown description before rendering (per spec).

Notes

• No new storage model — reuses Phase A's KV/R2.
• Reference implementation: playground (AP + resource on one Worker).