TTKQ Functional Baseline

This document turns the public TTKQ desktop and mobile sites into a functional baseline that product, design, engineering and QA can work from together. It is a structured analysis of the reference site plus the target requirements for building it — not a system audit performed with admin access, and not a pixel-level design hand-off.

Evidence was captured on 5 September 2026 from a logged-out desktop browser at 1440 × 1000 and a mobile browser at 390 × 844. Live content and scores were dynamic samples used only to confirm structure; they are not sports facts. The source site routes to www or m by User-Agent.

Tier	What it asserts	What it does not assert
Verified	Actually rendered or actually operated.	That it works signed in, or for other roles.
Code-evidenced	The public route, component, validation or string exists.	That the account works or the back office is complete.
Access anomaly	What this capture observed.	A persistent defect — it needs stable reproduction first.
Proposed	Target behaviour so the module is buildable and testable.	Anything about the source site. Proposed field names are not its API contract.

No account was registered. No SMS, message or comment was sent. No installer was downloaded. The native app internals, the operations back office, hidden rollouts and other permission levels were not reached — no claim of zero omissions is made for those areas.

Section 01

Product goals, scope and roles

The core path is: find a match or an anchor → check the score and match data → enter the stream → follow or set a reminder → chat and come back. Video, replays and news carry the hours when nothing is live.

The mobile site also contains a complete friends-and-groups path. That should be reviewed as an independent social subsystem — not treated as "a chat input box in the live room".

Role	Visible capability	Verification boundary
Guest	Browse home, scores, fixtures, data and content; enter a room and read public messages	Some interactions trigger sign-in; guest posting was not conclusively verified
Registered user	Profile and security, follows and reminders, DMs, friends, groups, feedback	Code-evidenced; needs a legitimate test account to accept
Anchor	Anchor profile, schedule, room identity and interaction	Public profile seen; the broadcast console was never reached
Group admin / owner	Announcements, muting, members, group settings	Public client-side role code only
Operations	Content and data, recommendations, permission configuration	Proposed target; no evidence from the source back office

Priority

P0 — navigation, home, match scores, live basics, authentication, error handling. P1 — data analysis, follows and reminders, content, profile and feedback. P2 — the full friends-and-groups system, tournament specials, tags and broadcast.

Priority sets iteration order only; it does not remove a module from scope. If chat is the product's main value, M27–M33 should move forward as a block.

Section 02

Module coverage

ID	Module	Evidence	Sources
M01	Global navigation and site frame	Verified	D01 H01 S01
M02	Home recommendations and promo slots	Verified	D01 H01
M03	All live streams and today's picks	Verified	D02 H02
M04	Live room and playback	Interface only	D03 H03 S02
M05	Room chat and DM entry	Partly verified	D03 H03 S02
M06	Live match data and commentary	Verified	D03 H03 S02
M07	Odds and movement history	Verified	D03 H03 S02
M08	Pre-match analysis and head-to-head	Code-evidenced	H03 S03
M09	Line-ups and player statistics	Code-evidenced	S03
M10	Football score centre	Verified	D04 H04
M11	Basketball score centre	Verified	D05 H04
M12	Score filters and display settings	Verified	D04 H04 S03
M13	Match favourites and pinning	Rules proposed	D04 D05 H04
M14	Fixtures and match reminders	Submission unverified	D06 H05 S01
M15	League data and standings	Desktop anomaly	D07 H06 S03
M16	Tournament specials	Entry falls back	S01 S03
M17	Short video and video detail	Detail unverified	D08 H07 S01 S03
M18	Replays and external sources	Partly visible	D09 H08 S01
M19	News, articles and comments	Detail failed	D10 H09 S03
M20	Site-wide search	Verified	H10 S03
M21	Anchor directory and profile	Verified	D01 H03 S03
M22	Sign in, register, recover	Not submitted	D11 H11 S01 S03
M23	Profile, avatar, bio, QR	Code-evidenced	S01 S03
M24	Account security	Code-evidenced	S01 S03
M25	My follows and reminders	Code-evidenced	S01 S03
M26	Feedback and history	Code-evidenced	S01 S03
M27	Message list and contacts	Code-evidenced	H11 S03
M28	Friend search and requests	Code-evidenced	S03
M29	Direct messages	Code-evidenced	S03
M30	Group discovery and creation	Code-evidenced	S03
M31	Group messages and roles	Code-evidenced	S03
M32	Group profile and lifecycle	Code-evidenced	S03
M33	Contact tags and broadcast	Code-evidenced	S03
M34	App download and install	Not installed	D12 H12 S03
M35	About, terms, privacy	Partly verified	D13 D14 S01 S03
M36	Platform operations	Proposed	A01
M37	Scan and QR recognition	Code-evidenced	S03

Section 03

Cross-cutting business rules

Ten rules that apply to every module. Most production bugs in a product of this shape come from breaking one of them.

R01Identity keys. Matches, anchors, rooms, teams, content and users each have a stable ID. The desktop directory types 1/2/3/99 and the match sport types 1 football / 2 basketball / 8 other are different enumerations and must never be mixed. Display names are for display, never for joining.

R02Time. The API supplies a timestamp plus a zone; the interface states one zone consistently and allows localisation. The captured site showed differing times between areas — do not assume it has standardised on Beijing time. Day grouping, reminders and history must all use the same strategy.

R03Distinct states. Unknown vs zero. Empty list vs failed request. Match finished vs anchor offline. Relationship saved vs notification delivered. Message delivered vs message read. These are five different pairs and each must stay distinguishable.

R04Concurrency. Every request carries a snapshot of the current filters and a sequence number; a slow response must never overwrite newer criteria. Realtime data merges by version or event sequence, and duplicate pushes are dropped.

R05Writes. Follows, reminders, messages and feedback all carry an idempotency key. Check permission first; roll the UI back on failure. Optimistic updates must never impersonate a server success.

R06Return after sign-in. Sign-in triggered from following, reminders, chat or comments preserves returnTo and any draft. Sign-out or token expiry clears private data while public content stays reachable.

R07Security. Escape nicknames, chat and article content on display. Validate attachment type, size and permission. QR codes and external links never auto-execute an unknown action. The server performs the final check on every sensitive operation.

R08Interpreting numbers. Heat, play count, follower count, comment count and concurrent viewers are five separate definitions — do not see a number and guess which one it is. Standings accept authoritative deductions and rankings; the client does not recompute over them.

R09Platform differences are real. Desktop bio is 200 characters, mobile signature is 60. Desktop has a confirm-password field that mobile registration does not. Before unifying, make an explicit decision — never silently truncate.

R10Operational switches. Specials, DMs, guest posting, download channels, group creation permission and reminder channels are all configurable. When one is off, hide it or explain why — never leave a dead entry point.

Section 04

Requirements by module

Each module lists its evidence tier, purpose, numbered functional requirements (-F), proposed data fields, required state coverage, and acceptance scenarios (-AC). The IDs are citable — use them in tickets and test cases.

M01

Global navigation and site frame

Verified

Desktop header and footer, mobile primary navigation, cross-platform hand-off and global back.

