Prompt provenance PR2 QA
Prompt provenance PR2 QA
Section titled “Prompt provenance PR2 QA”Check the customer prompt journey on the deployed PR2 revision. This is functional acceptance of the four-table provenance layer, which adds no SQL functions or triggers. Paid prompt analysis and media-tag quality are outside this pass. Hosted QA has not yet been executed.
Before QA starts
Section titled “Before QA starts”Engineering provides the deployed revision, links, session-isolated test accounts and characters, and a small set of supported generation fixtures. One account must own a proven gallery source; another must be unable to read it. Engineering also provides a text-free before/after record for each check: fixture IDs, field keys, origin/edit flags, capture or read outcome, and deletion acknowledgment. The UI shows prompt text but has no provenance inspector, so QA uses that record to verify origins without inspecting storage or copying private prompt text into the report.
Engineering owns enrollment, the capture flag, owner-reconciliation authority, the already-configured deletion credential, fixture cleanup, and a separately approved budget for ordinary test generations. QA does not run SQL, handle tokens, send synthetic webhooks, or inject faults. Use the normal product journey and an engineering-coordinated test-account deletion through Clerk. Do not start this pass until the environment and budget are ready.
Four checks
Section titled “Four checks”| Check | What QA does | Expected result |
|---|---|---|
| 1. Author edits and prefills | Generate once after editing a text field. Separately generate with an untouched prefill, then with an edit reverted to its prefill. Compare the supplied field-level record. | The edited field records userEdited=true and changedFromPrefill=true. The untouched prefill records both flags as false. The reverted edit records userEdited=true and changedFromPrefill=false. Each record matches the exact submitted value, and each accepted generation remains usable. |
| 2. Gallery reuse and owner boundary | In the owner account, reopen a captured gallery item in the create form and generate from its retained exact field. Compare the visible prefill and supplied field-level record. In the second account, ask engineering to exercise the same source through its authenticated read path. | Only the requested, retained field can be proven as one-hop reuse for its owner. The other account receives no proven source field. QA does not need an origin badge in the UI. |
| 3. Deletion and restore fence | With engineering, delete a test account or character through its normal product path. For account deletion, engineering verifies the real signature-verified Clerk handoff and its successful acknowledgment after the durable scrub commits. Reopen or restore the relevant test fixture if the product supports it. | Deleted provenance is unavailable. A restored character or retained gallery link does not restore reuse of a pre-deletion source. Engineering supplies the acknowledgment and before/after evidence; QA checks the visible result. |
| 4. Capture disabled | With engineering’s disabled-capture fixture, make an ordinary supported generation and compare its outcome with the existing generation flow. | Generation completes normally while no new prompt provenance is captured. |
Engineering evidence and release gates
Section titled “Engineering evidence and release gates”Engineering attaches automated results for signature failures, missing or wrong service credentials, durable acknowledgment, owner and character races, replay, restore, source changes, and migration shape. Restore regressions include delayed capture after individual media deletion, with and without surviving siblings, and deletion before the first capture. QA does not repeat those cases. Record each functional check as PASS, FAIL, or NOT RUN, with the deployed revision, fixture IDs, and text-free before/after evidence. For a failure, record the steps and observed result without including private prompt text.
The authenticated deletion RPC must be available in production before PR2 merges through a separately approved server release. A local passing test or this hosted QA pass does not satisfy that production gate. Do not switch the Clerk webhook until engineering verifies the server capability and ordered rollout described in the provenance flow.