The whole thing, without installing anything

1 Bring the story in

us-ingest → writes state/US-004/00-source.md

The source is captured verbatim, with the checks logged rather than assumed: redaction scan, control-character sanitisation, and an untrusted-input check — because a requirement document is data, not instructions.

- **Redaction scan**: no direct personal/sensitive data found (no real names,
  SSNs, cards, health data, addresses). No masking applied.
- **Untrusted-input check**: the source text contains no directive aimed at the
  assistant — it is a plain requirement description. Treated as data throughout.

> **As an** employee,
> **I want** to submit an expense report and have it approved through the right chain,
> **so that** I get reimbursed correctly and the company keeps an auditable trail.

2 Find what the story does not say

need-understanding → writes state/US-004/02-understanding.md

This is the step most generators skip, and the one that decides whether the suite is honest. Nine questions came out of eight acceptance criteria. Here is one, unedited:

Q1 — AC2/AC6: threshold boundary at exactly €500 and exactly €5000.
Why it matters: routes every report; an off-by-one here silently under- or
over-approves.
A close literal reading is self-consistent ("under €500" excludes 500 from band A;
the closed range "€500–€5000" includes both ends; "above €5000" excludes 5000 from
band C) — so band B would be `[500, 5000]` inclusive on both ends. But this reading
depends on treating two different phrasings ("under X" vs "X–Y") as precisely
complementary, which is exactly the kind of boundary phrasing that real
implementations get wrong.

3 Choose techniques, and say why

istqb-design → writes state/US-004/03-design.md

One line per acceptance criterion. The justification is the deliverable — a technique named without a reason is decoration.

| AC2 | Boundary value analysis + Decision table | Three amount bands with two
  literal boundaries (€500, €5000) → BVA; the resulting required-role set per band
  is a decision table (amount band × role). |

| AC5 | Boundary value analysis | A strict amount threshold (€25) on receipt
  requirement — BVA at value/value-1. |

| (cross-cutting) | Error guessing / checklist | Authorization and IDOR conditions,
  anchored on the systematic-expansion checklist (not named per-AC in the source,
  but a reflex expansion for any authenticated multi-actor workflow). |

That last row is the one worth noticing: nothing in the story mentions authorization. It comes from a systematic expansion pass, not from the text — and it is the row that later produced a real IDOR finding in the demo application.

4 Rank by risk, and hand the arbitration back

prioritize → writes state/US-004/04-priorities.md

Probability × impact per condition, proposed. The tool ranks; a human decides. Every ambiguity is carried through with the question that produced it, so a P1 flagged low (Q1) stays visibly unresolved rather than quietly becoming a fact.

5 Write the test book

testbook-generate → writes testbooks/US-004/*.feature and coverage-matrix.md

38 scenarios from one story. Stable IDs so a regeneration diffs instead of overwriting, the technique on the tag line, the condition in a comment.

@QAIA-US-004-019 @AC4 @P2 @negative @boundary
# condition: AC4-C3 [req-neg] — priority P2
Scenario: A line dated 91 days ago is blocked with an explanatory message
  Given "employee@demo" has a draft report with one EUR line "supplies" of 10.00
        dated 91 days ago, receipt attached
  When "employee@demo" submits the report
  Then the attempt is refused with a message mentioning "90 days"

| AC  | Condition   | Scenario ID       | Prio | Rationale                              | Confidence  |
| AC2 | AC2-C1      | @QAIA-US-004-008  | P1   | Financial-control boundary.            | normal      |
| AC2 | AC2-C2      | @QAIA-US-004-009  | P1   | Q1-flagged; exact-€500 planted-        | low (Q1)   |
|     |             |                   |      | ambiguity boundary.                    |             |
| AC3 | AC3-C1 [req-neg] | @QAIA-US-004-013 | P1  | Classic internal-control defect class. | normal      |

Eleven of the 38 rows carry a named open question like that one.

6 Turn it into tests that run without QAIA

automate → writes Playwright specs carrying the same IDs

Native Playwright, page objects as fixtures, the scenario ID on the test so a failure points back at the requirement.

test('@QAIA-US-004-021 @AC5 @P1 @negative @boundary a line at exactly the receipt
      threshold without a receipt is refused', async ({ request }) => {
  const t = await apiLogin(request, B, 'employee@demo');
  const { id } = await apiCreateDraft(request, B, t, {
    lines: [{ category: 'gear', amount: 25.00, date: todayISO(), receipt: false }],
  });
  const r = await apiSubmit(request, B, t, id);
  expect(r.status()).toBe(422);
});

7 Scored by something that did not write it

testbook-score, automation-score, aptitude-gate — a separate, read-only plugin

No producer grades its own output. That rule has repeatedly caught defects the producing skill could not see in itself — including one where the generated code was perfectly faithful to a test book whose Then was too weak, so the tests passed against the very defect the requirement existed to forbid. A judge looking only at code-vs-book would have missed it too.

What you would still have to decide

Nothing above tells you whether this is worth your time on your ticket — no QA engineer has ever run it end to end on real work, and that is the project's largest unknown. If you would consider being the first, there is a 15-minute pilot kit built for exactly that, and the only thing asked in return is where it went wrong.

← Back to the overview · Read the full run, every file →