Live status without pretending the gated work is done.

This matrix records the public positioning work from source: buyer-facing About and FAQ pages, sitewide navigation, home audience lanes, footer links, and Studio handoff copy. It separates clarity coverage from owner-reviewed policy, payment, refund, and payout claims.

• About page positioning

  source

  Current source

  The buyer About page states that TIRED.EVENTS is both an events-ticketing platform and a services marketplace for attendees, hosts, service providers, and promoters.

  Proof

  Current web source includes audience-specific sections for attendees, hosts, service providers, and promoters plus capability tiles for ticketing, QR passes, galleries, maps, social feed, analytics, payouts, and notifications.

  Next proof

  Verify the live page content and mobile layout after the next buyer-web deploy; keep any unsupported payment or payout wording gated by Stripe proof.

• FAQ page coverage

  source

  Current source

  The buyer FAQ answers what the platform is, how buying tickets works, how hosts sell events, platform fees, service listings, promoter accounts, refunds, Stripe-secured payments, and support.

  Proof

  Current web source uses native details/summary rows with links to events, nearby discovery, tickets, services, Studio, and About, so the page remains keyboard accessible without client JavaScript.

  Next proof

  Run live browser checks for FAQ expand/collapse, links, and wording once real payment/refund policy language is owner-reviewed.

• Policies page boundary

  source

  Current source

  The buyer /policies page now gives a conservative operational overview for fees, refunds, payments, payout readiness, service bookings, media privacy, support, and launch boundaries.

  Proof

  Current web source links Policies from the footer and FAQ, names Stripe-side Tax/Radar/KYC/payout evidence as owner-gated, and warns that operational policy copy is not a replacement for owner-reviewed legal terms.

  Next proof

  Owner must review the final legal terms, refund language, privacy policy, payment disclosures, and provider-side Stripe evidence before public policy copy can be launch-final.

• Nav, home, and footer clarity

  source

  Current source

  The buyer home page, navigation, and global footer repeatedly position the product as ticketing plus services, with routes for events, nearby discovery, services, saved events, About, FAQ, Policies, sign-in, and Studio handoff.

  Proof

  Current source includes the home audience explorer, Nav links for Events/Nearby/Services, and a footer with Explore, Company, and Get started columns that points hosts to the Studio dashboard and readers to the policy overview.

  Next proof

  Verify desktop and mobile pages with real public inventory so positioning copy and empty states both match what buyers, hosts, providers, and promoters actually see.

• Policy and owner-review boundary

  gated

  Current source

  The source explains fees, refunds, Stripe payments, payouts, and provider bookings, but policy wording and money-movement claims are not launch-final without owner review and provider-side evidence.

  Proof

  This status page records source coverage only; it does not inspect Stripe dashboard policy, refund policy approvals, legal terms, Tax/Radar, Connect KYC, or payout settlement evidence.

  Next proof

  Owner must review public policy wording and provide payment/provider evidence before content positioning can move from source-backed to launch-final.

This matrix records the promoter expansion posture from source and tests: event-linked feed posts, collaboration consent, revenue-share percentages, projected earnings, invite attribution, and post analytics boundaries. It does not claim live payout or role-account proof without owner-approved accounts and transaction scope.

• Event-linked promoter posts

  source

  Current source

  Promoter and host feed posts can attach a published event summary, and unapproved promoters cannot promote an event they are not accepted to collaborate on.

  Proof

  Current API tests cover host-owned event posts, accepted-promoter event posts, promotedEvent feed/detail payloads, unknown/draft event rejection, and non-collaborator denial.

  Next proof

  Verify the live feed composer, promoted-event card, and event-link permissions with approved host and promoter accounts.

• Collab consent and revenue share

  source

  Current source

  A promoter can request to collaborate on a public event; the event owner or super admin can accept or decline and set a 0-100 revenue-share percent.

  Proof

  Current API and Studio source cover pending requests, owner list/decision routes, duplicate request idempotency, declined rows, rev-share clamping, and the event editor collaboration panel.

  Next proof

  Use approved accounts to verify request, accept, decline, and rev-share readback in the live Studio UI before treating promoter collaboration as launch-proven.

• Promoter analytics

  source

  Current source

  Promoter rows expose invite/activity attribution and projected earnings from accepted collaborations; post analytics remain author-only or super-admin-only.

  Proof

  Current tests cover scoped promoter stats, /me/collabs projectedEarnings, accepted-collab invite permission, and post analytics 401/403/author/super-admin boundaries.

  Next proof

  Verify invite attribution, post views/interactions, projected earnings, and promoter-denied sales analytics against a real event and accepted promoter account.

• Money movement boundary

  gated

  Current source

  Revenue share is source-modeled as projected earnings; no promoter payout, buyer-fee allocation, or Stripe transfer is claimed live by this slice.

  Proof

  The current source tests verify authorization and math boundaries only. Provider-side Stripe evidence, payout ledger settlement, and owner-approved transaction scope are not present.

  Next proof

  Owner must approve the exact promoter payout model and Stripe/ledger verification scope before any real revenue-share money movement is tested or claimed.

This matrix records the broader feed and social-profile posture from source and tests: followed-account feeds, public profiles, typed posts, polls, comments, likes, suggestions, photo limits, and author-only analytics. It does not claim live role-account proof, media-sample proof, or external social-platform publishing.

• Signed-in feed and suggestions

  source

  Current source

  The web feed reads followed-account posts for the signed-in user, keeps the composer behind auth, and renders who-to-follow suggestions from accounts the viewer does not already follow.

  Proof

  Current web source wires /feed, Composer, WhoToFollow, GET /v1/feed, POST/DELETE follow, and GET /v1/accounts/suggestions; API tests cover auth, followed-feed inclusion, unfollow clearing, suggestion ranking, and followed-account exclusion.

  Next proof

  Use approved buyer, host, and promoter accounts to verify feed empty states, follow suggestions, follow/unfollow state, and composer visibility in the live browser.

• Public profiles and post detail

  source

  Current source

  Public account pages show display name, account type, follower count, post count, caller follow state, and the account's posts; post detail pages render the post, comments, likes, and poll state.

  Proof

  Current web and API source cover /u/:id, /p/:id, profile counts, public account posts newest-first, 404 unknown accounts/posts, and detail view-count recording.

  Next proof

  Verify public profile and post-detail links against operator-owned accounts and posts before treating social discovery as launch-proven.

