Files

T

saqib mirandClaude Sonnet 5 c18e203ad1 docs: plan and design artifacts for support organization feature

Reuses the existing identity/teams, identity/agents, and
orchestration/hierarchy scaffold directories per doc 07's documented
module placement. Key decisions: last-write-wins availability (not
optimistic locking — operational telemetry, not a durable record),
compound-unique skill upsert, cycle detection only on reparenting edits
(not creation, which can't form a cycle), and a capability-eligibility
read path that composes hierarchy scope with caller-supplied skills
while deliberately excluding availability per doc 05's own ordering.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-02 17:52:33 +05:30

2.8 KiB

Raw Blame History

Quickstart: Validating Support Organization

Prerequisites: migrations applied. No dependency on any earlier feature's data.

Scenario 1 — teams and agents, deactivation doesn't delete or cascade (User Story 1)

Create a team. Expected: active: true.
Create an agent on that team. Expected: appears in GET /admin/teams/:teamId's roster.
Deactivate the agent. Expected: absent from GET /admin/agents?active=true, still returned by GET /admin/agents/:agentId.
Reactivate the agent. Expected: reappears in the active listing.
Deactivate the team. Expected: the agent's own active value is unchanged.

Scenario 2 — skills and availability (User Story 2)

Add a skill tag with a level to an agent. Expected: appears in the agent's skill list.
Add the same tag again with a different level. Expected: one entry for that tag, updated level — not two entries.
Set the agent's availability (status: busy, working hours, no load given). Expected: currentLoad defaults to 0.
Update the same agent's availability to status: available. Expected: GET .../availability returns exactly one record, with the new status.
Attempt to set status: "not_a_real_status". Expected: 400.

Scenario 3 — the hierarchy tree (User Story 3)

Create a root hierarchy node.
Create a child node with parentId set to the root. Expected: GET .../:rootId/children returns it.
Attempt to create a node with a parentId that doesn't exist. Expected: 404.
Edit the child node's parentId to point at itself. Expected: 400 CYCLE_DETECTED.
Deactivate the root. Expected: absent from GET /admin/hierarchy-nodes?active=true; the child remains active and unaffected.
Create two sibling nodes under the same parent with order: 1 and order: 2. Expected: .../children returns them in that order.

Scenario 4 — capability eligibility (User Story 4)

Create two agents on active teams; give agent A skill x, agent B skill y.
Query /support-org/capability-eligibility?skills=x. Expected: only agent A.
Set agent A's availability to offline. Query again. Expected: agent A is still returned — availability never filters this lookup (FR-015).
Deactivate agent A. Query again. Expected: empty result — never an error.
Create a hierarchy node scoped to productScope: [productId] with skills: [z]. Query /support-org/capability-eligibility?skills=x&productId=productId for an agent who holds both x and z. Expected: that agent is returned; an agent holding only x (not z) is not.

What "done" looks like

All four scenarios pass, and together they demonstrate every functional requirement and success criterion in spec.md without needing to read the implementation to know what "correct" means.

2.8 KiB Raw Blame History