Yeah, I don't think this is possible when matching an expression against a list of possibilities.

It's sometimes possible in a subset of other cases when matching only against a single block with simplifying assumptions, but even in cases where it's possible I think "does not match <simple regexp>" is preferable to "does match <complicated regexp with lookbehinds / weird stuff no one uses>".

I actually thought I added this the last time I was in there, but obviously didn't. Maybe there was something complicated that I'm forgetting, but let me take a quick look and see if this is messier than I think.

After D15254, you should be able to use either "does not contain" or "does not match regexp" against text or list-of-text fields, including "Affected files".

Note that "Affected files does not contain CONTRIBUTING.md" will incorrectly fail to match if the author touches "/x/y/z/secret/depths/CONTRIBUTING.md". If you want to make sure you're matching at the root, use (^/CONTRIBUTING\.md\z) or similar. Here's an example setup that seemed to work for me locally (although I wrote a diff rule, since they're easier to test), from D15254:

Oh, the weird/nonstandard stuff in my regexp, if you or some future reader hasn't seen it before:

• (...) - These are valid delimiters, like the standard /.../. You could just use @...@ or similar instead. /.../ is also fine, but you'll have to escape the / in the path if you use that.
• \z - This is "end of input", like the opposite of ^. Otherwise, with $, we'd match the filename /CONTRIBUTING.md\n, with a literal newline at the end. I'm not sure you can commit that to any VCS, but wouldn't be surprised. We had one semi-security-bug a while ago with $ matching before "\n" so I've been trying to use \z consistently since then since the intent is almost always "end of input", not "end of input, or maybe newline then end of input".

Awesome. Thank you!

No problem, thanks for the detailed request. Let me know if I missed anything or you run into trouble.