Runtime Surfaces

This page enumerates the shipped surfaces under apps/ and the responsibility boundary for each one.

apps/app

Main recruiter SaaS surface built with Next.js.

• canonical recruiter workstation
• owns the browser desk experience
• uses Clerk provider wiring
• consumes shared contracts, UI, and workflow helpers

apps/web

Public marketing site built with Next.js.

• public-facing product narrative
• separate from the recruiter desk
• shares UI and workflow vocabulary where useful

apps/api

NestJS API.

• health and stack metadata
• tenant dashboard endpoints
• public reference-request creation
• tenant ops feed and message routes

apps/docs

Nextra docs app.

• product explanation
• contributor onboarding
• architecture and operations docs
• editorial public/private boundary guidance

apps/desktop

Electron workstation.

• local recruiter power surface
• exposes runtime info through a preload bridge
• inspects local agent availability
• reads runtime and monorepo skill catalogs
• surfaces .claude and .codex symlink health

apps/mobile

Expo mobile app.

• recruiter notifications and lightweight triage
• mobile companion rather than full desktop parity

apps/extension

Plasmo browser extension.

• popup entrypoint
• side panel entrypoint
• context-menu and active-tab handoff into the recruiter app
• app URL driven by PLASMO_PUBLIC_APP_URL with localhost fallback

apps/cli

Local veref command-line interface.

• health checks against the API
• tenant ops feed retrieval
• ops message creation through flags, JSON file input, or stdin
• defaults to VEREF_API_URL or http://localhost:8787

Surface interaction summary

• recruiter browser app is the center of the product experience
• API supports tenant and public workflow endpoints
• desktop extends local operator workflows and runtime inspection
• extension captures context from browser-based hiring surfaces
• mobile handles urgent recruiter moments
• CLI supports local operational checks and message workflows
• docs explain all of the above without introducing a separate private docs runtime

Current surface boundaries

• candidates and referees are described as public-flow participants, not recruiter-app users
• the docs app is informative, not operational
• the desktop app is local-runtime aware in ways the browser surfaces should not be
• the extension is a handoff surface, not the source of truth for candidate state