Owner review 46 — the hub and list-a boards, first library pass (2026-10-19)

Status: Active — all six lanes landed; the proposals wait for the owner · Date: 2026-10-19

The owner's first pass covers the hub board (홈, 기록, 프로필, 클럽 홈) and the list-a board (tabs, inboxes, club management): "this is everything I've reviewed up to lists: tabs, inboxes, club management". The rest of the library pass (list-b, detail, forms, auth, flows) is still to come. The same message answered the takeover questions (below).

The marks

The owner's list repeats the numbers 3 and 9, so the marks are numbered M1–M28 here; the words are the owner's.

#	Mark (owner)	Lane	State
M1	"Page grammar is sound."	—	Approved
M2	"Home page seems fine."	—	Approved
M3	기록: "The only grip I have with the components here is the strip, which gets used in other pages as well. This is the only component that has a lot of empty space at the front and at the end. This breaks the visual alignment of the general page. How can we ameliorate that? What's the best practice for a summary row like this?"	A	Accepted (10-19)
M4	"In the records page, we probably don't need to add 복식 or 단식과 복식 labels next to 최고의 파트너 & 천적 because they are sort of implied by other labels, no?"	—	Accepted (10-19)
M5	"In 200%, the monthly active doesn't render correctly. And I am not sure what the activity grid actually shows. Is it a heatmap of activity per month along the grid? Can it be scrolled then?"	A	Approved (10-20)
M6	프로필: "let's work on the full foundation for the 신뢰 section. What are we measuring? Why does it matter? What would matter to people?"	D	Two-line records (10-20)
M7	"As for the other friends and accomplishments (and in fact 랭킹 section in the records page), can we focus on the alignment, position and best practices for the count next to the section header? They seem a bit out of alignment."	A	Accepted (10-19)
M8	"Achievements seem to have the same alignment issue where the section has too much spacing in front and at the end. Can we make this section horizontally scrollable?"	A	Accepted (10-19)
M9	클럽 홈: "navigation tabs (홈, 채팅, 순위, etc.) should also underline the counts (like 3) next to the tab name."	A	Accepted (10-19)
M10	클럽 홈 순위: "we should also show the group standing. And how about turning it into a 기록 section? That way, we can show standings and statistics (h2h, best partners, nemesis, and all the other things that a records page would show but make it so that we are showing the stats for the entire members. Who are the best partners? Who are the worst matchups? and etc.). This way, we can remove 복식 파트너 추천 from the members page and dedicate it to really just showing the members."	C	No Block (10-20)
M11	클럽 홈 회비: "instead of labels, let's put a copy button next to the account number. We will eventually configure an escrow-type payment system for the app (the way smaxh app does). And configure the empty states more properly. 멤버 초대해 보세요 seems a bit empty."	C	Approved (10-20)
M12	"I think club list items should also be larger, to match the feed items in home and club pages. It's lacking crucial information like gender, ratings/conditions, preferred match format (and what other should we list if we allow three rows of key facts?)"	B	Approved (10-20)
M13	"The same goes for sessions. Sessions should also match the feed items."	B	Approved (10-20)
M14	"Alarm is perhaps the most underworked section of them all. Find best practices and improve the UI/UX of it all, making sure we can aggregate alerts from all parts of the app into here."	E	처리할 일 filter (10-20)
M15	"Conversations seem fine."	—	Approved
M16	"Members page needs a clean grammar and UI/UX review. It seems there are action items as well as a members list, but we don't seem to have clear distinction."	C	Drawn (round 2)
M17	회비 page: "Same issue here with the strip. And it must be noted that different clubs would have different lengths and frequencies of member dues. And we would need separate pages for my dues as well as dues and expenditures for the entire club. Can you look into what this page would actually have to entail? What would be best practices, in terms of functionalities as well as UI/UX, for this in an app that supports group activities?"	C	Drawn (round 2)
M18	"Club sessions (incoming, live and past) should also go through the same item re-configuration to match the feed item. This way, most of the new 'events' in the app adopt the same grammar and look."	B	Approved (10-20)
M19	"On attendance, let's also take care of the strip. It's otherwise fine."	A	Accepted (10-19)
M20	"Reports are fine."	—	Approved
M21	"For tennis venues, let's also adopt the same feed item grammar and look. And users should be able to enter not just the # of courts but also which courts they have booked."	B	Approved (10-20)
M22	"Let's adopt the same feed item grammar and look for 클럽 대항전."	B	Approved (10-20)
M23	"Album's fine unless you have something to say."	—	Approved; a note may follow
M24	"For best partners, make sure we can properly show how each point is calculated. And remove metadata like 궁합 - 클럽 멤버 중 나와 잘 맞을 만한 ..."	F	Drawn (round 3)
M25	"Participants list seem fine, but we need to combine this with the participation fee page (and adopt the person row grammar)."	C	Drawn (round 2)
M26	"Participation confirmation page also take care of the strip and adopt the same person row grammar. And this isn't after a session — this should be performed before and during a session starts so that matchups can be adjusted accordingly. And we should also be able to know who starts when because everybody has a different start and end time when it comes to participation in a session."	C	Drawn (round 2)
M27	"Pick up host page is fine."	—	Approved
M28	"And broadly speaking, we really need to properly take care how club pages navigate to different pages. Which ones should be more accessible than others? Related ones should be mutually accessible. The same goes for pickup pages."	F	Drawn (rounds 3–5)

Lanes: A, the shared primitives (Strip, section-head count, horizontal shelf, tab counts, the activity grid); B, list items on the Feed item grammar (clubs, sessions, a club's sessions, venues and booked courts, 대항전); C, club money, members and participation (회비 pages, members, the club 기록 section, participants with fees, participation before and during a session with each player's own times); D, the foundation of 신뢰; E, 알림 as one inbox for the whole app; F, how best partners are scored, and navigation between club pages and pickup pages.

Proposed rulings after lanes A–C

Evidence: lane A, lane B, lane C. Each is drawn on its board for the owner to judge; nothing reaches app code before the owner's library pass allows it.

