---

This section details on the original issue you should resolve

<issue_title>[Improvement] - Possible enhancements or user awareness on the string matching on the body</issue_title>
<issue_description>The stdinBody.contains compare that is being done here, is misleading. If we want to capture the initialized method as per the spec, the string.contains will also glob notifications/initialized which can be problematic.

Ideas to circumvent the problem:

1. Allow the use of regular expressions to capture the required fragment
2. Introduce different properties to do a string.equals instead of a string.contains
3. Keep the behavior as is, but warn the users that the comparison is a contains and that edge cases such as above can produce incorrect results. Instead instruct users to pass a fragment of the JSON rather than a string that is contained in a property value of the json from the STDIN.

There may be other ways. Happy to brainstorm.</issue_description>

<agent_instructions>Implement this feature. Go through the comments to understand how. If anything's unclear, check first before writing code.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@waldekmastykarz Good catch and a great idea! @waldekmastykarz Thinking about the options, we already support `contains` and the property name, specifically `fragment` indicates (albeit perhaps not explicitly enough?) that it's a partial match. How would you suggest we warn the user? Would a squiggly in VSCode through the Dev Proxy Toolkit extension be sufficient? Wouldn't it be annoying when you know about that behavior and don't want to be reminded again? @waldekmastykarz So basically let user specify either the bodyFragment, which is a string contains, or a regex, which can be either full or partial match depending on the specified pattern, correct?