[jasper-yl]

Which issue or RFC does this PR close?

Refs #2398 (item 4: prepared context is never injected into Responses requests).

This PR is stacked on #2399, which keeps Responses user messages in the canonical form and forwards every other item verbatim. Until #2399 merges, this PR also shows its commit; the change here is the last commit, feat(gateway): inject prepared context into Responses requests.

Rationale for this change

The Responses route never injects prepared context. Three things were missing:

• inject_context is set only for the Chat route.
• The recall query and the injection target only recognize content parts of type text. Responses user input uses input_text, so even with injection enabled, no query would be extracted.
• The declared location is always rooted at /messages/{i}/.... A Responses body has no messages, so Core would check the wrong bytes.

What changes are included in this PR?

• WireRenderer::message_list_key() names the top-level key of the message list in the rendered body: messages by default, input for OpenAiResponsesRenderer. GatewayRenderer delegates. The executor builds the declared JSON pointer from it, so the pointer matches the body that is checked and sent.
• A shared is_text_part accepts text and input_text parts, both for the recall query and for the injection target. The injection itself is unchanged: the block is prepended to the first text part of the last user message, and its byte range is declared.
• PC_GATEWAY_INJECTION=on now enables injection on both routes, so a deployment that turns injection on gets it for Responses clients such as Codex too. PC_GATEWAY_INJECTION_RESPONSES=off keeps the Responses route uninjected, for operators who want to roll it out separately.
• gateway/README.md documents both variables.

Are there any user-facing changes?

Yes, for deployments that set PC_GATEWAY_INJECTION=on: Responses requests are now injected as well. Set PC_GATEWAY_INJECTION_RESPONSES=off to keep the previous behavior. Deployments without injection are unchanged.

How was this change tested?

• cargo fmt --all -- --check, cargo clippy --all-targets -- -D warnings and cargo test in gateway/, all clean.

• New tests:

  • responses_injection_targets_input_text_and_declares_input_pointer (executor, with the real OpenAiResponsesRenderer): the recall query comes from input_text parts, the declared pointer is /input/1/content/0/text, and the declared byte range of the rendered body that goes to the check is exactly the injected block. Other parts and the preceding developer item are unchanged.
  • responses_injection_follows_the_injection_switch_unless_opted_out (ingress): the switch matrix.

  Reverting the pointer root or the input_text recognition makes the executor test fail.

• End to end against a master Server in enforcing mode, with an openai-responses target pointing at a local recorder, one remembered fact in the scope, and a Codex 0.145 request (stream: true). With Responses injection off, the upstream body equals the request. With it on, the prepared context is prepended to the task text, every other item is unchanged, and Core's before_send and before_release checks both accept the declared location.

AI usage statement

Built with Claude Code (Claude Opus 5.5), which wrote the change and the tests and ran the checks above.

🤖 Generated with Claude Code

[hidb4ai]

One correctness issue remains: enabling Responses injection rejects supported string-content messages before they reach the upstream. Reproduction and the required behavior are inline.

[hidb4ai]

LGTM