# Engineering Standards

Technical standards for all implementation work in Assembly Hangar.

## Code organization
- Use the existing stack and conventions; do not introduce new architecture when the current one can be improved.
- Keep business logic separated from UI where possible.
- Keep files readable and reasonably sized; keep modules separated.
- Do not introduce new libraries without a strong reason.

## Component reuse, naming and typing
- Reuse existing shared components, helpers, hooks and utilities before writing new ones.
- Use clear, consistent names that match existing conventions.
- Use typed interfaces; do not weaken types to silence the compiler.
- Do not duplicate logic; extract a shared helper instead of copy-pasting.

## API calls, services, hooks, utilities
- Route data access through existing service and data layers; do not scatter fetch logic.
- Keep request and response shapes typed.
- Centralize shared utilities; avoid one-off copies of the same function.

## Forms, loading, error and empty states
- Every async surface handles loading, empty and error states explicitly.
- Forms validate input and surface clear, actionable messages.
- Do not present a blank or broken state as if it were complete.

## Environment variables and data persistence
- Never hardcode secrets, tenant ids, user ids or environment values; use environment variables or settings.
- Do not fake persistence. If data is not actually saved or loaded, do not pretend it is.
- If data saving or loading is broken, prioritize that above styling.

## Validation, testing, build, lint, typecheck
- Run the available checks (typecheck, lint, tests, build) and report results.
- Do not disable tests to make a build pass.
- Do not ignore TypeScript or lint errors.

## Avoid
- Hardcoded mock data presented as real.
- Duplicate logic and duplicate components.
- Silently swallowing errors; handle errors explicitly.

## Acceptance criteria for technical work
A technical change is acceptable only if:
- code is readable;
- existing patterns are respected;
- types are handled;
- errors are handled;
- data flow is understandable;
- no duplicate logic is introduced;
- checks pass or failures are clearly reported;
- the change can be reviewed by another developer or agent.