Given this should the prompt pruning process co-ordinate the stubs that are output? This relates to #1838 in that during a run it may be advantageous to ensure the same stubs are used across probes that can utilize them.

This is no longer the case, intents come from run.spec per #1866.

cas does not seem like a top level option to me, but more something that is part of the run configuration. Do we want to retain expand_intent_tree and serve_detectorless_intents? Both these options seem possible to eliminate, I don't see a reason to ever not expand a tree and removal of a leaf could be achived with negative(-) intent selection entries. Probes should come with a primary detector that acting as a fallback avoiding the reason to have serve_detectorless_intents.

As to trust_code_stubs I am not sold this should exist either. Currently these are all deployed code that is part of the install so the trust level can be implied. If future additions allow code based extension imported from the user XDG data path I could see adding this however again this could be a run level restriction to allow code from XDG paths more generally to support a user supplied plugin.

• expand_intent_tree: Agreed! In PR fix: drop name fallback for stub-less intents #1876, we're removing the intent name fallback. As a result, any non-leaf intent will log a warning that it has no stubs and will be skipped. Since today all non-leaf intents have empty default_stubs, setting expand_intent_tree=False no longer makes sense.

• serve_detectorless_intents: I'm not entirely certain we should remove it. In fact, intents without a mapped detector fall back to the probe's detector. However, we only use this fallback if serve_detectorless_intents=True. With serve_detectorless_intents=False, these intents aren't served by IntentService. On the other hand, we need to consider that probe_detector_names depends on what the probe declares. For GrandmaIntent, the default is always.Fail, so serving detectorless intents with =True results in unreliable detections.

• trust_code_stubs: Agreed.

The reasoning to keep serve_detectorless_intents is unclear, I would hazard the current fallback to alwaysFail in the first IntentProbe implementation indicates to me that the primary detector may have simply been a placeholder that could be reconsidered. Though, I could also see it as logical to have the default detector when no intent specific detector is available be always.Fail since how to detect success is not defined for a specific random intent stub.