Documentation Boundaries
This docs app contains customer guidance, developer integration docs, and contributor notes. The boundary is editorial, not enforced by auth or route-level access control.
Why this page exists
apps/docs is a single Nextra surface. That means customer-safe narrative, partner integration detail, and repo-internal operating notes live side by side. Anyone writing docs, demos, or external collateral needs to know where the line is.
Public-safe content
The following material is generally safe to reuse outside the repo:
- high-level explanation of Veref as an agency-first reference-check and hiring-ops product
- actor model for recruiter, candidate, and referee flows
- public workflow explanation
- customer-facing guidance from Customer Guide
- high-level architecture language such as Next.js, NestJS, Postgres, Prisma, Clerk, OpenRouter, Resend, and Twilio
- API-key concepts, scope names, and public API-key route categories from API Access
Repo-internal content
The following material should stay inside contributor or operational contexts:
- local commands such as
bun install,bun run dev:*, and./skills.sh install - environment variable names and local URLs from
.env.example - internal file paths, package names, and implementation boundaries
- operational route details such as
v1/tenants/:tenantId/ops/feed - local agent and desktop bridge diagnostics
- troubleshooting playbooks and deployment notes
- brand implementation prompts and design artifact specs
Mixed pages
Some pages are mixed by design.
- Developer Quickstart, API Access, and Endpoint Reference are integration docs. Share them with customer developers, but review examples before copying into marketing material.
- Architecture is partly public-safe and partly contributor-focused.
- Integrations is safe at a category level, but preview-mode and env-specific details are internal.
- Product and Customer Guide are mostly public-safe.
- Local Development, Deployment & Operations, and Troubleshooting are internal.
- Brand Identity is secondary reference material, not the main docs entrypoint.
Rule of thumb
If a page includes any of the following, do not treat it as public marketing copy:
- environment variables
- repo paths
- setup commands
- tenant-scoped internal endpoints
- desktop runtime paths
- skill-link or symlink repair instructions
Recommended usage
- Use customer guide, product, and workflow pages for public-facing explanation.
- Use developer quickstart, API access, endpoint reference, and CLI pages for customer integration.
- Use contributor, local development, deployment, and troubleshooting pages for engineers and agents working in the repo.
- When in doubt, strip concrete commands, route names, and env details before sharing externally.