Definition of Done

A task, feature, or bug fix is considered done when all of the following criteria are met.

Code Quality

Code compiles and builds without errors or warnings.
Code follows the project’s established style guidelines and linting rules.
A strict linter standard must be enforced by git hooks locally (pre-commit) and as the first stage of remote CI/CD pipelines.
Code formatting must be enforced by an automated formatter (e.g. Prettier) and checked in CI.
TypeScript strict mode (or equivalent strictness for the project language) must be enabled with no suppressions.
const over let; var is never permitted.
Named exports only; default exports are not permitted.
No any types unless explicitly documented and justified.
No TODO or FIXME comments left unresolved for the current task.
Dead code, unused imports, and unused variables have been removed.
Strongly typed languages are preferred for all projects.
Recursion is not allowed except where tail-call optimization is guaranteed by the language runtime. Use iterative approaches with explicit stacks.
All queues and buffers must be bounded.
Pure functions are preferred where possible.

All projects must comply with the Security Standards. The following are the minimum security checks required before any task is considered done:

No critical, high, or medium vulnerabilities as determined by a SAST tool appropriate to the language. See Vulnerability Management for full requirements and remediation SLAs.
CodeQL must be enabled on all projects.
Dependabot must be enabled on all projects for source code dependencies, and GitHub Actions dependencies.
All GitHub Actions must be pinned to specific commit SHAs, not tags.
OWASP and CIS standards must be met. See Security Standards for the full set of controls.
All network traffic must be encrypted in flight. See Encryption in Transit for cipher and protocol requirements.
Post-Quantum Cryptography (PQC) is preferred for all encryption (e.g. TLS 1.3+). TLS 1.2 is the minimum acceptable version.
For non-PQC cryptography, all solutions must use ECC.
HTML output must be automatically escaped to prevent XSS. See Input Validation and Output Encoding for full encoding requirements.
No hardcoded secrets, credentials, or API keys in source code. See Secrets Management for storage and rotation requirements.
Projects should minimize runtime dependencies to reduce supply chain attack surface. Zero runtime dependencies is the ideal.
A SECURITY.md policy must be present with reporting instructions and response timelines.

At least 98% unit/integration/e2e test coverage covering both happy path and sad path.
All existing tests pass with zero failures.
Edge cases and error paths are explicitly covered.
Tests are organized into unit/, integration/, and e2e/ directories.
E2E tests must cover all supported browsers where applicable.
Test-driven development is preferred: tests written before or alongside implementation.
Coverage thresholds must be enforced in CI and must not regress.

CI must run as a multi-stage pipeline: lint/typecheck, test, build, e2e, deploy.
Lint and type checking must be the first stage and must block all subsequent stages.
Build artifacts must be verified (correct outputs exist, bundle size within limits).
All CI checks must pass before a PR can be merged.
Post-deployment verification (smoke tests or E2E against the deployed environment) should be performed where applicable.
Local CI execution must be supported (e.g. via act or equivalent) so developers can validate before pushing.

Pre-commit hooks must enforce type checking and code formatting.
Pre-push hooks must enforce tests and coverage thresholds.
Hook setup must be documented and simple (e.g. symlink from git-hooks/ to .git/hooks/).

A pull request has been opened and reviewed by at least one other team member.
All review comments have been addressed or resolved.
Reviews must include explicit security consideration for authentication, authorization, input handling, and data exposure. See Secure Development Lifecycle.
The PR description clearly explains what changed and why.

Public APIs, functions, and types have clear documentation (e.g. JSDoc, GoDoc, or equivalent).
All documentation must be maintained in a docs/ directory tree, organized by topic, and linked from an index page.
Documentation must use GitHub-flavored Markdown with language-tagged code blocks.
One concept per page; use relative internal links.
Breaking changes are documented in a CHANGELOG.md.
A CONTRIBUTING.md must be present with setup instructions, development workflow, and coding conventions.
A CODE_OF_CONDUCT.md must be present in all projects.

Projects must use tag-based semantic versioning.
Commit messages must follow Conventional Commits format: feat:, fix:, test:, docs:, refactor:, perf:, chore:.
All GitHub remote connections must use SSH, not HTTPS. Repository URLs must use the git@github.com: format.

All code must be original work or covered by an MIT-compatible license.
No code may be copied without license verification.
Third-party assets (fonts, icons, data) must have explicit permission or compatible licensing.
A ThirdPartyNotices.txt or equivalent must be maintained if any third-party components are used.

Feature flags or configuration changes are documented.
Database migrations (if any) are reversible and tested.
Monitoring and alerting are in place for new components or endpoints. See Logging and Monitoring for security-specific monitoring requirements.

The work satisfies the requirements defined in the issue or ticket.
The feature has been verified in a staging or preview environment where applicable.
Product owner or stakeholder has approved the work (when required).