contract-validation

Files (6)

• SKILL.md
• .gitkeep · assets/
• .gitkeep · examples/
• .gitkeep · references/
• .gitkeep · scripts/
• .gitkeep · templates/

SKILL.md (first lines)

# Contract Validation

Keep data crossing a process, package, transport, persistence, or UI boundary explicit and validated.

## Ownership

- Locate the existing authoritative schema or contract before creating a new one.
- Define runtime validation and inferred static types together when the repository's schema library
  supports both.
- Keep shared request, response, error, enum, identifier, and parameter contracts in their owning
  shared package rather than duplicating them in consumers.
- Reuse primitive schemas and compose larger contracts instead of repeating validation rules.
- Keep transport adapters, UI forms, persistence models, and domain models distinct when their shapes
  have different responsibilities.

## Changes

1. Identify every producer and consumer of the contract.
2. Record compatibility impact for added, removed, renamed, optional, and narrowed fields.
3. Update the authoritative schema and its public exports.
4. Update adapters and consumers without recreating the contract locally.
5. Validate both successful and rejected inputs at the boundary.
6. Check malformed responses, unknown keys, nullability, defaults, enum values, and boundary lengths
   when they are relevant to the contract.

## API Boundaries

- Parse untrusted input at the boundary before business logic runs.
- Validate outbound payloads when communicating with an external or independently deployed service.
- Parse inbound responses before exposing them to callers.
- Preserve structured error information without leaking secrets or internal implementation details.
- Keep route, query, form, and response parsing behavior aligned with the shared contract.

## Verification

- When an OpenAPI implementation needs a Nest DTO, make it a thin transport adapter over the authoritative shared schema and inferred type. Put examples and descriptions on the DTO/OpenAPI decorators without recreating validation rules or a second domain contract.
- Search for duplicate handwritten types or schemas after the change.
- Confirm public barrels and package exports expose the intended contract.
- Run focused schema tests, affected package checks, and the repository's required validation.
- Use `test-first-workflow` to define accepted and rejected cases before editing.

From gowebknot/monorepo-template, MIT.

More from gowebknot/monorepo-template