A plugin step that re-triggers itself on every save

Plugin step writes a column its own trigger filters on.

The step re-queues itself on every save, doubling side effects and burning depth budget. Only the platform's depth guard keeps it from an infinite loop.

For each update step, compare its filtering attributes against the columns its code writes. Any overlap is the finding. The filtering attributes are in the registration; the writes need the source or a look at what the step actually does. The classic symptom is a value that comes back after you correct it.

Move the write to a PreOperation Target modification, or drop the column from the step's filter.

This one is environment health, so it carries a plain label and no control mapping. Presenting an operational gap as a security finding would make the real security findings harder to trust, so we keep the two apart.

• Two plugin steps at the same execution order writing one column
• A plugin registered twice on the same message
• An update plugin step with no filtering attributes
• A plugin step on Retrieve or RetrieveMultiple