• Typed posts and engagement

  source

  Current source

  Post creation supports text, photo, poll, and event-update posts; poll posts need enough options, event updates must be hosted by the author, likes are idempotent, comments append, and poll votes return an authoritative tally.

  Proof

  Current API tests cover typed-post validation, plan-based photo limits, post upload URLs under posts/<accountId>, like/unlike behavior, comments, poll vote errors, and poll detail myVote readback.

  Next proof

  Run signed-in browser QA for text, photo, poll, event-update, like, comment, and vote flows with approved accounts and safe media samples.

• Post analytics boundary

  guarded

  Current source

  Post detail reads record views, and post analytics are limited to the author or a super admin; public viewers can see engagement counts without receiving author-only analytics.

  Proof

  Current tests cover source attribution normalization, range validation, author and super-admin analytics reads, 403 for other users, 404 unknown posts, and unauthenticated rejection.

  Next proof

  Verify author-only analytics, non-author denial, and source/range behavior with approved live accounts before using it for promoter or host reporting sign-off.

This matrix records FE-02 and FE-03 behavior from source and tests: listing gates, search and saved-event behavior, mappable records, crawlable event-detail metadata, and malformed-link guards. It does not replace browser proof against an operator-owned published event.

• Public event listing gate

  source

  Current source

  The public event feed and /events page only present published events with a confirmed parseable start date; undated host drafts stay out of buyer discovery and maps.

  Proof

  Current API tests cover schedule_required_for_publication, and the public /events page filters records without confirmed upcoming schedules before rendering the catalog or map.

  Next proof

  Create or identify an operator-owned published event with a real start date, venue, and tickets to verify the live buyer catalog against actual data.

• Search, category, saved, and nearby

  source

  Current source

  Search and category filters read from /v1/events/search, saved-event state is account-scoped, and map pins require real event coordinates.

  Proof

  Current tests cover search route ordering, published-event filtering, category filtering, invalid category rejection on write paths, saved-event scoping, and saved-list output.

  Next proof

  Verify search, category chips, saved events, and nearby map behavior with real published events in more than one category and at least one mapped location.

• Cards, maps, and public stats

  source

  Current source

  Public discovery cards and the featured spotlight consume signed cover art, prominent event dates, from-price and tier-count data, a right-side map preview with coordinate-filtered pins, and host-controlled publicStats for view and going counts.

  Proof

  Current API tests cover priceFrom, tierCount, featured, signed coverImageUrl, publicStats privacy gating, event-view increments, distinct paid-buyer going counts, and owner PATCH of publicStats/featured. Studio now exposes the public stats toggle from the event editor.

  Next proof

  Verify cards, map pins, featured placement, and public/private stats with an operator-owned event that has coordinates, ticket tiers, paid buyers, and real view activity.

• Crawlable event detail

  guarded

  Current source

  Event detail pages now emit schema.org Event JSON-LD from real event, venue, geo, image, and ticket-tier fields when a confirmed schedule exists.

  Proof

  Current web tests cover JSON-LD creation, missing/invalid schedule fail-closed behavior, optional-field omission without placeholders, and sold-out offer availability.

  Next proof

  Use a live published event to inspect rendered HTML, metadata, JSON-LD, calendar download, ticket tiers, photos, reviews, save, share, and checkout boundaries.

• Attendee review write gate

  source

  Current source

  Review writes require both an owned ticket and an event that has already ended; a ticket-holder for a future event receives event_not_ended, while a non-ticket-holder still receives must_attend first.

  Proof

  Current API tests cover ticket-holder review success after endsAt, future-event event_not_ended denial, must_attend priority for non-ticket-holders, and startsAt fallback when endsAt is unset. The public event page pre-empts future-event review forms from the same event-ended hint.

  Next proof

  Verify the review form and API behavior against an operator-owned past event with a real ticket-holder before launch sign-off.

• Malformed event links

  guarded

  Current source

  Event-ID routes reject malformed IDs before database UUID casts across public review/gallery reads, save/review writes, ticket management, invites, analytics, and collab panels.

  Proof

  Current API tests cover malformed public event-id reads, buyer save/unsave/review writes, management ticket/edit/invite/analytics/collab routes, and the no-op view beacon.

  Next proof

  Keep malformed event links in live smoke checks after each API deploy so stale client state and crawler traffic cannot become server errors.

• Real event proof

  gated

  Current source

  Production public event inventory is currently honest-empty, so browser probes cannot prove event detail, structured data, or checkout behavior against real data.

  Proof

  This status page reads the live public event count from tiredapi.co and keeps launch criteria waiting while it remains zero.

  Next proof

  Owner must authorize or create a real event record before FE-02 and FE-03 can advance beyond source-backed readiness.

This matrix records the location-discovery posture from source and tests: Use my location, browser geolocation retry, preset/manual fallback, miles-based radius search, nearest-first API sorting, city labels, and the real mapped-event proof gate.

• Use my location control

  source

  Current source

  The public /nearby page keeps a first-screen Use my location control, retries browser geolocation on demand, and falls back to preset cities or validated manual coordinates when permission is denied or unavailable.

  Proof

  Current web source wires navigator.geolocation, the Use my location button, preset city picks, latitude/longitude validation, and retry behavior without requiring sign-in.

  Next proof

  Run live browser QA on desktop and mobile for allow, deny, timeout, retry, preset city, and manual coordinate paths.

• Miles, radius, and nearest-first API

  source

  Current source

  Nearby discovery uses radiusMiles in and distanceMiles out, defaults to 25 miles, clamps out-of-range radii, and sorts published scheduled events nearest-first.

  Proof

  Current API tests cover within-radius inclusion, tight-radius exclusion, no-coordinate and unpublished exclusion, default/clamped radiusMiles behavior, missing lat/lng 400s, distanceMiles output, and route ordering before the slug handler.

  Next proof

  Verify against operator-owned mapped events in at least two radius bands so live nearby results can be compared against expected distances.

• City names over coordinates

  guarded

  Current source

  Nearby cards and the home nearby teaser render venue city or reverse-geocoded city labels for users; precise coordinates stay in the browser request/map context instead of being the primary buyer-facing label.

  Proof

  Current web source calls reverseGeocodeCity for the viewer point, renders Near {city}, reads event venue.city, and formats distances in miles or feet.

  Next proof

  Use live browser QA with approved mapped events to verify city labels, map framing, distance text, and that raw coordinates are not the buyer-facing event label.

