Owner review 4, lane E: the match row the ATP way, avatars, and the block chevron (2026-10-12)

Status: Draft · Date: 2026-10-12 · Lane E of owner review 4, points 5 and 1. Inputs: MatchScoreboard and its call sites, FvkTeamLines, FvkMatchShell, FvkMatchRow, FvkCBlockFrame and FvkBlock in the kit as built today, the library §4 (Block, Match state block), the faces canon, the review-3 lanes A and C (their peer tables are reused, not redone), and sources fetched on 2026-10-12 (§0, §1, §7.2). Audience: Korean club members aged 40 to 60. Nothing outside this file was changed.

Owner, review 4. Point 5: "As far as the match row goes, it's definitely cleaner but we can also reference how ATP posts theirs and schedules and results. I was thinking we could also use the avatars here if there's a possibility but before that I certainly want to look at how ATP implements it and the existing implementation we have already does something like this so please look into that." Point 1: "I am wondering if the chevron is necessary. If so, the block must redirect the user to the related page, but I can't tell what it is at the moment. If not necessary, it's just a visual noise." Point 11: "For pickup players' faces, initials is fine."

0. Evidence tags and limits

Tag	Meaning
C	Read in our code or kit today, with path:line.
W	Fetched as text from the live page on 2026-10-12. The fetch tool returns text, not styling, so it shows anatomy and wording but not weights or pixels.
L	Taken from the review-3 lane C or review-1 lane A tables, which measured store frames and DOM on 2026-10-11. Not re-measured here.
X	Not reached. Said so rather than guessed.

Not reached today: the Roland-Garros matches page returned an empty list (no cards loaded), the US Open site timed out, Australian Open and the WTA site were not attempted, Sofascore is unreachable headless (lane C), Apple's HIG and Material 3 guideline pages returned only their titles. Where this lane needs those, it cites the earlier lane tables or marks the claim X. No ATP pixel size below is invented: the only ATP measure is lane C's store-frame pitch (L).

1. Point 5, what ATP does

1.1 Anatomy (W, 2026-10-12, ATP US Open results and the Paris results page)

Part	What the page does
Grouping	A day heading ("Sun, 13 September, 2026 Day (21)"), then one card per match.
Card header	One bold line: round and court ("Final - Arthur Ashe Stadium", "Round of 128 - Court 6"). The court is in the header, not on a player line.
Player line	Small headshot, then "First Last" as a link to the profile, then the seed in parentheses after the name: "(1)", "(Q)", "(WC)", "(LL)", "(9/AL)". Unseeded: nothing.
Flag	None on the web card (country is only a filter). The ATP app frame shows a flag (L: lane C table, "ATP WTA Live").
Set columns	One number per set, in set order, on the player's own line. The loser's tiebreak points are a second small number in the same set cell ("6 5" = 6, tiebreak 5).
Winner marker	Not visible in extracted text; the app frame shows a green check left of the winner's scores and dimmed loser scores (L).
Status	The results cards carry none ("RET" and "W/O" did not appear on the pages fetched). Walkovers and retirements are a data state: a feed keeps partial sets for a retirement and none for a walkover (Sportradar status workflow, W).
Footer	"H2H" and "Stats" links on each card. The card is not one big link; the names and the footer are.
Schedule (order of play)	Not on the pages fetched (the daily-schedule URL returned the results archive). Third-party listings use "From 4.30pm" and "Not Before 5.30pm" session labels with seeds in brackets (Scotsman, US Open order of play, W).
Doubles	X for the agent's pages; settled by the main-thread check below: one line and one headshot per partner, the seed on both.

Main-thread check (W, 2026-10-12, Roland-Garros 2025 singles results and doubles results). It closes the doubles gap above:

• Every player line carries a headshot. The image alt text is the photo id ("Player-Photo-a0e2"), so the photo is decoration beside the linked name, not the link itself.
• Doubles: each partner has their own line and their own photo (four lines and four photos per match), and the seed repeats on both partners ("Marcel Granollers (5)", "Horacio Zeballos (5)"). The team's set scores sit beside the pair. There is no slash between partners.
• Header: the round and the duration on one line ("Round of 16 - 03:19").
• Tiebreak: the loser's points follow their games in the same cell ("6 8" beside "7").
• No winner marker in the text, and no "Ret." or "W/O" on either page.

