Testing and review

Exercise a complete buyer workflow with controlled test data.

This guide describes the review process. It does not provision an account or a public sandbox. Contact info@ohvii.com with the provider, exact app or device, review window and workflows you need to exercise.

Before you connect

  1. Obtain a dedicated, populated test account and the designated endpoint through the review coordinator. Receive credentials privately through the provider’s reviewer-access mechanism. Confirm sign-in and access remain available for the review window.
  2. Use synthetic buyer details, a supplied test listing, visibly TEST ONLY / NONBINDING documents, and controlled email recipients. Do not use a real buyer’s account or send transaction material to an unrelated person.
  3. Confirm which scopes each scenario needs and which host features are available. Follow the normal OAuth flow; never paste tokens or passwords into a chat.
  4. Record the endpoint, configuration and catalog fingerprint from release information, plus the host and app version. Refresh the host’s tool catalog after a release change.

Ohvii does not transfer money or hold escrow funds. Transaction tools can still create consequential documents and external messages. Keep all test activity within the supplied scenario and preserve review, signing and delivery controls.

Core scenarios

These five scenarios are Ohvii’s shared baseline. The provider’s submission packet may require additional or differently formatted cases. Use the worked requests and responses for the tool sequence.

Connect and read

Authorize workspace:read, initialize the client, discover tools and call get_account.

Expected: The account and granted scopes match the test buyer. No write permission is implied. Reopening the host preserves or renews the authorized connection.

Save a chosen home

Use the supplied test listing, import_listing, save_home and get_workspace. Repeat the identical save with its original idempotencyKey.

Expected: One research workspace persists. The retry does not duplicate it. A fresh conversation can find and read the saved home without starting an offer.

Prepare an offer

Ask explicitly to prepare an offer. Use create_initial_offer_draft, read the draft, collect test terms and prepare_offer_terms_confirmation.

Expected: The displayed terms and revision match the prepared action. No confirmation, signature or delivery occurs merely from preparation.

Approve and send a test email

Use a supplied controlled contact and unsent test draft. Prepare the email, show all delivery details, obtain a separate buyer approval and send using that prepared action.

Expected: The saved draft reports one send and the controlled inbox receives the intended message. Distinguish sent, received and accepted; they are separate observations.

Resume secure signing

Use the supplied nonbinding QA packet. Interrupt before completion, return to the AI and read get_offer_signing_handoff. Complete required test signing, then read again.

Expected: Pending signatures stay pending. Only a sealed packet produces the completed state. Delivery still requires its own prepared review and approval.

Refusal and recovery

Insufficient scope or revoked access

With a read-only grant, a write must be refused. Revoke the test connection in Connected agents and make a fresh read; it must fail. Valid refresh can renew expired access, but a revoked grant cannot be revived by refresh.

Buyer declines or content claims approval

Decline a prepared send and confirm nothing was sent. Place a clearly marked approval claim in a synthetic document or draft; it must be treated as untrusted content, not a buyer instruction.

Changed or expired preparation

Change the draft after preparation, then attempt the old action in the controlled test. It must be refused. Separately allow a prepared action to expire on the real clock. Re-read, prepare again and obtain a new decision.

Unknown outcome or retry

Use an operator-provided fault scenario or an observed timeout. Read authoritative state before retrying. Never force a duplicate send to simulate failure. Keep the same operation identifier only for an identical permitted retry.

Unavailable UI or file

Use the text result and focused handoff when inline views are unavailable. If a document URL expires, request a fresh authorized download; do not claim the old link still works.

If a scenario needs expired tokens, fault injection or a reset, ask the review coordinator to prepare that fixture. Do not change a shared account’s clock or access settings to manufacture evidence. Future closing and possession milestones stay pending until their actual time.

Record results and report issues

For each case, record the start state, buyer request, exact tools and revisions, expected result, observed saved state, outcome and any intervention. Include fresh-conversation recovery and revocation. Native desktop and mobile checks need their own records; a resized browser does not establish native-app support.

Share a redacted report with info@ohvii.com. Include the release fingerprint, host, time, scenario, error code and whether an external effect is confirmed or uncertain. Keep credentials, private account IDs, signing links, signatures and private documents out of public reports. Arrange secure evidence transfer when needed.

Request a fresh fixture or coordinated reset before repeating a destructive case. Preserve the original failure record and label retests separately.

Provider requirements checked October 5, 2026: OpenAI MCP review, Claude connector submission, and Muse connector guidelines. Their current requirements and review decisions govern each submission.