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
- 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) anddense_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. - Surfaces no scenario ever populates (the app renders their empty state):
club_bank_accounts(회비 bank card),inter_club_challenges(대항전),tournamentsrows (the tournament board;home_tournamentseeds 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'andmembership_recommendations(게스트 제안/추천),saved_venues(즐겨찾기),venue_source_observationsfor seeded courts (photos, blog reviews, hours),venue_owner_claims(인증됨 badge and the whole owner-claim flow),venue_contributions/venue_corrections(제보/수정 내역). - 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.
- Drift bug in reconcile:
realizeVenuesFromPublicCourtsrewritescourt_venueswith curated data after the insert-time trigger already linked a directoryvenuesrow, so the linked row keeps the fabricated name/address/coords/court_count; the finder and the club schedule disagree about the same court. - 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.
- Read-side telemetry of the run: two
get_club_admin_snapshotrefusals ("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_claimsrevokes 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 withclub_showcase → recruitment_states → session_fee_manual → qa_venue_layer → qa_club_ops(all layered); rung-2 chainsqa_showcaseandclub_showcasecarry the two new keys, soyarn qa:seed --localasserts 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_messagesinserts are refused by the rate-limit trigger —qa_club_opsinserts under a set JWT claim,dense_socialstill 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).