• M3, M17, M19, M25, M26, the Strip. The empty space has been moved three times already (start, hug-last, centred; reviews 1, 2 and 3): with n equal cells it only changes place. Proposed rule: a count that repeats the sections below it is not drawn twice. 회비, 참석 확인 and the participants page lose their Strip for one line that says what is left to do ("₩510,000 / ₩600,000 · 17/20명", "6명 · 입금 확인 3 · 필요 2"). A true stat summary (기록 전적, 신뢰) becomes tonal tiles from rail to rail (gray100, r12, 8 apart), which gives the space an edge. Fallback: Cell rows (label left, value right). Drawn as a proposal on the hub, list-a and library boards: tiles for 기록's 전적, 프로필's 신뢰, the 순위 peek, 출석 현황 (가입 후 출석률 and 추적; 주의 left, it repeated the head under it) and 클럽 대항전 (승 and 패; 진행 중 left for the same reason); one line for 회비 (hub and list-a), 참가비 and 출석 확인 ("8명 | 불참 2 | 미확인 2"). The lines keep the slash forms of the examples; the caption-row rule prefers "N 중 M", which the owner may choose instead.
• M4. The 복식 and 단식과 복식 labels leave 최고의 파트너 and 천적; the module already implies them.
• M5. The grid is one cell per day and one column per week, the last 22 weeks to today. It says so once, in the same words as its accessibility label ("최근 22주 중 N일 활동"), with steps defined (0, 1, 2, 3, 4+ matches that day). It does not scroll: older history is behind 분석 ›. At 200% the month labels scale in the chrome class, so they no longer run into the grid.
• M7. Title, count and text action share one baseline; the count sits 8 after the title (was 4), 15/22 ink2 with its unit.
• M8. 업적 becomes a Shelf: 76-wide items 8 apart, the first on the rail, the fifth peeking; up to five earned, then 전체 보기. The library's Shelf test gains this exception.
• M9. The tab underline spans the label and its count.
• M10, M16. 순위 becomes the club's 기록: a season Block, then 순위 전체|조별 (a table per 조), 베스트 파트너, 라이벌과 천적, 출석, 상승세, and 선수별 전적. The members pane becomes the roster only: actions (가입 신청, 게스트) gather on one 할 일 row that opens 가입 심사, and 복식 파트너 추천 moves to 기록 or the 대진 flow.
• M11. A copy button beside the account number (the native clipboard module arrives with the next build; until then the share sheet). Empty states become setup steps for officials and a calm line for members. "smaxh" is 스매시 by smaxh Corp., which holds no-show deposits; escrow is a later design on top of the existing payment hold.
• M12, M13, M18, M21, M22. One Feed item for every event-like object, with two facts rows (what, then who), 144 tall: clubs (level, composition and format; rhythm, dues, the join gate), sessions (time and your state; format, composition, level, booked courts), venues (courts, surface, indoor; open now, price), 대항전 (period; standing). Booked courts are already stored and enterable (sessions.used_courts, 00499); the boards and the session model start showing them ("3~4번 코트").
• M17. Two pages: 내 회비, and 클럽 회비·장부 (balance, collection progress, rows with verbs, a ledger of income and expenses). Dues follow each club's own plan (monthly, quarterly, yearly, per session, one-off), which needs a dues-plan migration.
• M25. Participants and fees become one page of person rows, sectioned by what the host must do.
• M26. 참석 확인 opens two hours before the start and runs through the session. Each player has their own window (arrival and departure), and match generation reads it; this needs new rsvps columns and an engine change.

Proposed rulings after lanes D to F

Evidence: lane D, lane E, lane F.

