Launch proof session

Run owner-approved proof without widening scope.

Use this runbook after intake, records validation, and records review. It sequences the real event, service, role-account, Stripe, media, monitoring, and rollback checks, but it does not submit, persist, seed, mutate, authorize, charge, upload, page, request secrets, or create public inventory.

Activation worksheet Owner intake Launch records Validate packet Records review Evidence packet Session packet Session closeout Readiness status

Session step 1

Source and runtime

source ready

Start with the deployed commit, image tag, Cloud Run revision, traffic split, public health, and route reachability before touching owner-gated systems.

Evidence to record

Confirm `tired-dashboard`, `tired-web`, and `tired-api-core` revisions and images.
Open `/status`, `/activation`, `/activation/evidence`, `/activation/records`, `/activation/records/validate`, and `/activation/records/review`.
Record public health responses for `https://tiredapi.co/health` and `https://tired.events/api/health`.

Stop condition

Do not treat HTTP 200 or revision parity as proof of real event, payment, media, role, or monitoring behavior.

Session step 2

Owner approvals

approval required

Use the owner intake, records packet, validator, and review checklist to define the exact approved proof window.

Evidence to record

Fill the intake with owner-approved event, service, account, payment, media, and monitoring boundaries.
Validate the records packet before the session starts.
Review aliases, approval window, lane completeness, approved scope, and stop conditions.

Stop condition

Do not proceed with credentials, production records, provider state, media, payments, or alert channels when the approval window is missing or expired.

Session step 3

Real event and service

owner gated

Move honest-empty public surfaces toward real proof only with operator-owned event and service records.

Evidence to record

Verify public event listing, event detail, JSON-LD, ticket tier, quote boundary, and analytics visibility against the approved event.
Verify public service listing, service detail, JSON-LD, provider workspace ownership, and booking or Connect boundary against the approved service.
Capture public bytes, marker text, account context, and denied-state evidence separately.

Stop condition

Do not seed fake inventory, publish private drafts, create orders, expose private venue details, invent provider rows, or imply payout readiness.

Session step 4

Role-account QA

owner gated

Prove host, provider, promoter, buyer, scanner, manager, and admin boundaries with approved accounts and redacted evidence.

Evidence to record

Check intended workspace access and denied routes for each approved role.
Verify onboarding intent, active account context, settings/profile behavior, scanner access, promoter collaboration, and admin-only surfaces.
Record aliases, timestamps, routes, observed result, and redacted screenshots only when approved.

Stop condition

Do not store passwords, tokens, cookies, raw emails, reusable credentials, private screenshots, or owner account secrets.

Session step 5

Stripe and media

owner gated

Handle money and protected media as separate owner-approved proof lanes with explicit rollback and redaction boundaries.

Evidence to record

Confirm Stripe mode, account, webhook endpoint, Checkout session, webhook fulfillment, refund, Connect, Tax, Radar, KYC, payout, and balance evidence only inside approved scope.
Verify approved public, unlisted, private, protected, manifest, ZIP, quota, revocation, native share, copy, and save behavior against safe media.
Keep Stripe IDs, object aliases, expiry, counts, integrity hashes, and access results separate from secrets and raw object keys.

Stop condition

Do not run charges, refunds, transfers, upload media, expose protected objects, mutate grants, or redistribute originals without explicit owner approval.

Session step 6

Monitoring and closeout

approval required

Close the session with operational evidence, explicit gaps, and rollback readiness instead of broad launch-complete claims.

Evidence to record

Record alert policies, notification channels, SLOs, Error Reporting, Cloud Trace, logs, and any tested alert delivery with timestamps.
Record rollback target revision, image, traffic-shift command, public verification, and escalation owner.
Update the ledger and archive with what passed, what failed, what stayed gated, and what must not be claimed complete.

Stop condition

Do not create channels that page people, mutate monitoring providers, or mark launch complete from source tests, screenshots, or public probes alone.