diff --git a/docs/fixtures/index.html b/docs/fixtures/index.html index acbfc9e2..51c07e1a 100644 --- a/docs/fixtures/index.html +++ b/docs/fixtures/index.html @@ -166,8 +166,9 @@
true when at least one role: "tool" message is present;
- false when none are. Stateless alternative to ordering fixtures by
+ true when the current turn (the messages after the last
+ role: "user" message) contains a role: "tool" result;
+ false when it does not. Stateless alternative to ordering fixtures by
toolCallId. See Multi-Turn Conversations
- Two additional fields inspect the full message array rather than just the tail: + Two additional fields derive their value from the request shape rather than from a single + tail message:
hasToolResult checks whether any role: "tool" message
- exists in the request. true means “this request carries tool
- results”; false means “no tools have executed yet.”
+ hasToolResult checks whether the current turn — the
+ messages after the last role: "user" message — contains a
+ role: "tool" result. true means “a tool has executed in
+ this turn”; false means “no tool result yet this turn.”
+ It is scoped to the current turn, not the whole conversation — that is what keeps
+ the leg-1 tool-call fixture (false) and the leg-2 narration fixture
+ (true) working on every turn of a multi-turn session, because
+ earlier turns’ tool results no longer force true forever. (If the
+ request carries no user message at all, it falls back to scanning the whole
+ conversation.)
- hasToolResult checks whether the request contains any
- role: "tool" messages. For a simple two-step tool round, this is often
- simpler than turnIndex:
+ hasToolResult checks whether the current turn (the messages after
+ the last role: "user" message) contains a role: "tool" result.
+ For a simple two-step tool round, this is often simpler than turnIndex:
hasToolResultrole: "tool" presence. Stateless. Does not require
- pinning a specific tool_call_id.
+ Boolean check for role: "tool" presence in the current turn. Stateless.
+ Does not require pinning a specific tool_call_id.
inputText), the normalized model becomes model, and for chat
requests the recorder also writes the multi-turn disambiguators
turnIndex (the number of assistant messages already in the conversation) and
- hasToolResult (whether a tool-result message is present). If no match
- criteria can be derived (e.g., empty messages), the fixture is saved to disk with a
- warning but not registered in memory.
+ hasToolResult (whether the current turn — the messages after the last
+ user message — contains a tool result). If no match criteria can be derived (e.g.,
+ empty messages), the fixture is saved to disk with a warning but not registered in memory.
match.userMessage), the normalized
model, and two shape disambiguators read off the request itself:
turnIndex (how many assistant messages the conversation already contains) and
- hasToolResult (whether a tool-result message is present). Embedding requests
- key on the input text instead. There is no history-based fingerprinting of the full
- request body — but because a growing conversation carries a growing
- turnIndex, successive turns that happen to end with the same user message
- still record as distinct fixtures.
+ hasToolResult (whether the current turn — the messages after the last
+ user message — contains a tool result). Embedding requests key on the input text
+ instead. There is no history-based fingerprinting of the full request body — but
+ because a growing conversation carries a growing turnIndex, successive turns
+ that happen to end with the same user message still record as distinct fixtures.