So ATP's doubles row is 4 lines tall, against our one line per team. That is the trade the board should show.

1.2 Peers (L, from review 3 lane C §4.2; one row re-checked today)

Product	Layout	Doubles	Winner	Notes
ATP WTA Live app	Header line, then one player per line; flag, name, seed	n/a	Green check; loser dimmed	Pitch about 20 at 390 (5.1% of width); set columns at the right; tiebreak superscript
Flashscore	One block per team; surname and initial ("Carreno-Busta P.")	Stacked, pitch 16	Names 800 against 400	Match pitch 51 singles, 83 doubles; the score is centred on the team block (Flashscore, W for the name format)
네이버 스포츠	Header (time, league, 종료/예정 tag), two team lines, crest left	n/a	Loser's score at α0.5, small ◂	Pitch 37; names 15/20; no "VS" or "대" anywhere in 24 rows
SwingVision	Two sides stacked, avatar then name	Stacked	Check and bright numerals
Playtomic	Pairs of avatars with first names under	Adjacent faces, hairline between pairs	n/a (open match)

Reading. ATP's pattern is a header line (round, court, status) over one line per player, a small photo before the name, seed after it, set numbers in tabular columns at the right, the loser dimmed. It is the same skeleton as FvkMatchShell (header first, then team lines, §3). What ATP has that we do not: a photo per player line, a seed. What we have that ATP does not need: the viewer's team first with "(나)", pending/disputed states, the answer pair. Schedule cards against result cards: ATP keeps one card for both; the schedule version is the same card with no numbers and a time label ("Not Before"), and the result version adds the numbers. That is exactly how FvkMatchRow already works (upcoming and confirmed states share FvkMatchShell).

2. What we shipped, MatchScoreboard (C)

File: packages/app/src/presentation/components/sessions/match-scoreboard.tsx (503 lines).

Aspect	Behaviour	path:line
Structure	YStack gap="$2" holding TeamRow, VsDivider, TeamRow.	match-scoreboard.tsx:154 and following
Team row	XStack gap="$3": optional 3-wide team colour bar, a YStack flex=1 gap="$2" with one line per player, then the set cells at the right.	:378 onward
Player line	PlayerIdentityChip with avatarSize="SM" (32, packages/ui/src/box-sizes.ts:28), name weight 700 for the winning team and 500 otherwise, avatar tone primary or muted; then optional tier badge, 게스트 chip, and (pickup only) the primary-club chip.	:420-445
Doubles	The two players are two stacked lines (avatar, name) in the one team row, 8 apart: a doubles team is about 72 tall, the whole card about 176 (arithmetic from 32 + 8 + 32 per team, a divider and a gap; not DOM-measured).	:405-410
Singles height	32 + 8 + divider + 8 + 32, about 96 plus the MatchRowHeader above it (not DOM-measured).	:154
Divider	VsDivider: two 5-high bars around a "VS" label. Before a result it is the ELO tug-of-war (bars sized by win probability, "favored N%" label); after a result it is neutral; a draw shows a 무 badge.	:306-376, bars :345, :370
Tier badge	Exception-only: drawn for everyone only when the players' tiers differ.	:186-197
Set cells	SetCell {games, tiebreak}; each cell is a fixed 26 wide: a 16 right-aligned games slot plus a 10 reserved superscript slot, so columns align row to row. Games use cardTitle, weight 700 for the winning team; the loser's tiebreak is a hard-coded 9px superscript.	:467-503
Winner	Weight and avatar tone only; no check. Draw: neither emphasised.	:230-250, :481-486
Phases	A: avatar, name, tier, guest, scoreline. B: club chip, pickup only. C: any number of sets, via scoreboardCellsFromMatchSets and scoreboardCellsForLiveMatch.	file header, :61, :95