• Real inventory boundary

  gated

  Current source

  The nearby source path is ready, but public production inventory can still be honest-empty, so A3/B3 is not launch-proven against real event geography.

  Proof

  This status row records source and deployed behavior only; it does not create event records or mutate location/DNS/provider state.

  Next proof

  Owner must authorize or identify mapped public events before nearby discovery can move from source-backed to real-data launch proof.

This matrix records the pass and scanner posture from source and tests: QR wallet passes, pass-code scanner compatibility, ticket-type scan settings, multi-use entries, order privacy, event context, and the remaining live door-flow gate.

• QR pass wallet

  source

  Current source

  The buyer ticket wallet renders an Apple-Wallet-style pass stack with QR codes, copyable pass codes, event artwork when present, event date, venue city/name, ticket type name, and single-use or multi-use entry state.

  Proof

  Current web source renders PassWallet with QRCodeCanvas from passToken, signed eventCoverImageUrl, eventStartsAt, eventVenue, ticketTypeName, usesRemaining, transfer controls, and reduced-motion/plain-list fallback.

  Next proof

  Verify a live buyer wallet with an owner-approved paid ticket, event cover art, venue, and ticket type before treating the pass UI as launch-proven.

• QR token scanner compatibility

  source

  Current source

  The Studio scanner accepts either the buyer QR pass token or the internal ticket id, so a phone QR and a pasted ticket id hit the same host/super-admin scan authorization path.

  Proof

  Current API and DB tests cover scanning by ticket id, arbitrary passToken, UUID-shaped passToken, first scan admission, already-used idempotency, non-host 403, unknown not_found, and unauthenticated rejection.

  Next proof

  Run a supervised door-flow check by scanning a real buyer QR from a phone or browser wallet into the live Studio scanner.

• Ticket types and multi-use entries

  source

  Current source

  Host ticket types carry scanMethod and maxUses; multi-use passes remain valid until the last admitted entry and show remaining entries in both wallet and scanner result copy.

  Proof

  Current API tests cover default qr scanMethod, explicit scanMethod values, maxUses validation, GET /v1/tickets maxUses/usesCount joins, and scan responses with usesRemaining for multi-use passes.

  Next proof

  Verify a real multi-use pass across multiple door scans, including final exhaustion and a blocked extra scan.

• Orders and pass context

  guarded

  Current source

  Buyer order history is private to the owner, order detail includes purchased items and refunds, and the ticket wallet receives event slug/start/venue context for deep links and approximate area display.

  Proof

  Current order-history and ticket-type tests cover buyer-only order reads, order detail items/refunds, 403 for another user, 401 unauthenticated, ticketTypeName, eventTitle, eventSlug, eventStartsAt, and eventVenue.

  Next proof

  Use an approved buyer account to verify upcoming/past orders, receipt detail, wallet deep links, and post-refund ticket state against live records.

• Real door proof

  gated

  Current source

  The ticket wallet, QR, and scanner path are source-backed, but no owner-approved live ticket has been scanned in this slice.

  Proof

  This status row records source, tests, Cloud Run deploys, and public reachability only; it does not perform a real checkout, issue a real pass, or scan an attendee at the door.

  Next proof

  Owner must authorize a real or controlled test event, paid or comp ticket, buyer account, and scanner account before A5/B1/A6 can move from source-backed to launch-proven.

This matrix records the continuous A7/A8 posture from source, tests, and recorded browser evidence: compact public navigation, buyer mobile entry points, Studio mobile controls, no-horizontal-overflow checks, and the remaining approved-device proof gate.

• Responsive compact parity

  source

  Current source

  A7 covers mobile parity for home, event discovery, nearby, auth/onboarding, feed, services, galleries, tickets, and Studio status surfaces instead of treating desktop checks as enough.

  Proof

  Current web and Studio source uses responsive grids, wrapping controls, mobile nav overlays, compact auth buttons, wallet fallbacks, and no-horizontal-overflow browser evidence already recorded for deployed public slices.

  Next proof

  Repeat live browser QA on approved mobile viewports after each visible UI slice, including signed-in buyer, host, provider, promoter, scanner, and admin paths.

• Buyer mobile entry points

  guarded

  Current source

  The public navigation keeps Events, Nearby, Services, Galleries, Feed, Sign in, Sign up, ticket wallet, and nearby controls reachable from compact screens.

  Proof

  Current Nav source exposes a mobile explore overlay, fixed nearby launcher, compact auth controls below 900px, and a signed-in ticket shortcut; home source stacks the live inventory, gallery, nearby, and audience sections.

  Next proof

  Use owner-approved buyer accounts and real inventory to verify tap targets, signed-in account chips, pass wallet QR display, cart quote states, and gallery ZIP controls on mobile devices.

• Studio mobile controls

  guarded

  Current source

  Studio uses a compact nav, mobile tool menu, wrapping admin/status controls, account-aware routes, and responsive metrics so operator pages remain reachable without relying on desktop-only chrome.

  Proof

  Current dashboard source keeps admin/status rows grid-stacked on small screens, mobile nav hidden/visible breakpoints, wrapping auth controls, and responsive dashboard metric cards.

  Next proof

  Verify host, provider, promoter, scanner, plan/flag admin, analytics, and onboarding workflows with approved role accounts on phone-sized browsers.

• A8 modernization boundary

  source

  Current source

  A8 is tracked as a continuous modernization loop, not a one-time done claim: every slice should keep live data, honest empty states, compact controls, guarded permissions, and explicit proof gates.

  Proof

  This status page now records the A7/A8 matrix alongside source, runtime, owner-gated activation, incident, domain, payment, media, role, social, ticket, and analytics evidence.

  Next proof

  Keep adding specific QoL fixes only when source or browser evidence shows a real workflow gap; do not mark launch-complete from static screenshots or HTTP 200 alone.

• Real device proof

  gated

  Current source

  The source and recorded browser checks cover responsive posture, but no pass in this slice used owner-approved real accounts across physical mobile devices.

  Proof

  This row records source-backed mobile readiness and prior no-horizontal-overflow evidence only; it does not create real inventory, run payment flows, or mutate provider/mobile app settings.

  Next proof

  Owner must provide approved test accounts, real event/service records, safe media, and device/browser targets before A7/A8 can move from source-backed readiness to launch-proven.