M01-F01Desktop navigation carries Home, a Scores dropdown with Football and Basketball, All Live, Fixtures, Data, Video, News and App Download. The current section stays selected.

M01-F02Mobile bottom navigation is Home, Chat, Fixtures, Scores, Data. The top bar has the brand mark, search, app download and the user avatar. Chat routes to sign-in when signed out.

M01-F03Desktop add-to-desktop, back-to-top, and the footer About and Disclaimer links stay independent of the main content. Mobile detail pages use back plus a home entry.

M01-F04Route to desktop or mobile by device, preserving the match, anchor and content identifiers across platforms. Narrowing the 1200px desktop page is not a substitute for a mobile version.

Proposed fields

route · deviceType · activeNav · isLoggedIn · redirectTarget · featureFlags

State coverage

default
active
hover
expanded
signed in
signed out
dead route

Acceptance

M01-AC01After switching any primary nav item, the title, selected state, URL and content all agree; browser back restores the previous page.

M01-AC02At 390px all five bottom items are fully tappable, and the fixed bar does not cover the last row of content.

M02

Home recommendations and promotional slots

Verified

Live discovery and routing into other modules.

M02-F01Desktop carries a hero carousel, five thumbnail recommendations on the right, an enter-room button, a horizontal featured-match card row, Now Streaming, Popular Anchors, Football / Basketball / Other live sections, and See All links.

M02-F02Mobile carries a top carousel, featured matches, today's picks and more. Recommended anchor cards run two per row showing anchor name, popularity, LIVE and the match title.

M02-F03Carousel items bind to their enter-room target. Featured matches aggregate by match; live cards separate by anchor room. Multiple anchors on one match must not be de-duplicated into one card.

M02-F04Keep the app prompt overlay, bottom download bar, QR code and permanent-domain notice. Dismissal frequency is configuration-driven; proposed default is not to re-show within the same session.

M02-F05List size, ordering, league scope, promotional artwork and link targets are all content-configured. Do not hard-code the matches and anchors seen in this capture.

Proposed fields

bannerId · image · target · matchId · roomId · anchorId · cover · nickname · heat · sportType · startAt · score

State coverage

has recommendations
none
image loading
image failed
anchor offline
match ended
promo dismissed

Acceptance

M02-AC01After the carousel advances, the button enters the current item — not the previous one.

M02-AC02Different anchors on the same match keep separate room cards; broken artwork still leaves a readable title and a placeholder.

M03

All live streams and today's picks

Verified

The full and per-category live directory.

M03-F01Desktop /lives/1, /2, /3, /99 map to All, Football, Basketball and Other; mobile picks have the same filters. These directory type values are not the sport type values used on the detail page.

M03-F02Each card shows cover, title, anchor and popularity, and opens the matching room. Switching category clears the previous category's results.

M03-F03Load-more or pagination should use a stable cursor so that a heat update cannot silently reorder the card a user is about to tap. The source ordering algorithm is unconfirmed.

Proposed fields

directoryType · roomId · anchorId · matchId · cover · title · heat · liveState · cursor

State coverage

loading
has streams
empty category
ended
paging failed
no more

Acceptance

M03-AC01The football filter never returns a basketball fixture; the All aggregate does include Other.

M03-AC02Once a stream ends, the card enters an explicit ended state instead of loading a player forever.

M04

Live room and playback

Interface verified · playback unverified

The match-and-anchor room container, the player, and everything attached to it.

M04-F01Three desktop entry shapes: sport + match + anchor, sport + match, and anchor alone. Mobile entries carry the equivalent query parameters.

M04-F02Show league, kick-off, both team names and the score, the anchor profile, follow state and heat. Desktop puts the player left and chat right with data and recommendations below; mobile puts media on top with seven tabs beneath.

M04-F03The mobile tabs are Chat, Data, Anchor, Odds, Analysis, Streams, DM. Switching tabs must not change which room is being watched.

M04-F04No playable <video> element was detected on desktop or mobile in this capture, so playback, line switching, quality selection and casting cannot be claimed as verified. Generic player strings in the public bundle do not prove those features are enabled.

M04-F05Target: play, pause, mute, volume, full screen, error retry and live-state feedback. Show a line or quality selector only if the source actually offers one. When autoplay is blocked, offer click-to-play.

M04-F06Show upcoming fixtures, video recommendations and the source disclosure. When the anchor is offline, keep the profile and the next scheduled slot — never display a fake online status.

Proposed fields

sportType · matchId · anchorId · roomId · liveState · streamSources · poster · heat · matchStatus · startAt

State coverage

not started
connecting
playing
paused
buffering
ended
no source
expired source
network failure
format unsupported

Acceptance

M04-AC01No stream or a timeout must show the reason and a retry — never a long blank.

M04-AC02Switching anchor stops the old stream and unsubscribes the old chat room; switching to a data tab never creates a second playback pipeline.

M05

Room chat and the anchor DM entry point

Partly verified · sending unverified

Public room chat, system notices, join notifications and the route into direct messages.

M05-F01Public chat shows role, nickname, content, system notices and join messages. Desktop shows guests a sign-in prompt. Mobile code also contains a guest-nickname flow — the actual permission must come from the server, not the client.

M05-F02Implement text, emoji, send status, message time, recall placeholders and system notices. Where image or video messages are not supported on a platform, show an explicit placeholder and a client entry point.

M05-F03While a user is reading history, do not force-scroll to the bottom; show a new-message affordance instead. De-duplicate pushes by messageId; on reconnect, backfill by sequence.

M05-F04The desktop follow button was observed triggering the sign-in dialog. A DM entry exists but direct sending was not verified. Mobile DM may route to the app or to an add-anchor request — display according to the actual configuration.

M05-F05Public code contains a rate-limit prompt and a join-notification switch. Rate limits, muting and the recall window are all server-returned — the client never grants itself these permissions.

Proposed fields

messageId · roomId · senderId · role · displayName · messageType · content · sentAt · sequence · sendState · muteState

State coverage

guest
can post
muted
connecting
reconnecting
sending
failed
recalled
unsupported type

Acceptance

M05-AC01A guest pressing send either completes sign-in or the server-permitted guest initialisation — the message is never silently dropped.

M05-AC02Reconnecting produces no duplicate messages; a failed send keeps its draft and allows retry.

M06

Live match data and text commentary

Verified & code-evidenced

Football statistics, basketball period statistics, and the event feed.

M06-F01Football covers attacks, dangerous attacks, possession, shots on and off target, and text commentary — with goal, penalty, own goal, cards, second yellow, substitution, corner and penalty-miss events.

M06-F02Basketball covers quarters one to four, overtime and the total. Mobile code also carries team fouls, timeouts remaining, two-point, three-point and free-throw scoring with percentages.

M06-F03Cover pre-match, both halves, half time, stoppage, penalties, periods, overtime and full time, plus TBD, interrupted, postponed, cancelled and abandoned. Map the concrete enumeration when integrating the data source.

M06-F04Include a last-updated time and a staleness hint. Periods that have not happened yet use a placeholder — a real zero and an unknown must never share a representation. Server pushes update in place.

Proposed fields

score · periodScores · eventId · eventType · minute · teamSide · player · statistics · updatedAt

State coverage

