FIX Preserve converter role scoping in prepended history

[Roman Lutz (romanlutz)]

Description

Request converters could rewrite simulated-assistant history when an attack supplied a prepended conversation. This was especially easy to trigger when AIRT Jailbreak attached a template converter to conversation-based techniques such as context_compliance.

This change makes prepended conversion role-aware while preserving the logical conversation:

• Prepended request conversion defaults to user messages. Assistant and simulated-assistant conversion require explicit opt-in.
• AttackStrategy owns one resolved PrependedConversationConfig, shared normalizer resolution, and identifier provenance. Single-turn and multi-turn base classes carry that policy so concrete attacks only forward it, including SkeletonKey and factory-created attacks.
• All prepended copies are role-mapped, converted, and validated before any are written to memory.
• Prepended history remains structured in memory for every target.
• Targets without editable history receive an explicit per-send EDITABLE_HISTORY normalizer override. The default target capability policy remains unchanged, including MULTI_TURN: RAISE behavior and native guardrails such as Crescendo's editable-history requirement.
• A per-conversation TargetNormalizationContext records the exact persisted seed-message IDs and provider-attempt lifecycle. It does not infer the seed from message roles or successful responses.
• Stateful targets receive the seed once per logical conversation, then only the current request. Stateless targets receive the original seed with each current request. Unseeded targets receive only the current request.
• TAP clones remap only the original seed boundary. Copied live turns never become seed history, and a new logical conversation starts with an unconsumed seed boundary.
• processing and unknown failures and their genuinely adjacent request are excluded from replay. blocked and empty remain real provider turns.
• Concurrent sends sharing one context are rejected so stateful bootstrap context cannot be duplicated.
• Original and converted target views are rendered independently. Tokenizer generation prompts follow the live request, and live multimodal pieces retain their ordering and text-piece metadata.
• Converted non-text seed history is rejected when flattening would be lossy. Native non-text history that must be flattened becomes an explicit placeholder and emits a warning.
• Conversation scoring selects the final assistant response rather than an unrelated trailing message.
• Jailbreak excludes delivery techniques that are simulated, multi-turn, or otherwise incompatible with request-converter composition.

Why capability overrides and an explicit context

This incorporates rlundeen2's proposal to express editable-history adaptation through the target capability pipeline, while retaining explicit state for the part capabilities cannot answer.

A target capability tells us what adaptation is required. It does not tell us:

• which persisted messages are the original seed;
• whether this logical conversation has already sent that seed;
• whether a failure happened before provider invocation or after it began;
• whether a retry may safely include the seed again; or
• whether another send currently owns the bootstrap operation.

Inferring those answers from memory is ambiguous. A blocked or empty response is still a real provider round trip, a write-only target may not persist an assistant response, and a processing error may otherwise be mistaken for seed history.

TargetNormalizationContext therefore owns only the explicit seed boundary and send lifecycle. PrependedConversationConfig supplies the formatter as a per-send capability override, and the target's normalization pipeline owns the provider-facing adaptation. Centralizing that policy on AttackStrategy keeps the same configuration and identifier visible across base classes, concrete techniques, and factory construction instead of rebuilding it in each attack. This provides:

• structured, auditable memory with an ephemeral provider-facing view;
• no mutable formatter state on reusable targets;
• deterministic retry, cancellation, and concurrency behavior;
• custom formatting after converters run and while the live request is available;
• safe composition with ordinary target normalizers;
• stable behavior with sparse custom capability policies; and
• no database or GUI schema changes.

The same shared HistorySquashNormalizer implements both prepended-history adaptation and ordinary multi-turn adaptation. Lifecycle belongs to the surrounding context and capability pipeline, not to a second flattening implementation.

Processing order

1. Resolve the attack's prepended-conversation policy once and include it in attack provenance.
2. Convert and validate structured prepended messages.
3. Persist the structured prepended messages and record their message-piece IDs as the seed boundary.
4. Convert and hash the live request.
5. Acquire the target normalization context and remove non-replayable failed exchanges.
6. Select the explicit seed boundary and build the per-send EDITABLE_HISTORY override.
7. Run editable-history adaptation before cardinality-changing system, multi-turn, and JSON-schema normalizers.
8. Validate the provider-facing request, mark provider invocation, and send it.
9. Persist the logical request and response through PromptNormalizer.

A pre-provider failure leaves the seed available for retry. Once provider invocation begins, a stateful conversation consumes its seed even if the call later fails or is cancelled. A duplicated logical conversation remaps the seed IDs and starts unconsumed.

Tests and documentation

Coverage includes centralized attack-policy ownership and factory forwarding, SkeletonKey, PAIR, BargeIn, final-assistant score selection, target normalization and lifecycle, real PromptNormalizer error persistence, stateful and stateless payloads, retries and cancellation, concurrent sends, TAP retained and cloned branches, non-text converter output and placeholder warnings, custom capability policies, Crescendo requirements, configured formatters, multimodal requests, converter/factory/Jailbreak compatibility, and latest-main integration. Framework and target documentation describe component ownership, capability distinctions, processing order, branching behavior, metadata ownership, and the direct-streaming BargeIn exception.

