saqib mirandClaude Sonnet 5
846b9e8dca
Maps the feature onto the three existing orchestration/{routing,
assignments,orchestration} scaffold stubs. Key decisions: Assignment
refined as a version-row-per-period model (paired with a separate
append-only AssignmentHistory event log), round-robin concurrency
safety via atomic Redis INCR (reusing existing infra, not a new one),
LEAST_LOADED/SKILL_BASED tie-breaks falling back to that same cursor,
currentLoad read but never mutated by this feature, and the escalation
trigger reusing 005's existing domain-event bus rather than a new
notification path.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.5 KiB
3.5 KiB
Quickstart: Validating Orchestration and Assignment
Prerequisites: migrations applied; at least one team/agent/hierarchy node set up per 006-support-organization's own quickstart, since this feature is a real consumer of that data.
Scenario 1 — automatic resolution on human escalation (User Story 1)
- Configure a hierarchy node scoped to a product with a required skill; give one agent that skill.
- Create a ticket for that product and force it to
HUMAN_ESCALATION(e.g., via 003's status update endpoint, or 005's confidence-threshold escalation path). - Expected: without any further caller action, an
Assignmentis created for the skilled agent, and the ticket's status becomesIN_PROGRESS. - Repeat for a product with no matching hierarchy node. Expected: orchestration still runs, falling back to a skill-only match across all active agents.
Scenario 2 — pluggable strategies, including concurrency-safe round robin (User Story 2)
- Configure a node with
ROUND_ROBINand three eligible agents. Escalate three tickets in sequence. Expected: each is assigned to a different agent; a fourth escalation cycles back to the first agent. - Fire two escalations against the same eligible set at the same time (e.g., two concurrent requests). Expected: they resolve to two different agents (for a set of two or more), and a subsequent, sequential escalation continues the cycle correctly — no skipped or repeated position.
- Configure
LEAST_LOADED; set two agents'currentLoadto different values. Escalate a ticket. Expected: the lower-load agent is chosen. - Configure
SKILL_BASED; give two agents the required skill at different proficiency levels. Escalate a ticket. Expected: the higher-level agent is chosen. - Escalate a ticket whose context resolves to zero eligible agents. Expected: no
Assignmentis created, the ticket stays inHUMAN_ESCALATION, and anAssignmentHistoryrow withagentId: nullexists.
Scenario 3 — durable history across reassignment (User Story 3)
- Assign a ticket (Scenario 1). Manually reassign it (Scenario 4) to a different agent.
GET /tickets/:ticketId/assignment-history. Expected: both the original assignment and the reassignment are present, in order, each with its ownstrategy/actor.GET /tickets/:ticketId/assignment. Expected: reflects only the most recent assignment.
Scenario 4 — manual assignment and reassignment (User Story 4)
POST /admin/tickets/:ticketId/assignmentwith a specificagentId. Expected: that agent becomes the current assignment regardless of what the configured strategy would have picked.- Repeat with a nonexistent
agentId. Expected:404, noAssignmentrow created. - Repeat step 1 with a different agent. Expected: the ticket's current assignment changes; the prior one remains in history (Scenario 3).
Scenario 5 — re-escalation reassigns fresh (User Story 5)
- From an already-assigned ticket, trigger
HUMAN_ESCALATIONagain. - Expected: a fresh eligible-agent set is computed (not reused from the first assignment)
and a new
Assignmentis created; the previous one is no longer current but remains in history.
What "done" looks like
All five scenarios pass, and together they demonstrate every functional requirement and success
criterion in spec.md — including SC-002, which specifically requires verifying concurrency
safety under genuinely concurrent load, not just sequential calls.