pre-match
in play
half time
finished
stale data
no statistics
abnormal termination

Acceptance

M06-AC01An overtime game's total includes overtime; overtime never overwrites the fourth quarter.

M06-AC02Cancelled and postponed never render as finished; missing statistics are never filled with zero.

M07

Odds and movement history

Verified & code-evidenced

Odds display only. No betting transactions.

M07-F01Desktop shows 1X2, handicap and over/under. Each bookmaker row carries opening, current and time. Football 1X2 includes home, draw and away; basketball must not force a draw value.

M07-F02Bookmakers can be selected, hidden, kept or shown in full, with a count shown. Mobile adds 1X2, handicap, over/under, high / low / average, and a per-bookmaker movement history page.

M07-F03The mobile movement page lists bookmaker, home or over, the line, away or under, and the change time. Opening and current align on the same bookmaker and the same market type.

M07-F04Suspension shows an explicit marker — never a zero. Direction uses color plus a symbol. If the feed drops, keep the last version and label its update time.

Proposed fields

companyId · marketType · initial · current · line · homeValue · drawValue · awayValue · changedAt · isClosed

State coverage

has data
no bookmakers
suspended
changed
stale
history failed

Acceptance

M07-AC01Keeping two bookmakers shows only those two; Show All restores the rest.

M07-AC02One bookmaker's history sorts by time; basketball 1X2 never generates a fabricated draw column.

M08

Pre-match analysis and head-to-head

Tabs verified · detail code-evidenced

Standings, recent form, head-to-head, absences and upcoming fixtures.

M08-F01Show home and away rank, recent form, football goals for and against or basketball points per game. Head-to-head lists date, competition, fixture, result and the odds outcome.

M08-F02Filters support all-or-same-venue, last 10 / 15 / 20 matches, competition and venue. Cancel discards the draft selection; confirm refreshes the data.

M08-F03Include absent players with reason and position, plus upcoming fixtures with date, competition, opponent and days between.

M08-F04Win rate, handicap rate and over rate must carry a sample size and a range. An incomplete on-page sample is not an official conclusion.

Proposed fields

teamId · range · venueScope · leagueIds · historyMatches · injuries · nextMatches · sampleSize · rates

State coverage

has sample
insufficient sample
no meetings
no absence data
filter empty
load failed

Acceptance

M08-AC01"Last 10" and "same venue" apply together, not one overriding the other.

M08-AC02No absence data shows "no data" — never "everyone is fit".

M09

Football line-ups and basketball player statistics

Code-evidenced

Match line-up detail and the player statistics sub-page.

M09-F01Football separates home and away, starting XI, formation and substitutes. Player identity and shirt number are stored independently.

M09-F02Basketball separates home and away, starters and bench, listing minutes, points, rebounds, assists, field goals, threes, free throws, steals, blocks, turnovers and fouls.

M09-F03Line-up pending, data missing and match not started are three different messages. Being on the bench is not the same as having played. Wide mobile tables may scroll horizontally.

Proposed fields

matchId · teamSide · formation · playerId · shirtNo · isStarter · minutes · points · rebounds · assists · shooting

State coverage

unannounced
starting XI published
in play
statistics final
partially missing

Acceptance

M09-AC01Switching home / away updates both the formation and the substitutes.

M09-AC02A basketball player who did not appear shows "did not play" or a placeholder — never zero minutes counted as having played.

M10

Football score centre

Verified

Live scores, finished results, upcoming fixtures, and favourites.

M10-F01Desktop columns are competition, time, status, home, score, away, half time, corners, stream, odds, commentary and actions. In-play, upcoming and finished are grouped.

M10-F02Rows support pin and favourite; animation, stream and commentary are separate entry points, and a full legend explains the event markers. Team name, score, stream and actions must be separately tappable to prevent mis-taps.

M10-F03Desktop puts finished results and upcoming fixtures on their own routes. Mobile uses a date strip plus football / basketball / followed switches, with several days visible either side.

M10-F04Keep competition aliases, cards, corners and status. A live score update must never flash the whole table or reset the scroll position.

Proposed fields

matchId · league · kickoff · status · minute · teams · score · halfScore · corners · cards · streamAvailable · anchorCount · isPinned · isFavorite

State coverage

live
finished
upcoming
favourite
pinned
no stream
cancelled
no fixtures

Acceptance

M10-AC01Pin and favourite operate independently and never substitute for one another.

M10-AC02One matchId renders identically in live, detail and favourites. An unstarted match never shows 0–0 as if it had kicked off.

M11

Basketball score centre

Verified

Periods, differential, totals and the basketball score directory.

M11-F01Reuse the same four scopes — live, finished, upcoming, favourites — but keep the table structure independent from football.

M11-F02Show date, period and time remaining, both teams, quarters 1–4, both halves, full time, differential, combined total, moneyline, spread and total odds, plus actions.

M11-F03Mobile includes differential, combined total and a home/away marker setting. State whether the differential is home minus away or the reverse, and keep that sign convention identical across every page.

M11-F04Model overtime as an extensible array. Technical timeouts, pre-match and final states follow basketball's own status definitions.

Proposed fields

period · clock · quarterScores · overtimeScores · halfScores · totalScore · difference · combinedTotal · odds

State coverage

pre-match
each period
between periods
overtime
finished
interrupted
data missing

Acceptance

M11-AC01First-half total equals quarters one plus two; at full time the total reconciles with the periods plus overtime.

M11-AC02An unstarted game never shows a countdown styled as an in-period game clock.

M12

Score filters and display settings

Verified & code-evidenced

Competition scope, name-display mode, and which information columns show.

M12-F01The desktop competition filter carries all competitions, the big five leagues and tier-one events, grouped alphabetically with fixture counts, plus select all, invert, cancel and confirm.

M12-F02Desktop display settings offer Simplified, Traditional and "Crown" name modes, plus card visibility. "Crown" is recorded as the source site's own label — it is not a third natural language.

M12-F03Mobile carries all / popular competitions, hidden-fixture count after filtering, corners, cards, ranking and home-away marker settings.

M12-F04Display settings should persist per device; whether they sync to the account needs confirmation. Competition selection is a draft until confirmed; when empty, say that no competition is selected.

Proposed fields

leagueIds · preset · nameMode · showCards · showCorners · showRanking · showHomeAway · hiddenCount

State coverage

default
changed, unconfirmed
applied
all selected
none selected
cancelled

Acceptance

M12-AC01Inverting twice returns the original selection; cancelling leaves the list unchanged.

M12-AC02Switching to Traditional changes no match ID, score or follow state.

M13

Match favourites and pinning

Partly verified · rules proposed

Favouriting a match, and pinning it within the current list.

M13-F01Favouriting a match and following an anchor are modelled separately. Desktop has My Favourites, mobile has a followed-scores tab. The empty state routes back to all matches.

M13-F02The favourite button updates the current row and the favourites page. Failures roll back; repeated taps are idempotent. Whether guests may favourite locally or must sign in is an integration decision — persistence was not verified here.

M13-F03Pinning reorders the list and can be undone. Proposed: it applies only to the current score scope and never alters business recommendation heat.