• M24, best partners. Two of the score's inputs are wrong, so the number cannot be explained yet; both are confirmed in code. 함께 친 기록 (30 of the 100 points) reads the opponent ledger (player_matchups), so beating someone raises your chemistry with them; the teammate ledger (player_partner_records, 00692) has a hook and no caller. 출석 (15 points) divides a 0–1 rate by 100, so it is always 0 and the real maximum is 85. The fix is in the domain and the hook, not on a page: chemistry from the partner records (doubles and mixed, in every club, so a pickup played together counts; draws count to neither side, as on 기록) and attendance read as the 0–1 fraction it is. Fixed on 2026-10-19; it needed no ruling. Then the breakdown: a row opens a sheet with the total ("83점 / 100점"), four Cells that each give their points and the fact behind them (실력 차이 36/40 "나 ELO 1,482 · 이서연 1,523 (41점 차)", 함께 친 기록 23/30 "같은 편 12경기 9승 3패", 신뢰 10/15 "신뢰 멤버", 출석 14/15 "출석률 93%"), the sum, and a "?" that opens the four rules. The 궁합 caption row and the adjective reasons go; the figure carries its unit and line 2 states the strongest factor's fact. Small samples say so ("함께 친 적이 없어요 · 기본 15점"). One sheet serves the club 기록's 베스트 파트너 (M10) and the 대진 flow, and the five "best partner" rules in the code become one (5+ matches together, as ratified).
• M28, navigation. Rules: five panes at most; weekly work is never only in a sheet; monthly work sits in 관리 and at a pane's end with a count; rare work lives in 설정; every object a page names is a visible row that opens it; pages used one after another share a switcher. 관리 splits into 운영 (멤버 관리, 일정 관리, 회비 관리, 출석 현황, 신고 관리) and 설정 (테니스장 관리, 클럽 대항전, 성장 분석, 클럽 설정). Mutual links: a session ↔ its club, venue and host; a venue → its next sessions and open 번개; 클럽 홈 → its home court; a member or 순위 row → 프로필 and 나와의 전적; 내 회비 → 참가비 내역; 참석자 관리 ↔ 참석 확인. A public club session in 번개 찾기 names its club. Today's six dead ends (출석 현황, 대항전, 성장 분석, 앨범, the 회비 rows, the 순위 peek) get their way out. Prevention: an edge list generated from the routes.* call sites fails on a page nothing links to and on a broken pair.
• M6, 신뢰. Today the tier reads five inputs (sessions, distinct manner tags, account age, the lifetime attendance rate, unresolved reports), with seven faults: attendance is recorded only in clubs that turned tracking on (off by default) while the tier is app-wide; handling a report erases its demotion; a strike never expires, so the RSVP block lifts only by a 총무's excusal; two friends trading tags meet trusted's tag clause; veteran has no attendance clause; the demotion push always blames attendance; four formulas compute attendance. Proposed: facts the person controls and no composite score. Five things are measured (참석, 시간, 정산, 공정, 매너); the tier reads sessions, 참석, 매너 and upheld reports, and 정산 is for the host and 총무 only, never in the tier. Records count for 12 months or the last 20, so misses age out; a report counts once a 총무 upholds it, for 12 months; praise counts distinct people who shared a match. The four tiers keep their keys, labels and parity gate; what earns them changes (trusted: 20 sessions, fewer than 2 strikes, 5 praisers, no upheld report; veteran: 50 sessions, 6 months, the same gates, 10 praisers). The person sees their whole record and can ask for an excusal (사유 인정 요청). Nine migrations (lane D, § Migrations).
• M14, 알림. Today it is a v1 list under a v2 board: 37 of the 101 declared kinds never fire; a row disappears when it expires (about half the kinds within 48 hours), so 이전 알림 covers days, not the promised 30; repeats are not grouped (a 12-week series sends each member 12 new-session rows); and one severity decides push, band and bell at once, so FYI news lands in 할 일 and a cancelled session never reaches the bell. Proposed: 알림 opens with a pinned 할 일 (홈's own list, absent when empty), then 오늘 / 이번 주 / 이전 알림 (30 days), newest first, with one filter Choice (전체, 안 읽음, 관리, 일정, 경기, 회비·입금, 클럽, 사람, 시스템). Each row is a PersonRow: a face when a person did it, the club's avatar for club events, a glyph for the system; one 해요체 sentence with the actor first ("민지님 외 2명이 댓글을 남겼어요"), then the club and the thing; unread is the dot alone. Repeats fold into one row with the latest actor and 외 N. Swipe or select to delete, with 8 seconds to undo, and "이런 알림 끄기" in a row's menu. The bell counts the unread rows here, one per group, never 할 일 or chat, so it equals 안 읽음. A push follows urgency (time-sensitive only for what happens within the hour) and groups by the same key. Settings regroup the 13 categories into six families and add a per-club level (전체 / 공지만 / 끔). The missing signals arrive (friend requests, club invites, score corrections, a freed seat for the waitlist, 공지, mentions, achievements, 대항전). Eight migrations (lane E, § 5).
• Owner decisions from lanes D to F (the lead's recommendation in bold; the owner said yes to all ten on 2026-10-19, with W2 as W2a):
  1. 클럽 홈's next session: reinstate one next-session row above the Feed (review 41 removed 다음 일정), or keep it out (the club's sessions are already rows in its Feed; your own next session is one tap away on 홈 and 경기; another club session takes 2–4 taps).
  2. Attendance: record it in every club and pickup, the club setting then deciding only enforcement (this reverses the spec's club opt-in; pickups, the stranger case 신뢰 exists for, have no switch today); or keep the opt-in and label the rate as counted only where tracking is on.
  3. Who sees 신뢰: strangers see the tier only (today any signed-in viewer sees the rate and session count, and the anonymous share card the tier and sessions); a shared club, session or friend sees the tier and one fact.
  4. The name 신뢰 멤버, which collides with the section's name: keep it for now (lane D's advice) or rename it.
  5. 알림's order (D1): time sections (오늘, 이번 주, 이전 알림), where reading a row leaves it in place (Slack, GitHub), or read bands as drawn.
  6. Chat (D2): stays out of 알림; 메시지 keeps its own badge and push.
  7. A pending 친구 요청 (D3): answered inside 알림, as Instagram does (an exception to AnswerPair's "request lists only"); money, 가입 심사 and scores still open their pages.
  8. Urgent arrivals (D4): count on the bell, as the library says (today the code subtracts them).
  9. Low-severity pushes (D5): a per-club level (전체 / 공지만 / 끔, as Strava does) rather than silencing every low-severity push.
• For counsel, later: whether the tier or the RSVP block is a solely automated decision under PIPA Art. 37-2 (explanation on request, published criteria); 본인인증 as a one-time fact (EXT-19).

The owner's check of the drawings (2026-10-19)

The owner's words: "The activity grid can probably be compacted into a monthly grid. We don't have to show all these months all at once. All ther components are accepted. All great on hub pages except we still need to add a copy button for the 회비's account number. On 9, for the dues summary, we need to bring more visual emphasis to the summary because it is the most important. 10's fine. 도전 과제, on 클럽 대항정, we need the items to also reflect the feed items design. 12 is fine. 13 is fine. As for a general direction, I want our components across pages to have the same shared foundation. That eliminates the possibility of UI/UX divergence as well as hardcoding."

• Accepted: the section head (M7), the tabs (M9), the Strip's tiles face and its what's-left line (M3), the activity grid's sentence and steps (M5) and the badge shelf (M8); the hub pages (기록, 프로필, 클럽 홈; M4); on list-a, 출석 현황 (M19), 참가비 (M25) and 출석 확인 (M26). The library's "proposed" markers come off, and the same Strip rules reach the list-b and detail boards.
• Next on the boards:
  • The activity grid shows one month at a time, on the kit's calendar month (one month grid in the app), with a month switcher and its sentence; older months are a tap away, never on screen at once.
  • A copy button beside the 회비 account number (M11), as one shared account row wherever an account number shows; the clipboard module arrives with the native build (W5).
  • The 회비 page's summary leads the page with more emphasis: a Block (the period; the collected figure with a progress graphic; one line of facts) in place of the line.
  • 대항전's items on the Feed item (in progress with M12, M13, M18 and M21), and the board's 도전 과제 renamed 클럽 대항전, the app's name for it.
• Drawn (2026-10-19), for the owner's next look:
  • The activity grid is one month on the calendar's month grid, with ‹ › and its sentence ("9월 중 6일 활동"); the hover readout still names the day and its matches.
  • The account row's copy control is a copy icon button (owner: "copy '복사' button can be replaced by a copy icon button"), named 계좌번호 복사, with the toast 계좌번호를 복사했어요; one shared row on the hub's 클럽 홈 회비, list-a's 회비, detail's 참가비 sheet and the library.
  • The 회비 page leads with a dues Block: 9월 회비 and the month door, 370,000원 / 570,000원 with a progress ring, and 19명 중 12명 납부 | 미납 7명; drawn in every state and in the library as "Block, dues". Open for the owner: the door reads 월 선택 ▾, because the eyebrow already names 9월 (the member view's month Choice reads 9월 ▾).
  • 대항전's items are Feed items, and the board says 클럽 대항전; the 관리 sheets follow with the forms pre-work (one registry).
  • The Strip rules reach list-b and detail: tiles where the Strip is a stat summary (연습 기록, 리더보드 지역, 성장 분석, 장소, 공개 프로필, 기간 기록, 일일 요약, 선수별 전적), the what's-left line where it only restated counts (업적); the "proposed" markers are off.
• Drawn in round 1 (2026-10-19), for the owner's next look:
  • M14, 알림 (list-a, notifications, 25 frames): the viewer's whole 할 일 on top, then 오늘, 이번 주 and 이전 알림 (30 days); reading leaves a row in place and the dot is the only unread mark; a face, the club's logo or a glyph disc says who a row came from; a repeat is one row; a pending 친구 요청 is answered in its row; the bell counts the unread rows. The library's PersonRow, Avatar, Section head, AnswerPair and Toast entries carry it.
  • M6, 신뢰 (hub › 프로필; detail › 공개 프로필 and the new 내 신뢰 기록, 13 frames): the tier, 20회 중 참석, 연속 참석 and 칭찬한 사람, a private Notice only when there is something to do, every record with the rule applied and the day it drops off, and 사유 인정 요청; a stranger sees the tier only. The library's new § 4 Trust holds the model; the officials' view goes to the club-pages lane.
  • The forms pass's kit and library pre-work: the equal-choice Dialog, the Stepper beside a slider, one 관리 registry, the notification families (the money family is 회비와 참가비), the leave and edit guards, and the forms clauses. The forms board follows in batches.
• Drawn in round 2 (2026-10-19), for the owner's next look: the club pages (M10 기록 pane, M16 the roster, M17 내 회비 and 회비 관리, M25 참석자 관리, M26 참석 확인 with each player's window), the officials' side of 신뢰 (멤버 기록, 신고 관리's outcome), a member's 할 일 on 홈, and forms batch 1 (the forms pass's twelve conflicts, the new 행사 만들기).
• Drawn in round 3 (2026-10-20), for the owner's next look: navigation (M28: the 관리 split from one registry, the club's panes from one list, mutual links and the navigation map on the hub; the detail board's links are next), best partners (M24: the Score Sheet and its rules), forms batch 2 (the sweep), and W2a's last hand lane.
• Drawn in round 4 (2026-10-20), for the owner's next look: the detail board's links (M28: 일정 상세's club and venue rows and its own 관리 sheet, 번개 미리보기's rows, the sessions and clubs on both 장소 상세 pages, 공개 프로필's 나와의 전적, 성장 분석's way on), 참가비 내역 (the page 내 회비 ends in), the kit's Score Sheet, Explainer Sheet and "?", and forms batch 3 (the patterns).
• Drawn in round 5 (2026-10-20), for the owner's next look: forms batch 4 (the reveal) with round 4's calls on the forms board, so the forms pass is drawn whole; 나와의 전적 (M28: the 공개 프로필 door's page) and 성장 분석's 모집 계획; sessions named by place and day in alerts, records and fees; the kit's missing pieces (a Cell's second line at large text, the picked venue row, the Empty state's copy written once, faces as thumbnails, the warning caption).
• One shared foundation, a standing rule: every page composes the shared components; no page keeps its own variant of a shared pattern, and nothing is hardcoded. The page boards compose only the kit; in code, W2 to W4 build and adopt the shared primitives, with lint rules against hand-built variants. An audit of the page-local components on the boards starts now.

The owner's check of the activity grid and of the visual checks (2026-10-20)

The owner's words: "M5 still shows on-hover tooltips that render with date and the match count. I thought we only went with a count on hover. Or we can do color gradients for the heatmap so that we can indicate the # of wins or losses. So we have three shades of colors - wins, losses or neutral." Then: "And please, please, as we go through these visual checks, remove the stale ones and streamline the pages because otherwise, I can't know if you made the changes or not"

• Drawn (2026-10-20), for the owner's next look (the record page's item 4): a day you played takes its result's colour: the success hue where you won more, the danger hue where you lost more, the neutral fill when even, deeper by the margin (1, 2, 3 or more); a day without a match is its number alone. The readout is the day's count alone ("1승 2패"; the day is the number under it), the legend runs 패 to 승, and the sentence adds the month's record ("9월 중 6일 활동, 9승 6패"). One result scale serves the app (the library's 1.7, as the app's own 기간 기록 calendar colours a day), so the Form strip's cells take its solids.
• The visual checks, streamlined: the record page lists only what waits on the owner. Accepted items leave the list (one line names them), an item redrawn since the owner's last look says so, and no line describes a drawing that is gone; the flat v2 boards keep no drawing a change has replaced.

