devrites-api-interfacelisted

# devrites-api-interface: contract before implementation When a slice crosses a boundary (FE/BE, service/service, module/module) or exposes a public interface, define the contract first so both sides can proceed and the interface stays stable. ## Define the contract first - **Shape:** request/response or function signature; field names, types, optionality, units. Follow the project's existing naming and conventions. - **Status & errors:** success codes, error codes, error body shape, validation messages. Errors are part of the contract, not an afterthought. - **Semantics:** idempotency, pagination, ordering, nullability, side effects. - **Versioning/compat:** is this new or a change to an existing contract? A breaking change to an existing consumer is a user decision (and a drift event if unplanned). ## Stability principles - Design for the caller. The interface should make the common case easy and the wrong call hard. - **Prefer addition over modification.** A new field is additive and optional; changing a field's type or removing one is a breaking change. You can add later. You can't un-ship a shape consumers already read (observable behavior is the contract: [`deprecation.md`](../devrites-lib/reference/standards/deprecation.md) Hyrum's law). - **One-Version Rule.** Design as if only one version of this interface will ever exist: extend the single contract rather than fork a v2 you then maintain in parallel. Forking multiplies the surface and breeds diamo