M13-F04Favourited finished matches keep their result. When a match is merged, deleted or cancelled, keep an explicit explanation.

Proposed fields

userOrDeviceId · matchId · isFavorite · isPinned · createdAt

State coverage

not favourited
favourited
pinned
removing
empty favourites
match invalid

Acceptance

M13-AC01Favouriting the same match twice produces exactly one record.

M13-AC02Unpinning restores the base order; unfavouriting a match never unfollows an anchor.

M14

Fixtures and match reminders

Verified · reminder submission unverified

Finding matches and anchors by sport category and date.

M14-F01Desktop has All, Football, Basketball and Other, with a date strip showing five consecutive days in this capture. Columns are competition, status, home, score, away, anchors and the reminder action.

M14-F02Mobile groups by date and each day can collapse. Match rows show status, corners, cards and multiple anchor avatars with names.

M14-F03The match entry and the anchor entry go to different places — the match detail versus that specific anchor's room. Multiple anchors on one match must not create duplicate reminders.

M14-F04A reminder stores the user-to-match relationship. Notification channel, lead time and permissions are product configuration; actual delivery on the source site was not verified. Cancellation, rescheduling and completion must update the reminder state.

Proposed fields

date · sportCategory · matchId · kickoff · status · anchorList · appointmentState · remindAt

State coverage

upcoming
in play
finished
rescheduled
reminder set
no reminder
no anchors
date collapsed

Acceptance

M14-AC01Tapping anchor A enters A's room; tapping the match enters the default match detail.

M14-AC02A rescheduled match keeps the same matchId on its reminder; a cancelled match sends no kick-off reminder.

M15

League data and standings

Mobile verified · desktop load anomaly

Football and basketball leagues, seasons, standings and player rankings.

M15-F01Mobile selects leagues horizontally, with football standings and player rankings and basketball conference standings. Season selection is independent.

M15-F02Football standings show team, played, won, drawn, lost, goals for and against, and points. Player ranking code covers scorers, assists, key passes, shots and shots on target, offsides, pass completion, interceptions and clearances, fouls and cards. Which boards exist is configured per league.

M15-F03Basketball carries Eastern and Western conferences, win–loss, win rate, games behind and recent form. Playoffs and brackets depend on the competition's capabilities.

M15-F04League rule text must match the current league and season. The capture once showed CSL rules persisting after switching to the NBA — treat that as a cache-isolation regression test, not a confirmed permanent fault.

M15-F05Desktop /data rendered only an empty league-data container. This PRD defines the target from the verified mobile behaviour; the desktop layout is a proposed adaptation, not a reconstruction of the source desktop page.

Proposed fields

leagueId · sportType · seasonId · stage · rankingType · teamRankRows · playerRankRows · rulesVersion

State coverage

loading
season has no data
complete table
points deduction
tie
component load failed

Acceptance

M15-AC01Switching league or season clears the old rules and old table; a slower response must not overwrite the newer selection.

M15-AC02Points accept authoritative deductions — never force wins × 3 + draws over the supplied value.

M16

Tournament specials such as the World Cup

Code exists · desktop entry falls back

Tournament specials, opened by configuration.

M16-F01Public routes /world and mobile /pages/world/index exist, but desktop access returned to the home page in this capture. It cannot be marked as currently operating.

M16-F02The code covers fixtures, standings, player rankings, the bracket, group stage, round of 32 through the final, semi-finals and the third-place match, plus scorer, assist and card boards.

M16-F03If enabled, season, groups, knockout rounds and progression slots must all be configured. Undetermined ties show TBD — never hard-code this edition's teams.

Proposed fields

tournamentId · season · group · stage · bracketSlot · winnerId · ranking

State coverage

closed
build-up
group stage
knockout
slot TBD
finished

Acceptance

M16-AC01When the feature is off, navigation shows no dead entry point.

M16-AC02TBD slots never invent a team; a progression update affects only the linked next-round slot.

M17

Short video and video detail

Mobile list verified · detail unverified

Short-video categories, cards and playback detail.

M17-F01Mobile categories cover All, Football, Basketball plus NBA, CBA, Premier League, La Liga, Bundesliga, Serie A, CSL and Ligue 1. Cards show cover, title, author and play count. Categories are configuration-driven.

M17-F02Desktop /videos rendered a c_video-web shell with no content; /video/:id and the mobile playback route exist. An empty desktop shell must not be written up as a working video list.

M17-F03Target: the detail page shows the player, title, author, time or play count, and related recommendations. Progress, replay and error states come from the player's capabilities.

M17-F04Define what a play count means — valid start, de-duplication, anti-fraud. The many "99 plays" figures seen here are page display only and should not be taken as a real measurement model.

Proposed fields

videoId · category · cover · title · author · duration · playCount · source · playbackState

State coverage

list loading
empty category
has results
video unavailable
playback failed
completed

Acceptance

M17-AC01Switching category resets pagination and never mixes in the previous category's cards.

M17-AC02A dead video source shows retry and back-to-list — never a false playback success.

M18

Replays, highlights and external sources

Desktop verified · mobile partly visible

The replay directory for finished matches, and links to their sources.

M18-F01Desktop /playback categorises All plus NBA, CBA, CSL, Premier League, La Liga, Bundesliga, Ligue 1 and Serie A. The list carries time, title, both sides and the result, a replay or highlights entry, and pagination.

M18-F02The detail page shows the finished state, the match title, a source list and popular videos. Observed links point to third parties such as Douyin and MIGU — this must not be described as all-in-site playback.

M18-F03Mobile replay categories exist but the list was empty in this capture; /pages/playback/info exists. Target: support multiple segments, sources and highlight reels per match.

M18-F04Verify list and detail agree. In this sample the list and detail disagreed on the home team's score — logged as a data-consistency defect lead. Opening an external link must preserve the source attribution.

Proposed fields

replayId · matchId · category · result · segments · provider · externalUrl · page

State coverage

has replay
not yet uploaded
multiple segments
source dead
external page restricted

Acceptance

M18-AC01The source label matches the actual destination; returning to the list preserves the page number.

M18-AC02List and detail scores agree for one match; an unknown score uses a placeholder, not zero.

M19

News list, article detail and comments

Mobile list verified · detail failed to load

Sports news categories, recommendations, articles and comments.

M19-F01The mobile list has football / basketball switches, competition tags, a featured carousel, titles, relative time, author and numeric indicators. What those indicators mean needs API confirmation — do not assume they are likes.

M19-F02The desktop news container did not load. Mobile article 208644 returned "page failed to load" on open. Both are recorded as this capture's result.

M19-F03Public detail code contains title and body, publish time, all comments, related news, replies, load-more replies, collapse and a composer. The PRD must cover all of it — while not claiming comment posting was verified.

M19-F04Failed body or image loads can be retried. Comment posting needs permission checks, length limits, rate limits, a preserved draft on failure and a clear message when deleted. A reply binds to a comment ID, never to a list position.

Proposed fields

articleId · category · title · author · publishedAt · cover · bodyBlocks · commentId · parentId · replyCount

State coverage

list
loading
article unavailable
detail error
no comments
comments closed
submitting
in review

Acceptance

M19-AC01A failed detail offers back and retry; an empty body is never treated as a success.

