ccqa-rerecordlisted

# Re-record a ccqa test case You are given one test case as `<feature>/<spec>`. Finish with that spec passing **for the right reason** — not with an assertion weakened until it stopped complaining. Do not skip ahead to `ccqa record`. Which repair is correct depends on what the finding says went stale, and for some findings re-recording is the wrong move entirely. ## Rules that hold throughout - **Never edit a generated artefact** — `test.spec.ts`, `ir.json`, `generated.json`, anything a target emits. The next `ccqa record` overwrites it, so the edit is lost work that also hides the real defect. The only file you edit is the spec's `spec.yaml`; everything else changes by re-recording. - **Never weaken an assertion to make a run pass.** An assertion that matches nothing, and therefore always holds, is a defect — usually the very one you were sent to fix. - **Data the test creates is named with `${CCQA_RUN_ID}`** — ccqa sets a fresh value per spec per run — and a cleanup step at the end of the spec deletes it. A spec that leaves data behind poisons the next run. - **Keep values out of the spec.** URLs, accounts and secrets stay as `${VAR}` references the profile resolves; never inline what one resolved to. - **Do not pass `--report-to-hub`** to a local run. Repair work must not land in the ledger CI reads. - **A spec with `session:` expects a saved signed-in state.** If it is missing or expired, say so and stop — do not add login steps to work around it.