refactor(hotel_receptionist): split scenarios into scoped and open-ended files - #2390
refactor(hotel_receptionist): split scenarios into scoped and open-ended files#2390rosetta-livekit-bot[bot] wants to merge 1 commit into
Conversation
|
| @@ -0,0 +1,1476 @@ | |||
| # Open-ended and adversarial scenarios: disputes, complaints, policy/info Q&A, | |||
There was a problem hiding this comment.
🟡 Scenario split breaks license validation
After the split, both scenario files fall outside REUSE.toml metadata coverage. The mandatory REUSE check rejects them and blocks every PR build.
Prompt for agents
Update the license metadata for both examples/src/hotel_receptionist/scenarios_guardrails_and_faq.yaml and examples/src/hotel_receptionist/scenarios_tool_accuracy.yaml. Either add valid SPDX headers to both YAML files or replace the obsolete scenarios.yaml entry in REUSE.toml with paths covering both split files, then verify the REUSE-3.2 check passes.
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
Ports livekit/agents#7065 by splitting the hotel receptionist scenario suite into:
scenarios_tool_accuracy.yaml: 57 deterministic tool-flow scenarios withuserdata.expected_statescenarios_guardrails_and_faq.yaml: 43 open-ended, adversarial, policy, and FAQ scenarios graded onagent_expectationsonlyScenario bodies retain the existing TypeScript-port adaptations. The parsed union is content-identical to the original 100-scenario target suite, and scenario membership/order exactly matches the authoritative source PR.
Source diff coverage
examples/hotel_receptionist/scenarios_guardrails_and_faq.yaml: adapted toexamples/src/hotel_receptionist/scenarios_guardrails_and_faq.yaml. Ported the new 43-scenario open-ended/adversarial suite and source header/name while retaining existing target-specific JS scenario wording and tags.examples/hotel_receptionist/scenarios_tool_accuracy.yaml: adapted toexamples/src/hotel_receptionist/scenarios_tool_accuracy.yaml. Renamed and split the targetscenarios.yamlcounterpart into the 57 deterministicexpected_statescenarios, preserving existing target-specific JS scenario wording and tags.Validation
pnpm build --filter=livekit-agents-examples...pnpm --filter livekit-agents-examples buildpnpm --filter livekit-agents-examples lint(passes with two pre-existing TSDoc warnings)pnpm --filter livekit-agents-examples test(96 passed, 2 skipped; exits nonzero becausesurvey_agent.test.tsemits two asynchronous pre-existingFakeLLM"No input text found" unhandled rejections after its tests complete)No changeset is included because only the private, changeset-ignored examples package is touched and no package code changed.
Ported from livekit/agents#7065
Original PR description
What
Splits
examples/hotel_receptionist/scenarios.yaml(100 scenarios) into two files, as agreed in the 2026-08-27 eng sync:scenarios_tool_flows.yaml(57) — scoped tool-based scenarios. Every scenario drives a concrete tool flow to a deterministic end state and is graded on the final DB diff (userdata.expected_state) in addition toagent_expectations. These are the ones representative of real customer flows and usable to evaluate simulation quality.scenarios_guardrails_and_faq.yaml(43) — open-ended/adversarial scenarios: disputes, complaints, policy/info Q&A, guardrail probes (prompt extraction, privacy pressure, harmful requests), and judgment calls. Graded onagent_expectationsonly; useful for guardrail testing, not sim-quality evaluation.Split criterion
Presence of a deterministic
userdata.expected_state— the objective encoding of "scoped tool-based": the scenario's outcome is asserted as DB state written through the agent's tools. Everything NL-judge-only goes to the guardrails file. If any individual scenario should live on the other side, moving it is a pure cut/paste.Guarantees
The split was done textually (comments and formatting preserved) and validated by script:
expected_state; no guardrails/faq scenario doesOnly the file headers and the two suite
namefields are new. Nothing in the repo referencesscenarios.yamlby path, so no code changes are needed.