Skip to content

Dev-scenario audit — do the seeds show what the app can show? — 2026-09-08

Status: Active · Owner ask: "the dev scenarios may not reflect what the app is capable of fetching and showing — take another look so they really help us test the app."

Three read-only passes (seed side, read side, schema drift since the seeder's last data change on 2026-09-05) were crossed. The hosted project is the QA bed until the owner declares launch; seed-scenario admits the dev account there through the two-key unlock (see docs/workflows/qa-automation.md).

Findings

  1. The 전체 QA run never reaches the club-detail and social scenarios. The run the owner started on 2026-09-08 executed the home chain (home_* ×20), club_growth, club_cards, the participant views and the scenario builder. club_showcase (groups, gallery, guests, dues per surface) and dense_social (DM, practice logs, manner tags, friendships, challenges, season records, club ELO) are only in other presets, so after 전체 QA the row counts visible to the dev account were: club_groups 0, club_guests 0, saved_venues 0, dm_messages 0, practice_logs 0, manner_tags 0, elo_history 0.
  2. Surfaces no scenario ever populates (the app renders their empty state): club_bank_accounts (회비 bank card), inter_club_challenges (대항전), tournaments rows (the tournament board; home_tournament seeds matches only), match_score_calls (score-call flow), club_growth_events (성장 분석), user_consent (동의 관리/내역), signal_preferences, user_blocks (차단한 사용자), player_external_ratings (NTRP/UTR inference), club_play_regions, member_reports, host_reliability_events, session_templates/recurrences, DM group threads and pending DM requests, club_guests.status='proposed' and membership_recommendations (게스트 제안/추천), saved_venues (즐겨찾기), venue_source_observations for seeded courts (photos, blog reviews, hours), venue_owner_claims (인증됨 badge and the whole owner-claim flow), venue_contributions/venue_corrections (제보/수정 내역).
  3. Seeded courts carry none of the venue facts the finder now renders — rating, review count, hours, telephone, fee schedule — so card v3 and the detail sections only show real data on the imported corpus, never on the clubs' own courts.
  4. Drift bug in reconcile: realizeVenuesFromPublicCourts rewrites court_venues with curated data after the insert-time trigger already linked a directory venues row, so the linked row keeps the fabricated name/address/coords/court_count; the finder and the club schedule disagree about the same court.
  5. No enum or column drift between the seeder's inserts and migrations 00560–00631 (every written value is a valid member); the money-authority guards (00629/00631) bypass the service role by design and the seeder already lets the RSVP/refund/host-exemption triggers derive payment rows.
  6. Read-side telemetry of the run: two get_club_admin_snapshot refusals ("caller is not an active owner/admin") during the chain — the admin-attention hook's cached membership list outlived a truncate/rebuild step; transient to seeding, not a product bug.

Done (same day)

  • qa_venue_layer — facts, observations, saved venues, one pending correction and one pending contribution on the real user's clubs' courts, through three dev-only service-role RPCs (migration 00632). Owner certification is NOT seedable: venue_owner_claims revokes the service role and the submit/review RPCs need real applicant and staff sessions.
  • qa_club_ops — every table in finding 2 except the venue ones, plus the pro entitlement the analytics screen gates on.
  • 전체 QA (full_qa) ends with club_showcase → recruitment_states → session_fee_manual → qa_venue_layer → qa_club_ops (all layered); rung-2 chains qa_showcase and club_showcase carry the two new keys, so yarn qa:seed --local asserts them.
  • Three seeder bugs fixed or worked around: the realize step had been a silent no-op since 00451 (ambiguous embed, error swallowed) — fixed; the linked directory venue is now mirrored after realize; service-role dm_messages inserts are refused by the rate-limit trigger — qa_club_ops inserts under a set JWT claim, dense_social still seeds zero messages (follow-up: exempt the service role in the trigger).
  • Rule going forward (memory + this doc): a migration that adds a user-visible table or column ships with the scenario that populates it.

Still empty by design

Owner certification (인증됨), the owner-claim screens, and 최근 검색/최근 본 코트 (device-local store, filled by real navigation).

Markdown remains the source of truth. Run yarn docs:check before handoff.