Roadmap question: would a spec-first OpenAPI workflow fit Cot?

[firas-yangui]

Hi! I’m new to Cot and recently started contributing.

I wanted to ask whether there is a public roadmap or preferred direction for larger design ideas.

One area I’m interested in is a spec-first / contract-first API workflow. Cot already supports code-first OpenAPI generation, where Rust handlers and types generate the OpenAPI spec. I’m curious whether the project would be interested in the inverse direction too:

OpenAPI / JSON Schema spec
    -> generated Rust DTOs
    -> generated route / handler contracts
    -> Cot implementation must satisfy the spec

The goal would be to treat the API spec as the source of truth, which is useful for teams that design APIs contract-first before implementation.

A possible MVP could live as an experimental external crate or CLI tool first, for example:

• read an openapi.yaml
• generate Rust request / response DTOs
• generate handler traits or route stubs from operationId
• generate a Cot router builder
• fail generation or compilation when an operation is missing or mismatched

Initial scope could stay intentionally small:

• JSON request bodies
• JSON responses
• path parameters
• query parameters
• simple status codes
• components/schemas

Non-goals for a first version:

• full OpenAPI coverage
• replacing Cot’s current code-first OpenAPI support
• changing Cot core before the design is validated

Would this direction be interesting for Cot, perhaps as a separate experimental crate or tool first? If yes, I’d be happy to write a small RFC / MVP design before implementing anything large.

[seqre]

Hello @firas-yangui, that's actually a great idea that I'd love to see working! Having said that, we haven't thought so far about something like this. I imagine it as an extension of the cot-cli, I think it would fit well there. From my side, feel free to create MVP design or you can wait until @m4tx or @ElijahAhianyo share their point of view!