Deriving tool approval from capabilities() at registration?

[neerazz]

The rlm_eval advisory notes the trait default at spec.rs:632-633 would have returned
Required for anything with ExecutesCode, and that the tool overrode it to Auto.

Was deriving approval from capabilities() at registration considered and ruled out for a
reason I'm not seeing?

[neerazz]

@0xEr3n — What your git_show report surfaces is that the tool was registered ApprovalRequirement::Auto
and declared ToolCapability::ReadOnly. The one moment a human could object was removed by a
declaration that wasn't true.

Did you find it by reading the registry for tools whose declared capability didn't match their
argv, or from the other direction — git flags first, then hunting for a caller?

[neerazz]

@sai-sh — Your rlm_eval report showed something the first advisory didn't. The engine's
approval_required is two AND-ed conditions, so a per-tool Auto makes the operator's
--approval-policy unreachable — not overridden, never read.

The advisory notes the same fix never reached rlm_open either. Did you see other tools
overriding the default the same way, or were those two isolated?

[Hmbown]

The rlm_eval advisory notes the trait default at spec.rs:632-633 would have returned
Required for anything with ExecutesCode, and that the tool overrode it to Auto.

Was deriving approval from capabilities() at registration considered and ruled out for a
reason I'm not seeing?

let me take a look at this - thank you!