Styling from design system

[anna-follestad-4ss]

What changed

• This PR adds a link to the 4subsea design repo: https://github.com/4Subsea/4subsea-design-system
• All fonts and colour definitions uses tokens from the 4subsea design system instead of the previous hard-coding.
• The design system is added through a pip install
• Added tests that check for hard-coded values (should generally be none)

Why

The styling was based on the current (July 2026) version of 4subsea styling, but hardcoded and so fixed to that version. We want the template repo to reflect actual latest version of the 4subsea style library, so that python dashboards are compliant with the company style.

Definition of done

CI covers the first two. See CONTRIBUTING.md for why each is here.

• pytest passes
• black is clean
• Every threshold, unit and label comes from a named constant, not a literal
• Anything machine-specific is in .env.example, not hardcoded (unless it's
  a documented, deliberate simplification - see README)
• Every page opened and looked at after the change
• At least one displayed number spot-checked against the source
• CLAUDE.md updated if this establishes a new convention, README.md if it
  changes how to run, refresh or deploy anything

[Copilot]

🟡 Changes recommended

Critical issues remain in fork CI authentication and unrestricted asset serving, alongside moderate dependency, token, and test gaps.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates dashboard styling to use the 4Subsea design-system package, including Plotly themes, CSS tokens, asset serving, validation tests, documentation, and CI authentication.

Changes:

• Replaces hardcoded styling values with design-system tokens.
• Adds packaged CSS serving and token regression tests.
• Updates dependencies, CI configuration, and styling documentation.

File summaries

File	Summary and review notes
tests/test_style_tokens.py	Adds hardcoded-style checks. Moderate issues: Python font families and RGB values are not fully checked, and the font-token check accepts arbitrary var(...) values.
src/theme.py	Registers the external Plotly theme.
src/assets/css/main.css	Maps application styles to design-system tokens. Moderate issue: --radius usages remain without a local declaration.
src/app.py	Serves design-system CSS assets. Critical issue: unrestricted filenames can expose package files. Moderate issue: the asset route lacks a test for successful stylesheet delivery.
requirements.txt	Adds the design-system dependency. Moderate issue: the VCS dependency is not pinned to a branch, tag, or commit.
README.md	Documents the design-system styling integration.
CLAUDE.md	Updates styling conventions.
.github/workflows/ci.yml	Configures dependency authentication. Critical issue: forked pull requests cannot access the required secret and will fail during dependency installation.

Review details

Suppressed comments (6)

.github/workflows/ci.yml:33

• This writes the access token into the global git config and leaves it there for the later black and pytest steps. Because those steps execute PR-controlled code, a test or imported module can read ~/.gitconfig and exfiltrate DESIGN_ACCESS_TOKEN; scope the rewrite to the install step and remove it with a trap before running checks.

          git config --global url."https://x-access-token:${DESIGN_ACCESS_TOKEN}@github.com/".insteadOf "https://github.com/"

src/app.py:56

• The new route is the only way the browser can load colors_and_type.css, but the app tests never request it. A wrong package directory or missing packaged asset would therefore return 404 while pytest still passes, leaving every page without the design-system tokens. Add a Flask test-client assertion for the stylesheet response (including a successful status/content type).

@app.server.route(f"{DESIGN_SYSTEM_URL_PREFIX}/<path:filename>")
def design_system_static(filename):
    return flask.send_from_directory(DESIGN_SYSTEM_DIR, filename)

src/assets/css/main.css:35

• The only --radius declaration was removed from :root, but .visual, .slicer, and the modebar still use border-radius: var(--radius). Unless the external stylesheet happens to export this exact variable, those declarations become invalid and the intended rounded corners disappear; keep an app-local alias to the design-system radius token or update the uses to the package's actual token.

  --gap: var(--space-4);

tests/test_style_tokens.py:64

• The README says this guard covers hard-coded colors and font families in both CSS and Python, but the Python test only searches for hex colors. A new Python figure/component can reintroduce a literal font.family and all tests still pass, so the stated styling policy is not actually enforced; add a Python font-family check or narrow the documentation to CSS.

@pytest.mark.parametrize("path", _py_files(), ids=lambda p: p.relative_to(SRC))
def test_python_has_no_hardcoded_colors(path):
    violations = _matches(path, HEX_COLOR)

tests/test_style_tokens.py:54

• The guard treats any var( as a valid font token, so a declaration such as font-family: var(--color), Arial would pass even though it does not use a font token and still hardcodes a family. Match the declaration against the expected --font-... token instead.

        if "font-family" in line and "var(" not in line:

tests/test_style_tokens.py:64

• RGB_FUNC is defined specifically for color detection, but the Python test only applies HEX_COLOR. A future Python rgba(...)/rgb(...) literal would therefore bypass the new hardcoded-color guard despite the test's documented purpose; include RGB_FUNC in this check.

    violations = _matches(path, HEX_COLOR)

• Files reviewed: 7/8 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.