Corthex · Launch lab / acceptance
Before “live”, show what actually passed.
A good answer in a preview is one observation. Launch readiness also needs real storefront identity, unavailable tools, changed sources and a team that can follow up.
Use the workbench to record your own tests. It preserves failures and untested cases rather than turning an unchecked list into a launch certificate.
Keep a rehearsal separate from a real test.
Prepare a bounded environment
Choose a test shop or controlled test page, fictional customers and orders, reviewed policy content and an identified reviewer. Record the assistant, plugin or module version and the relevant settings. Establish which actions may be performed before testing begins. Do not use an arbitrary real customer order merely because it is convenient, and do not place a payment or send a real customer message as part of a presentation check.
Write the expected result before asking
For each question, state the source or tool that should be used, the facts that may be disclosed and the action that should remain unavailable. An expected refusal is a meaningful pass. A polished answer that reveals another customer’s details is a failure even if the product explanation is correct. Define critical boundaries before reviewing the responses so you do not accidentally judge confidence as correctness.
Capture the result and its limits
Keep a redacted screenshot, tool outcome or report reference together with the expected result. A local simulation can demonstrate a decision rule; it cannot establish that the actual storefront has paired correctly. A dashboard knowledge preview does not establish authenticated order access. A real test should use the same entry point, customer role and connection path the visitor will use. Write down which kind of evidence you collected.
Record the uncomfortable cases too.
An evidence note is required before a marked pass counts as a complete recorded review. Nothing on this page tests or modifies your installation automatically.
Self-reported review. This worksheet runs no AI, store or security tests. Entries stay in this tab; download to keep them. Use fictional/redacted evidence, never credentials or private customer records.
Keep unresolved and untested cases visible. A pass without evidence is not a completed review.
Choose stopping conditions you will honor.
Stop the rollout when a test crosses a customer boundary, invents an order state, reports an unperformed change or promises an unavailable human reply. Those findings need an owner and a correction, not a better screenshot. Repeat the failing question after the change and re-run its neighboring negative case. Fixing own-order access, for example, should be followed by the guest and other-customer tests.
“Not tested” is a finding. It is not a quiet pass.
For noncritical presentation issues, record the limitation and decide deliberately who will fix it and when. Keep that decision separate from an access failure. The workbench intentionally does not produce a security score or certify a store. Its role is to make your review traceable, including the evidence you have not collected yet.
Test the platform you actually installed.
For native WooCommerce, verify pairing, enabled commerce tools and signed-in own-order identity. A guest’s email or number is not a substitute. For PrestaShop, verify the module and read-only Webservice; do not expect order writes from that connection. For a generic embed, test knowledge and presentation without assuming private order access. A custom site action requires its own real host support and consent path.
For handoff, test staff available, nobody available and a request already waiting. Verify what the visitor sees and what the team can actually find in the inbox. Availability is not the same as an immediate response. For mobile and keyboard checks, include opening and closing the widget, focus visibility, readable sources and a long answer. A desktop screenshot alone cannot establish those behaviors.
Retest when the answer conditions change.
A new source, model, plugin version, permission setting or website action can change the result of a previously passing case. Keep the downloaded review as a dated record, then create a new one for the changed installation. Do not overwrite an earlier failure with a later pass without retaining what changed. Review actual pilot usage separately from forecasts, and do not infer sales or resolved requests from activity counts.
This worksheet helps you decide what still needs evidence. Publishing a site or changing a production integration remains a separate authorized step with your normal release checks. Give the review owner a clear handover: what was tested, what is deliberately out of scope and which support route remains available if the live connection fails.
Check who owns the installer before repeating the storefront test: compare the WordPress plugin and widget routes. Before expanding the pilot, calculate a budget from the tested conversation assumptions.