---
id: specify-client-config-validation
name: Specify client config validation timing and schema evolution
status: completed
depends_on: []
scope: narrow
risk: high
impact: component
level: implementation
---

## Description

"Validated against the TypeBox schema for this type **on write**" in `services.md:19` is ambiguous:
1. Who validates? Drizzle insert schema? API handler? DB trigger? Direct SQL bypasses application validation.
2. Schema evolution: when code deployment changes a client type's TypeBox schema, existing DB rows may become invalid.
3. No re-validation on read is documented.

## Acceptance Criteria

- [ ] `services.md` specifies: "validate on write (API handler layer) + warn on read (start-up validation pass with logging, not blocking)"
- [ ] Schema evolution contract is documented: new fields MUST be `Type.Optional()`; breaking changes MUST use a new client `type` string (e.g., `llm-provider-v2`)
- [ ] Whether a `configSchemaVersion` in `metadata` is needed is decided and documented
- [ ] The validation chain is explicit: API handler validates → Drizzle insert → DB stores; direct SQL bypass noted as risk

## References

- docs/reviews/storage-architecture-review-2026-04-21.md#C12
- docs/architecture/storage/services.md:19
- docs/decisions/ADR-007
- docs/architecture/storage/README.md Open Question #10

## Notes

> To be filled by implementation agent

## Summary

> To be filled on completion