The requirement's outcome in one sentence, and the order in which its slices get built, starting with the walking skeleton, the thinnest slice that proves the whole loop works.
Epic. A dispatcher assigns the right technician in under a minute from board suggestions: the story set instantiating the behavior specified in
Recommendation rules[1], feature committed in
the project PRD[2].
Decision: walking skeletonUS-1 see three suggestions with reasons →
US-2 accept a suggestion → US-4 assignment
recorded and technician notified. The thinnest end-to-end slice: it proves the
recommendation loop before any refinement lands. Agreed with A. Reyes (product
lead), July 9, 2026.
One card per story. Actors are the PRD's personas, never "a user". Each card fences the specified behavior it covers, then proves the fence with acceptance tests: preconditions first (stated even when there are none), concrete test rows against the FRD's scenario outlines (real values, an observable expected result, a path class, a test-case id), then postconditions. Two testers reading the same row must run the same test.
US-1Dana sees three
qualified, nearby suggestions with reasons when a job arrives
Preconditions
Job JOB-2201 created at the Toronto hub requiring skill "Gas fitting (G2)", routine priority. On-shift technicians positioned:
T-014 8 min away, T-022 19 min,
T-045 37 min (all G2-certified);
T-104 6 min away, on shift, no G2 certification. Dana signed
in as dispatcher; Priya signed in read-only.
Row
Path
Test instance
Expected observable result
Test case
AT-1
happy
JOB-2201 arrives on the board
Three suggestions render within 5 seconds, ranked
T-014, T-022,
T-045, each showing at least two true reasons
("8 min away", "G2 certified")
Postconditions & environment
Render-only: no assignment state changes; one suggestion-telemetry record per render. Environment: dispatch board on desktop Chrome and Edge, current versions (PRD experience constraints[2]).
US-2Dana accepts a suggestion
and the assignment stands
Scope fence
Override capture with a stored reason. Excludes: reason-code configurability, open question OQ-2, A. Reyes, Jul 25
(FRD open questions[6]).
Preconditions
Job JOB-2214 open at the Toronto hub with three suggestions
rendered; Dana signed in as dispatcher; T-088 on shift but not
among the suggestions; T-104 on shift, missing the required gas
certification.
Row
Path
Test instance
Expected observable result
Test case
AT-1
happy
Dana assigns T-088 with reason code
RC-03 "customer request"
Assignment records T-088 with
RC-03; T-088 notified; override
logged in suggestion telemetry
Dana overrides to T-104, who lacks the required gas
certification
The board warns, requires explicit confirmation, and records the skill-mismatch flag: the FRD's defined behavior, and her choice still wins (FR-012[1])
Postconditions & environmentJOB-2214 assigned; the event log holds one override entry with
its reason code; suggestion telemetry updated. Environment: board on desktop Chrome and
Edge current; the technician-facing confirmation rides US-4's
mobile scope.
US-4Marcus receives and
confirms his assignment on his phone
actor: Marcus (technician)size: 5depends: US-2slice 1vertical slice ✓
Postconditions & environment Confirmation event logged.
Environment: day view on iOS Safari and Android Chrome, current versions
(PRD experience constraints[2]).
Decision: split applied & row deferrals
Suggestion generation and acceptance were one 13-point story; split by workflow step
into US-1 and US-2; the register's split ceiling is 8 (§4). Corner-case rows (feed loss mid-override) are deferred to slice 3 by name (slice decision[7]). A deferral is a decision; silence is not.
Three layers, captured once each. The FRD owns every rule as an abstract scenario outline, the only Given/When/Then anywhere. Stories own concrete rows against those outlines: the tables in §2. Execution evidence (§5) proves the rows ran. A rule discovered during story writing goes up to the FRD as a change request; a new data instance stays here as a row.
Evidence: the boundary held
One missing rule surfaced during example mapping (a double-acceptance race) and was filed
as an FRD change request rather than written into US-2. The FRD stays the single source of rules; the story kept only the concrete instance (US-2 AT-2) once the outline landed.
Honest sizes, the mapping session that authored the rows, and two distinct gates. Ready protects entry to development; it is deliberately not a full-specification stage gate, so refinement flow never blocks. Done protects closure (§5 holds the evidence). The lifecycle renders as a state diagram because this story set customizes the gates.
Scale: modified Fibonacci; split ceiling 8 for this set (agreed with the team, July 9). Spikes are time-boxed with a stated knowledge outcome, never pointed:
SP-1 is two days, its output a go/no-go note.
Evidence: example mapping, July 9, 2026
Three Amigos per story, 25 minutes each: A. Reyes (product), E. Sandoval (engineering), K. Yamada (QA lead; QA in the room is the point). Four rules mapped to FRD links, eleven examples became §2's acceptance-test rows, two questions moved to §8 with owners the same day. US-6 overran its timebox; split before Ready, recorded as the signal it is.
Ready (entry to dev): example-mapped · rows concrete · size set · dependencies
stated · FRD links resolve. Done: the project standard
(Definition of Done[5]) plus one story-set addition: override-reason telemetry visible on the pilot dashboard. Closure itself is governed by §5's evidence and sign-off.
Story lifecycle: state diagram rendered through Specira's diagram service. Fallback: Draft → Ready (DoR gate: example-mapped, concrete rows, size, dependencies, FR links) → In progress → In review (verification passes; findings loop back) → Done (DoD: project standard + story-set additions; acceptance evidence recorded).
A story is accepted on evidence, not on a nod. Three distinct confirmations: the product owner accepts business fit, the domain reviewer confirms the workflow reads true to practice, QA confirms every row executed with results recorded. Failed acceptance returns through the same Ready gate, never forced, and evidence is never edited after sign-off.
Evidence record: US-3 (accepted September 18, 2026)
Test case
Row
Result
Environment / build
Tester
Date
TC-311
AT-1
pass
pilot · build 2026-09-17
K. Yamada
Sep 18
TC-312
AT-2
pass
pilot · build 2026-09-17
K. Yamada
Sep 18
TC-313
AT-3
fail → pass (DF-112)
pilot · builds 2026-09-16 / 09-17
K. Yamada
Sep 16 / 18
TC-314
AT-4
pass
pilot · build 2026-09-17
K. Yamada
Sep 18
Defect
Found by
What
Disposition
DF-112
TC-313
Override note truncated at 249 characters
Fix before acceptance: fixed in build 2026-09-17, re-run passed
DF-114
TC-311
Reason-code chip overlaps the technician name at narrow widths (cosmetic)
Defer: owner D. Kaur (design), due October 9, 2026
Sign-off: accepted
Business fit: A. Reyes (product lead) · workflow true to practice: M. Chen (dispatch lead) · coverage and execution: K. Yamada (QA lead). September 18, 2026. Full run export attached (US-3 acceptance run[4]); test-case links
resolve in the test-case register[10].
Kickback: the gate works both waysUS-7 failed its first acceptance on TC-322
(shortfall notice missing the count) and returned to the backlog through the same Ready
gate; the failed run's evidence is retained unedited beside the passing one.
§6
Agent Implementation Handoff
conditional · active: stories may be agent-implemented1 decision1 evidence rulevalidator: agent_handoff_complete_when_flagged
A thin story makes a coding agent guess, and agents guess plausibly-wrong.
Every agent-flagged story carries pointers, boundaries, runnable verification, and one
pattern to imitate. The test: an agent told to ask clarifying questions first should have
none these fields don't already answer.
story: US-3: override with reason code
pointers: board assignment module · override dialog component · assignment event recorder
exemplar: the acceptance path shipped in US-2; imitate its event pattern
boundaries:
always: record the reason code atomically with the assignment
ask first: any new dependency or schema change
never: touch suggestion ranking
verify: run the board suite's override cases; they implement TC-311..314, so the agent's checks and QA's checks agree · manual mirror of row AT-2: an override without a reason cannot complete
pitfall: acceptance is idempotent by job id; do not introduce a second write path
Decision: agent readinessUS-3 is agent-implementable as specified.
US-1 stays human-paired: it establishes the board's suggestion rendering patterns that later stories imitate, and the exemplar has to exist before agents can follow it.
The FRD's error catalog, story by story: covered, carried inside a feature story's rows, or deferred with a slice. Every bounded input gets its boundary rows somewhere in the set. No failure behavior is invented at story level: rows instantiate the FRD's defined failure semantics with real triggering values.
US-7Dana sees an honest
shortfall notice when fewer than three technicians qualify
Rows AT-1: job submitted with skill "Gas fitting (G4)" (not in the taxonomy) → rejected naming the value (TC-331) · AT-2: empty skill field → the FRD's
required-field behavior (TC-332).
Boundary coverage & path classes across the set
Bounded input
Boundary rows
Lives in
Proximity bands (FR-011[1]: A<10, B 10 to 20, C 20 to 40, D>40 min)
9 / 10 / 11 · 39 / 40 / 41
US-1 AT-2, AT-3
Override note length (250-character maximum)
250 / 251
US-3 AT-3
Story
Happy
Negative
Boundary
Edge
Corner
US-1
●
●
●
none
deferred to slice 3 by name (feed loss mid-action):
decision[7]
US-2
●
none
none
●
US-3
●
●
●
●
US-7 / US-8
none
●
none
●
§8
Open Questions
mandatory1 decision
Owned and dated, with what each blocks; an unowned question is not tracked. Questions raised in example mapping land here the same day.
Question
Owner
Answer by
Blocks
OQ-2 Are override reason codes tenant-configurable or
fixed? raised in the July 9 example-mapping session
Omission note: how the agent-handoff section renders when a team is all-human: "§6 Agent Implementation Handoff omitted: implementation is exclusively human this cycle. Rationale recorded in adaptation event #2."
Refs
References & Package Contents
Package items travel in the same export bundle; workspace items link into
Specira where the governed record lives.