Call sites (C). completed-row.tsx:145, live-row.tsx:136, draws-row.tsx:87 (the scorecard), session-matchups-card.tsx:188 (the session page), tournament-board/current-round-section.tsx:121, add-round/preview-list.tsx:35, scorecard/king-of-court/court-card.tsx:247. The profile's recent matches and the records history do not use it: they use MatchHistoryRow with an AvatarStack of size XS (28) for the viewer's side (packages/app/src/presentation/components/match-history-row.tsx:99-105).

What it teaches the redesign. It already puts an avatar before every name, but at a cost the kit has been removing: the "VS" bar and ELO tug-of-war (review 2 dropped them), a name weight swing that changes line widths, per-player lines that make a doubles card 176 tall, and chips (tier, guest, club) stacked on the name line. The ATP idea (a photo per player line) is already shipped; the redesign's job is to keep the idea only where it earns its height.

3. What the redesign has (C)

• FvkTeamLines (flat-v2-kit-content.jsx:2133): one team per line, contexts row (names 15/22, numerals 17/24·700, line 22 or 24, 8 apart), block (on ink, 24/32), sheet (24/32·700, line 48, 12 apart, faces: a 40 avatar group before each name), cells (FVK_TEAM_CTX, :2001-2006). The viewer's team first with "(나)", a 1px break between partners, no word between teams, the winner emphasised only on accepted results, one spoken label (fvkTeamLinesLabel, :2065).
• FvkMatchShell (flat-v2-kit-content.jsx:~2345): header line (court, one fact, one trailing element), then FvkTeamLines context="row", then optionally the AnswerPair. Heights at 390: 104 (Tag, names only), 108 (Tag, numerals), 116 (Button), 98 (text).
• FvkMatchRow (flat-v2-kit-controls.jsx:4257): states upcoming, playing, enter, waiting, countered, confirmed, host, contested, disputed, void, built on the shell. Frames: flat-v2-lib-social.jsx:1632-1851.
• FvkAvatar (flat-v2-kit-content.jsx:664): sizes 32, 40, 48, 56; group draws two overlapped faces (inner 20/24/28/32 for 32/40/48/56, 2px ring); a missing photo draws initials (fvkCInitials).

So faces already exist in the kit at one place, the sheet context (faces prop, FvkTeamLines :2290-2298). The proposal reuses that prop, not a new component.

4. Faces policy

