Skip to main content
Was this helpful?

Development Workflow

This page describes the expected workflow for product work, CI maintenance, and dependency updates in the PrimeCal monorepo.

Branching​

  • Start from main.
  • Use a task-focused branch such as codex/<topic> or release/<topic>.
  • Keep unrelated work out of the branch. If the repo is already dirty, scope your changes carefully instead of reverting someone else’s work.

Local verification before PR​

Run the full local acceptance stack for application changes:

npm run ci:quality
npm run ci:i18n
npm --prefix backend-nestjs run test:unit
npm --prefix backend-nestjs run test:security
npm --prefix backend-nestjs run test:integration
npm --prefix backend-nestjs run test:e2e
npm --prefix backend-nestjs run test:mcp:integration
npm --prefix backend-nestjs run test:mcp:security
npm --prefix frontend run lint
npm --prefix frontend run test:unit
npm --prefix frontend run test:integration
npm --prefix frontend run build:typecheck
npm run docs:check
npm run docs:portal:build

If you changed manifests or lockfiles, also run:

npm run ci:dependency-audit

Pull request expectations​

Every PR should:

  • keep tests aligned with the current supported behavior
  • update docs when workflow, release, security, or user-visible behavior changes
  • avoid duplicate utilities, workflows, or deployment paths
  • preserve KISS and DRY over clever abstractions

Dependabot pull requests​

Dependabot PRs are not auto-approved by default. Review them like product code:

  1. Check the dependency scope and changelog.
  2. Run the relevant local suites for that scope.
  3. Run the full local stack for major or cross-cutting updates.
  4. Merge only when the dependency upgrade and the behavior changes are both understood.

If an alert cannot be fixed immediately, document the mitigation in the security docs and PR.

Release model​

Current release policy:

  • backend deploys automatically from main
  • docs portal deploys automatically from main
  • frontend app releases are manual
  • root-site releases are manual

Do not introduce a second deploy path for the same target unless the old one is retired in the same change.

Hosted CI blocker​

As of July 10, 2026, GitHub-hosted Actions are blocked by billing and spending-limit issues. That means:

  • local verification is the current acceptance path
  • workflow files still need to stay runnable
  • after billing is restored, the owner must re-run CI and deploy checks before final sign-off

Safe merge checklist​

  1. Local verification passed for the touched scope.
  2. Docs match the real workflow and release policy.
  3. Dependency alerts are fixed or explicitly mitigated.
  4. No legacy workflow or duplicate release path was left active by accident.