luigidemasi opened a new issue, #111: URL: https://github.com/apache/camel-kit/issues/111
> Imported from [luigidemasi/camel-kit#256](https://github.com/luigidemasi/camel-kit/issues/256), opened by [luigidemasi](https://github.com/luigidemasi) on 2026-10-20. --- ## Description During a greenfield integration interview, Camel Kit should explicitly establish whether each relevant interface contract already exists, will be supplied, or needs to be designed with the user. The current interview asks about data formats, source and destination technologies, and field mappings. It does not explicitly ask who will provide the interface definitions or whether designing new ones is in scope. This can leave an unresolved decision about API operations, request/response structures, event payloads or message schemas. For example: > Do you already have an interface definition for this integration boundary, will you provide one later, or would you like us to design it together? Examples include OpenAPI, AsyncAPI, WSDL, JSON Schema, XSD and documented message contracts. Source and target interfaces may have different answers. ## Expected behavior - Read supplied requirements and contract artifacts first. Do not repeat a question that the supplied material already resolves. - Ask about unresolved contract availability and design responsibility, one question at a time. - For existing contracts, request or locate the relevant artifacts and establish compatibility constraints. - For contracts to be supplied later, record the dependency and keep affected design decisions open; do not invent a contract to fill the gap. - For new contracts within the user's control, propose the definition for approval as part of the design before implementation. Do not assume an external system's interface can be redesigned. - Preserve the answer, artifact references, constraints and unresolved dependencies in the design record. ## Acceptance criteria - Greenfield discovery explicitly covers existing, pending and newly designed contracts, including mixed source/target cases. - Shared discovery guidance remains consistent for standalone Brainstorm and Ship without changing their existing approval or ownership boundaries. - Focused behavioral checks cover supplied contracts, missing contracts, pending artifacts and user-approved new designs. Checks must distinguish asking an unresolved question from unnecessarily repeating an answered one. - Relevant guides and examples are updated. ## Code references Verified on main at `5493c8d679d4f6ee0819bfdb7f1aa1a841e7d360`: - [Greenfield interview, per-flow questions](https://github.com/luigidemasi/camel-kit/blob/5493c8d679d4f6ee0819bfdb7f1aa1a841e7d360/camel-kit-core/src/main/resources/skills/camel-brainstorm/guides/greenfield-interview.md#L110) - [Shared discovery completeness](https://github.com/luigidemasi/camel-kit/blob/5493c8d679d4f6ee0819bfdb7f1aa1a841e7d360/camel-kit-core/src/main/resources/skills/shared/discovery-completeness.md) The shared rules already require message contracts and material decisions to be resolved; this enhancement makes the interface-contract choice explicit in the interview. ## Website impact **Required.** Update the greenfield and Brainstorm documentation to explain what interface artifacts users can supply, how pending contracts are handled, and how new contracts are proposed and approved. Website follow-up: [camel-kit-web#58](https://github.com/luigidemasi/camel-kit-web/issues/58). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