The owner's check of items 4 to 15 (2026-10-20)

The owner's words: "Activity heat map is better. Approved. The copy icon button is approved. But I am still concerned 입금 완료 안리기 has the metadata (납부 분의는 ~) and is not at the very bottom even though it's a CTA in one render. Otherwise, I like it. 클럽 대항전 also has the same issue where it has 5 rows of data. The same goes for club, session, venue. All feed items should have at most 4 rows of facts. Streamline what need to be presented. I like the strip, and but it needs no meta data (like 무승부는 승률에 넣지 않아요). We generally never put meta data unless an error occured during an input process. Work on these and update accordingly. Then I will move on."

• Approved: the activity grid by result (M5, item 4), the copy icon button (M11, item 8) and the dues pages (item 9, the Block and its door as drawn), and the Strip (item 15) without its meta line.
• Drawn (2026-10-20):
  • 입금 완료 알리기 is the bottom CTA band wherever a member owes dues: 클럽 홈's 회비 pane drew it in the content with "납부 문의는 총무에게 연락해 주세요" under it, and now pins it at the very bottom with no line; list-a's 내 회비 had the band and loses the same line.
  • A Feed item has at most four rows (M12, M13, M18, M21, M22): the overline, the title, the facts row, then the footer (홈, 클럽 홈) or the who row (a list of one kind), never both, so every item is 128. A list item shows no posted time and no counts; a venue's distance leads its facts while 가까운 순 is on and its rating ends its who row; a session's seats stay only as its deciding fact.
  • No meta lines on any board (the library's 1.16): no footnote under a figure, a group or a Strip, no line beside a CTA, no hint or note under a field, no Section head note that explains, no legend. On the seven page boards the sweep took out 29 Caption rows (알림's end line became the kit's Feed end), 39 field hints (회원 탈퇴's phrase became its label; the password rule is the error's text in sign-up and in 비밀번호 변경 alike), about 76 helpers and band lines, 19 Section head notes (클럽 홈's 출석 and 상승세 now name their measure in the title: 최근 20회 출석, 7일 상승세), 5 Sheet descriptions, 8 explanations under switches and doors, 9 lock reasons, a field note and two explaining Notices; 26 lines stay, each with its reason on the board (an error after a press, a live total or count, an empty Module's line, the shortfall, the price of joining, the dues plan's figures, one requirement to proceed, 네이버 제공). The library boards follow: the Field hint and Field note sections are marked retired with one error-only frame each, the Caption row keeps four frames (the Feed end, 네이버 제공, the shortfall), the CTA band keeps the helpers 1.16 allows (a total, a live total, the price of joining, a failure), and a locked Cell shows its lock alone.

The owner's second check of 2026-10-20 (클럽 홈, 알림, 내 신뢰 기록, the forms)