docs/canon/data-and-hooks.md § Faces (C, :128): a face reaches a client only through public.can_view_face (self, a shared active club, an accepted friend, or the person's own public opt-in; never anonymous); a NULL face means initials. Owner, point 11: for pickup players initials are fine.

Consequence for a match list: in a club session every player shares the club with the viewer, so faces mostly show; in a pickup session most opponents are strangers, so most avatars are initials. A row of initials beside a name that already says the same thing carries no information (it is the name, shortened), and a pickup list would be a column of grey circles with one letter each. Faces therefore help only where the viewer is deciding about, or recognising, a specific person, and where the photo can be expected to exist.

5. Proposal, the match row

5.1 Recommendation (one)

Keep FvkMatchRow text-only as the default for every list (result and schedule). Add the faces as an optional faces flag on FvkTeamLines context="row" that the board shows in exactly three places: the profile's recent matches (and h2h), the Confirm and Decide sheets (already built), and the 대진표 round card of a club session. Never on the scorecard list, the 경기 tab list, the session matchups card, the Block, or any pickup session.

Evidence for the default: (a) the ATP skeleton is header first, then a line per competitor, which the kit already has; ATP's photo is a face of a celebrity people recognise, ours is initials for strangers (§4); (b) at list density the avatar costs height (table below) and 56 px of name width, and the owner's own review-3 ruling was "names never cut"; (c) lane C's evidence (§4.2 above) shows Naver and Flashscore, the closest Korean and tennis peers for dense lists, use no photo on a result row (Naver uses a crest); ATP's web card uses a small photo, and our shipped scoreboard had one and review 2 judged it noisy enough to simplify.

Trade-off. Faces make a club-session list friendlier and match the existing MatchScoreboard feel; they cost 20 px per row and show initials half the time. That is the owner's taste (§7, question 1), so the board draws both and the owner picks.

5.2 The row, geometry

Row context stays 15/22 names, 17/24 numerals. With faces:

Piece	Singles	Doubles
Face	one 32 FvkAvatar	one FvkAvatar group of two overlapped faces at 32 (inner 20, ring 2: the kit's existing group)
Gap, face to names	12 (the sheet context's gap)	12
Names	FvkNames, unchanged (partners joined by the break)	unchanged
Line height	32	32
Set columns	unchanged	unchanged

Overlapped group is chosen over side by side because side by side at 24 costs 52 of a 350 column (two faces plus a gap) and a 24 face cannot show a photo; the kit's group already solves it. The group's 20 inner faces are the limit: below that, initials of one character are illegible, which is another reason faces stay out of dense lists.

Heights at 390 (arithmetic from the kit constants above; to be DOM-verified when the board is built):

Rows	Text only (today)	With faces (line 32)
One row, Tag, names only	104	124 (+20)
One row, numerals	108	124 (+16)
4 matches	416 to 432	496
8 matches	832 to 864	992
Shipped MatchScoreboard, singles / doubles	about 96 + header / about 176 + header	n/a

An 8-match round with faces is about 1.2 screens of scrolling more than the text row, and in a doubles-heavy round the faces row (124) is still shorter than the shipped doubles scoreboard (about 176 plus header).

200% text. Names wrap and the numerals cap at 1.5, as FvkTeamLines already does. Faces are decorative, so at scale 1.5 and above they are not drawn: the team line returns to the text row's heights (this is the same rule the library applies to inline glyphs, which grow to 1.5 and stop). A face is never the only carrier of who is who.

5.3 Result variant (specimen)

Header: 1번 코트 | 확정된 점수 and the trailing Tag (확정). Lines: [face] 김민준 (나) | 이서연 6 4 over [face] 박지훈 | 최유나 3 6; winner names 600 ink and loser 400 secondary only on accepted results. No check, no ◂, no "VS" (rulings stand). A retirement or walkover keeps the partial or empty set cells and puts the reason in the header fact ("기권", "부전승"); the wording and counting rules belong to the point-12 lane.

5.4 Schedule (order-of-play) variant (specimen)

Same shell, state upcoming: header 1번 코트 | 14:00 with the Tag 예정; two team lines, names only, no numerals, no tiebreak slot. The ATP "Not Before" equivalent is the header fact 14:00 이후 for a rotation match that starts when the court frees; a fixed slot shows 14:00. The viewer's team first with "(나)" is what lets a player find their own match, which is ATP's British-players-in-bold trick done structurally. A seed has no equivalent in our model; the closest honest signal is the Level tag, which the row does not carry (BADGE-EXCEPTION, canon/status-and-recruitment.md).

5.5 One implementation

All of §5.2 to §5.4 are props on the existing FvkTeamLines (faces already exists for sheet; extend it to row) and the existing FvkMatchRow/FvkMatchShell. No new component. In app code the one shared primitive replaces MatchScoreboard's TeamRow/ScoreCell (already the lane-C plan), with MatchHistoryRow's AvatarStack retired in favour of the same face slot so the profile list and the scorecard list stop being two implementations.

5.6 Where faces appear

Place	Faces	Why
Confirm and Decide sheets	Yes (built)	The viewer is deciding about named people; 40 faces, line 48.
Profile recent matches, h2h	Yes	The list is about a person; the face is the page's subject.
대진표 round card (club session)	Option, owner's taste	Club-session faces are visible (shared club); pickup shows initials, so off there.
Scorecard (live, completed, draws)	No	A scorecard is read for court and score; 8+ rows per round.
경기 tab list, session matchups card	No	Density; the row's content is when, where and who-won.
Match state Block	No	On ink, 144 tall, the numeral is the figure.
Pickup sessions anywhere	No	Initials add nothing (owner point 11).

6. What the owner should compare (board specimens)

One board, one phone per state, the same match (김민준, 이서연 against 박지훈, 최유나, 6-4 6-3 with one tiebreak 7-6(4)) and the same singles pair, drawn at 390:

1. ATP pattern, drawn from the facts in §1.1. Header line (round, court), headshot, name, seed, two set columns with a tiebreak superscript, loser dimmed. Labelled "reference".
2. Shipped MatchScoreboard, singles and doubles, drawn from §2 (32 avatars, VS bar, 26-wide set cells, stacked doubles). Labelled "shipped".
3. Proposal, text only, result and schedule, singles and doubles (FvkMatchRow today).
4. Proposal with faces, result and schedule, singles and doubles (overlapped pair), one with a real photo and one with initials.
5. Stacks of 4 and 8 rows, text only against faces, to show the 416 / 496 and 832 / 992 heights side by side.
6. 200% text, text only and faces (faces dropped), to show the rule.
7. A pickup list (all initials) against the same list text only, so the owner sees what point 11 means in practice.

7. Point 1, the block chevron

7.1 Every Block and what pressing it opens (C)

FvkCBlockFrame (flat-v2-kit-content.jsx:3563) draws one 16 chevron at α0.8, absolutely positioned at top: 50%, right: rail, in a 24 lane (:3651-3665), data-adorn="box". Every Block passes through it:

Block	Built at	Frames	Press opens (library)	Notes
홈 day	FvkBlock kind="day" :3762	flat-v2-lib-surfaces.jsx:208-246, 296-299; flat-v2-hub.jsx:243, 330, 364, 378, 453	경기 › 내 경기 scrolled to that day (a tab switch, library :880); empty state opens create	A tab switch, not a push; the chevron promises a deeper page
ELO	kind="elo"	flat-v2-lib-surfaces.jsx:323-329; flat-v2-hub.jsx:729-741	Library: "the rating detail" (:892). The hub board HubPgTierBody (flat-v2-hub.jsx:1082) says it opens the tier explainer.	The kit contradicts itself on the destination. Decide one (§7.3).
Identity	FvkCBlockIdentity :3861	flat-v2-lib-surfaces.jsx:353-369; flat-v2-hub.jsx:1249-1373	The public profile (library :904); 프로필 수정 is in 설정 › 계정	On the 프로필 tab this opens the page's own subject
Match state	FvkCBlockMatch :3988	flat-v2-lib-surfaces.jsx:400-443; flat-v2-detail.jsx:1959; flat-v2-lib-rows.jsx:3106	점수 입력 opens ScoreEntry; 점수 확인 opens the Confirm sheet; waiting opens the submitter Confirm sheet; the court name opens the read-only 대진표 (library :939)	The only Block with several destinations, chosen by state
Club hero	FvkClubHero :4038	flat-v2-hub.jsx:1557, 2303	Not a Block; no chevron, no press	Already the right shape for a non-door

7.2 Peers

Source	What it shows
Toss 증권 홈, 내 투자 (L, lane A of review 1 :381)	The chevron is after the figure and its label ("4,000,000원 ›"), not at the container edge. The surface is one door, no buttons inside.
Apple Health summary card (L, review 1 lane A :384)	Whole card pressable; the chevron sits on the top row beside the category name and time. The name of the category is the name of the destination. Apple Fitness: card title plus chevron, whole card (L :386).
카카오T notice row (L, review 1 lane B :49)	A short text, then a trailing chevron: the chevron ends a row whose text states what opens.
NN/g, Clickable elements (W, today)	"make sure you use arrows sparingly, as they can defeat the purpose of keeping your interface simple"; an icon on its own is the "least favorable approach because the arrow is not a standard cue", so combine it with "another visual cue, such as a text label"; "Make all elements ... that are associated with each other clickable."
Material 3 cards	The official page returned only its title (X). Secondhand (benchmark summary, unverified): a card is a container, whole-card press is for one dominant action, no chevron by default. Compose has a clickable card (guide).
당근, 배민, 카카오뱅크, 네이버 "my" hubs	X. Not reached; no claim made. Review 1's store frames cover only their headers.

Reading. Two real peers (Toss, Apple Health) put the chevron in the text line that names the thing it opens, never floating at the far edge of the surface; NN/g says an arrow alone is the weakest cue and wants a label next to it. Our Block floats its chevron alone at the right edge, vertically centred, which is the one placement the evidence does not support, and the owner's complaint (he cannot tell where it goes) is exactly NN/g's point. Review 3 centralised the chevron; this review asks whether it should exist.

7.3 Recommendation per Block

Law. A chevron is the suffix of a text that names where it goes. It is never alone, never at a container edge, and never on a surface whose press stays on the same page's subject (a tab switch uses the destination's name with no chevron; an expand uses its own up or down glyph).

Block	Decision	What changes
홈 day	Move beside a label.	Zone A's trailing slot (aEnd, already exists) carries a text action in the eyebrow style, "내 일정 ›" (white α0.8, 13/18·600, chevron 16 after it). It names the destination (경기 › 내 경기); the eyebrow (the date) yields first, per the existing aEnd rule. The edge chevron and its 24 lane go; the zones can use the full width again. Empty state: "일정 만들기 ›", since it opens create.
ELO	Move beside a label.	"ELO 기록 ›" in aEnd; it opens the rating detail (history and the tier explainer inside it). Remove the contradiction: the hub board that says the Block opens the tier explainer is rewritten to open the detail; the explainer is one tap inside it.
Identity	Drop the chevron and the press.	The block is the page's own header. Pressing your own header to see your public profile is a rare errand; give it a Cell in 설정 › 계정 ("공개 프로필 보기 ›") where its destination is named. Another person's profile never needed a door. Evidence: Toss and Apple put the door on the data summaries, not on an identity header; NN/g's "use sparingly". This is a taste call (question 2).
Match state	Label by action, otherwise none.	When there is an action, zone A already says it: "점수 입력 ›" and "점수 확인 ›" (the chevron joins the action text, which is the label). With no action (court name, or a Tag in aEnd), no chevron: the state Tag and the caption below the block say what is going on, and the rest of the match list has no chevrons either, so the Block should not be the one that does.
Club hero	Unchanged (no chevron).

7.4 The same law elsewhere (a sweep of where a chevron appears without naming a place)

Kit sites that draw a chevron (C): fvkCTrail (flat-v2-kit-content.jsx:1047, chevron prop of rows and FvkTextRow), fvkCCellTrailing (:2857, :2878, :2887, :2898: Cell variants nav, value, count, tag, menu), FvkTextAction kind="link" chevron (:3260, :3386), the section head action (FvkSectionHead, :3381), FvkIconButton icon="chevronRight" (:3413, :4941, a pager "다음"), and the up/down fold glyphs (:1753, :3394, :3545: expand, not navigation, exempt). Counts of the word "chevron" per file: flat-v2-additions.jsx 46, flat-v2-kit-content.jsx 33, flat-v2-lib-rows.jsx 25, flat-v2-list-a.jsx 20 (a grep count, not a count of drawn chevrons).

Applying the law:

• Cells (settings, menu, value pickers): keep. The Cell's label is the destination ("알림 설정 ›"), the pattern the iOS-style and Korean app lists all share; the chevron is at the row end because the row is the text line. Allowed.
• Section heads: keep the text action with its chevron ("전체 보기 ›"), which is the Toss and Apple pattern. Rule: the action text must say what it opens when the section title alone does not ("전체 보기" under a "오늘 일정" title is fine; a bare "보기 ›" is not).
• Rows that open the item itself (Match row, session row, person row, thread): no chevron. The row's text is the item; the press opens it. (This is already the library's Match row, and MediaRow and PersonRow carry none by default.) Add a verifier: a chevron prop on a row whose first line is not a label-type text (a feed item) fails.
• Tab-switch destinations (the day Block): label only, with the chevron, because it navigates away from the tab; the chevron is kept only because the label names a different place.
• Folds: their own up/down glyph; never right-pointing.
• Pager FvkIconButton chevrons: have a named button ("다음"); out of the law.

7.5 Decided by evidence, and the owner's taste

Decided by evidence: no floating edge chevron (Toss, Apple and NN/g agree; the owner's complaint confirms it); a chevron always rides on a label; fold glyphs stay separate. Taste: whether the identity Block keeps a door (question 2) and whether the day Block deserves a label or just loses its chevron (question 3).

8. Questions for the owner (few)

1. Faces on result rows: keep the list rows text-only and show faces only in sheets and on person-centred lists (recommended), or add the 32 faces to club-session rows (+20 per row, initials in pickup)?
2. Identity Block: drop the door (public profile moves to 설정 › 계정, recommended), or keep it with a label "공개 프로필 ›"?
3. Day Block: label it "내 일정 ›" (recommended), or drop the chevron and rely on the section head below it ("오늘 일정 · 전체 보기 ›")?

9. Implementation

Kit:

• [ ] FvkCBlockFrame (flat-v2-kit-content.jsx:3563): delete the edge chevron span (:3651-3665) and the paddingRight: rail + 24 lane (:3588); add the optional aLabel (a text-with-chevron node) that renders in aEnd's slot with the same shrink rules; the Block's aria-label carries the destination.
• [ ] FvkBlock (:3762): day passes aLabel "내 일정 ›" (empty: "일정 만들기 ›"); ELO passes "ELO 기록 ›"; identity passes none and renders as a non-pressable surface (no data-hit, no role="button", no pressed state).
• [ ] FvkCBlockMatch (:3988): the action eyebrow ("점수 입력", "점수 확인") gets the trailing chevron inside the eyebrow text; no chevron for the court-name and Tag states.
• [ ] FvkTeamLines (:2133): extend faces from sheet to row; row context with faces uses line 32, face 32 (single or the overlapped group), gap 12; faces are not drawn when scale >= 1.5. No other component changes.
• [ ] FvkMatchShell (:~2345) and FvkMatchRow (flat-v2-kit-controls.jsx:4257): pass faces through; add the upcoming header fact 14:00 이후 variant to fvkMatchFact.
• [ ] Verifier (board checks): fail any chevronRight that is not the last child of a node that also contains text, except FvkIconButton pagers; assert the edge-chevron is gone from every Block frame; assert every Block with a label has aria-label naming the destination.

Boards:

• [ ] flat-v2-lib-surfaces.jsx:208-443: redraw the day, ELO, identity and match Block frames with the new zone A (rest, long text, 200%, empty, loading); mark the identity Block as non-pressable.
• [ ] flat-v2-hub.jsx:1082: make the ELO Block open the rating detail; fix HubPgTierBody to be the explainer inside that detail.
• [ ] flat-v2-lib-social.jsx:1632-1851 or a new section there: add the §6 specimens (ATP reference, shipped scoreboard, text-only, faces, 4 and 8 stacks, 200%, pickup initials). Use the kit's FvkMatchRow and FvkTeamLines only; the ATP and shipped specimens are labelled drawings of facts in §1 and §2.
• [ ] The profile recent-matches frame: draw faces on row (singles and doubles) if the owner chooses it.

Library (docs/design/flat-v2-component-library-2026-10-09.md):

• [ ] §4 Block: replace the "Chevron" bullet (:851) and the Affordance sentence (:853) with the label-suffix law; update the Day, ELO, Identity and Match state block anatomies (:880, :892, :904, :912-939).
• [ ] §5 Team lines: add the faces row context (face 32, gap 12, line 32, off from 1.5×); §10 Match row states: schedule header fact and the heights with faces (124).
• [ ] §1.13 IA6: drop the Block chevron as an example of a box-centred adornment (the Cell chevron remains).
• [ ] Add the chevron law to a foundations entry so Cells, section heads and rows cite it; decision log entry for veto.

App (when built, not now):

• [ ] packages/app/src/presentation/components/sessions/match-scoreboard.tsx: replaced by the one team-lines primitive; MatchHistoryRow (match-history-row.tsx:99) uses the same face slot instead of AvatarStack; face resolution only through the can_view_face-masked profile reads (docs/canon/data-and-hooks.md § Faces), initials otherwise.
• [ ] No schema change is needed for this lane.