This matrix records the FE-SVC public marketplace behavior from source and tests: listed-only public routes, service detail metadata, malformed-link guards, checkout boundaries, and the real provider-data gate.

• Public listing gate

  guarded

  Current source

  The public services feed and single-service detail route only expose services whose status is listed.

  Proof

  Current marketplace tests cover listed-only public feeds and now verify draft service IDs return 404 through the public detail route while staying visible to the provider workspace.

  Next proof

  Create or authorize a real listed provider service, then verify the public list, detail page, and provider workspace from browser sessions.

• Service detail metadata

  source

  Current source

  Public service detail pages emit schema.org Service JSON-LD from the listing title, description, category, price, currency, and canonical URL when a listing is public.

  Proof

  Current web tests cover Service JSON-LD generation, draft and blank-title fail-closed behavior, optional-field omission, and origin-specific canonical URLs.

  Next proof

  Verify the emitted JSON-LD against a real listed service and inspect crawler-visible markup after provider data exists.

• Malformed service links

  guarded

  Current source

  Public detail, provider edit, and booking routes reject malformed service IDs before database UUID casts.

  Proof

  Current marketplace tests cover malformed public detail IDs returning not_found, malformed provider edit IDs returning not_found, and malformed booking IDs returning not_bookable.

  Next proof

  Keep checking malformed links after each API deploy so public crawlers and bad client state cannot turn invalid URLs into server errors.

• Booking boundary

  guarded

  Current source

  Book buttons remain behind signed-in checkout, positive service price, provider charges-enabled state, and Stripe gateway availability.

  Proof

  Current source and marketplace tests cover provider_not_payable, connect_unavailable, listed-service booking, fee calculation, webhook-paid service orders, and pending payout ledger rows.

  Next proof

  Run owner-approved provider Connect onboarding and a real service booking before claiming service payments or payouts are live.

• Real service proof

  gated

  Current source

  The live public service feed can still be honest-empty; source behavior does not prove there are operator-owned service listings.

  Proof

  This status page reads /v1/services at request time and reports the public count separately from source readiness.

  Next proof

  Owner must provide or approve real provider records and role credentials for service listing/detail/booking launch proof.

This matrix records the current role, account-switching, provider, promoter, and admin posture from source and tests. It shows what the deployed product can enforce before owner-controlled account credentials are used for signed-in browser QA.

• Pre-auth onboarding chooser

  source

  Current source

  Onboarding routes attending users to the consumer account, hosting users to a host workspace, and promoting users to a promoter workspace; service-provider signup requires a provider specialty.

  Proof

  Current onboarding and account tests cover attending, hosting, promoting, host reuse, provider specialty requirements, provider specialty updates, and separate provider organizations by specialty.

  Next proof

  Use approved browser accounts to prove the chooser creates, persists, and routes each workspace type to the right first task.

• Email confirmation UX

  guarded

  Current source

  Buyer and Studio email signups send Firebase verification links, stop in a check-your-email state, offer resend, reload verification before continuing, keep Google sign-ins on the already-verified path, and now block explicitly unverified email identities from posting or hosting mutations at the API boundary.

  Proof

  Current buyer and Studio auth providers call sendEmailVerification on email signup and resend, both auth forms block unverified email/password sign-ins before app routing, verifiers preserve emailVerified/email_verified claims when providers send them, and API tests cover email_not_verified denial for host setup, hosting onboarding, event creation, post creation, and post upload URLs while allowing verified and legacy/OAuth-style identities.

  Next proof

  Run signed-in browser QA with real email/password and Google accounts to prove verification-link delivery, post-verify routing, and blocked pre-verification posting/hosting against production Identity Platform.

• Active account context

  guarded

  Current source

  Account-sensitive flows use the selected active account or X-Tired-Account-Id so linked host, provider, promoter, and consumer workspaces do not silently bleed into each other.

  Proof

  Current source and tests scope host checkout/refund paths, provider booking and payout paths, and account capability previews to the active or target account.

  Next proof

  Run manual switcher QA with one authorized linked user that has multiple real workspaces.

• Personal settings and host setup

  source

  Current source

  Buyer settings support display-name edits, private avatar upload keys with signed reads, a read-only account list instead of inline self-switching, and an idempotent create-host-account action for users ready to list events.

  Proof

  Current Wave C API tests cover avatar upload URLs under avatars/, PATCH /v1/me display-name/avatar persistence, signed avatar reads that do not expose raw object keys, POST /v1/me/host-account owner membership, host capability activation, idempotent host creation, and order event timing for upcoming/past buyer tabs.

  Next proof

  Run signed-in browser QA for settings profile edits, avatar upload, account-list readback, host-account creation, and buyer order tab behavior with approved accounts.

• Host, manager, and promoter roles

  guarded

  Current source

  Owner, admin, and manager roles can manage events; promoter members can invite attendees and read their own stats but cannot manage events, read private collaboration panels, or view sales analytics.

  Proof

  Current promoter tests cover manager and owner event management, promoter denials, attendee role forcing, invite permissions, and promoter stats scoping.

  Next proof

  Run real invite, accept, collaboration, analytics, and attribution checks with approved manager and promoter accounts.

• Provider workspaces

  source

  Current source

  Provider organizations require a specialty, keep separate provider profiles by specialty, and own service listing, booking, Connect onboarding, and payout surfaces.

  Proof

  Current accounts and marketplace tests cover provider specialty persistence, listed-service booking, Connect onboarding reuse, provider-not-payable blocking, and pending payout ledger rows.

  Next proof

  Verify a real provider listing, buyer booking, Connect account state, and post-payment payout evidence.

• Super-admin and feature flags

  guarded

  Current source

  Super-admin access comes from the email allowlist only; /admin/flags lets operators pick a platform account, grant or revoke cataloged secret-feature flags, and preview what that target account would see without inheriting the operator's super-admin view.

  Proof

  Current RBAC, admin-flag, and dashboard source tests cover allowlisted super-admin behavior, non-admin rejection, GET /v1/admin/feature-flags catalog reads, POST /v1/admin/accounts/:id/flags grant/revoke writes, audit logging, GET /v1/admin/accounts/:id/capabilities preview-as reads, GET /v1/me capability flags, and rejection of is_super_admin as an entitlement flag.

  Next proof

  Run approved admin browser QA for /admin/flags account search, flag toggles, optimistic rollback, preview dashboard output, and capability readback using an operator-approved test account.