The owner's words: "Just maybe, there is too much spacing above and below the club page's navigation tabs. Can you make sure it's canonical? And while I think the addition of a block to a club page helps to clarify the more important information, I am scared if it is taking up too much space that obscures the components below. This was not a problem for main pages because they had nothing on top, but with this, club pages will show very little. Maybe we should have blocks on club pages. What do you think? ahd 홈코트 section can be better because the section title (home court) is too tiny. I confirm the updated feed items. On the alarmt section, I don't think we need to have a separate todo list. We can add options in the alerts drop down filter (and please configure 모두 읽음 button properly because it just looks like a text - refer to best practices) to only show oustanding issues. And perhaps facts can use the contained strip? The no-show needs some work. We shoul. We should limit rows to 2 (including the title). It seem to have as many as 6 rows, in case of English version. And if would be great if we can also post a thumbnail on the items here, most likely that of venue. And I think I like the forms; just mke sure they implement a consistent and non-redundant (cleaned up of clutter, stale or unnecessary options) UI/UX across forms."

• Approved: the Feed items at four rows (M12, M13, M18, M21, M22; items 11 and 14), and the forms, with a consistency pass.
• Drawn (2026-10-20):
  • 클럽 홈's Tabs sit 8 under the hero (they sat 24 under it; list-a's drawing of the same page already used 8), and a pane starts as the Tabs rule says, 24 to a title and 16 to a row; a visitor, who has no Tabs, no longer gets two gaps in a row.
  • The owner asked whether club pages should have Blocks. The lead's answer, drawn: no Block inside a club page. The band and the hero already lead it, so 기록's season is a Section head with the 시즌 ▾ Choice over three tiles, and a member's 회비 is a Section head (3분기 회비 | 7월~9월) over two tiles (낼 금액, 9월 25일까지 D-6). Pages with nothing on top keep theirs (홈, 기록, 프로필; 회비 관리; 내 회비).
  • 홈 코트 is a Section head over the venue's row with its map.
  • 알림 keeps no 할 일 list: its filter offers 전체, 안 읽음 and 처리할 일 (the alerts that ask the viewer to act while their request is open), and 모두 읽음 is a tonal Button, as every Section head's command now is. 홈's 할 일 door opens 알림 at 처리할 일.
  • 내 신뢰 기록 opens on the 신뢰 head over 프로필's three tiles; every record is a two-line row with its venue's map (at most two lines in Korean and English), and the row opens the record's Sheet, which holds the rule applied, the day it drops off and 사유 인정 요청.
  • The forms: each thing is done one way. 일정 만들기 asks 실력 as 클럽 만들기 does (클럽 기준 그대로 | 범위 설정) and its 종목 Sheet carries 경기 유형; one label per field across 클럽 만들기 and 클럽 설정 (성격, 실력 범위, 소개, 탐색에 공개, 정원) and 최대 인원 for every cap; 사진 변경 on every photo row; 공개 범위 설정 draws value Cells like every settings page; Steppers show bare numbers; 게스트 참가비 is 무료 | 유료 as 참가비 is. Gone as redundant or stale: 회원 탈퇴's second Dialog (the typed phrase confirms it), 클럽 가입하기's Notice that repeated its own row and button, 글쓰기's 총무 전용 (운영진방 already is), 설정's 공개 프로필 보기 (공개 범위 설정 previews it), 호스트 참가비 면제 under the account (it sits with 회비 now), and the review lines the meta sweep missed. Left for you: 프로필 수정's 비공개 values, one word for a venue (장소, 테니스장, 활동 장소) and the app's 경기 방식 (친선 | 경쟁), which 일정 만들기 does not ask.

The owner's third check of 2026-10-20 (the page levels)

The owner's words: "Forms checked. In the 신뢰 기록, I think we just need to show a one-line alert about the cap for warning and when it releases. Just pure numerical facts. 알림 seems good. Club 홈 -> 기록 & 멤버 looks good. In terms of 회비, perhaps there's too much space above and below the 회비 설정 row (is this the right place to host this information though?). On 멤버 기록 (신뢰 등급), I thought I asked you to render the contained strip where each stat is contained and aligned horizontally? See, examining your work, I can't help but feel that we are lacking a grammar rule. I want there to be a consistent grammar across pages across the hierarchy. And please tell me if I am reading this right. At the topmost pages (primary pages reached from the bottom navigation), we have a block followed by list(s) (unless there is a navigation component on top of the list). In the secondary pages like the club pages, we have the top hero, navigation and list(s). Then we have the detail pages that have no top hero, no further navigation, and strip and or lists. Am I reading this right? I can be wrong, and I need your correction in our attempt to organize the visual grammar across the app. I am asking this because we seem to be mixing grammars here and there across the hierarchy. Can you please organize things by the visual hierarchy so that we can directly compare and audit how pages of the same level in the hierarchy are implemented? The current division of pages are a bit misleading. And please make sure to update the pages along the way. And please mark the pages with the corresponding codes that the visual benchmarks. I find it difficult to pinpoint the pages to audit."

• Approved: 알림 (item 16), 클럽 홈's 기록 and 멤버 (19, with 40), and the forms (18 and 41).
• The reading, corrected (library § 1.17, Page levels):
  • Tab roots (L1): right. A root leads with one Block when it has one answer (홈, 기록, 프로필) or with the Tabs when it switches between views (클럽, 경기), never both; then bounded Modules and the one Feed.
  • Object pages (L2): right, with two corrections. A level is the page's kind, not its depth: an object page is one thing opened from a row (a club, a session, a venue, a person), wherever it is reached from. Its navigation (Tabs) appears only when the thing has views of its own, which today is 클럽 홈 alone; 일정 상세, 장소 상세 and 공개 프로필 go from the hero to Modules and a Feed. The hero is the thing's own: a photo band and the logo for a club, a map band for a session or a venue, the face and no band for a person.
  • Detail pages (L3): right, plus no Block. No hero, no Tabs and no Block: a page that sums something up leads with a Section head over the tiles, then a one-line alert of numbers when something needs attention, then its lists; a list leads with the list, its one filter in the first head. Named exceptions: 참석자 관리 and 참석 확인 share a switcher, and 스코어카드 keeps its live Tabs.
  • Missing from the reading: forms (L4: wizards, edit pages, settings; no lead, the first question, the CTA band) and the pages before sign-in and the public previews (L0, Entry).
