Is your feature request related to a problem? Please describe.
PR #2503 makes the adversarial simulated-conversation prompt canonical as a SeedPrompt, but simulated_target_system_prompt_path and next_message_system_prompt_path still flow through AttackTechniqueFactory, SeedSimulatedConversation, AttackParameters, and execution as runtime file paths.
That leaves one configuration object with mixed prompt representations, makes the remaining prompt content harder to inspect or modify during attack generation, and keeps execution coupled to local files. It also leaves prompt loading/rendering responsibilities split across the model and executor; the next-message YAML is currently loaded synchronously from an async execution path.
Describe the solution you'd like
Plan and implement a coordinated migration for the remaining simulated-conversation system prompts:
- Add canonical
simulated_target_system_prompt: SeedPrompt | None and next_message_system_prompt: SeedPrompt | None inputs.
- Make the preferred factory and execution flow
SeedPrompt-only for all three prompt roles.
- Load YAML at setup/composition boundaries with
SeedPrompt.from_yaml_file(...) and carry prompt data—not paths—through models, attack parameters, and executors.
- Keep the existing
*_path fields/parameters as compatibility adapters for direct callers and persisted legacy records; define a safe warning/removal window rather than removing them immediately.
- Move file loading out of async execution and move prompt loading/rendering helpers out of the canonical data model where appropriate.
- Preserve each surface's existing defaults, including the compliant simulated-target prompt, direct next-message prompt,
final_user_message behavior, and the direct generator's optional simulated-target behavior.
- Preserve deterministic serialization/hashing, response schemas, template parameters/metadata, sequence ranges, and database round-trips for both legacy path-backed and canonical inline representations.
- Decide how
SimulatedTargetSystemPromptPaths and NextMessageSystemPromptPaths should evolve without introducing mutable or nondeterministic shared SeedPrompt instances.
- Update call sites and paired documentation, with focused tests for validation, defaults, legacy reconstruction, execution forwarding, template rendering/schema behavior, async file I/O, and identity determinism.
Describe alternatives you've considered, if relevant
Expand #2503 to cover all prompt roles. That would make the end state more uniform immediately, but it substantially increases the PR's persistence, defaulting, rendering, public API, and documentation scope beyond the benchmark-owned adversarial-prompt gap that motivated it. Keeping #2503 as the first compatible slice and doing the remaining roles as one planned follow-up is lower risk and easier to review.
Additional context
Follow-up to #2503 and the benchmark-owned prompt work discussed in #2494. The architecture guidance in doc/code/framework.md favors passing seeds rather than runtime file paths and keeping prompt packaging in the technique/factory layer.
Is your feature request related to a problem? Please describe.
PR #2503 makes the adversarial simulated-conversation prompt canonical as a
SeedPrompt, butsimulated_target_system_prompt_pathandnext_message_system_prompt_pathstill flow throughAttackTechniqueFactory,SeedSimulatedConversation,AttackParameters, and execution as runtime file paths.That leaves one configuration object with mixed prompt representations, makes the remaining prompt content harder to inspect or modify during attack generation, and keeps execution coupled to local files. It also leaves prompt loading/rendering responsibilities split across the model and executor; the next-message YAML is currently loaded synchronously from an async execution path.
Describe the solution you'd like
Plan and implement a coordinated migration for the remaining simulated-conversation system prompts:
simulated_target_system_prompt: SeedPrompt | Noneandnext_message_system_prompt: SeedPrompt | Noneinputs.SeedPrompt-only for all three prompt roles.SeedPrompt.from_yaml_file(...)and carry prompt data—not paths—through models, attack parameters, and executors.*_pathfields/parameters as compatibility adapters for direct callers and persisted legacy records; define a safe warning/removal window rather than removing them immediately.final_user_messagebehavior, and the direct generator's optional simulated-target behavior.SimulatedTargetSystemPromptPathsandNextMessageSystemPromptPathsshould evolve without introducing mutable or nondeterministic sharedSeedPromptinstances.Describe alternatives you've considered, if relevant
Expand #2503 to cover all prompt roles. That would make the end state more uniform immediately, but it substantially increases the PR's persistence, defaulting, rendering, public API, and documentation scope beyond the benchmark-owned adversarial-prompt gap that motivated it. Keeping #2503 as the first compatible slice and doing the remaining roles as one planned follow-up is lower risk and easier to review.
Additional context
Follow-up to #2503 and the benchmark-owned prompt work discussed in #2494. The architecture guidance in
doc/code/framework.mdfavors passing seeds rather than runtime file paths and keeping prompt packaging in the technique/factory layer.