• Admin plan catalog editor

  source

  Current source

  Studio now exposes /admin/plans for super admins to create custom plan tiers, update plan metadata, and replace plan-managed feature rows only after an explicit replacement toggle. Plan assignment clears stale plan-managed entitlements before copying the selected plan.

  Proof

  Current DB, API, and dashboard tests cover feature-enriched admin plan reads, POST /v1/admin/plans, PATCH /v1/admin/plans/:id, audit logging, admin-console linking, the UI feature-replacement gate, stale max_post_photos cleanup, payout_hold_days replacement, and ad-hoc entitlement preservation.

  Next proof

  Use owner-approved super-admin credentials and an operator-approved test plan before performing live plan create, update, assignment, or feature replacement QA.

• Malformed account and social links

  guarded

  Current source

  Account, social-post, and admin-account routes reject malformed UUIDs before account, feed, engagement, invite, plan, flag, or capability database work.

  Proof

  Current API tests cover malformed public account/post reads, follow/unfollow, like/unlike, comments, poll votes, post analytics, account edit/invites/promoter stats, and admin account plan/detail/flags/capabilities routes.

  Next proof

  Use approved role accounts to verify the same boundaries in signed-in browser flows before calling FE-09 launch-proven.

• Malformed collab and media IDs

  guarded

  Current source

  Collab decisions, photo interaction recording, promoted post event links, and event-update payload IDs reject malformed UUIDs before collaboration, media analytics, or event lookup database work.

  Proof

  Current API tests cover malformed collab decision IDs, photo event IDs, promoted-post event IDs, and event-update payload IDs while preserving auth-first and request-validation behavior.

  Next proof

  Verify the same paths with owner-approved host, promoter, and media records before treating live collaboration or media analytics QA as launch-proven.

• Malformed body-supplied IDs

  guarded

  Current source

  Gallery event placement, notification mark-read, and admin plan assignment reject malformed body-supplied UUIDs before event, notification, or plan database casts.

  Proof

  Current API tests cover malformed gallery create/update eventId, notification read ids, and admin planId bodies while preserving auth-first and existing error contracts.

  Next proof

  Verify the same signed-in host, user, and admin paths with owner-approved role credentials before treating this as manual QA complete.

• Authorized manual QA

  gated

  Current source

  Public probes cannot sign in as the required host, provider, promoter, consumer, manager, or admin accounts.

  Proof

  This pass verifies source behavior and deploys the evidence matrix, but it does not use owner-controlled role credentials.

  Next proof

  Owner must authorize or provide test accounts before FE-09 can move from source-guarded to launch-proven.

This matrix records the current event and portfolio analytics posture from source and tests. It separates host-scoped API enforcement, time-windowed ticket metrics, all-time view/review signals, and promoter attribution from the still-required live proof against real events, orders, scans, reviews, and role accounts.

• Event sales analytics

  source

  Current source

  Studio event analytics read GET /v1/events/:id/analytics for the selected range and render gross ticket revenue, ticket status counts, checked-in tickets, views, attendee review summary, and per-tier sell-through.

  Proof

  Current API and dashboard source gate analytics to host event managers or super admins; API tests cover paid checkout, signed webhook issuance, door scan, gross revenue, and 401/403/404 responses.

  Next proof

  Verify against an operator-owned event with paid tickets, scanned tickets, reviews, and a non-manager account to prove the live UI and access boundaries.

• Portfolio rollup

  source

  Current source

  The /analytics Studio page fetches the signed-in account event list, requests each event analytics payload in parallel, drops per-event failures, and rolls up revenue, tickets sold, scans, events, and sell-through without fake rows.

  Proof

  Current dashboard source keeps signed-out users on the sign-in path, renders an honest empty state when there are no analytics, and sorts event rollups by real gross revenue.

  Next proof

  Use an approved host account with multiple events to verify the live rollup, failure tolerance, range changes, and empty-state transitions.

• Range and metric boundaries

  guarded

  Current source

  Analytics range accepts all, 7d, 30d, and 90d. Ticket sales, revenue, and status counts respect the selected order window; views and review summary remain all-time signals.

  Proof

  Current API rejects invalid ranges and passes the selected window into event sales aggregation while the UI labels all-time views and attendee feedback separately.

  Next proof

  Run dated paid-order fixtures or live operator records across more than one time window to prove dashboard numbers change only where intended.

• Promoter attribution

  guarded

  Current source

  Event analytics includes collaboration rows with projected promoter earnings, and portfolio analytics shows host-owner/admin promoter stats from accepted invite activity.

  Proof

  Current source scopes promoter leaderboard reads to host owners/admins and keeps projected earnings as math from gross revenue, not a payout claim.

  Next proof

  Verify invite, accept, attribution, projected earnings, and promoter-denied sales analytics with approved host and promoter accounts.

• Real analytics proof

  gated

  Current source

  Production public event inventory is still honest-empty, and public probes cannot sign in as a host account, so FE-06 cannot be launch-proven from this status page alone.

  Proof

  The public status page can record source coverage and runtime reachability, but it has no owner-controlled event, order, scan, review, or role-account evidence.

  Next proof

  Owner must authorize real or test operator data plus role credentials before FE-06 can move from source-backed readiness to launch sign-off.

This matrix records the current notification posture from source and tests. It separates the signed-in in-app notification center, ticket/social alerts, and saved-event reminder rows from external push, SMS, email, or social DM delivery that still needs owner approval and provider proof.

• In-app notification center

  source

  Current source

  The signed-in buyer notification center reads unread/newest rows from /v1/me/notifications and can mark all or selected notifications read.

  Proof

  Current API tests cover auth requirements, empty state, user scoping, unread counts, specific-id mark-read, and mark-all behavior.

  Next proof

  Verify with approved signed-in browser accounts before calling the notification center launch-proven.

• Ticket and social alerts

  source

  Current source

  Ticket-issued, ticket-transferred, new-follower, post-liked, and post-comment actions create best-effort in-app notifications without blocking the underlying action.

  Proof

  Current tests cover ticket issuance, comp grants, transfer notification, social self-action suppression, follower notifications, like/comment notifications, and recipient scoping.

  Next proof

  Use real accounts to verify notification rows, badge counts, read state, and links from the live UI.

