danvics/docling-studio
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
docling-studio/docs/git-workflow/code-review-checklist.md
Pier-Jean Malandrino 941028e705 ci: add release-gate pipeline, fix CI duplication, add OSS playbook docs 
- Add release-gate.yml: 11-job pipeline (lint, tests, Docker build/smoke,
  Trivy scan, dep audit, audit checks, e2e API+UI, PR summary comment)
- Fix CI double-trigger on release branches (push + PR)
- Add CODE_OF_CONDUCT.md, SECURITY.md, PR template
- Add docs: git-workflow, architecture (ADR), release, operations, community
- Add profiles/fastapi-vue for automated audit checks
- Add docs/PROCESSES.md: index of 19 available processes
2026-04-09 13:20:43 +02:00

2.1 KiB
Raw Blame History

Code Review Checklist

Use this checklist when reviewing a Pull Request. Not every item applies to every PR — skip what is irrelevant, but consciously skip it rather than miss it.

Correctness

  • The code does what the PR description says it does
  • Edge cases are handled (empty input, missing data, concurrent access)
  • Error paths return meaningful messages, not stack traces
  • No regressions on existing behavior

Architecture & Design

  • Dependencies flow inward: api → services → domain (never reversed)
  • Domain layer has no imports from api/, persistence/, infra/
  • No business logic in API routes — delegated to services
  • New abstractions are justified (no premature generalization)
  • Pinia stores stay within their feature boundary

Security

  • User input is validated at the API boundary (Pydantic schemas)
  • No secrets, API keys, or credentials in the code
  • No eval(), exec(), or raw SQL
  • File paths are sanitized (no path traversal)
  • CORS configuration is unchanged or explicitly justified

Tests

  • New behavior has corresponding tests
  • Tests are deterministic (no sleep, no random, no network)
  • Test names describe the scenario, not the implementation
  • E2E tests use data-e2e attributes, not CSS classes (see e2e/CONVENTIONS.md)

Code Quality

  • No dead code, no commented-out code
  • No TODO or FIXME without a linked issue
  • Functions are < 30 lines (or well-justified)
  • Variable names are descriptive and consistent with existing code
  • No duplicated logic that should be extracted

Documentation

  • CHANGELOG.md updated under [Unreleased] if user-facing change
  • API changes reflected in Pydantic schemas (auto-documented)
  • Breaking changes are flagged in the commit message

Pragmatic Checks

  • The PR does ONE thing (feature, fix, or refactor — not all at once)
  • No unrelated formatting changes mixed in
  • The diff is reviewable in < 15 minutes (split large PRs)
  • CI passes (tests + lint + type-check + build)