[Richard Lundeen (rlundeen2)]

Overall I think we can make this a lot smaller. The actual bug is narrow: request converters can rewrite simulated assistant history when an attack supplies a prepended conversation. It's easy to hit with context_compliance, where the jailbreak's TextJailbreakConverter ends up rewriting the fake assistant turns. So to me this is about which messages we convert, not new machinery — and I don't think we need to touch ConversationManager or put state on Message.

Here's the direction I'd like instead:

• PrependedConversationConfig stays the sole policy for prepended history. It already picks which roles get converters (apply_converters_to_roles) and which normalizer flattens history. If we default that to ["user"], the assistant-history bug is basically fixed on its own — assistant history is simulated target output, so you have to opt in with ["assistant"] to touch it. If we ever need more control over prepended history, we add it here.
• StrategyConverterConfig gets a way to scope a converter to the first turn. This decides which messages a converter applies to, exactly like apply_converters_to_roles already does. And because it's declarative it rides in the attack identifier, so resume/eval stay deterministic for free.
• Optional implementation detail We can derive "first turn" straight from memory if we want — without threading anything new through the attacks. The normalizer already has the conversation_id and a memory handle, so it can just ask: has the target actually replied yet? Define first-turn as "no real assistant message in this conversation" (prepended turns are stored as simulated_assistant, so they don't count). The nice thing is every case falls out correctly, including the tricky ones — e.g. on a prompt_sending retry we spin up a fresh conversation, so the jailbreak is correctly re-applied, whereas a naive per-send counter would drop it. Multi-turn continuations (Crescendo, TAP nodes copied from a parent) already have a real assistant reply, so they're correctly not re-wrapped.
• Jailbreak scenario: I still like prompt_sending and jailbreak_system_prompt as the defaults. We could add one or two more to show off the scoping (e.g. role play with the jailbreak on the system prompt, or context_compliance with the jailbreak only on the first live turn). But I don't think we should just include all techniques (like how they were before this PR) — they're all a bit different, and the jailbreak locus isn't the same for each. If we do role play, is the jailbreak on the system prompt, the first turn, or every turn? That should be a deliberate choice per technique, which is exactly why the scope belongs on the config.

Net: ConversationManager keeps applying the converter list it's given (role-filtered), no eager conversion, and no _request_converters_applied marker on Message. For non-chat targets we go back to today's behavior — flatten history, prepend it, let the live send convert the block. Unless I'm missing something, that's the whole change.

[Roman Lutz (romanlutz)]

Richard Lundeen (@rlundeen2) I like FIRST_LIVE_TURN as a declarative converter scope, but it does not preserve role scoping for non-chat targets. ConversationManager flattens prepended user/assistant history and the live request into one string before PromptNormalizer runs converters. At that point the converter sees the entire joined block. The turn scope can decide whether the converter runs, but not prevent the assistant portion from being rewritten.

The proposal would work if converter scope were applied while the conversation was still structured, before target normalization/flattening. That requires either the bridge in this PR or a larger pipeline change that introduces structured history adaptation and applies origin/role/turn scope before normalization. So I think FIRST_LIVE_TURN is useful follow-up API design, but it is not by itself a replacement for the current non-chat handling.

[Richard Lundeen (rlundeen2)]

Good catch, I think ConversationManager existed before target capabilities and it shouldn't do message normalization anymore. Agreed with the issue with ConversationManager flattening things. But I don't agree with this: "a larger pipeline change that introduces structured history adaptation" because it's already built and wired. I think the following would be tighter/less error-prone and not significantly more complicated than the current approach of adding converters to the conversation manager.

PromptTarget._get_normalized_conversation_async pulls conversation history from memory, appends the live message, and runs configuration.normalize_async — all after converters have run. The pipeline is capability-gated
and already registers the normalizer that does this exact job

So the shape I'd like to land on:

1. Have initialize_context_async treat non-chat targets like chat targets — write the prepended conversation to memory, structured, with roles.
2. Drop _handle_non_chat_target_async.
3. Gate the squash on missing EDITABLE_HISTORY in the capability→normalizer table (change to ADAPT)
4. Map PrependedConversationConfig.message_normalizer onto normalizer_overrides so callers keep format control.

One wrinkle is multi turn (but not editable) targets like playwright will need to squash but not squash previous turns. But that's the idea that FIRST_TURN could identify.

Also worth noting: _handle_non_chat_target_async only mutates context.next_message and never persists, so prepended history isn't recorded as conversation history for these targets today. Moving the squash into the pipeline fixes that too.

[Roman Lutz (romanlutz)]

But this means normalization happens in the target, and history represents something different, right?

History may show 8 turns of prompt/response but it's perhaps a non-editable history target so everything gets squashed into a single prompt. History should reflect that. Unless I'm misunderstanding.