feat(web,server): a room shows what the crew did together — consistency tiles, then a ladder

[janlauber]

Part of #992. Blocked on #994 — the social-stats research pass. The shape below is decided; the metrics are not, and picking them by taste is exactly what #994 exists to prevent.

A room's page shows four tiles: riders, streak, this month, medals. For a crew that rides together every week, that says almost nothing about the crew.

Mockups: https://claude.ai/code/artifact/880fdc31-6238-4547-9d3a-b291cda3f50d — right column.

Decided: consistency tiles lead, the ladder sits below

TOGETHER      STREAK        THIS MONTH      SHOWED UP
84 h          6 wk          21 sessions     ●●●●○●●●●●○●
ridden as a   a session     up from 17      last 12 sessions
crew          every week

── the ladder ──────────────────────────────────────
[this month] sessions  sprints
 1  Jan Lauber          4,210 kJ   12 sessions   ← you
 2  David Kneubühler    3,880 kJ   11 sessions
 3  Mike Frei           2,140 kJ    8 sessions
 4  Captain-SVXN        1,905 kJ    9 sessions

The order is the finding, not a layout preference. RESEARCH.md §13.3 puts consistency and time-in-saddle above every performance metric for this audience — "wins rider surveys by 5–8×" — so what everyone sees without scrolling is how often the crew shows up, and the ranked board is for whoever wants it.

A room-scoped ladder is explicitly permitted, and only this kind is:

Leaderboards, rankings, duels live inside a room — your crew's ladder, not the internet's. No public leaderboards.

What #994 has to settle before this is built

• Which metrics the tiles carry. "Hours together" and "showed up" are drawn as plausible, not chosen.
• Which boards exist and how they rank. kJ favours the heavy and the long; w/kg favours the light; execution favours whoever picked the easy workout — and §13.4 already warns execution must not double as a difficulty metric. The honest answer may be several boards and no single rank.
• The small-N and harm question. A four-person room where the same person is always first is a different object from a twelve-person room. Suppression thresholds, decay windows, and whether a rider can be off the board at all.
• Whether "showed up" is a stat or surveillance. It overlaps feat(server,web): a session leaves a recap — who was here, when they came, how long they stayed #985's argument and should be settled once, there or here, not twice.

What is already available

• rides.room_id with rides_room_started indexed for exactly this read path (20260906201812_ride_room_indexes.sql), and RoomMonthKj / ListRoomRideWeeks already query it.
• The room response already carries streakWeeks and medals (server/internal/rooms/rooms.go:206).
• xp_events carries the per-rider counts feat(web,server): the profile shows hours in voice, sessions, sprints and tracks — all of it already counted #993 is surfacing — the same numbers, grouped by room-mate.

The privacy question is the live one: a board naming another rider's kJ is durable disclosure of a ride that is private by default. Everyone in the room watched it happen live, which is the same argument #985 had to make for presence — and the same reason it needed an ADR. Expect one here too, or a metric set that avoids the problem.

Acceptance criteria

• docs: research the social stats layer — RESEARCH.md has no §14, and the room work is blocked on it #994 is merged and this issue's metrics cite it — no metric ships on taste.
• Consistency tiles above the fold; the ladder below.
• Every board is room-scoped, with no cross-room or global view reachable from it.
• The privacy position is written down — an ADR if a board shows another rider's ride-derived numbers, or a stated reason why the chosen metrics do not need one.
• Small rooms and new rooms render something that teaches rather than an empty ranked list (ux.md empty states).
• Heart rate appears nowhere.
• Numbers use the same vocabulary as feat(web,server): the profile shows hours in voice, sessions, sprints and tracks — all of it already counted #993's profile section — one glossary, not two.
• make ci green.

Deliberately not in scope

Cross-room comparison, global anything, a rider's private ride detail reachable from a board, and home (which should adopt whatever vocabulary this settles, not invent its own).

Related

#992 (epic), #994 (blocking research), #993 (the per-rider counts and their vocabulary), #985 (the presence-privacy argument), WATTROOM.md (room-scoped competition).

[janlauber]

Unblocking: #994 is merged — docs/RESEARCH.md §14 is in on main.

What §14 settles for this issue, so it is not re-derived:

• The tile order here is right, and now has evidence. §14.7 ranks who rode this week, and whether that is the crew's normal first, and the crew's combined week second. The consistency-above-ladder decision in this issue matches the finding rather than merely preceding it.
• The fairness question has an answer: several boards, no single rank (§14.4). kJ rewards mass and duration, w/kg inverts it, and execution ranks workout choice rather than effort — but WattRoom already owns a fairer primitive in Category (D–A from the 90-day w/kg curve), which is a bracket rather than a rank and says who to compare with.
• The recommended default is a cooperative total — the crew's combined week, one figure nobody is ordered inside — with an ordered board opt-in per room and weekly-resetting, never the default view. The strongest single piece of evidence is Zwift's: "Keep Everyone Together" cannot be enabled together with Event Results, so the incumbent treats riding together and ranking each other as mutually exclusive modes.
• The standing-crew trap is named (§14.2, §14.8): a room does not re-randomise its members, so a stable ordering means the same person is last every week — the one configuration none of the products torn down has to survive, because they all reset, cap or re-randomise.
• "Showed up" is on the safe side of the line (§14.5), which also settles the feat(server,web): a session leaves a recap — who was here, when they came, how long they stayed #985 overlap: ephemeral-and-mutual presence is universally shipped, durable-and-one-sided is what got Strava's Flyby switched off for everyone. A room is closed membership with mutual consent, so a showed-up strip is fine provided what the room can see is fixed and shown before joining, and never aggregates across rooms.

Still not settled here, and §14.9 says why they are decisions rather than findings — two of them block this issue's build:

1. What a room may show about its members, and when they consent to it. The WHOOP pattern is the candidate: the metric set is chosen at team creation, immutable afterwards, and a joiner sees exactly what will be shared before joining. This is the ADR this issue's privacy paragraph anticipated.
2. Whether a room has an ordered board at all. §14 recommends cooperative-by-default and opt-in for the ladder; that is a product call, not a research output.

Leaving this unassigned rather than picking it up: building the tiles means answering (1) and (2) in passing, and this issue's own text says picking these by taste is what #994 existed to prevent.

[janlauber]

Adding needs-human-input so this stops surfacing as available work — it is not, and the reason is already in the comment above.

Two decisions gate the build (§14.9): what a room may show about its members and when they consent to it, and whether a room has an ordered board at all. Both are product/privacy calls, and this issue's own text says picking them by taste is what #994 existed to prevent. An agent taking this would answer both in passing, which is precisely the failure mode.

The label is the only change; nothing here is re-decided.

[janlauber]

Taking this — #994 merged, so the research this was blocked on exists. Reading RESEARCH.md's social-stats section first and citing it for every metric; will post the metric set and the privacy position here before building the ladder.