Skip to content
flexcal Documentation

Contributing

The full guide lives in CONTRIBUTING.md. This page summarises what matters most day to day.

Before you start

  • Check the issues and pull requests so two people do not build the same thing.
  • Feature requests wait for a maintainer to remove the needs approval label. Bug fixes, security, performance and documentation work can start immediately.

Pull requests

  • Title follows Conventional Commits: feat(scope): …, fix(scope): …, refactor: ….
  • Open it as a draft; a maintainer marks it ready.
  • Keep it small: under roughly 500 changed lines and 10 code files. Split by layer (schema → backend → UI) or by feature component when it grows past that.
  • Summarise the change at the top and say how you tested it.
  • Link issues with Closes #123.

Before pushing

Terminal window
bun run type-check:ci --force
bunx biome check --write .
TZ=UTC bun run test

Code conventions

  • Prisma queries use select, never include, so nothing sensitive leaks and payloads stay small.
  • Never expose credential.key from an API or tRPC endpoint.
  • Import types with import type { X }, and import from source paths rather than barrel files.
  • Business logic belongs in services, data access in repositories, HTTP concerns in tRPC routers.
  • Use ErrorWithCode outside tRPC routers and TRPCError inside them.
  • Add every user-visible string to the English locale file.
  • Comments explain why, not what.

AGENTS.md and the agents/rules/ directory in the repository hold the long-form version of these rules, including the architecture and dependency-layering constraints.

Reporting bugs

Open an issue with the version or image tag, how you deployed, the relevant configuration with secrets redacted, and the log output. Security issues follow SECURITY.md instead.