FEAT: Support custom scenarios over selected dataset examples #2760

Is your feature request related to a problem? Please describe.

The explorer's multi-select flow needs an ordinary scenario over exactly the selected examples, defaulting to prompt sending. Reusing another scenario's defaults could unexpectedly add techniques, sample away selections, or run prompt sending twice as both a technique and baseline.

Work item 14 of 17 in #2744. Technical prerequisites: the general scorer registry API in #2755 (completed in #2990) and the exact-selection/scorer-reference contract in #2757. Keep not ready yet until promoted.

Describe the solution you'd like

Add only the smallest scenario/configuration adapter still needed after #2757 resolves exact selected examples. Reuse Scenario, DatasetAttackConfiguration(seed_groups=..., max_total="all"), existing attack factories/builders, scorer resolution, and normal progress/results/history.

Current technique.execute already implements one-technique configuration, optional saved history, run-local editing, objective-scorer selection, and explicit baseline policy. It deliberately accepts one free-text objective and removes dataset inputs; it is a reuse pattern, not an already-complete multi-example scenario or a reason to widen its contract here. Do not rebuild its UI/runner or loop over REST launches to mimic one scenario.

• The default effective attack is exactly prompt sending with no additional converters. Do not fall back to another scenario's default technique set or emit a duplicate baseline for the same population.
• Accept a compatible configured objective scorer through the existing objective_scorer: RegisteredComponentReference (registry_name plus identifier_hash), retained by FEAT GUI: Accept exact seed selections in scenario requests #2757. Reuse shared source-pinned resolution and Scenario._get_default_objective_scorer/registry default policy rather than add a name-only resolver or new global defaults. For the selected-example consumer, verify the configured default and required condition coverage. A missing, changed, or incompatible explicit choice must not silently select another scorer. Missing/unusable prerequisites need actionable setup guidance, never an incompatible or unscored run.
• Reuse configured composites and inverters where appropriate. Catalog membership, a class name, or a true_false result family alone does not prove objective compatibility. Keep scorer-specific checks in shared scorer/registry/core policy; backend models and services adapt that policy rather than creating another compatibility table.
• Preserve objective-result meaning: raw refusal=true means refusal, not attack success. Use appropriate existing inverter/composite semantics. raise_if_scorer_blocks concerns the scoring target blocking a judging request; it is not a refusal-result polarity switch.
• Require valid objectives; preserve source objectives and accept explicit user-supplied objectives for examples that need them instead of inventing goals.
• Resolve explicit selections through the contract from item 13. Retain group boundaries, roles, multimodal content, and provenance. Explain unsupported seed shapes rather than flattening templates or simulated configuration into text.
• Expose supported registered techniques and converter-composition seams for the later UI. Attacks/converters/scorers keep their normal responsibilities; the scenario packages them and owns execution orchestration.
• Use registry-compatible construction and metadata introspection without fetching datasets or generating conversations. Validate execution prerequisites at the appropriate run/setup boundary.

Acceptance criteria:

• N valid selected examples with default settings produce exactly N prompt-sending executions, not N plus an extra baseline/default attack set.
• Missing objectives/scorers, incompatible modalities/techniques, and invalid groups produce actionable validation errors.
• Tagged compatible defaults, non-default explicit choices, configured composites/inverters, and raw-refusal semantics are covered by focused tests.
• Empty registries, missing/incompatible defaults, missing scorer dependencies, unknown/stale requested names, and registry reinitialization have defined errors or setup guidance without silently replacing an explicit selection.
• Read-only estimates and confirmed launch use the same explicit selection and effective configured scorer, target, and technique configuration.
• Normal scenario progress, results/history, and supported resume behavior preserve the selected population and provenance.
• Existing scenarios' defaults and named-dataset behavior do not change.
• Focused scenario/service tests use local fixtures and fake targets/scorers, with no paid calls.

Describe alternatives you've considered, if relevant

Do not create a GUI-specific batch executor, generate Python scenario classes from user text, add an unscored mode, or redesign memory. Avoid adding a duplicate global prompt-sending factory merely to work around baseline semantics.

Additional context

This item retains the selected-population objective-compatibility, default-selection, and result-polarity acceptance from #2755. General discovery, source-pinned explicit selection, and core default-scorer handling already exist. Extend only demonstrated gaps in that shared policy for this consumer; do not recreate the registry, defaults, or constructor resolver. Reuse the existing picker in #2759 without moving scorer logic into HTTP DTOs or the browser.

Start with Scenario, DatasetAttackConfiguration, MatrixAtomicAttackBuilder, AttackTechniqueRegistry, ScorerRegistry, and existing matrix-shaped scenarios as patterns. The core technique catalog intentionally omits bare prompt sending because it is normally a baseline; handle the custom scenario's default deliberately. Read doc\code\framework.md and scenario/setup-technique/model/test instructions.

Relationship to scenario dataset generation

The scenario dataset plan is complementary: it supplies generated named data and shared preparation, while this adapter runs exactly the stored examples selected in the explorer. Source/limit preparation (#2956), configured providers (#3116), and #3143's scenario-owned options/shared wire settings are merged. Reuse them; do not build another preparation lifecycle or generic runner.

This adapter's input population remains the exact selection resolved by #2757. Current generic attack configuration defaults can cap named sources at five each or inline inputs at five total. Configure the selected-input path deliberately so neither cap, random sampling, or named-source overrides change N selected examples; null/default is not an uncapped value. Missing or changed selected records must fail rather than invoking a configured provider to generate replacements.

Generated SeedObjective rows are ordinary stored objectives here. Preserve them and their provenance; missing objectives still need explicit user input, not automatic generation. This scorer judges the attack outcome, not generation quality. Explicit scenario refresh is already merged in #3206; it must not regenerate an exact selection. New generation controls or additional destructive-refresh UX are optional, not adapter prerequisites. Scope refreshed against main 791e12c6e5e4302e7c1211af6af8973aa6fe1f37 on October 31, 2026; release gates are unchanged.