M19-AC02A submitted reply binds to the correct parent comment; a signed-out user tapping post keeps their draft.

M20

Site-wide search

Mobile verified

Searching teams, anchors, live streams and fixtures.

M20-F01The home search placeholder prompts for teams and anchors and opens a dedicated search page with hot terms and a cancel control.

M20-F02After input, All / Anchors / Live tabs appear. The code covers related anchors, related streams, related fixtures and more. Searching "Lakers" returned no results in this capture.

M20-F03Proposed: a blank keyword issues no request; submissions trim whitespace; requests carry a sequence number so an older response cannot overwrite a newer one. The empty state keeps the keyword editable.

M20-F04In results, following an anchor and opening their profile are separate actions. Clearing the input restores hot terms; cancel returns to the originating page.

Proposed fields

keyword · resultType · anchorResults · liveResults · scheduleResults · hotWords · cursor

State coverage

initial
typing
searching
results
no results
failed

Acceptance

M20-AC01Whitespace alone does not trigger a search; rapid consecutive searches show only the last keyword's results.

M20-AC02No results echoes the search term clearly and lets the user edit it.

M21

Anchor directory and profile

Verified & code-evidenced

Featured anchors, following, broadcast schedule and the DM entry point.

M21-F01Home popular anchors and the mobile featured directory show avatar, nickname and follow state, and open the full profile.

M21-F02The profile carries account ID, popularity, followers, live status, schedule and DM. With no schedule, say the anchor has none.

M21-F03Unfollowing confirms that go-live reminders will stop. Whether notifications are enabled, and through which channel, needs confirmation.

M21-F04Anchor identity and match sessions are separate — an offline anchor's profile stays browsable. DM or add-request display follows server permission and platform capability.

Proposed fields

anchorId · nickname · avatar · bio · accountCode · fans · heat · followState · liveRoom · schedules

State coverage

live
offline
following
not following
no schedule
profile unavailable

Acceptance

M21-AC01The same anchor reached from home or from search resolves to one identity.

M21-AC02Unfollowing syncs across every entry point; a failure rolls back.

M22

Sign in, register and password recovery

Forms verified · submission not executed

Password sign-in, SMS sign-in, registration, recovery and the result screens.

M22-F01Desktop password sign-in takes phone plus password; SMS sign-in takes phone plus code. Registration takes username, phone, password, confirm password, code and agreement consent. Recovery takes phone, new password, confirm and code.

M22-F02Mobile sign-in accepts a phone number or a TTKQ ID with a quick-login switch. Registration fields differ from desktop, and the success page distinguishes registration from reset.

M22-F03Public code shows phone-format validation, a 4-digit code, a 6–16 character password and a match check. Code length and password policy must be unified server-side — do not assume every form shares the same rule.

M22-F04Sending an SMS may first raise a captcha or image challenge, with reload, refresh and resend countdown. No SMS was sent, no account registered, no credentials submitted in this capture.

M22-F05Target: a successful sign-in returns to the triggering page; cancelling loses neither a search nor a comment draft; repeat submissions lock the button. A failed code send must never advance to the success countdown.

Proposed fields

loginMethod · phoneOrAccount · nickname · password · confirmPassword · code · verificationTicket · agreementVersion · returnTo

State coverage

empty
format error
captcha challenge
sending
countdown
verification failed
signed in
registered
reset

Acceptance

M22-AC01Mismatched passwords do not submit; registration without required consent does not proceed; a wrong code does not clear every filled field.

M22-AC02Sign-in triggered from a follow returns to that anchor; the old-session policy after a password change is enforced server-side.

M23

Profile, avatar, bio and personal QR

Code-evidenced · needs signed-in re-verification

Editing the profile: avatar, nickname, bio and personal code.

M23-F01Desktop profile carries avatar, nickname, phone, password, bio and save. The mobile account centre carries avatar, nickname, signature, phone, QR code, account security, feedback and sign-out.

M23-F02Desktop avatar upload accepts png, jpg and jpeg up to 2MB. Nickname is 12 characters maximum with a change cooldown read from remaining_days.

M23-F03Desktop bio caps at 200 characters, mobile signature at 60 — an explicit platform difference. The implementation must either unify the field or store both, never truncate silently.

M23-F04The personal QR shows the avatar, the TTKQ ID and a save action. Scanning identifies the person — a login token must never be placed inside a QR code.

M23-F05Upload and save show progress and allow retry on failure. Sign-out confirms first and clears private caches.

Proposed fields

userId · accountCode · avatar · nickname · bio · signature · phoneMasked · nicknameChangeLimit · qrPayload

State coverage

viewing
editing
cooldown, locked
uploading
failed
saved
sign-out confirm

Acceptance

M23-AC01An oversized avatar or nickname is flagged before upload, and the server validates again.

M23-AC02Cancelling an edit restores the previous profile; the cooldown button state matches the server.

M24

Account security: phone and password changes

Code-evidenced

Changing the bound phone number, changing the password, and re-authentication.

M24-F01Changing the phone takes the current number, the new number, a code and a confirmation, and the success message names the number to use next time.

M24-F02Changing the password supports both the old-password path and the forgot-password SMS path. New password and confirmation must match.

M24-F03The result offers back-to-security or re-sign-in, and the code contains a countdown back to sign-in. Every sensitive operation needs server authorisation and second-factor verification.

M24-F04Requirements: mask the number; bind the code to the operation type; the account system defines the old-session revocation policy and cross-device notification.

Proposed fields

oldPhoneMasked · newPhone · smsCode · oldPassword · newPassword · confirmPassword · reauthState

State coverage

bound
verifying
wrong code
number taken
changed
session invalidated

Acceptance

M24-AC01A code cannot be replayed across phone numbers or across operation types.

M24-AC02After a password change, sign-out follows the unified session policy — not merely a front-end redirect.

M25

My follows and my reminders

Code-evidenced

Managing personal relationships and reminders.

M25-F01My Follows lists followed anchors, their live state and an unfollow action, with an empty state that routes to adding follows. The list pages, and unfollowing raises a confirmation.

M25-F02My Reminders organises matches by date, reads the reminder list and calls the reminder-state operations. Cancel and success feedback are both present in the code.

M25-F03Target: one relationship stays in sync across pages. A followed anchor with no current stream is kept so the next broadcast is reachable. A failed notification and a successful reminder relationship are two different outcomes.

Proposed fields

userId · anchorId · followedAt · matchId · appointmentId · reminderState · pagination

State coverage

empty
has follows
live
offline
has reminders
cancelled
finished
load failed

Acceptance

M25-AC01Unfollowing affects only that anchor; cancelling a reminder affects only that match.

M25-AC02Removing the last item switches to the empty state without leaving a blank paged view.

M26

Feedback and feedback history

Code-evidenced

Collecting feedback, image upload, contact details and history.

M26-F01The desktop form takes content up to 500 characters, images, and a contact method supporting phone, WeChat and QQ. Images are png, jpg or jpeg at 2MB or less. Content is required.

M26-F02Mobile feedback accepts up to three images with required content. Whether it also caps at 500 characters and 2MB per image needs cross-platform confirmation.