• Saved-event reminders

  source

  Current source

  Saved published events starting within 24 hours can create one in-app saved_event_reminder when the user opens their notification center.

  Proof

  Current tests cover reminder creation for a saved published due event, duplicate suppression, and no reminders for unsaved, draft, past, or far-future events.

  Next proof

  Verify with an operator-owned published event and signed-in consumer account; decide later whether reminders need a background scheduler instead of notification-center opportunistic delivery.

• External delivery channels

  gated

  Current source

  Push, SMS, email reminders, and social DMs are not wired or claimed live by this slice.

  Proof

  The notifications page now labels saved-event reminders as in-app only and keeps external channels behind an explicit launch gate.

  Next proof

  Owner must choose channels, approve provider credentials/costs/privacy posture, and verify delivery before external reminders can pass.

This checklist names the owner-controlled items that still block launch-complete evidence. It is intentionally not a seed script: real inventory, credentials, payments, media, and alert channels require approval before mutation or provider-side verification. The activation worksheet turns these gates into evidence lanes without authorizing production data, payment, media, or provider changes. The evidence packet lists the exact fields and artifacts to capture once each owner gate is approved. The coverage matrix maps the platform overhaul and social promoter expansion waves to live surfaces, source-backed coverage, and remaining owner-gated proof. The launch records worksheet prepares the operator-owned event, service, account, and media records needed to move honest-empty states toward real proof without seeding production data. The local validator checks copied records packets for missing fields and secret-like values before owner review. The records review checklist names schema, alias, owner-approval, lane-completeness, approved-scope, and stop-condition checks before production proof starts. The inventory snapshot reads public no-store home, events, services, and plans routes before any records are added. The launch rehearsal turns that inventory into an owner go/no-go packet before real event or service proof can move. The proof session runbook sequences the approved event, service, role-account, Stripe, media, monitoring, and rollback checks without widening scope, and the no-store session packet exposes the same sequence for evidence handoff. The closeout checklist separates passed, failed, still-gated, rollback, and follow-up evidence before any launch-complete claim. The media proof rehearsal narrows TG-PRIV and TG-ZIP into protected grants, quota burst, ZIP integrity, native save/share, and closeout checks before approved media is touched. The operator handoff names the real event, service, role-account, payment, media, monitoring, and rollback inputs the owner must bring into the next proof session before any production mutation. The handoff review confirms aliases, approval windows, mutation boundaries, forbidden fields, evidence buckets, and stop conditions before the session can move.

• Operator-owned event

  waiting

  Current state

  Public inventory currently reports 0 listed events and 0 tickets sold.

  Evidence needed

  A scheduled published public event with venue, tickets, public detail metadata, buyer listing visibility, and non-mutating checkout quote evidence.

  Owner action

  Authorize or create the first real event record and identify the host account allowed to verify FE-02, FE-03, FE-04, and FE-06.

• Operator-owned service

  waiting

  Current state

  Public inventory currently reports 0 listed services.

  Evidence needed

  A listed provider service that renders in public search/detail, keeps drafts private, exposes service metadata, and reaches the expected Connect or booking boundary.

  Owner action

  Authorize or create the first real provider/service record and decide whether booking proof stops at unavailable Connect or continues into payment QA.

• Authorized role accounts

  gated

  Current state

  Public probes cannot sign in as host, provider, promoter, consumer, manager, or super-admin accounts.

  Evidence needed

  Browser evidence for onboarding, account switching, event management, provider listing, promoter collaboration, ticket scanning, admin plan/flag views, and permission denials.

  Owner action

  Provide approved test accounts or run a supervised session that covers each role without exposing reusable credentials in notes or logs.

• Approved media set

  gated

  Current state

  Public inventory currently reports 0 public galleries; real bucket object and protected grant behavior remain unproven.

  Evidence needed

  Live public, unlisted, and private galleries with approved objects proving owner read, non-owner denial, signed upload/read expiry, manifest, ZIP integrity, and native share/save behavior.

  Owner action

  Approve a media sample and account context before any real bucket object, protected grant, or privacy-sensitive browser check is performed.

• Stripe and Connect proof

  gated

  Current state

  API source and env-name checks show Stripe paths exist, but live account mode, webhook delivery, KYC, payout, tax, and Radar behavior are not proven.

  Evidence needed

  Owner-approved checkout, webhook fulfilment, refund, Connect onboarding, service booking, payout ledger, Stripe account mode, Tax/Radar settings, KYC, and payout/balance evidence.

  Owner action

  Authorize the exact Stripe mode/account and transaction scope before any charge, refund, bank, or provider-side payment verification.

• Operational monitoring

  waiting

  Current state

  Read-only checks found no alert policies, notification channels, or visible Cloud Trace rows; narrow Cloud Logging and Error Reporting samples found no recent service errors or groups.

  Evidence needed

  Uptime, 5xx/error rate, latency, failed deploy, checkout/webhook, and media delivery policies with owner-approved channels, tested delivery, SLOs, and Error Reporting or trace review.

  Owner action

  Approve monitoring channels, recipients, escalation rules, and any alert-delivery test that may contact people or external systems.

These criteria separate visible runtime health from evidence that needs real operator data, owner-controlled credentials, protected media, or authorized role accounts. A deployed page can update the checklist; it does not make gated criteria pass.

• Source, build, and runtime parity

  pass

  EvidenceStudio reports tired-dashboard-00184-hf9; API and buyer health probes are reachable.

  Next proofRecord the exact source commit, Cloud Build image, Cloud Run traffic, and browser checks in the repo ledger for each release.

• Real public event data

  waiting

  EvidenceThe public event feed is reachable but currently honest-empty.

  Next proofCreate or identify an operator-owned published event, then verify /events, event detail metadata/JSON-LD, calendar, tickets, checkout boundaries, galleries, and analytics against that record.

• Real public service data

  waiting

  EvidenceThe public services feed is reachable but currently honest-empty.

  Next proofCreate or identify an operator-owned provider listing, then verify list, detail, Connect readiness errors, and booking boundaries.

• Payments and payouts

  gated

  EvidencePublic pages intentionally do not expose Stripe live-secret, Connect, Tax/Radar, webhook, or payout proof.

  Next proofOwner must activate credentials and webhooks, then run authorized checkout, refund, Connect, and webhook QA before this can pass.

