teecup/.mcp.json

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--headless", "--viewport", "390x844"]
    }
  }
}
Update Todos Log in as user in chrome-devtools browser (magic link) Screenshot scorekort-grid page at mobile viewport Fix critical sticky-column overlap bug found via real browser test Verify fix by scrolling grid + re-screenshotting Assess density and golfscore-language compliance Update CLAUDE.md/FEATURE_BACKLOG.md with the real bug+fix Report findings to user Good thing you asked me to actually look — I found and fixed a real, serious bug. What was broken: position: sticky on table cells, combined with sticky columns on both the left (player names) and right (Ut/Inn/Sum) at once, rendered completely garbled in Chrome — the sticky right columns got pulled to the visible edge immediately and overlapped/bled into the hole columns underneath (you'd have seen overlapping digits like "436"/"472"). My first fix attempt (border-collapse → border-separate) didn't touch the real cause and the second screenshot still showed the same mess. Root cause: combining sticky-left and sticky-right in one table wider than the viewport is inherently unstable — at scroll position 0, the sticky-right cells are already pinned to the screen edge, sitting visually on top of whatever hole columns happen to be there in normal document flow, only partially hidden by their translucent background. Fix: dropped sticky positioning from the Ut/Inn/Sum columns entirely — they now scroll with the rest of the holes, same well-supported pattern as the (correctly-working) sticky name column. Verified for real this time: Screenshot at scroll-left=0: all numbers clean, correct circle/square/plain-text score marks (bogey/double-bogey/par all visually distinct). Scrolled the grid all the way right via a script: holes 14-18 plus Ut/Inn/Sum all render cleanly, name column still correctly pinned — Ut 36 / Inn 36 / Sum 72 on the Par row, which is exactly right for an 18-hole par-72 course. Accessibility tree confirms the golf-term labels ("Bogey", "Dobbel bogey", "Par") are actually present in aria-labels, so §Golfscore-språket's "never color alone" rule holds in practice, not just in code. No dead space concerns — density looks reasonable against §0.1's tolerance, and green stays reserved for active-state/under-par per §0.2 (no stray "grønt-på-grønt" spotted). Redeployed twice (once for the failed attempt, once for the real fix); both times /health → 200, teeoff.no unaffected. Docs updated with the full story, since this is the first time this session a real browser was available to verify hand-coded frontend work — worth remembering for anything else built blind this week that you haven't clicked through yet. 2026-07-27 14:34:18 +02:00			`{`
			`"mcpServers": {`
			`"chrome-devtools": {`
			`"command": "npx",`
			`"args": ["-y", "chrome-devtools-mcp@latest", "--headless", "--viewport", "390x844"]`
			`}`
			`}`
			`}`