• Drawn (2026-10-20):
  • Every page has a code (84 pages: L0 7, L1 6, L2 6, L3 45, L4 20) in docs/workflows/page-levels.json. Each board shows the code beside the page's name, and a page drawn inside another page's section (내 회비, 회비 설정, 가입 신청, 메시지 요청, the email sign-in) shows it on its frames. The new index wireframes/page-levels.html shows every page's first screen by level and family, side by side; the record page lists the same codes. The board build fails when a page has no code or a code names a page that is not drawn.
  • 내 신뢰 기록 and 프로필's 신뢰: the cap is one line of numbers, 불참 1/2건 | 2027년 9월 5일 해제 (warning) and 불참 2/2건 | 2027년 8월 9일 해제 (danger). The cap counts records (two stop new RSVPs) while 출석 주의 adds their weights, so the unit 건 says which.
  • 회비 관리 and 내 회비 lead with a Section head over tiles, not a Block. The 회비 설정 row left 회비 관리 with the space around it: the plan is the club's setting, and its one door is 클럽 설정 › 회비 › 회비 설정.
  • 멤버 기록 opens on the 신뢰 head over three tiles in a row (13회 중 참석, 연속 참석, 지각); 출석 주의 is one line, 출석 주의 3.5/3 | 2027년 8월 22일 해제; the absence and attendance records are two-line rows with the venue's map, as on 내 신뢰 기록, and a row opens the record's Sheet, where an official answers 인정 or 거절.
  • 공개 프로필 leads with the person's hero (the face, the name and the facts) in place of the identity Block. 가입 심사, 제안 접수 내역, 장소 소유권, 기간 기록 and 일일 요약 lost their Heroes: a task leads with its row, a record with its tiles.
  • A page's first head sits 12 under the Header everywhere, as on 알림 (pages had it at 0 or 12, and 기간 기록's 필터 was cut by the Header); a frame drawn scrolled draws its Header scrolled. The board verifier's new under-header check keeps both.
  • 메시지 and 일정 관리 lost their Tabs: 메시지 opens on the inbox, with a 메시지 요청 row on top while requests wait, and 일정 관리's head offers 예정 and 지난 일정; 장소 정보 제안 내역 and 소유권 신청 내역 keep their views as the head's filter.
• Left for you: 스코어카드's Tabs and match Block (the live exception); 클럽 가입하기's club hero (review 43, option B), which the rule would make the club's row; whether 내 회비 stays a page when 클럽 홈's 회비 pane shows the same; and 회비 관리's tiles in place of the Block your 10-19 check asked for as emphasis.

The owner's answer of 2026-10-21 (the four calls of the page levels)

The owner chose the lead's recommendations: "Apply your recommendations on the four calls: keep 스코어카드's live Tabs as the one exception, name the club as a row on 클럽 가입하기, fold 내 회비 into 클럽 홈's 회비 pane, and keep 회비 관리's tiles."

• 스코어카드 keeps its live Tabs and the match Block, the one live exception (library § 1.17).
• 클럽 가입하기 names the club as its row (the logo, the name, 강남구 | NTRP 3.0–4.0 | 멤버 42명), as 소유권 신청 names its venue: a form about one thing names it first as its row. Review 43's club hero leaves the page.
• 내 회비 folds into 클럽 홈's 회비 pane. The pane draws every plan the page drew (매월, 분기, 매년, 일정마다, 한 번, 완납) with the account's copy row and 입금 완료 알리기; a 회비 push or door opens 클럽 홈 at 회비; 회비 관리 is the officials' alone. The page's code, L3-12, retires: codes are stable, so it stays unused.
• 회비 관리 keeps its tiles (the head 9월 회비 over 받은 회비 and 19명 중 납부).

The owner's notes of 2026-10-25 and the cohesion pass

The owner's notes: "L3-01 Confirmed. L3-11 I am not sure about the location of 취소, 3명 선택됨 전체 선택. We the have too many locations where user interactions happen. The bottom is the CTA; do we need the top row? A user can simply tab to select or deselect. Why do we need 선택 button next to 확인 대기? Let's streamline our actions in all sections. Agree with the rest. L3-35 I find the top summary rows under 참석자 page to be quite ugly. (the top two rows below the navigation tab, tracking the count and fee). We should streamline our actions here as well. L3-36 Confirmed."

The owner's request: "I am working through our visual checks, but I find that we literally too many for me to manually check. Can you make sure we are applying a consistent grammr and UI/UX principles across all our pages so that a user can never feel out of place as they navigate in and out because they claerly know what to expect from a consistet and clear visual grammar and cues? Let's make sure all our pages do a really good job of delivering a consistent, clean and intuitive experience to all users. And that means not just the pages themselves but the navigations among them are top notch. So please take your time and work through them all. And give me the cohesively finished wireframes, along with their navigations and relationships, so that I can really just check your work instead of micro managing you every step of the way." And, before the night: "I am going to sleep, so I want you to run autonomously until you can ensure all pages in our new v2 flat layout are all designed and organized cohesively in accordance with our design grammar, practics, principles and system. We are trying to deliver an intuitive, modern and clean UI/Ux that is ready to be implemented once approved. So that means no visual clutter, no loud components scattered everywhere."

• Confirmed: 내 신뢰 기록 (L3-01) and 참석 확인 (L3-36).
• 회비 관리 (L3-11), drawn: no Select mode. The page keeps its Header; the 확인 대기 rows carry ticked checkboxes and a tap ticks or unticks one; the band names the job with the count (3명 납부 확인), then 미납 4명에게 알림 보내기 once nothing waits, then nothing. Rows carry no buttons and no ⋯: a row opens the member's Sheet (멤버 기록 first). 지출 추가 and 회비 설정 are the header ⋯.
• 참석자 관리 (L3-35), drawn: the two top rows are gone (the count line and the fee Cell); the page opens on its first section under the switcher. The same picking and band as 회비 관리 (3명 입금 확인), the same words (확인 대기, 미납), no ⋯ on rows, a row opens the person's Sheet.
• The cohesion pass, drawn on every flat v2 page (84): the library gained § 1.18 Actions (one home per action: the band does the page's job, rows are picked by tapping them, a row is one tap, rare commands are the header ⋯, sharing is the header's 공유, making is the FAB, a section head holds one control, counts live in heads, a Notice is a state) and § 1.19 Words (a door reads the title of the page it opens; one word per thing). Select mode is retired everywhere. Row ⋯ menus are gone from every page board. The lime Level tag shows only where the library says (Roster, Podium, identity, the first row of a level run). Every first head sits 12 under the Header. The object pages share one header (공유, 저장, ⋯ or 관리). Settings pages edit by value Cells, their danger zone last.
• The navigation, drawn and checked: docs/workflows/page-links.json lists every link (329, with the control each rides on) and wireframes/page-map.html draws them: pick a page to see what it opens and what opens it. The build fails on a page nothing opens, a page no tab reaches, a dead end that is not a named leaf, or a mutual pair that opens one way. Doors to pages that no board draws yet are listed as owed (정기 일정, 조, 앨범 관리, 행사) and drawn as doors.
• Prevention: the board lint's action-home rule (no Select mode bar, no row ⋯, no Section head command but 알림's approved 모두 읽음) and the verifier's one-loud check (a primary in a page's content beside the band fails).
• Left for you: the owed pages (정기 일정, 조, 앨범 관리, 행사), to draw next.