• Media privacy and ZIP/share

  gated

  EvidenceGallery routes, public/unlisted/private access tests, signed download manifests, client-side manifest metadata verification, a source-backed ZIP endpoint, CORS-readable export integrity metadata, client-side ZIP SHA-256 verification, atomic persisted hashed quota windows, and owner-only export window revocation exist, but this status pass has not proven protected grants, real bucket objects, live production concurrency behavior, live ZIP integrity against real media, or native save behavior.

  Next proofVerify public/unlisted/private gallery access, upload URLs, signed manifests, protected delivery, grant headers, ZIP download contents, and share behavior with authorized media.

• Role-based manual QA

  gated

  EvidenceSigned-in host, provider, promoter, consumer, and admin accounts require authorization that public probes cannot supply.

  Next proofRun manual flows with approved accounts: onboarding, account switching, event publish, service listing, promoter collab, admin, scanner, tickets, and refunds.

This matrix records the current checkout, refund, Connect, and payout posture from source and read-only provider evidence. It does not expose Stripe secrets and does not replace authorized charge, webhook, refund, tax, Radar, KYC, or bank-payout verification.

• Gateway configuration

  configured

  Current source

  The API boots with a real Stripe gateway only when STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET are present; otherwise checkout and Connect degrade to controlled unavailable responses.

  Proof

  Read-only Cloud Run env-name inspection for tired-api-core found STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET configured; secret values were not read or exposed.

  Next proof

  Owner must confirm Stripe mode, account, webhook endpoint, signing secret rotation, and allowed charge paths before money movement is called live.

• Ticket checkout and webhooks

  source

  Current source

  Authenticated checkout creates one-host ticket orders, applies host fee entitlements, opens a Checkout session, and relies on the signed webhook to mark paid and issue tickets.

  Proof

  Current tests cover successful checkout, invalid quantities, bad webhook signatures, webhook-paid ticket issuance, signed cover URLs, and idempotent notification behavior.

  Next proof

  Run an owner-approved checkout against a real published event and record Checkout session, webhook delivery, issued tickets, and buyer receipt evidence.

• Buyer fee quote before payment

  source

  Current source

  The live buyer cart calls public POST /v1/checkout/quote to show the server subtotal, plan-based buyer fee, tax placeholder, and estimated total before a signed-in checkout attempt.

  Proof

  Current API/db/web tests cover non-mutating order quotes, no inventory reservation, one-host validation, sold-out handling, malformed item rejection, and cart quote fallback rendering.

  Next proof

  Verify a successful quote against an operator-owned published event with real ticket inventory, then compare the quoted total with the authorized Checkout session before claiming payment launch proof.

• Refund controls

  source

  Current source

  Refunds are full-only, scoped to the buyer, super admin, or selected host workspace, and release the refund claim if the gateway call fails.

  Proof

  Current refund tests cover host order selection, full refund, ticket voiding, idempotent duplicate refund rejection, partial-refund rejection, and gateway failure recovery.

  Next proof

  Verify an owner-approved refund against a paid real order, then confirm Stripe refund state, ticket status, receipt, and reconciliation record.

• Malformed ticket/order links

  source

  Current source

  Checkout item validation and authenticated ticket, ticket-type, and order routes reject malformed UUIDs before database casts or gateway-side effects.

  Proof

  Current API tests cover malformed checkout ticket type IDs, ticket-type edit and comp IDs, ticket scan and transfer IDs, order refund IDs, and order detail IDs.

  Next proof

  Authenticated live checks still require owner-approved buyer, scanner, host, and paid-order records before this can prove real checkout or refund behavior.

• Connect service bookings

  source

  Current source

  Provider workspaces can create or reuse Connect Express accounts, refresh onboarding status, and accept bookings only when the provider is charges-enabled.

  Proof

  Current marketplace tests cover Connect onboarding reuse, connect_unavailable 503, provider_not_payable, listed-service booking, application fee calculation, webhook-paid service orders, and pending payout ledger rows.

  Next proof

  Run authorized provider onboarding and a real service booking before claiming Connect readiness or payout operations are live.

• Tax, Radar, and bank payouts

  gated

  Current source

  Service Checkout requests enable Stripe automatic_tax, but ticket Tax/Radar configuration and bank payout settlement are not proven by source or public probes.

  Proof

  No current pass inspected Stripe dashboard settings, Radar rules, tax registrations, payout schedules, KYC state, balance transactions, or bank settlement evidence.

  Next proof

  Owner must review Stripe Tax/Radar/Connect/KYC settings and provide post-transaction Stripe evidence before this gate can pass.

This matrix records the current media privacy posture from the deployed source. It separates gallery visibility and signed URL guardrails from the still-gated proof for real buckets, protected grants, ZIP integrity, and native save behavior.

• Public event galleries

  source

  Current source

  Gallery visibility supports public, unlisted, and private. Public galleries must be attached to a scheduled published public event.

  Proof

  Current API creation and edit paths reject public galleries without a ready public event; public home inventory joins galleries through public scheduled events.

  Next proof

  Verify with an operator-owned event gallery containing real media before treating buyer gallery browsing as launch-complete.

• Private and unlisted access

  source

  Current source

  Non-public gallery reads require the owner account or super admin; the buyer gallery page renders a locked state when the API returns forbidden.

  Proof

  Current API tests cover public, unlisted, private, and valid-unknown gallery reads; signed-out and non-owner denials; owner and super-admin access; and event gallery listings that exclude unlisted/private galleries.

  Next proof

  Run authorized owner, non-owner, and signed-out browser checks against real private and unlisted galleries.

• Uploads and signed reads

  guarded

  Current source

  Upload URLs are signed V4 writes, and gallery photo reads are short-lived signed GET URLs from the private media bucket.

  Proof

  The storage gateway signs uploads for 15 minutes and reads for one hour; missing MEDIA_BUCKET makes upload-url return storage_unavailable instead of faking success.

  Next proof

  Confirm live bucket, IAM signing, object registration, and signed read expiry using approved media.

