Owner review 48 — the patterns in the page review (2026-10-28)
Status: Draft · Date: 2026-10-28 · The owner marked every page from L0 to L3 on the page review (https://claude.ai/artifact/EKvHgpfADndkXvjNPhRQHF): 27 of 63 to fix, 36 fine. Then: "having different items in the same page is generally unadvisable, especially if we have lists that can get long. If we are using different items, the items need to be compact enough to fit on a horizontal line. In case we don't have to and stick to a single item, we can just keep the vertical lists. And I probably also have recurring messages in my feedback. Please consolidate them, identify patterns and direction of how I want things to look and be fixed and always investigate before you make any changes." This record groups every note of rounds 46 to 48 into patterns, checks each pattern on all 84 pages, and proposes the fixes. Nothing is redrawn until the owner agrees. Companions: review 46 rulings, the language pass, the library's § 1.16 to § 1.19.
How this was investigated
- The notes. Every mark and its history on the review page: 63 pages, 30 current notes and 16 from earlier rounds.
- The pages. The r4 shots of every page, and a structure probe,
~/twomore-tools/handoff/struct-dump.mjs. The probe renders each page's main frame and lists its top-level components in order: a row with a thumbnail (feed-item,row-media), a person (row-person), a match (row-match), a text row (row-text), a label-and-value Cell (cell), stat tiles (strip), a Notice, a shelf. It also counts each page's text-only action cues and metadata lines. - The app. The shipped app's components where a note names one: the arrival picker with its round chips (
packages/features/sessions/src/add-round/arrival-picker.tsx), the tier names (packages/app/src/config/i18n/ko/trust-tier-info.ts) and the terminology guide's 번개. - The outside. Three research briefs, filed under § 4, for the pages where the owner asked for best practice.
1. The direction in one paragraph
One page does one job, with one list of one item type. Anything of another kind on that page is compact and fits one horizontal line, or moves behind a door. A fact is said once: no second section repeats the hero or the 정보 group, and two pages that differ in a few rows are one page with variants. A page shows data and actions. A line about the data goes. An action looks like a control, never like plain text. Words say what they mean to a 40-to-60 club member at first read. Every section uses a shared component, and the shipped app's working parts lead the drawing. Where a manager acts on people, the action sits on those people in the list. Before a page is redrawn, the lead investigates it: the real app, best practice with sources, and the inventory of every page the change touches.
2. The patterns
P1 — One item type per list; other kinds on one horizontal line
The owner: the rule above (2026-10-28); "Having different components in random places makes things cluttered" (L3-03); "Instead of a top section dedicated to to-do lists, let's keep the same grammar and render the relevant people on the list" (L3-25); "We are all rendering people on the list" (L3-26); "concerned about 홈 코트 section occupying too much space above the feed" (L2-01); "Can't we just combine the two" (L1-01).
Reading. A page's vertical list holds one item type. An item of a different type is compact enough to sit side by side with others on one horizontal line: a summary line, a chip row, a tile row or a face shelf. It does not take a section of its own above the list. A page that holds one item type keeps its vertical list as it is.
Where it applies (the probe's inventory; growable lists of different types on one page):
| Page | The lists today | Direction |
|---|---|---|
| L1-04 기록 (marked fine) | 순위 people rows, partner and rival face grid 2×3, 경기 기록 match rows, a heatmap | the list is 경기 기록; 순위 becomes one line (클럽 3위 / 42명 ›); partners and rivals one face shelf; the month heatmap stays as the summary |
| L2-04 and L2-05 장소 상세 | 다음 일정 session rows, 홈 코트로 쓰는 클럽 club rows, 정보 Cells, 사진, 정보 출처 | the list is 다음 일정; the clubs are one line of logos; 사진 a shelf; 출처 a row inside 정보 |
| L3-11 회비 관리 | member rows in three groups, 장부 ledger rows | the list is the members; 장부 moves to its own page behind one line (장부 잔액 1,240,000원 ›) |
| L3-02 멤버 기록 | 불참 and 참석 session rows, 회비와 참가비 rows, 지각 rows | the list is the sessions, each with its state (참석, 불참 0.5, 12분 늦음, 사유 인정); 회비 is one line that opens 회비 관리 |
| L3-04 기간 기록 (fine) | 상대 people rows, match rows | the list is the matches; 상대 a face shelf |
| L3-32 가입 심사 | 참석 기록 Cells, 함께 친 멤버 rows, 칭찬 Cell, 추천 rows | the facts in one 정보 group; 함께 친 멤버 and 추천 one face line each |
| L3-40 토너먼트 | standings rows, match pairs | by § 4's research (a bracket or group layout) |
| L1-01 홈 | 할 일 rows and 소식 rows, one row type in two sections | one feed; 할 일 is an option of its 전체 ▾ menu, and its items lead 전체 |
| L2-01 클럽 홈 | a 홈 코트 media row above the feed | 홈 코트 is one line in the hero's facts |
| L3-25 멤버 관리, L3-26 가입 신청 | door rows (가입 신청 2, 출석 주의 3) above the roster; applicants, guests and a door on L3-26 | one people list: applicants are its first group (승인 · 거절 on the row), 출석 주의 is a tag and a filter option; L3-26 folds into L3-25 |
Fine as they are (one item type): 클럽, 경기, 경기 · 테니스장, 하루 기록, 선수별 전적, 출석 현황, 업적, 알림, 메시지, 메시지 요청, 참가비 내역, 순위표, 친구 목록, 친구 찾기, 차단한 사용자, 동의 이력, 앨범, 복식 파트너 추천, 일정 관리, 신고 관리, 장소 정보 제안 내역, 소유권 신청 내역, 참석자 관리, 호스트 관리.
P2 — One page per job: merge near-twin pages
The owner: "it looks like 장소 상세 for clubs and directories are essentially the same things. Do we need to have two separate sets of pages then? Can't we just tweak minor details?" (L2-04); "공개 프로필, 신뢰 & 멤버 기록 can be consolidated into a single set of pages as long as we can tweak minor details for each page" (L3-02); "we are all rendering people on the list" (L3-26); "Can't we just combine the two" (L1-01).
| Merge | What differs today | One page, its variants |
|---|---|---|
| 장소 상세 · 클럽 (L2-04) + · 디렉터리 (L2-05) | the club's view adds 예약 시작, 예약 사이트, 예약 알림 and 메모; the directory adds 확인됨, 사진 and 정보 출처 | one 장소 상세; a viewer from a club sees the club's rows inside 정보 (no door to the other page, no 테니스장 정보 row) |
| 공개 프로필 (L2-06) + 내 신뢰 기록 (L3-01) + 멤버 기록 (L3-02) | all three lead with 신뢰 and tiles; L3-01 and L3-02 share the 불참 and 참석 lists | 공개 프로필 for everyone; one 신뢰 기록 page under it: for oneself it is 내 신뢰 기록, for an official it adds the member's 회비 line and 인정 요청 answers |
| 가입 신청 (L3-26) into 멤버 관리 (L3-25) | separate page reached by a door row | 멤버 관리's first group; 게스트 지명 joins 멤버 초대 (L4-10) as one way to invite |
| 홈's 할 일 into 소식 (L1-01) | two sections of the same row | one feed, 할 일 in its menu |
P3 — Say a fact once
The owner: "We probably don't need another 장소 section, given the top photo and the title are all about 장소" (L2-02, L2-03); "Why do we have a separate section for 테니스장 정보 when we have 정보 section at the bottom?" (L2-04, L2-05); earlier, "We don't need a separate 내 신뢰 기록 section when it can be merged into the 신뢰 section" (L1-05, round 46).
Direction. The 장소 Cell under a session's hero goes; the map band and the title open the venue (a visible 지도 pill on the band, per P4). The 테니스장 정보 row and 강남 라켓클럽의 코트 row go with the merge (P2). Rule: a section never repeats the hero, and a page has one 정보 group.
P4 — Less metadata; actions look like actions
The owner: "Across all pages, we are removing as much meta data as possible and elevating action cues so that they are never just texts" (L0-03); "We probably don't need meta data like 클럽의 테니스장은~" (L3-29); "The 확인 근거 line seems to be off and not in harmony with other information" (L3-33, L3-34); "나와의 전적 at the bottom just seems raw" (L2-06); earlier, "the cards, especially those containing blocks, are poorly designed" (L0-07, round 46).
Inventory. Text-only action cues (a text-action or an expand-toggle) are on 21 of the 63 pages: 이메일로 로그인 and the legal links on L0-01 and L0-03; the head doors 등급 안내 ›, 기간 기록 ›, 선수별 전적 ›, 티어 안내 ›, 전체 보기 ›, 일정 보기 ›; and every N개 더 보기. End-of-list lines on four pages (L3-13 최근 30일 알림이에요, L3-29 클럽의 테니스장은 여기까지예요, L3-30, L3-31). A free sentence between Cells on L3-33 (현장 안내판에서 …).
Direction.
- A head door and N개 더 보기 become the quiet small control the filter Choice already uses (the bordered pill). 이메일로 로그인 becomes the tonal second button.
- The Feed end line stays only after a paged Feed. A bounded list ends without a line (this narrows § 1.16).
- Evidence and other facts are Cells in one group, never a free sentence between them. On L3-33, 확인한 날짜, 확인 방법 and 참고 링크 are three Cells. A change reads as before → after in one value (06:00~21:00 → 06:00~22:00).
- 나와의 전적 becomes the two tiles 같은 편 and 상대, as 선수별 전적 filtered to one person already draws them.
P5 — Words people understand
The owner: "I don't know what 신뢰 활동멤버 mean" (L2-06) and "Again, what does 활동 멤버 mean?" (L3-01); "번개 actually sounds pretty outdated. Any better term?" (L2-03); "What is 게스트 지명?" (L3-26); "장소 정보 제안 내역 is just a weird phrasing" (L3-29); "모두 읽음 doesn't seem like a best practice" (L3-13); "we really need a good language pass on all pages" (L1-03c, done 2026-10-28).
Finding. 활동 멤버 is a trust tier's name (the second of four, trust-tier-info.ts). On a profile it renders after the head 신뢰 as "신뢰 활동 멤버", which reads as one phrase and says nothing about what the tier means. 번개 is canon in the terminology guide ("번개 never 픽업"). 게스트 지명 is an official proposing that a guest join the club (the board's search takeover). 장소 정보 제안 내역 has two views, 내가 보낸 제안 and 검토할 제안; by the venue canon only a platform administrator or the venue's accepted owner reviews a suggestion (docs/canon/venue-data.md, venue review authority), so neither view is the club's. Direction: show a tier as a named level with a one-line meaning; pick a successor for 번개 from § 4's research; 게스트 지명 becomes 멤버 초대's guest path; 장소 정보 제안 내역 becomes 보낸 제안. All of these are Korean-label changes: the tier enum, the SQL and pickup in code stay.
P6 — Shared components; the shipped app leads
The owner: "In the currently implemented app, we have a lot of working parts that have been thoroughly designed in terms of their functionalities and experiences. It's the UI that needs fixing" (L1-02, round 46); "On filters, always aim to use shared components" (L1-03); "we need to make sure each section is implemented using shared components" (L2-06); "We should implement our shared time selector" (L3-36); "a consistent grammar across all discovery pages. Search button at the top right and filter at the end of a section title row" (L1-02, round 46).
Finding. The filters were redrawn on the shared controls in 97fd9b5f6, and the owner marked them fine. The open cases: 참석 확인 has no time input, and the app already has an arrival picker with round chips (arrival-picker.tsx) and the shared time selector. 공개 프로필's 나와의 전적 is a bare text row, not the tile pair the kit has.
P7 — A fixed order of information
The owner: "What do you think is the right order of information?" (L2-06); "Let's ensure we have a proper order and flow of information" (L3-03); "let's make sure we have the proper order of information" (L3-11); earlier, the 신뢰 banner "right below the 신뢰 section title" (L1-05).
Direction. Every page follows one order: who or what it is (identity) → what needs the viewer now (the state, the one loud thing) → the one list → the facts (the 정보 group) → doors to the rest. Applied:
- 공개 프로필: face and name; one line of NTRP, 구력 and the tier; one tile row (총 경기, 승률, ELO); 나와의 전적 tiles; 업적 shelf; 클럽; then the band.
- 회비 관리: the tiles; 확인 대기 (the band's job); 미납; 완납; the 장부 line.
- 성장 분석: one summary tile row on top; then one Cell group per question (가입 흐름, 유입, 모집 프로필, 모집 계획). Today the page mixes 2×2, four-wide and three-wide tiles with Cells.
P8 — Act where the people are
The owner: "We need to make it possible to alert each or all members that haven't paid the fees directly on the list" (L3-11); "render the relevant people on the list" (L3-25); "I don't want the check-in process to be a lengthy one that's performed by the operator alone" (L3-36); "we need to put approval to a vote" (L3-32).
Direction.
- 회비 관리. The 미납 group's rows each carry an sm 알림 button, the one verb that group exists for (§ 1.18 already allows a list's one verb on its row). The 미납 head carries 모두 알리기.
- Check-in. Players set their own arrival with the shared time selector and its shortcuts. The host's page shows who has not, and confirms in one press.
- Joining. Approving a join becomes a vote. This is a feature change: who votes and what passes is the owner's decision (§ 7).
P9 — Investigate before drawing
The owner: "What's the best practice here?" (L0-02, L3-22); "make sure you do your research on Korean sign-up processes" (L0-04, round 46); "Can you do some research on how to succinctly and compactly mark messages as read?" (L3-13); "Find best practices for that" (L3-38); "Do a thorough research on this topic" (L3-40); "Find best practices for this" (L3-43, L3-44, L3-45); "always investigate before you make any changes" (2026-10-28).
Direction. Each redraw states its evidence first: the shipped component it uses, the outside references with links, and the pages the change touches. § 4 holds this round's research.
P10 — Operators and live play need depth
The owner: "Live should be the very first tab. We need to bring more visual focus to matches that are live … it should be able to support regular round-based sessions as well as tournaments … other tabs need to support a bracket layout" (L3-38); "So this is basically the operator's view? Can you do a thorough check on it to make sure it can really support operators in-game?" (L3-39); "tournaments need to support brackets and groups and what not" (L3-40); "Club vs club isn't properly configured yet. We can defer its implementation" (L3-10).
Direction. The live pages are a feature batch of their own, grounded in § 4. 클럽 대항전 is deferred: its page keeps its code, is marked deferred in the levels index, and leaves the review until the feature returns.
3. Page by page (pages marked to fix)
| Page | Patterns | The fix |
|---|---|---|
| L0-03 이메일 가입 | P4 | 이메일로 로그인 as the tonal second button; the rule for all pages |
| L1-01 홈 | P1, P2 | one feed; 할 일 in the 전체 ▾ menu, its items first under 전체 |
| L2-01 클럽 홈 | P1 | 홈 코트 as one line in the hero's facts |
| L2-02 일정 상세 | P3 | the 장소 Cell goes; the map band and title open the venue |
| L2-03 번개 미리보기 | P3, P5 | the same; 번개's successor word |
| L2-04, L2-05 장소 상세 | P1, P2, P3 | one page, one list (다음 일정), clubs on one line, one 정보 group |
| L2-06 공개 프로필 | P2, P4, P5, P7 | the order above; the tier with its meaning; 나와의 전적 tiles |
| L3-01, L3-02 신뢰 기록 | P1, P2, P5 | one page with two variants; one session list with states |
| L3-03 성장 분석 | P1, P7 | one tile row, then one Cell group per question |
| L3-10 클럽 대항전 | P10 | deferred |
| L3-11 회비 관리 | P1, P7, P8 | members only, 알림 on 미납 rows and 모두 알리기; 장부 its own page |
| L3-13 알림 | P5, P9 | the read control by § 4 |
| L3-25, L3-26 멤버 관리 | P1, P2, P5, P8 | one people list; applicants first; 출석 주의 a filter; 게스트 지명 into 멤버 초대 |
| L3-29 테니스장 관리 | P4, P5 | no end line; the door leaves the club page: 보낸 제안 opens from 프로필, 검토할 제안 from the owner's own venue page |
| L3-32 가입 심사 | P1, P8 | facts in one group, faces on lines, the guest's results (승패 and ELO), a vote by § 7 |
| L3-33, L3-34 제안 · 소유권 | P4 | evidence as Cells; before → after values |
| L3-36 참석 확인 | P6, P8 | self check-in with the shared time selector and shortcuts; the host confirms |
| L3-38 스코어카드 | P10 | LIVE first; live focus; bracket and group views for a tournament |
| L3-39 대진표 | P10 | the operator's console, checked against § 4's must-haves |
| L3-40 토너먼트 | P1, P10 | brackets and groups by § 4; folded into L3-38 and L3-39 (batch 4) |
| L3-43, L3-44, L3-45 | P9 | 문의하기, 이용약관 and 개인정보 처리방침 by § 4 |
L3-22 공지사항 is marked fine with a question ("What's the best practice here?"); § 4 answers it.
4. Research
The three briefs, with every source: owner review 48 research. What they settle:
- 알림 (L3-13). No 모두 읽음. Opening the list clears the bell's badge; a row's unread dot clears on tap; what is still dotted counts as seen when the viewer leaves. If an explicit control is wanted, it is one header icon with a 되돌리기 toast, never a pill in a section head (Courier, PatternFly, LinkedIn).
- 공지사항 (L3-22). Rows of title and date that open a notice page (a push can link to it); an important one pinned first; an unread dot, no NEW badge (Toss, 당근, KakaoBank).
- 문의하기 (L3-43). The FAQ is the page's one list, grouped under three to five topics; under it one 문의하기 button that opens an email with the app version, device and account filled in (Toss, Kakao; Apple's guideline 1.5 requires an easy way to reach us).
- 이용약관, 개인정보 처리방침 (L3-44, L3-45). One page each: the title; one line of 시행일 with one 이전 버전 control; for the privacy policy a short summary (items, purposes, retention, third parties, rights, the officer); a contents list that jumps to each article; numbered articles with tables (Kakao, 당근, Toss; 개인정보 보호법 제30조). The text stays counsel's.
- 참석 확인 (L3-36). A player presses 도착 (it stamps now, live from shortly before the start) and 먼저 가기 when leaving; a player who forgot picks a chip (정시, +15분, +30분, 직접 → the shared time selector), as the app's arrival picker already does. The host sees only the exceptions and confirms the rest in one press; lateness is computed, never typed.
- 스코어카드, 대진표, 토너먼트 (L3-38 to L3-40). One structure for both: a tournament is stages, groups, rounds and matches (Toornament); a club session is one stage, one group, N rounds. The page shows one horizontal line of chips (stage, group, round) and under it one list of match rows (P1). LIVE is the first tab, the viewer's matches first, then by court; a live match carries a calm LIVE label and a score that rolls when it changes. One match card with three states (예정, LIVE, 종료) and an outcome label (기권, 부전승). In a tournament, the full tree is 일정's alternate pinch-zoom view with the viewer's path marked. The organizer's 대진표 needs, at the least: a court board with a queue, fast score entry for players (winner first, then save and next), an outcome menu instead of a score, edit and clear, and 다음 라운드; stall alerts and adding a latecomer make it a tool rather than a viewer. For appeal: 내 다음 경기 always in view and a ping when the court frees, the viewer's own day, streaks and head-to-head, a shareable result card, a recap at the session's end.
- 번개 (L2-03). Still in common use, so replacing it is a tone decision. Candidates: 오픈 매치 (open to anyone; match is tennis's word), 소셜 매치 (PLAB's platform tone), 반짝 모임 (lighter). 게스트 stays for the person who joins.
- The tier (L2-06, L3-01). The tiers ship as 새싹, 활동 멤버, 신뢰 멤버 and 베테랑 멤버, so under the head 신뢰 the label reads as two tier names at once. Show one tier as a name, its evidence in one line (최근 20회 중 19회 참석) and the step to the next (크몽, Airbnb, 당근's named levels); rename so no tier repeats 신뢰 or needs 멤버 (candidates: 새싹 · 단골 · 믿음직 · 베테랑).
5. Library changes this implies
- New § 1.20, one item type per list (P1), with its prevention: a board-lint rule that fails a page frame with growable lists of two row types (the probe's logic, run at build).
- § 1.16: the Feed end only after a paged Feed.
- § 1.17: the List family's "a door row on top when something waits" becomes "what waits leads the list as its first group" (멤버 관리). 메시지 요청 keeps its door: unaccepted messages stay apart by design.
- § 1.18: a head door and N개 더 보기 are the quiet pill control, never bare text; 회비 관리's 미납 rows carry 알림 and the head 모두 알리기; 알림's 모두 읽음 is replaced per § 4.
- § 1.19: the words of P5 once picked.
- page-levels.json: L2-05, L3-01 or L3-02, and L3-26 retire into the merged pages (their codes kept unused); L3-10 marked deferred.
6. Proposed batches
Each batch is one writer per board file, at most three agents, and committed green.
- The rules first (done 2026-10-28; the rebuild log's "Owner review 48, batch 1"): this record's § 5 into the library, the lint rule, and the kit's pill for head doors and 더 보기. The kit change redraws every page at once.
- Structure (done 2026-10-29; the rebuild log's "Owner review 48, batch 2"): the merges and the one-list pages. flat-v2-hub (L1-01, L1-04, L2-01), flat-v2-detail (L2-02 to L2-06, L3-01, L3-03, L3-04, L3-32 to L3-34) and flat-v2-list-a (L3-02, L3-11, L3-25, L3-26, L3-29).
- Research-led pages (done 2026-10-29; the rebuild log's "Owner review 48, batch 3"): 참석 확인; 알림's read control; 공지사항, 문의하기, the two legal pages.
- Live and tournaments (done 2026-10-29; the rebuild log's "Owner review 48, batch 4"): 스코어카드 and 대진표 redrawn for a session and a tournament alike, 토너먼트 folded into them, the kit's Bracket and Group table (research § 8).
- Words (done 2026-10-29; the rebuild log's "Owner review 48, batch 5"): 번개 is 매치 on every flat v2 board, in the library and the terminology guide; the app's ko.ts follows as screens are built. The tier names left early: 신뢰 점수 was drawn on 2026-10-29 (the owner: "Draw it now").
7. Decisions for the owner
- The reading of P1. Items of another kind sit side by side on one horizontal line (a summary line, chips, tiles, a face shelf), above a vertical list of one item type. Answered (the owner, 2026-10-28): "Your reading of my rule is right." Then refined: "Items of the same kind render as a horizontal list if the page has multiple lists of different kinds. Items of the same kind render as a vertical list if there is only one list of the same kind." Library § 1.20 states it so.
- 기록 (L1-04) and 기간 기록 (L3-04) change too. Both were marked fine before this rule. Answered: "Yes, make changes to pages if the inspection revealed something to fix, even if I approved the design."
- The join vote (L3-32): who votes (officials or all members) and what passes (a majority, or no objection within 48 hours). Answered: "both majority and no objection should work": the club chooses its rule. Who votes was left open; the lead's default is the club's members, for veto.
- A successor for 번개: 오픈 매치 (the lead's pick), 소셜 매치, 반짝 모임, or keep 번개. Answered: "How about just plain 매치? or 경기?" The lead's call, for veto: 매치. 경기 already names the games tab and a played match, and a third sense would collide; 매치 is what Korean sports apps call an open game (PLAB's 소셜 매치). In code it stays
pickup. - The tier names: keep them and fix only the display, or rename (새싹 · 단골 · 믿음직 · 베테랑, or the owner's words). The display fix happens either way. Researched (the owner asked, 2026-10-28; the research note, § 4): the lead recommends set A, 새내기 · 단골 · 약속지기 · 버팀목, each with its one line, tier 4's word the owner's choice (버팀목 is also a familiar government loan); set B, 새싹 · 새잎 · 열매 · 느티나무, keeps the growth image. Both declined (the owner, 2026-10-29: "Let's do a more generic tier names"; § 5): the lead recommends set E, 신규 · 일반 · 우수 · 최우수, over metals (브론즈 to 플래티넘, which read as a rating rank) and numbered steps (1단계 to 4단계, which sit beside NTRP and the 레벨 knobs); the owner picks. Softer, then (the owner, 2026-10-29: "why don't we something softer? I know Naver Cafe is using 새싹 etc."; § 6): Naver Cafe's own ladder (씨앗, 새싹, 잎새, 가지, 열매, 나무, 숲); the lead recommends set H, 새싹 · 잎새 · 열매 · 나무, over I, which ends on 숲. Decided: a point system (the owner, 2026-10-29: "Hmm this feels too close to what Naver does. How about a point system?", then "Yes, points"; § 7): 신뢰 점수, 0 to 100, starting at 50 and hidden until 5 sessions, every point a row of 신뢰 기록. The named tiers are set aside.