Write TestRail Cases

Core principle: A test case exists to verify a business rule, not to document a click path. Navigation is the means; assertions about the resulting state are the point. A case whose expected results could be true even if the feature were broken is a failed case.

IMPORTANT — evidence only, never assumption. Every functional claim you put in a case — what a business rule does, what a config parameter changes, what a modal/toast says, whether feature X depends on Y — must trace to a real source you actually read this session: an existing TestRail case, a Jira ticket, GitHub source/README, the FOLIO wiki, or FOLIO API docs. Never invent or infer behavior from general software knowledge, "it's probably similar to feature Z", or pattern-matching against other areas. If you have not verified a fact from a real source, either fetch the source or ask the user before writing it into a case — do not guess and move on.

Mandatory Workflow (follow in this exact order)

1. Detect the application area from the story (see Area Detection below) and read the matching context file in references/context/. Never skip this. If the area cannot be determined, ask the user.

   1b. Assess context quality. After reading the context file, check if enrichment is needed (see Lightweight Context Enrichment below). Trigger enrichment automatically if ANY of these are true:

   • Context file does not exist
   • File header says DRAFT
   • File has fewer than 10 Key Business Rules
   • File has no "Exact UI Texts" section or fewer than 3 confirmed toasts
   • File has more than 5 items in "Known Gaps / Items to Verify"