The owner's page review of 2026-10-27 (L0 to L1)

The owner asked for a way to check each page by marking it and writing the feedback under it, and the lead built the page review (https://claude.ai/artifact/EKvHgpfADndkXvjNPhRQHF): every page as its main screen, Approve or Needs changes, a note, the lead's answer under each note. The owner marked L0 and L1.

• Approved: L0-01 시작, L0-02 이메일 로그인, L0-03 이메일 가입, L0-05 업데이트.
• L0-04 본인인증: "Can we render how we would conduct 본인인증? And make sure you do your research on Korean sign-up processes so that we can cover it well. Let's make it simple and efficient."
• L0-06 공개 미리보기: "We need to ensure we know what information we want to present to people who are shared the link."
• L0-07 공유 카드: the same, and "the cards, especially those containing blocks, are poorly designed. Why don't we just use blocks as the cards to share?"
• L1-01 홈: "I like that we display todo items on the home tab, but I feel that their implementation clashes with the rest of the components in the page"
• L1-02 클럽: "Make sure our filters are correctly configured. The region filters should be consolidated into a single region filter (we already have the working model in our app) and the NTRP ratings can be a slider (we also have a working model). In the currently implemented app, we have a lot of working parts that have been thoroughly designed in terms of their functionaalities and experiences. It's the UI that needs fixing. And in the 경기 pages, there is no search bar. There is a search button at the top right. We need to ensure we have a consistent grammar across all discovery pages. Search button at the top right and filter at the end of a section title row."
• L1-03 경기: "Same here as clubs. We need to configure filters correctly."
• L1-03c 테니스장: "The same goes here. Search at the top right, filter on the same row as the section title. Filters show up on top of the list only if it's active. We activate 가까운 순 by default. .가까운 순 & 저장한 테니스장 (which should be renamed - we really need a good language pass on all pages) are all filters as well."
• L1-04 기록: "Great, let's make sure we configure filters properly"
• L1-05 프로필: "Needs a language pass. Blocks need to be beter configured to reflect various states that a user would be in. Do a thorough investigation on what those would entail. 신뢰 banner needs to be put on top of the containers, right below the 신뢰 section title. We don't need a separate 내 신뢰 기록 section when it can be merged into the 신뢰 section. Instead of 등급 안내, 내 신뢰 기록 can work. 등급 안내 can be added inside the 내 신뢰 기록 page. Make sure you take care of the UI/UX properly."

The lead's calls, for veto:

1. One discovery grammar (클럽 탐색, 경기, 테니스장, 기록's 경기 기록): search is a header icon at the top right; the filter is the first section head's one control (필터 ▾, 필터 N ▾ when on); active filters show as one row of removable Choices under that head only when on, defaults included (테니스장's 가까운 순, 번개 찾기's default region).
2. The filters are the app's (research: the implemented app read file by file): 지역 is one filter, two chained Choices (시/도, then 시/군/구), the app's RegionDistrictFilter; 수준 is the app's band slider over the five real NTRP bands (2.0–3.0 to 4.5+), not chips; each surface keeps the app's facets in the app's order (경기 regains 경기 방식, 코트 유형, 참가비; 기록 loses the 기간 and 단복식 the board had invented). The board kit carries both pieces.
3. 저장한 테니스장 becomes 저장됨, the 경기 tab's word for saved sessions; the language pass on every page follows the redraws as its own batch.
4. The tier explainer moves inside 내 신뢰 기록 as the owner asked. CLAUDE.md's trust rule says TrustTierInfoSheet is the one explainer, reachable from every place the tier shows; from 프로필 it is now one step further, through 내 신뢰 기록 (the rule's wording follows once the owner confirms).
5. Shared links show what, not who (research with benchmarks): a preview shows what, when, where, level and seats, and never faces, names, initials or the host; the share card is the page's own Block, full-bleed; live counts stay on the page, not the image.
6. 본인인증 in four taps of ours (research with Korean peers and the law): social login, then one screen that is both 약관 동의 and the start of 본인인증 (why we ask, "주민등록번호는 받지 않아요", the items received, 동의하고 본인인증하기), then the verification company's window and PASS (not ours, no result screen of our own), then the stops for failure, a phone not in the member's name (a family line or a foreigner), under 14 and a duplicate account. Nothing is built yet. Open for the owner, with counsel where marked: the order (one screen with the terms, against the earlier 본인인증-then-약관 ruling; counsel), the channel (Danal, or Inicis only if it lets us store the CI), under-14 refused inside the vendor window, the foreigners' country, verification at sign-up or deferred for invite links, the display name, and the vendor-facing name while the brand name is open.

The owner's second pass of the page review (2026-10-28, L0 to L1)

The owner reviewed the redrawn pages ("All reviewed through L1 pages").

• Approved: L0-01 시작, L0-03 이메일 가입, L0-05 업데이트, L0-06 공개 미리보기, L0-07 공유 카드, L1-04 기록 and L1-05 프로필. L1-05's approval settles call 4 above: the tier explainer one step away from 프로필, inside 내 신뢰 기록, stands.
• L0-02 이메일 로그인 (marked after the first pass): "We need a better treatment for emails that are already registered. What's the best practice here?"
• L0-04 본인인증: "As ruled before is fine. You can reference best practices though. And there are various identification providers, such as PASS, toss, naver and Kakao. We can use those."
• L1-01 홈: "I like that we have the same UI for the 할 일, but it needs to be polished."
• L1-02 클럽: "Make sure we are using shared components for filters. And make sure we have a polished and consistent grammar for all filter pages."
• L1-03 경기: "Same here as clubs. We need to configure filters correctly. On filters, always aim to use shared components. So put a date picker. Slider should be a shared component. In fact, in all these filter modal, we need to ensure we use shared components."
• L1-03c 테니스장: "Same filter issue."

The lead's calls, for veto:

1. 본인인증, then 약관, as ruled in review 4 (the owner's "as ruled before"): 시작, 1/3 본인인증, 2/3 약관 동의, 3/3 첫 시작; the first pass's one-screen merge is undone. 본인인증 says why before it asks (Toss's one finding that raised completion), then offers PASS, 토스, 네이버 and 카카오 as four equal buttons, in the 시작 page's grammar, each going straight to that provider (KG이니시스 통합인증 on PortOne v2 with directAgency), and 다른 방법으로 인증 (금융인증서, the banks, 휴대폰 본인확인) as a quiet link to the vendor's window. Danal 휴대폰 본인확인 stays the fallback channel. Still open with the vendor (EXT-19): whether the 통합인증 CI may key a person (Inicis's own page files PASS, 네이버 and 카카오 under 간편인증), and Kakao's CI paperwork.
2. An already-registered email gets the same screen as a new one (OWASP's generic response: no account enumeration and no dead end): 인증 메일 받기 always ends at 메일을 보냈어요; a registered address receives a mail with a one-tap 로그인하기 and 비밀번호 재설정 in place of the sign-up link; email sign-in says 이메일 또는 비밀번호가 맞지 않아요, never which one. A duplicate person is still caught by the CI at 본인인증. Build note: Supabase answers "User already registered" while email confirmations are off (our config) and sends nothing to a confirmed duplicate while they are on, so that mail needs our own Send Email hook.
3. One filter-sheet grammar, built only from the forms' shared pieces: 보기 first where a page has one; then Picker Cells for where and when (날짜 opens the shared date picker, the app's presets over the month calendar; 지역 is one cell over the app's region picker); then a Choice set per facet, plain labels; then the band sliders (수준 over the five NTRP bands, 참가비 over the app's fee stops), each the slider with its tag and Stepper that 일정 만들기 and 클럽 만들기 use, so the wizards and the filters draw one level band; fields 32 apart; 초기화 and 결과 N개 보기. The sheet's own chips, region chips and edge-labelled tier slider leave the kit. 기록's sheet changes with it.
4. 할 일 keeps the Feed's row and gains its polish: each row's tile is its subject (the session's venue map, the court, the club's logo, the applicant's face), never a grey glyph tile, and every row fills its footer as 소식 does (the deadline or 납부 기한 at the left, the count at the right); several applicants read as the first one and 외 N명. HomeTask ({ kind, count, deadline? }) does not carry the session, the applicant or the 납부 기한 yet; the app adds them when the page is built.
5. 초기화 returns to the defaults (테니스장's 가까운 순, 번개 찾기's saved region), as drawn in the first pass: the owner's "we activate 가까운 순 by default" makes the default part of the filter, and the question drew no objection.

The language pass (2026-10-28, every page)

Asked in the page review of 2026-10-27: "we really need a good language pass on all pages" (L1-03c) and "Needs a language pass" (L1-05). Every line the 84 pages render was read once; 75 pages changed (496 lines), 9 needed nothing. The record of every rewrite is docs/design/copy-plans/2026-10-28-flat-v2-language-pass.md; the words joined the component library's § 1.19.

The lead's calls, for veto:

1. Toss's current rules for partner apps (앱인토스 UI/UX 가이드) over our March voice guide where they differ: a question asks ~할까요? (가입을 그만둘까요?, never 그만두시겠어요?); a result the user caused is active (신청했어요, 연습을 기록했어요); a dialog's dismiss is 닫기 (참석 유지 and 신청 유지 are gone).
2. One word per thing, eleven new rows in § 1.19: 순위 (its page 순위표; 랭킹 and 리더보드 retire), 최고의 파트너, 혼합복식, ELO (not 레이팅), 칭찬 (칭찬 남기기, 칭찬해 준 사람), 수준 for the NTRP band, 가입 방식 and 참석 방식 each with 바로 and 승인 후, 승인 대기, 신청 마감, 클럽 찾기 (the 클럽 tab's second view, was 탐색), 끝내기, 남은 금액 (잔액 only for the ledger).
3. Three pages renamed: L3-17 리더보드 → 순위표, L3-05 일일 요약 → 하루 기록, L3-33 제안 접수 내역 → 제안 상세.
4. The cap lines say their rule in words: 불참 2/2건 | 2027년 8월 9일 해제 → 불참 2건으로 한도에 닿았어요. 2027년 8월 9일에 풀려요 (and the official's 출석 주의 line the same way).
5. Kept on purpose: the consent rows' 합니다 (they are the shipped legal strings, verbatim until counsel reviews them), the legal documents, 삭제 for things and 내보내기 for people, 스코어카드, 가입 심사, the sign-in buttons' brand labels, the tier names, and every doors' page-title word (회비 설정, 멤버 초대).

Prevention: the board lint's copy-words rule (scripts/lib/flat-v2-board-lint-words.mjs) fails a page board that brings a retired word or form back.

The takeover questions, answered

The owner's words: "KIPO filling - sure we can work on it once we finish the product work. As for refund on leaving, set a deadline for when leaving can count as cancellation (what's often the best practice policy here?). And yes, work on that hosted photos. And let's work on those stale instructions. Well, for now, all pushes and deployments can be done automatically. You have my permission. As long as the rebuilt tools are verified, sure commit. And yes to the recommended fix on the height entries. And yes to all the remaining."

Question	Answer
W2 gate	Opened on 2026-10-19 ("I say yes to all recommendations"): W2a now, W2b with the pages.
R1/R2 review	R1 and the list-a board reviewed above; R2 (detail) still to come.
KIPO filing (EXT-17)	After the product work.
A paid fee when a member leaves	Ruled 2026-10-19 (decision log): a departure 24 hours or more before the start (the free-cancel window) counts as a free cancellation and the paid fee is owed back; inside 24 hours it stays with the host; a removal always refunds. It ships with the money pages.
Hosted photos	Yes: a photo-only seed step for hosted clubs.
Stale auto-loaded instructions	Fixed: CLAUDE.md, the /commit, /start and /plan skills, the post-compact hook text, the SessionStart hook path and the agent memory; deny rules for supabase db reset, supabase stop --no-backup and --all, git stash and git push --no-verify added to the local settings.
Hosted writes	All pushes and deployments are automatic for now (commit, push, db push of validated migrations, edge-function and cockpit deploys). Pushes never use --no-verify. Hosted data writes still need the owner's word, except the photo seed approved here.
The rebuilt tools	Commit once verified.
Stale board height entries	Fix them.
Decisions logged while building (W0.3b–W0.6, 00698)	Accepted.
Cleanup	Yes: the leftover branches, the two sibling worktrees and the Dependabot PRs.
/wireframes/web-app-2	Parked until after mobile flat v2.
Stale docs and the cockpit	Yes: refresh and redeploy.