# RC1 Staging Smoke Test

## Persistent SMPP runtime

1. Confirm both activation flags and documented timeout units.
2. Start `gateway:smpp:run yas` in the foreground.
3. Confirm a second copy exits nonzero without opening a session.
4. Submit one approved message and confirm outbox publication, one submission, acceptance, and public `submitted`.
5. Observe a DLR and existing terminal projection/webhook behavior.
6. Stop with Ctrl+C and confirm lease release.
7. Restart and confirm terminal or acknowledgement-unknown submissions are not resent.

Use only dedicated test tenants, approved recipients/senders, placeholders in retained scripts, and sanitized evidence. This checklist does not authorize deployment or live traffic.

## Simulator testing

Before external connectivity, verify application availability, Bearer authentication rejection/acceptance, tenant isolation, single and bulk submission, durable idempotent replay and conflict, stable ordering, message/status reads, webhook configuration, signature verification, duplicate suppression, and evidence persistence with a simulator or test doubles.

## Staging testing on 10.0.0.200

1. Record the deployed commit, platform versions, migration status, routes, time synchronization, and HTTPS result.
2. Confirm invalid credentials return the standard safe envelope.
3. Submit one approved test message; retain current request correlation ID, body correlation ID, idempotency key reference, and `message_id` without retaining message content.
4. Replay the exact request with a new request correlation ID; confirm the header is current and the result is original.
5. Submit a conflicting body with the same key; confirm `409 IDEMPOTENCY_CONFLICT` and no second message.
6. Query `GET /api/v1/messages/{message_id}` and verify the full public resource has required message identity, recipient, normalized status, creation time, and current-request correlation plus only applicable optional fields.
7. Query `GET /api/v1/messages/{message_id}/status` separately. Confirm the same `message_id`, normalized public `status`, authoritative `occurred_at`, current-request body `correlation_id`, matching `X-Correlation-ID` response header, and optional `client_reference` only when available.
8. Confirm both resources enforce the same tenant isolation and expose no provider, database, SMPP, or internal-enum fields.
9. Configure and read the webhook safely; confirm the secret is never returned.
10. Verify database records exist and sensitive plaintext is absent using approved read-only queries.

## Live YAS testing

Only during an approved YAS window:

1. Run `php artisan gateway:smpp:bind-test yas` and retain sanitized bind evidence.
2. Run one approved `gateway:sms:send-test` with `--request-dlr`; confirm submit acknowledgement and provider identifier are handled without exposing credentials.
3. Confirm the correlated DLR projects the expected public terminal status.
4. Publish the committed webhook outbox using the approved one-shot command and verify one signed receiver request.
5. Repeat/observe duplicate DLR handling and confirm no duplicate evidence or webhook event.

## Evidence and decision

Capture operator/time, commit, environment, correlation/message IDs, HTTP statuses and safe response fields, migration/constraint evidence, sanitized SMPP result, projected status, webhook headers with signature redacted, receiver verification outcome, and incident references.

GO requires all applicable simulator and staging checks, approved YAS checks, tenant isolation, persistence, duplicate handling, and rollback readiness. Any unexplained authentication bypass, data leak, duplicate creation, failed migration, incorrect public status, invalid signature acceptance, or partial persistence is NO-GO. Separate infrastructure unavailability from application failure, but do not waive it for production acceptance.