Synthetic intake test runner

This package prepares and sends test events. It does not configure a Make
scenario, create a Pipedrive connection, or certify a CRM result.

1. Download send-test-case.mjs and duplicate-test-cases.json into one folder.
   Use Node 24.20.0, the runtime used to check this package. No npm install is
   needed for the sender. Open a terminal in that folder.

2. Print one case without any network request:
   node send-test-case.mjs --cases duplicate-test-cases.json --case D02 --run-id intake-001

   Inspect its baseline, deliveries, procedure and expected outcome. D02 sends
   ten sequential requests. D03 sends two concurrent requests. Within a case,
   every delivery preserves the same submission key and payload.

3. Build the documented scenario in a separate test environment. Preserve
   submission_key. Map symbolic contact_key values to synthetic test contacts
   using one recorded matching rule. Map the required pipeline, stage, owner,
   service, and intended next activity. Do not use real customer data.
   The sender cannot supply your account-specific fields or create a blueprint.

4. Prepare that case's baseline and its event ledger before sending. Each
   run ID and case ID forms a namespace. D04 and D05 must use the prefixed
   seed identifiers printed by the dry plan; do not reuse D01 records directly.
   D09 needs two distinct test people matching its single symbolic contact key.
   Keep the same run ID for recovery attempts. A new run ID is a new enquiry.
   Snapshot the baseline record IDs and counts; do not reset a live workflow.

5. Set MAKE_TEST_WEBHOOK_URL in your local environment to the reviewed HTTPS
   test webhook. Treat the complete URL as a secret. Do not paste it into a
   shared report, commit, message, or shell example. Then explicitly send:
   node send-test-case.mjs --cases duplicate-test-cases.json --case D02 --run-id intake-001 --send --confirm-test-environment --confirm-baseline > delivery-D02.json

   The report omits the endpoint and response bodies. It records HTTP status,
   payload hashes and timing. A 2xx response only confirms acknowledgement.
   Redirects fail. There are no automatic retries in this sender. A timeout
   can follow a successful write: inspect the destination before repeating.

6. D06 and D07 need a separately configured, controlled failure. Read the case
   procedure and record the setup. Add --confirm-fault-setup only after setup.
   D06 fails after saving the person and before creating the deal. D07 loses
   the response after a successful deal write and before saving its ID.
   One sender run does not perform the recovery procedure for you. Inspect
   the actual incomplete execution, retry behaviour and destination first.
   An automatic-completion switch alone does not prove duplicate prevention.

7. Observe the Make execution history and final Pipedrive records separately.
   Record all attempts and measured credits, including recovery work. Wait
   until the scenario has finished before counting. For D02, retain evidence
   from all ten deliveries. For D03, retain both concurrent execution records.

8. Fill run-receipts-template.json with synthetic internal references only.
   Keep kind=blank_run_log before testing. Use in_progress_run_log while some
   cases remain not_run, then completed_run_log when all cases are recorded.
   A complete handoff requires all final typed references: person:<ID>,
   deal:<ID>, activity:<ID>. D04 includes the seeded records in its totals.
   D05, D08 and D09 use quarantined only after the expected review outcome
   and review reference are recorded. D07 review remains unresolved; pass
   requires one person, one deal and one verified next activity.

9. Open the result-log checker on the duplicate-prevention page. It processes
   JSON locally, up to 256 KiB. The source package also provides:
   node scripts/validate-run-receipts.mjs /path/to/run-receipts.json

   The command-line limit is 1 MiB. Its exit codes are 0 for a consistent log
   ready for evidence review, 1 for an invalid document, 2 for a valid but
   unfinished log, and 64 for bad command input. external_evidence_verified
   always remains false. A person must inspect the referenced run evidence.

Sender exit codes: 0 for a dry plan or all HTTP acknowledgements; 1 for a
delivery failure; 2 for invalid input, missing configuration or confirmation.
Use --help for the sender's options. Local tests do not prove vendor behaviour.