luigidemasi opened a new issue, #68: URL: https://github.com/apache/camel-kit/issues/68
> Imported from [luigidemasi/camel-kit#121](https://github.com/luigidemasi/camel-kit/issues/121), opened by [luigidemasi](https://github.com/luigidemasi) on 2026-06-29. > Closed by [luigidemasi/camel-kit#122](https://github.com/luigidemasi/camel-kit/pull/122), merged on 2026-06-29. --- ## Description The shipped Camel Kit skills/guides/personas have several semantic inconsistencies that can degrade generated Camel code even though the current structural tests pass. The main problem is workflow drift: newer pipeline artifacts and runtime vocabulary are mixed with older `/camel-implement` / per-flow TDD assumptions. This can cause agents to select the wrong runtime branch, read stale or nonexistent design artifacts, duplicate catalog verification work, or leave unresolved template values. ## Problems to Address 1. Runtime naming is inconsistent across skills: - `shared/mcp-setup.md` defines MCP/config runtime values as `main`, `spring-boot`, and `quarkus`. - Implementation/debug/verify guides still use `jbang` and `springboot`. - This can lead to invalid MCP calls or incorrect runtime-specific generation paths. 2. The artifact model is split between the new pipeline and legacy TDD paths: - Newer flow uses `docs/camel-kit/<PIPELINE_ID>/design-spec.md`. - Several guides still read/write `docs/flows/{flow-name}/{flow-name}.tdd.md`. - Execute/re-plan/test-data logic may therefore miss the actual design context. 3. Migration guides still point to legacy commands: - Migration output guides reference `/camel-implement`, `/camel-validate`, and `/camel-test`. - The current workflow should route through `/camel-plan` and `/camel-execute`. 4. Spring Boot generation depends on an implicit external lookup: - The Spring Boot POM template requires `[SPRING_BOOT_VERSION]`. - The selected version is not persisted in `.camel-kit/config.properties` or the design spec. - This can leave placeholders unresolved or cause agents to guess the plugin version. 5. Catalog verification rules conflict: - `camel-execute` says the preverified catalog summary should be the source of truth. - Implementer/persona guides still require every implementer to re-verify every artifact through MCP. - This increases noise and can produce inconsistent guidance. 6. Iron Law references are out of sync: - `shared/iron-laws.md` defines Constitution Compliance as Iron Law 2. - Several guides/personas refer to it as Iron Law 3. 7. Execute orchestration and implementer summaries conflict: - `camel-execute` requires terse task completion handoff. - The implementer guide still asks for verbose completion and next-step summaries. ## Expected Behavior The skills should use one consistent workflow model: - Canonical runtime values should be `main`, `spring-boot`, and `quarkus`, with any legacy command/runtime aliases mapped explicitly. - All active guides should agree on whether the source of truth is `docs/camel-kit/<PIPELINE_ID>/...` or per-flow TDD files. - Migration output should feed the current plan/execute workflow. - Spring Boot version selection should be deterministic and persisted. - Catalog verification should have one clear contract. - Iron Law references should match `shared/iron-laws.md`. - Subagent output rules should align with `camel-execute`. ## Suggested Fixes - Add semantic tests/lints for stale tokens such as `springboot`, `jbang`, `docs/flows`, `/camel-implement`, `/camel-test`, `camel.version`, and mismatched Iron Law references. - Centralize runtime mapping in one shared guide. - Update migration, execute, implementer, debug, verify, and test-data guides to the same artifact model. - Persist `project.springBootVersion` or provide a deterministic resolver during version selection. - Clarify that preverified catalog summaries satisfy artifact verification unless no summary is available. ## Verification Current structural tests pass: ```bash ./mvnw -pl camel-kit-core -Dtest=DefaultGeneratorTest,WorkflowManifestTest,ShippedAssetStructureTest test ``` Result: 40 tests passing. -- 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]
