Documentation Boundaries

This docs app contains both product explanation and contributor guidance. 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 product-safe narrative and repo-internal operating detail 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
high-level architecture language such as Next.js, NestJS, Postgres, Prisma, Clerk, OpenRouter, Resend, and Twilio
descriptions of the desktop workstation, mobile companion, browser extension, and docs site as product surfaces

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

Mixed pages

Some pages are mixed by design.

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 is mostly public-safe.
Local Development, Deployment & Operations, and Troubleshooting are internal.

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 product and workflow pages for public-facing explanation.
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.