M26-F03Desktop feedback history shows content, images, contact and pagination, displaying "none" for an empty contact. No separate mobile history entry was found — do not claim the two platforms are equivalent.

M26-F04A failed upload can be removed and re-picked; submission locks to prevent duplicates; success goes to history or back. The source site has no verified support-reply flow — do not invent ticket statuses.

Proposed fields

feedbackId · content · attachments · contact · submittedAt · page

State coverage

editing
uploading
over limit
empty
submitting
success
history empty
failed

Acceptance

M26-AC01A fourth image is rejected, and a failed upload is never submitted as a successful attachment.

M26-AC02A timed-out submission keeps the content; repeated taps produce exactly one submission intent.

M27

Message list and contacts

Code-evidenced · sign-in entry verified

The mobile chat entry point and contact organisation.

M27-F01Mobile chat has Messages and Contacts tabs, a connecting state, conversation search, unread counts, a mention indicator, last-message preview and time.

M27-F02Conversations offer mute / unmute and delete. Contacts carry New Friends, Groups and Tags. The action menu carries start a group, add a friend and scan.

M27-F03Previews distinguish image, video, voice, file and group announcement, with an explicit note for unsupported types. With no conversations, prompt the user to add friends.

M27-F04Two legacy message paths also exist — /pages/message/index and /chat — and the code contains an add-anchor request. Confirm by account capability whether they are still official entries. Do not build two parallel conversation systems.

Proposed fields

conversationId · type · peerId · title · avatar · lastMessage · unreadCount · mentioned · muted · lastAt · connectionState

State coverage

signed out
connecting
online
reconnecting
no conversations
unread
muted

Acceptance

M27-AC01Muting keeps the messages and the unread rules — it is not the same as deleting the conversation.

M27-AC02Cross-device read sync follows the server cursor, not just clearing the local badge.

M28

Finding friends, requests and profiles

Code-evidenced

Adding friends, reviewing requests, remarks and relationship management.

M28-F01Search by TTKQ ID or phone number; no match echoes the keyword. Results open a profile showing nickname, TTKQ ID, online state, signature, tags and remark.

M28-F02Adding a stranger opens friend verification with a request message of up to 20 characters. New Friends separates pending, declined and added; the recipient can accept or decline.

M28-F03Once friends, messaging is available. Remarks cap at 12 characters. Copying the account ID gives success or failure feedback. Whether phone search can discover a user is a privacy setting decided server-side.

Proposed fields

peerId · accountCode · relationship · applicationId · verificationText · remark · tags · online

State coverage

not friends
request sent
pending
declined
added
no results

Acceptance

M28-AC01Repeat requests are idempotent; reviewing an expired request shows the current relationship.

M28-AC02A non-friend cannot reach friend-only profile data by editing the URL.

M29

Direct messages and message actions

Code-evidenced

Friend DMs, quoting, recall and media messages.

M29-F01Messages support text, image, video, file and voice with an unsupported placeholder, and show read state. Actual browser send capability must be verified per platform.

M29-F02Messages can be quoted and recalled, and the quote can be cleared from the composer. Sending, uploading and failed are separate states, and retrying never creates a duplicate.

M29-F03Broadcast and DM share a message model but differ in recipient semantics. A message must never be broadcast into a conversation it was not addressed to.

M29-F04Microphone and photo-library permissions are requested only on a deliberate user action. No message was sent and no device permission was requested in this capture.

Proposed fields

conversationId · messageId · clientMessageId · sender · recipient · payload · quoteId · readAt · revokedAt

State coverage

sending
delivered
read
failed
quoted
recalled
attachment unsupported

Acceptance

M29-AC01After a recall, quotes of the original follow one consistent privacy policy and leave no readable sensitive text behind.

M29-AC02Offline resend de-duplicates by clientMessageId; an unsent voice note is never auto-uploaded.

M30

Group discovery, creation and joining

Code-evidenced

The group list, creation, invite codes and joining.

M30-F01The group list is searchable and shows a count. Starting a group selects friends, and the code explicitly contains a no-permission-to-create restriction.

M30-F02Join-group and group QR / group-ID pages exist, reachable by scan or code. The QR flow must recognise expired, dissolved and approval-required states.

M30-F03Member selection, submission de-duplication, member cap, invitation and approval policy are all server capabilities. No fixed member cap was verified — do not invent one.

Proposed fields

groupId · name · avatar · selectedMemberIds · canCreate · joinPolicy · inviteCode · expiresAt

State coverage

no permission
selecting members
creating
created
pending review
joined
code expired

Acceptance

M30-AC01Without create permission the server refuses, and the client hides or disables the entry and explains why.

M30-AC02An expired group QR never lands in a different group; scanning twice does not join twice.

M31

Group messages and role management

Code-evidenced

Group chat, mentions, announcements and member role actions.

M31-F01Group messages show owner, admin and member identity, and support announcements, quoting, recall, media and @mentions. Mention-all is gated by canMentionAll.

M31-F02The member page separates owner, admins and members with online and "me" markers. Role actions cover promote / demote admin, mute / unmute and remove.

M31-F03The code contains delete-all style message management whose real scope needs role testing. The confirmation copy must state clearly whether it deletes locally or recalls for everyone.

M31-F04Role permissions are enforced server-side; an admin must not be able to act on the owner by tampering with the client. Removing a member confirms first and ends their send permission immediately.

Proposed fields

groupId · memberId · role · permissions · muteUntil · mentionIds · announcement · messageId

State coverage

member
admin
owner
muted
removed
group dissolved
permission changed

Acceptance

M31-AC01An ordinary member sees no management entry, and a direct request is refused as well.

M31-AC02When a member is muted, the composer they are typing in updates immediately and cannot send.

M32

Group profile, notifications, leaving and dissolving

Code-evidenced

Group information, membership changes, notifications and lifecycle.

M32-F01The group profile carries a member preview with view-all, group avatar and name, group ID and QR, announcement, my nickname in the group, group-wide mute and do-not-disturb.

M32-F02The code states that only the owner may change the group name. Adding and removing members follows permissions. Character limits come from configuration — do not write a fixed universal cap.

M32-F03A member leaving and an owner dissolving are different actions. Both confirm that messages will stop, then remove or archive the conversation and navigate back.

Proposed fields

groupProfile · memberCount · announcement · selfNickname · isAllMuted · doNotDisturb · groupState

State coverage

editing
insufficient permission
saving
all muted
leave confirm
dissolve confirm
dissolved

Acceptance

M32-AC01Owner and member see different exit actions; cancelling the confirmation changes nothing.

M32-AC02Announcement and group-name changes propagate to the conversation list; a dissolved group accepts no new invitations.

M33

Contact tags and broadcast history

Code-evidenced

Tag management, member organisation, sending and history.

M33-F01The tags page supports create, search, manage and bulk delete. Tag detail can rename, delete, add and remove friends, and import from a group.

M33-F02Broadcasting to a tag states clearly how many friends will receive it and supports media. History lists the content, recipients, count, file view and send-again.

M33-F03Broadcast is an explicit user action — confirm the recipient list before sending. Permission, recipient count and rate limits are defined server-side. Deleting a tag never deletes the friendships.

