# Definition of Done and Release Gates

A feature is not done because it renders. A project is done when it is useful, verified, operable, and transferable.

## Feature-level definition of done

A feature is complete when:

- Acceptance criteria are satisfied.
- Normal, empty, loading, success, validation, and failure states are handled.
- Keyboard and mobile behavior are usable.
- User-facing text is understandable and consistent.
- Inputs are validated on the appropriate client and server boundaries.
- Authorization is enforced server-side when access is restricted.
- Errors are logged without exposing secrets or sensitive data.
- The implementation is documented when future maintainers would not understand it immediately.
- The feature has been tested in the context of the complete workflow.
- Reused intelligence has a recorded outcome when the result is known.

## Project-level definition of done

A production project must have:

- A documented owner and primary business goal
- A working primary conversion or operational flow
- Responsive support for agreed viewport ranges
- No known critical or high-severity defects
- No exposed credentials or secrets
- TLS enabled in production
- Validated forms and protected APIs
- Accessible critical workflows
- Analytics or operational logging for important events
- Deployment, backup, and rollback documentation
- A post-deployment smoke test
- An audit score of at least 80, unless an explicit prototype classification is documented
- Reusable components, repairs, deployment knowledge, and lessons captured or explicitly marked as not applicable

## Absolute release blockers

Any one of these blocks production release:

1. Exposed credentials, private keys, tokens, or unrestricted administrative endpoints
2. Broken primary CTA, checkout, application, booking, login, intake, or submission flow
3. Authorization failure allowing users to access data or actions outside their role
4. Known data-loss or destructive-action risk without confirmation and recovery
5. Transmission of sensitive information without appropriate encryption
6. Missing legal consent or privacy behavior required for the actual data being collected
7. Critical workflow unusable by keyboard or assistive technology when accessibility is required
8. Production deployment has no rollback or recovery method
9. Errors are silently swallowed in a way that can create false success
10. Test or placeholder data is presented as live production data

## Conditional release blockers

These require remediation or written acceptance by the project owner:

- Audit score below 80
- Performance score below the agreed target
- Missing analytics for the primary goal
- Unsupported browser or device behavior affecting a meaningful user segment
- Incomplete content or trust information
- Non-critical accessibility violations
- Unresolved medium-severity defects

## Release sign-off

Record:

- Version or commit
- Release date
- Project owner
- Technical owner
- Audit score
- Known limitations
- Rollback path
- Smoke-test result
- Next review date