Feature/bpmn

[ademait]

💣 Describe the issue or problem you are addressing with this Pull Request

• Support for BPMN diagram

📋 Describe the solution you implemented

• Based on how the agents acts in other diagrams, I provide the same tailored for BPMN.
• Tested locally by adding/removing elements, setting guardrails to avoid LLM hallucination (e.g., if we say to the agent to delete an element that does not exist), editing existing elements, creating processes from scratch

🤔 If any, describe alternatives you've considered

NA

[ArmenSl]

Thanks for this. It is a clean, well-structured addition that mostly follows the existing per-diagram pattern closely: the handler implements the full BaseDiagramHandler contract, the schema mirrors the sibling Modification/Target/Changes triad (Pydantic v2, exports complete), and the registry wiring (factory, metadata, protocol types, suggestions, generation_handler, model_context) is filled in everywhere the other diagram types appear. The _validate_and_refine generation path is a nice touch. A few things I would like to work through before merge, mostly around the not-found guardrail and staying close to the base class.

1. The "element does not exist" guardrail is not actually enforced on the modification path. This is the main one. Right now the only existence check for add_flow/remove_flow/modify_node/remove_element is the LLM self-reporting elementFound (base_handler.py:372). Nothing validates that changes.source/changes.target/target.nodeId actually exist in the current diagram before the spec is forwarded to the WME, so a model that hallucinates an id and still says elementFound: true will ship a bogus modification. The generation path validates refs, but generate_modification does not. Two related points:

• getattr(parsed, 'elementFound', True) defaults to "found" when the field is missing, so a malformed response fails open. For the destructive actions (remove/modify) it would be safer to default to not-found.
• The good news is the fix is already half-written: _bpmn_resolve can resolve every endpoint/target against current_model["elements"] and drop or refuse modifications whose refs do not exist, which is exactly the guarantee the PR description is going for.

2. The handler re-implements a fair amount that the base class and model_context already provide. _bpmn_mod_message, _bpmn_single_mod_sentence, _bpmn_resolve and the subtype-label maps (~150 lines) hand-roll message building and element lookup that the siblings get from the base _friendly_batch_message/_build_mod_target_name path and from model_context. StateMachineHandler.generate_modification just returns _execute_modification(...) and lets the base build the message. Routing the BPMN handler through the same path (and extending the base target-naming only where flow endpoints genuinely need it) would cut the custom code and keep it consistent. It also dovetails with point 1, since the resolver you already have becomes the validation hook.

3. The tests cover the message builder, but not the behaviour or the guardrail. test_bpmn.py exercises _bpmn_mod_message in isolation, but nothing drives generate_modification/generate_complete_system with a mocked predict_structured the way test_prompt_caching.py does, so the actual add/modify/remove application and the elementFound short-circuit are untested, and remove_flow has no test at all. Since the guardrail is the headline feature, a test that returns BPMNModificationResponse(elementFound=False, modifications=[]) and asserts the plain assistant reply would be worth adding.

4. A couple of diagram-type lists were not updated for BPMN. The live routing path is fully BPMN-aware, but the request planner's allowed-type prompt still hardcodes the six other types and omits BPMN (orchestrator/request_planner.py:752), so the planner can be told BPMN is not a valid output even when the keyword hint points at it. That file is not in this PR, but it looks like the one place that could stop BPMN from being selected in a multi-step request, so worth adding |BPMN there (ideally built from SUPPORTED_DIAGRAM_TYPES). Smaller siblings of the same kind: no _HEURISTIC_BPMN fast-path in _SINGLE_DIAGRAM_HEURISTICS, and the modeling-help branch in state_bodies.py:339 has a tailored block for Quantum but BPMN falls to the generic else.

Minor:

• schemas/bpmn.py:182: the default_factory=list on modifications (vs the siblings' min_length=1) is the correct choice for the elementFound=false empty-list case, but a one-line comment noting why would help, since it reads as an inconsistency otherwise.
• base_handler.py:679: full prompt content (including user diagram text) is logged at INFO on every structured call; worth gating behind DEBUG.
• User node names are interpolated verbatim into the prompt; output is schema-constrained so the blast radius is small, but fencing the diagram context as an untrusted block would be tidy.
• The dead IMPLICIT_TARGET_RULES dict omits BPMN (harmless, it is unused), and .gitignore is missing a trailing newline.

None of the minors block anything. Items 1 to 4 are the ones I would want addressed, and 1 is the only thing I would call a must-fix. Really solid groundwork overall, and the pattern-matching to the other handlers is most of the way there. Happy to look again once the guardrail has a server-side check and the tests drive the real path.