Skip to main content
This page describes the code review procedure referenced in the Cell Labs, Inc. Secure Development Policy. It applies to every change merged into a production branch of any business-critical RevDesk system.

​
Scope

The procedure applies to all source code repositories owned by Cell Labs, Inc. that build, deploy, or run any of the following:
  • The RevDesk web application and API
  • Customer-facing infrastructure (voice, telephony, calendar sync, CRM sync, billing)
  • Internal services that handle Confidential or customer data
  • Build, deployment, or CI/CD configuration that affects production
Documentation-only changes, marketing site copy, and ephemeral experimental branches are reviewed but may follow a lighter cadence.

​
Required controls

​
1. Pull requests are required

All changes that target a production branch are made via a pull request on GitHub. Direct pushes to main and prod are disabled at the repository level. There is no “emergency bypass” path that skips review.

​
2. At least one reviewer other than the author

Every pull request must receive an approving review from at least one engineer who is not the author before it can be merged. Branch protection enforces this; the merge button is disabled until the approval is recorded. For changes that touch authentication, billing, telephony provisioning, or PHI handling, the reviewer must be a senior engineer or the CTO.

​
3. Continuous integration must pass

The following CI checks must complete successfully on the pull request’s head commit before merge is allowed:
  • TypeScript type checking (tsgo --noEmit)
  • ESLint
  • Unit and integration tests
  • Build of the production bundle
Pre-commit hooks run a subset of these locally to surface failures earlier. Hooks are not skipped (--no-verify is prohibited).

​
4. Preview deployment must build

Vercel runs a preview deployment for every pull request. The preview must build successfully and pass automated smoke checks before the PR is eligible for merge. Reviewers also use the preview URL to spot-check user-facing behavior.

​
5. Separation of duties

Development, testing, and deployment of a change are not performed by a single individual without oversight. The author opens the PR; a separate reviewer approves it; production deploys (including database migrations) are visible to the engineering team and tracked in deployment history.

​
What reviewers check

Reviewers look for:
  • Correctness. Does the code do what the description says it does? Are edge cases handled?
  • Security. OWASP Top 10 sensitivity — input validation at system boundaries, no SQL injection, no XSS, no broken access control, no secrets in code or logs.
  • Coding standards. Adherence to the codebase’s style and patterns: type safety (no as any), explicit error handling (ErrorWithCode in non-tRPC paths), Prisma select over include, repository-and-DTO separation, no barrel imports.
  • Tests. New behavior is covered by tests appropriate to the change. Bug fixes include a regression test where feasible.
  • Comments and naming. Comments explain why when the reason is non-obvious; identifiers are self-describing.
  • Backwards compatibility. Database schema changes, API contracts, and feature flag transitions are designed to be safe under concurrent deploys.

​
Hotfixes and emergencies

Hotfixes follow the same review path as any other change — pull request, approval, CI green, preview build, merge. The expedited cases are reviewed quickly, not skipped. If a production incident genuinely requires bypassing the standard procedure (e.g. reverting a deploy that is actively breaking customers), the bypass requires explicit CTO approval, must be documented in the incident timeline, and is followed by a retrospective pull request that brings the change under the standard review process.

​
Outsourced and contractor development

Any contractor or outsourced developer working on Cell Labs, Inc. code is bound by the same procedure. They open pull requests against the same repositories and their changes are reviewed by a Cell Labs employee before merge.

​
Version control

All source code is stored in centralized Git repositories owned by Cell Labs, Inc. Access is granted by role (engineering, contractor, read-only) and revoked promptly on offboarding. Branch protection, required reviews, and required status checks are enforced at the repository level.