M33-F04A bulk send shows success or failure per recipient with retry. Never report overall success while hiding partial failures.

Proposed fields

tagId · tagName · memberIds · sendJobId · recipientSnapshot · content · perRecipientResult · sentAt

State coverage

no tags
editing
selecting friends
awaiting confirmation
sending
partial success
complete

Acceptance

M33-AC01A tag broadcast snapshots recipients at send time; editing the tag afterwards does not affect the in-flight job.

M33-AC02Send-again requires fresh confirmation and never auto-repeats; deleting a tag keeps the contacts.

M34

App download and install guidance

Entry verified · not downloaded or installed

The download page, QR codes, platform routing, add-to-home-screen and install help.

M34-F01The desktop app page offers an iOS manifest entry and an Android package entry. The home overlay and bottom banner supply a QR code and the permanent domain.

M34-F02Mobile /pages/common/download, /app, an iOS tutorial and a store redirect page all exist, adapting after browser and OS detection.

M34-F03The live page includes an add-to-home-screen tutorial. Distinguish bookmarking from profile installation, state the real action and its source, and never trigger a download or install automatically.

M34-F04Target: record download-button clicks and guidance impressions. A click is not an install — installation success must be reported back by the client. A dead link offers retry or an official alternative.

Proposed fields

platform · version · packageUrl · manifestUrl · qrUrl · channel · installationMethod · downloadEvent

State coverage

iOS
Android
desktop QR
restricted browser
link dead
copy succeeded / failed

Acceptance

M34-AC01iOS and Android reach the correct targets; nothing downloads without a click.

M34-AC02The QR and the text channel agree; a failed copy never reports success.

M35

About, terms, privacy and generic content pages

Partly verified & code-evidenced

About, terms of service, privacy, generic web content and error pages.

M35-F01Desktop About positions the product as sports streaming and data. The disclaimer entry is titled Terms of Service and Disclaimer, and its content also covers privacy. A separate /privacy route exists.

M35-F02Mobile carries terms, privacy and common/news style content routes. Terms links from registration and sign-in must return to the form with its fields preserved.

M35-F03Target: manage agreements with a document ID, version, effective date and consent record. Do not copy the source site's legal entity, contact details or clauses.

M35-F04Generic content pages handle missing content, dead external links, offline, back and reload. An error must never loop through infinite redirects.

Proposed fields

documentId · version · title · effectiveAt · content · acceptedAt · targetUrl

State coverage

normal
version updated
load failed
document withdrawn
external link restricted

Acceptance

M35-AC01The registration terms link opens the correct version, and returning preserves the entered fields.

M35-AC02When a document is unavailable, show retry — never let a user consent to terms that failed to load.

M36

Platform operations and supporting capability

Proposed · source back office not accessed

The operations and back-office boundary needed to make the front end real.

M36-F01Operations configuration manages navigation switches, carousels, recommendation slots, anchor ordering, league categories, download channels, specials and announcements — with preview, publish, rollback and an audit log.

M36-F02Data ingestion manages match, team and player ID mapping, time and status normalisation, de-duplication and correction. Stream source management covers activation, validity windows and availability checks.

M36-F03Account and community support needs role permissions, verification codes, follows and reminders, message moderation and abuse handling, and feedback review. These are proposals for the target system, not claims about the source back office.

M36-F04Publishing video and news content manages cover, author, category, source, status and external links. Comment status and message status stay separate. Back-office fields extend from the data dictionary.

Proposed fields

operatorId · role · configVersion · contentStatus · publishAt · auditLog · providerMapping

State coverage

draft
pending publish
published
withdrawn
rolled back
data anomaly

Acceptance

M36-AC01A misconfiguration can be rolled back to the previous version, with the operator and timestamp recorded.

M36-AC02An unauthorised role cannot publish content or change user permissions, and front-end caches invalidate promptly.

M37

Scan and QR recognition

Public route code-evidenced

Personal codes, group codes and the general scan entry point.

M37-F01The chat menu includes Scan, and personal and group profiles each provide a QR code. The scanner route exists; the browser camera flow was not executed in this capture.

M37-F02Target: allow-list the recognised types to user, group and in-site link. Resolve first, show the target identity, then require an explicit confirmation before joining or adding.

M37-F03Camera permission denied, no camera, low resolution, invalid code and expired code all need feedback. Optional album decoding runs only after the user actively picks an image.

Proposed fields

scanType · payload · targetId · codeVersion · expiresAt · permissionState

State coverage

awaiting permission
scanning
recognised
invalid
expired
permission denied
unsupported

Acceptance

M37-AC01Scanning an unknown external link never opens or executes it automatically — only after confirmation.

M37-AC02A denied camera permission keeps a way back and never produces an unclosable black screen.

Section 05

Key data objects and boundaries

Object	Minimum fields	Consistency requirement
Match	id sport league teams kickoff status score periods updatedAt	Many rooms share one match; the score has a single source of truth
Room	id anchorId matchId state sources heat	A match-and-anchor pairing; source validity can change
Anchor	id accountCode avatar name bio followState nextSchedule	Going offline never deletes the profile
Ranking	leagueId season stage type rows rulesVersion	Leagues and seasons stay isolated; rules and table share a version
OddsSnapshot	matchId companyId marketType initial current line updatedAt	Opening and current share a market and a source; suspension is a state
Article / Video / Replay	id type category source title media state publishedAt	Content types stay separate; a replay source may be external
User	id accountCode phoneMasked nickname avatar limits	The client never stores a password; disclose private fields minimally
Relationship	userId targetId targetType state version	Following an anchor, favouriting a match and friendship are different types
Appointment	id userId matchId remindAt relationState deliveryState	A saved relationship is not a delivered reminder
Message	id clientId conversationId sender payload status sequence	Idempotent; the read cursor advances monotonically
Group	id profile roles permissions joinPolicy state	Server permissions take effect immediately on change
TagSendJob	id tagId recipientsSnapshot content results	Per-recipient results; resending requires a new intent
Feedback	id userId content attachments contact createdAt	A failed upload can never become a valid attachment
Document / Config	id version effectiveAt state	Agreement versions and operational publishes are traceable

Field values and lengths need integration testing except where explicitly evidenced. Count string lengths in Unicode characters or grapheme clusters — an emoji in a name must never be cut at a UTF-16 half. Transport user IDs, match IDs and article IDs as strings so large integers do not lose precision.

Section 06

API and realtime design guidance

Contracts here are defined by capability. They do not copy the source site's service domains or guess at its private API.

Public queries: home recommendations, live list, fixtures and scores, match detail, league standings, content list and detail, search. Authenticated writes: SMS challenge, sign-in and registration, relationship changes, reminders, feedback, comments, messages and group administration.

Queries return data, a cursor or pageInfo, serverTime and dataVersion. Errors return a stable code, a readable message, a retryable flag and fieldErrors where relevant.

Uploads validate identity and attachment conditions first, obtain a short-lived upload authorisation, then submit the resulting attachment ID. A permanent storage key must never reach the client.

