joeyutong commented on PR #918: URL: https://github.com/apache/flink-agents/pull/918#issuecomment-5068739384
I evaluated this Skill with clean-workspace scenarios covering both its workflow and generated artifacts. The case numbers below are internal identifiers; each finding includes the relevant input, expectation, and observed issue. ### Case 013: Keep generated artifacts consistent with the selected target version The input selected Flink Agents 0.3.0, Flink 2.0.2, YAML, and Python, with the release-0.3.0 source and schema available. The expected behavior was to bind the generated YAML to that selected release. Instead, the result used `trigger_conditions` from the bundled/current example, while release-0.3.0 requires `listen_to`. Since the latest source uses `trigger_conditions`, I do not think this review should prescribe one field as the universal fix. Could you make the support policy explicit and consistent—either make the patterns version-aware when older releases are selectable, or scope the Skill to the current snapshot and stop presenting incompatible historical releases as supported targets? A version offered to the user should not produce artifacts using another version's YAML contract. ### Case 016: Make the no-invented-business-logic boundary operational The input specified only the high-level flow: retrieve context, invoke a chat model, allow an order-query Tool/runtime Skill, and emit an answer. It did not define the input-to-query mapping, context formatting, chat-message construction, or output contract. The expected result was importable Action skeletons that fail explicitly. Instead, the generated Actions chose those transformations and added tests that asserted the invented behavior. Could we strengthen the current boundary with an explicit checklist or equivalent constraint logic? For each custom Action, Tool, or domain client, first classify its business contract as supplied or unresolved using only user requirements, existing code, and tests. If unresolved, allow only a signature, focused TODO, and explicit failure; do not emit events, transform payloads, compose messages, return business data, or add tests that assert those behaviors. The exact mechanism can be left to the contributor, but it should be more operational than the current general “do not invent business behavior” rule. -- 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]