• ZIP, native share, and grant secrets

  guarded

  Current source

  Public gallery pages can request a short-lived signed download manifest, verify its photo-count and expiry metadata before showing signed links, build a server-side ZIP from private object reads, verify the ZIP SHA-256 before starting a browser save, use native share or copy-link fallback without making the media bucket public, distinguish export quota and revocation responses from generic failures, and receive CORS-readable export integrity metadata. Export requests atomically persist hashed per-client windows in gallery_export_windows.

  Proof

  Current gallery tests cover public download-manifest access, private and unlisted manifest/ZIP denial without ownership, owner and super-admin access for non-public exports, signed read URLs, safe ZIP filenames, ZIP bytes, export photo-count headers, ZIP SHA-256 headers, CORS header exposure, atomic persisted hashed export windows, owner-only export window revocation, revoked-window reset behavior, client-side manifest metadata verification, client-side ZIP SHA-256 verification, web response mapping for rate-limited/revoked/forbidden/empty exports, and download-intent analytics.

  Next proof

  Use the media proof rehearsal to verify live manifests and ZIP contents against authorized real media, protected grant headers, live production quota concurrency evidence, and native save behavior.

This section separates public probes from provider-side monitoring. The current pass found reachable health routes and visible Cloud Run revision metadata, but did not find alert policies or notification channels to prove operational alerting.

• Public health probes

  verified

  Signaltiredapi.co/health and tired.events/api/health returned HTTP 200 during this request.

  Proof requiredKeep checking API, buyer, and Studio routes after each deploy; health alone does not prove revision or behavior.

• Cloud Run revision visibility

  verified

  SignalStudio runtime exposes tired-dashboard-00184-hf9; web and API revisions must still be checked through Cloud Run metadata.

  Proof requiredOperator verification must include latestReadyRevisionName, image tag or digest, and traffic split for tired-web, tired-dashboard, and tired-api-core.

• Alert policies

  waiting

  SignalRead-only GCP check in this pass returned no Cloud Monitoring alert-policy rows for tired-network-prod.

  Proof requiredCreate or connect policies for uptime, 5xx/error rate, latency, failed deploys, checkout/webhook failures, and media delivery before calling alerting complete.

• Notification channels

  waiting

  SignalRead-only GCP check in this pass returned no Cloud Monitoring notification-channel rows for tired-network-prod.

  Proof requiredAdd owner-approved notification channels and test a non-destructive alert delivery path with timestamps and recipient evidence.

• Recent error log review

  verified

  SignalRead-only Cloud Logging review found no severity>=ERROR rows for tired-web, tired-dashboard, or tired-api-core over the last two hours of this pass.

  Proof requiredThis is a narrow recent-log sample. Define SLOs/error budgets, review Error Reporting and traces, and record recurring telemetry reviews before release sign-off.

• Error Reporting groupStats review

  verified

  SignalRead-only Error Reporting groupStats REST query for tired-network-prod returned zero groups for the 24-hour period beginning 2026-08-01T09:34:36Z.

  Proof requiredThis is a bounded project-level groupStats check, not a trace review, SLO, alert policy, or recurring incident-review process.

• Cloud Trace list review

  waiting

  SignalRead-only Cloud Trace traces.list REST query for tired-network-prod returned zero traces between 2026-08-01T09:43:06Z and 2026-08-02T09:43:06Z.

  Proof requiredZero visible traces means trace instrumentation and latency/root-span review are still unproven before release sign-off.

This section records the latest read-only DNS, TLS, HTTP, and Cloud Run service evidence for the public hostnames. It does not replace deployment verification: each release still needs source commit, image, traffic, route, and browser checks.

• tired.events

  canonical

  DNS / TLS

  A resolves to 136.110.237.35. Google Trust Services certificate covers tired.events.

  Origin / proof

  Cloud Run service target is tired-web. HTTP 200 returned through Google Frontend during this pass; provider-authoritative Cloud Run domain-mapping rows remain unproven because the stable command requires the unavailable beta component and the alpha regional command returned no rows.

• tiredevents.com

  canonical

  DNS / TLS

  A resolves to 136.110.237.35. The same Google certificate covers tiredevents.com.

  Origin / proof

  Cloud Run service target is tired-dashboard. HTTP 200 returned through Google Frontend during this pass; provider-authoritative Cloud Run domain-mapping rows remain unproven because the stable command requires the unavailable beta component and the alpha regional command returned no rows.

• tiredapi.co

  canonical

  DNS / TLS

  A resolves to 136.110.237.35. The same Google certificate covers tiredapi.co.

  Origin / proof

  Cloud Run service target is tired-api-core. /health returned HTTP 200 during this pass; provider-authoritative Cloud Run domain-mapping rows remain unproven because the stable command requires the unavailable beta component and the alpha regional command returned no rows.

• api.tiredapi.co

  avoid

  DNS / TLS

  DNS did not return a usable canonical Cloud Run API origin in this pass. No current TLS/browser API proof was established.

  Origin / proof

  Not the canonical browser API origin. HTTP checks could not resolve api.tiredapi.co in this pass; use tiredapi.co unless a future mapping is proven.

This checklist is intentionally operational. It names the three live services and the proof needed before an incident response or rollback is called complete. Payment, media, DNS, secret, and real-account changes still require owner approval.

• Freeze the source

  ready

  ActionRecord the deployed source commit, image tag, Cloud Build id, Cloud Run service, revision, and traffic split before changing traffic.

  Proof requiredCurrent deploy evidence belongs in the repo ledger before a rollback is treated as controlled.

• Choose rollback target

  operator

  ActionUse Cloud Run revision history for the affected service and pick the last known-good revision whose source and browser behavior were verified.

  Proof requiredA rollback target needs revision, image, source commit, traffic percentage, and the reason it is known-good.

• Shift traffic

  operator

  ActionMove traffic in Cloud Run for the affected surface only: tired-web, tired-dashboard, or tired-api-core.

  Proof requiredRe-read Cloud Run metadata after the change; a successful command is not enough without latestReadyRevisionName and traffic evidence.

• Verify public behavior

  ready

  ActionCheck DNS/TLS/HTTP and rendered browser behavior for the affected domain after traffic changes.

  Proof requiredCapture route status, current revision, desktop/mobile render, and any data or auth behavior relevant to the incident.

• Escalate owner-gated systems

  gated

  ActionIf the incident touches Stripe, Connect, media buckets, protected downloads, DNS, secrets, or real accounts, stop before mutation unless the owner authorizes it.

  Proof requiredOwner approval and post-change provider evidence are required before claiming the incident is resolved.