Developer Docs Refresh PRD

Problem

The developer docs should explain the full VeryAI product surface before sending readers into implementation details. Today the docs are strongest around individual integration paths, but the first-time developer journey needs clearer answers to:

• What products does VeryAI offer today?
• When should I use liveness, palm verification, OAuth, ZK, the SDK, or the Discord bot?
• What does the end-to-end user experience look like?
• Which docs page should I read first for my use case?

Goals

1. Make the developer entry point accurately describe VeryAI's current product surface.
2. Keep ZK visible and important, while presenting it as one integration path rather than the only organizing principle.
3. Add a product/use-case layer above lower-level implementation docs.
4. Give developers clear next clicks for OAuth, ZK, SDK, liveness, palm verification, and Discord bot flows.
5. Improve readability and navigation labels without changing technical behavior.

Non-goals

• Rewriting legal, privacy, or compliance claims.
• Publishing new API guarantees that are not already supported.
• Replacing detailed OAuth, ZK, API, SDK, or Discord bot docs in this pass.
• Changing production docs infrastructure.

Proposed information architecture

1. Developer Introduction — what VeryAI does, what you can build, and how to choose a path.
2. Products & Use Cases — product-led overview for Discord bot verification, liveness detection, palm verification, OAuth/native SDK, and ZK proofs.
3. Getting Started — register in the Developer Portal and get credentials.
4. Integration Methods — OAuth2, ZK Integration, and Native SDK.
5. Platform Guides — Discord bot and future platform-specific guides.
6. Reference — API reference and error codes.

Acceptance criteria

• A first-time developer can identify the right integration path within two clicks from the docs landing page.
• Liveness and SDK are mentioned in the developer section, not only in product or legal pages.
• ZK remains represented, but the docs no longer imply every developer journey starts with ZK.
• The navigation has a product/use-case page before deep technical pages.
• Changes are small enough to review in one PR and can be iterated after product feedback.

Initial PR scope

• Refresh the developer introduction as a product/use-case-led entry page.
• Add a Products & Use Cases page.
• Add this PRD for review and follow-up planning.
• Expose the new pages in the docs sidebar.