Realtime splits into match-data and conversation subscriptions, reconnecting with the last sequence. Switching match unbinds the old subscription; a backgrounded page reduces non-essential refreshes; on recovery, take a snapshot first and then backfill the delta. Push failure may degrade to polling, but the polling interval is a design parameter — do not claim the source site uses a specific number of seconds.

Performance acceptance environment

A 390px mobile device, ordinary 4G, a same-region service node, 100 sample scores and 100 sample messages. Targets: first usable content within 3 seconds, ordinary interaction feedback within 200 milliseconds. Video start is measured separately as first-frame latency and failure rate, and must be reviewed against real sources and network conditions. These are targets, not measured results.

Section 07

Quality and exception acceptance matrix

Category	Must cover	Expected result
Data loading	First load, load more, empty list, timeout, 5xx, partial failure	Stable skeleton; errors offer retry; one module's failure never takes the site down
Network	Offline, weak signal, reconnect, out-of-order responses	Keep the last data and mark it stale — never fake live
Permissions	Guest, user, admin, group owner, expired token	Front and back end agree; no data exposed beyond permission
Match states	Pre-match, in play, half time, overtime, finished, postponed, cancelled, abandoned	One consistent status mapping; unknown scores use a placeholder
Content	Image 404, no video source, dead article, dead external link	Degrade readably with a real way back or retry
Forms	Whitespace, emoji, over-length, invalid phone, mismatched password, double submit	Field errors appear in place; drafts survive
Notifications	Reminder saved but delivery failed, do-not-disturb, @mention, multi-device read sync	States stay independent and diagnosable
Devices	360, 390, 430, 768, 1024, 1440, 1920px; orientation; keyboard	Nothing covered or overlapping; horizontal scroll boundaries are explicit
Undo	Cancel a filter, unfollow, leave a group, dissolve a group	Ordinary drafts are cancellable; destructive actions state their consequence
Long sessions	30 minutes of continuous browsing; 1,000 accumulated messages	List performance holds; resources and subscriptions are released
Caching	Switching league, season, anchor, account	No stale rules, stale profile or another person's messages
Accessibility	Keyboard, focus, screen reader, high contrast, reduced motion	Controls are named; state carries text or shape beyond color

Section 08

Analytics definitions

Event	Required properties	Definition
page_view	pageId moduleId device referrer	The route rendered successfully; error pages are logged separately
filter_apply	moduleId filters resultCount	Recorded on confirm — not once per checkbox
room_enter	matchId roomId anchorId source	Entering a room. Not the same as playback starting
play_start / play_error	roomId sourceId firstFrameMs errorCode	A start counts only after the first frame; no source counts as an error
follow / appointment	targetId operation result	Separate intent, success and failure
search_submit	keywordLength category resultCount	Avoid storing full keywords containing personal identifiers in the analytics layer
message_send	conversationType payloadType result latency	Never send private message bodies into general behavioural analytics
content_open	contentId contentType provider	External replays and in-site video are counted separately
download_click	platform channel placement	A click only. It is not an install
form_error	formId field errorCode	Never collect password or verification-code values
group_action	action role result	Management auditing stays separate from product analytics

Section 09

Open gaps to close before launch

Nine items that this capture could not resolve. Each must be closed before any "one-to-one rebuild" acceptance.

G01

Signed-in permissions

No test account was provided, so profile edits, follow and reminder persistence, message sending, comments, and group and tag operations were not exercised. Three permission levels are needed: ordinary user, group admin, group owner. The user should sign in on the site themselves — credentials do not belong in this document.

G02

The playback path

A player container was observed but no successful start was confirmed. A stable, licensed test stream is needed to verify first frame, audio-video sync, reconnection and full screen. Casting, picture-in-picture and download strings found in the player library are not evidence those features ship.

G03

Desktop content components

/data, /videos and /news rendered only shells this time, while the mobile data and content lists worked. The proposed desktop styling is an adaptation and must be re-checked once those components load.

G04

Article detail

Mobile article 208644 returned a page-load failure. Body and comment detail were reconstructed from public component code and are not presented as verified.

G05

Data consistency

Replay 2694 listed a home score of 72 while its detail showed 0. Switching to the NBA once left CSL rules on screen. Both are defect leads from the capture and need stable reproduction before a fix.

G06

Hidden and legacy routes

/world currently falls back to home. Mobile legacy message, chat/info and generic content pages have code but their entry points and roles are not fully verified. They stay as coverage items — not automatically as shipping menu entries.

G07

Business parameters

Match time display strategy, reminder lead time and channel, message recall window, group member cap, mute duration and tag broadcast limits all need decisions from product and the server team.

G08

Profile field differences

Desktop's 200-character bio versus mobile's 60-character signature must be unified or explicitly split into two fields. Verification-code length and phone-region policy need the same treatment.

G09

Native app and back office

There is no access evidence for the native app or the operations back office. M36 is supporting design guidance. The existence of an install entry does not imply the native feature set.

Section 10

Route coverage and sources

104

desktop or mobile paths and patterns were registered, all of them mapped to modules in this PRD. Aliases, compatibility entries and content templates mean the route count differs from the module count — route count is not a count of verified pages. The full list ships as ttkq-route-coverage.csv.

ID	Source	What it evidences
D01	Desktop home	Carousel, featured matches, anchors, sections, download overlay
D02	Desktop all live	Categories and cards
D03	Desktop live room sample	Room, chat, follow, odds, basketball statistics
D04	Desktop football scores	Table, filters, display settings, legend
D05	Desktop basketball scores	Period table and odds
D06	Desktop fixtures	Categories, dates, anchors, reminder entry
D07	Desktop data	Shell only — `league-data` did not render
D08	Desktop video	Shell only — `c_video-web` did not render
D09	Desktop replays	Directory and detail `/cba/2694`, external sources
D10	Desktop news	Shell only — `c_news-list-web` did not render
D11	Desktop account dialog	Sign-in, SMS, registration and recovery fields
D12	Desktop download	iOS and Android entries; nothing downloaded
D13	About	Service positioning
D14	Disclaimer	Terms and privacy body
H01	Mobile home	Mobile UA, search, recommendations, five-item tab bar
H02	Mobile picks	All, football, basketball, other
H03	Mobile live room	Seven tabs, odds, analysis, anchor profile; playback unverified
H04	Mobile scores	Date strip and match list
H05	Mobile fixtures	Grouped by date, anchor list
H06	Mobile data	Leagues, seasons, football and basketball rankings
H07	Mobile video	Categories, author, play count
H08	Mobile replays	Categories shown; sample list empty
H09	Mobile news	List normal; article 208644 detail failed to load
H10	Mobile search	Hot terms, search tabs, no-results state
H11	Mobile sign-in	Where the chat entry routes
H12	Mobile download route	Public entry and code; no install performed
S01	Desktop routes and account code	Plus the public chunks it references: userinfo, users, userfollow, userappointment, userfeedback
S02	Desktop live code	Realtime data, odds, chat, follow
S03	Mobile routes and chunk index	65 public page chunks with their paths
C01	Desktop shared stylesheet	Brand color, container, navigation, dialog
C02	Desktop home stylesheet	Home flex container, cards and spacing
A01	Target implementation guidance	Engineering requirements derived from the observed front end — not back-office evidence