You are generating a manual-QA test-case report for branch {{BRANCH}} compared against {{DEFAULT_BRANCH}}.

The host (cadence) will write the markdown you emit to disk and echo it to stdout — your only job is to produce the report body between the BEGIN/END markers shown below. Do not run `git commit`, `git reset`, `git rebase`, `git push`, or any other history-rewriting command. Do not create, modify, or delete any files. Do not write the report to disk yourself.

The report's audience is a manual QA engineer. Each test case must be reproducible by a human exercising the system through its public API/UI. Do not author runnable unit/integration test code, and do not perform coverage analysis against existing test files.

## Step 1: Gather changes

Run these commands to understand what changed on this branch:

- `git log {{DEFAULT_BRANCH}}..HEAD --oneline` — list of commits unique to this branch with their short hashes.
- `git diff {{DEFAULT_BRANCH}}...HEAD` — full diff against the merge-base.

Use these as the source of truth. Do not invent endpoints, fields, or behaviors that the diff does not support.

## Step 2: Project context

The block below is pre-formatted reference material from `.cadence/context/`. Use it verbatim as additional input — schema dumps, entity descriptions, OpenAPI specs, and similar documents may help disambiguate API shape and DB structure. Do not modify or reformat it.

{{PROJECT_CONTEXT}}

## Step 3: DB-context detection rule

Inspect the project context block above and decide whether it contains usable DB schema or entity material — for example a SQL schema dump, ORM model definitions, an ER diagram, or a prose description of tables/collections and their columns/fields.

- If NO usable DB context is present, prepend exactly one line at the top of the report body (immediately after the `# Test cases: …` heading), verbatim:

  > Note: no DB schema context found in .cadence/context/. DB verification and setup sections were omitted. To enable them, add a schema dump or entity description to .cadence/context/.

  In this mode you MUST omit the `**DB verification:**` and `**DB setup hint:**` lines from every test case.

- If usable DB context IS present, do NOT emit the Note line. Include `**DB verification:**` on every test case, and include `**DB setup hint:**` only when the scenario cannot be reproduced via API alone (for example, when the precondition requires preexisting rows that no API endpoint can create). Never invent table or column names that the project context does not support.

## Step 4: Emit the report

Output ONLY the markdown report between the BEGIN and END markers below. No surrounding prose, no markdown fences, no explanation, no diff dump.

The report body MUST start with this heading:

```
# Test cases: {{BRANCH}} vs {{DEFAULT_BRANCH}}
```

It MAY then be followed by the Note line described in Step 3. After that, emit one or more test-case blocks. Each block MUST use this exact skeleton, with the labelled lines in this order:

```
### TC-N: <short title>

**Type:** functional | edge case | regression | error handling
**Priority:** high | medium | low
**Preconditions:**
- <bullet>
**Steps:**
1. <api or ui step>
**Expected:**
- <observable outcome>
**DB verification:**
- <query or expected row state>
**DB setup hint:**
- <how to seed required rows when no API path exists>
```

Rules for the per-TC structure:

- `**Type:**` value is exactly one of `functional`, `edge case`, `regression`, `error handling`.
- `**Priority:**` value is exactly one of `high`, `medium`, `low`.
- `**Preconditions:**` is a bullet list (may be a single `- none` bullet when nothing is required).
- `**Steps:**` is a numbered list of concrete API or UI steps.
- `**Expected:**` is a bullet list of observable outcomes.
- `**DB verification:**` and `**DB setup hint:**` are emitted only when the DB-context detection rule in Step 3 says they should be — and `**DB setup hint:**` is included only when the scenario cannot be reproduced via API alone.

Number the test cases sequentially as `TC-1`, `TC-2`, ... You decide how many cases each behavioral change warrants — some changes deserve only a golden-path case, others need golden-path plus boundary/edge plus error-handling coverage; do not pad and do not pin a per-change count.

## Step 5: Wrap and signal

Wrap the report exactly like this:

<<<CADENCE:REPORT_BEGIN>>>
# Test cases: {{BRANCH}} vs {{DEFAULT_BRANCH}}

### TC-1: <title>

**Type:** ...
**Priority:** ...
**Preconditions:**
- ...
**Steps:**
1. ...
**Expected:**
- ...
**DB verification:**
- ...
**DB setup hint:**
- ...
<<<CADENCE:REPORT_END>>>

After the END marker, on its own line, emit:

<<<CADENCE:REPORT_DONE>>>

If you cannot generate the report (e.g. git commands fail, the diff is unreadable, or the changes are too opaque to design test cases for), emit only:

<<<CADENCE:REPORT_FAILED>>>

and stop. Do not emit BEGIN/END markers in the failure case.

Progress log path (for your reference only — do not write to it): {{PROGRESS_FILE}}
