fix(storybook): temporarily keep EDS and native controls light

[chdefrene]

Component Development

Type

• Feature
• Fix
• Hotfix (should release ASAP)
• Maintenance (deps only)

Reference to assignment

Related to equinor/fusion-core-tasks#2120, Storybook portion only. Other runtime surfaces are handled separately. This is a nonclosing reference; legacy work remains unresolved.

Description of assignment

Temporarily keep normal Storybook UI using EDS CSS variables and native browser controls light, both at initial light/dark OS/browser preferences and when preferences change live. Do not add dark-mode support or change reusable component/provider defaults.

Description of Proposed Changes

• Set the preview root's explicit EDS light selector and native only light scheme synchronously in storybook/.storybook/preview-head.html, before stories render. Cover Docs canvases and body-portaled content without changing ThemeProvider.
• Add storybook/.storybook/manager-head.html to keep native manager controls light alongside its existing light Storybook theme. Target manager descendants because Storybook's layout and popovers explicitly restore light dark below the root. The selector outranks their generated class rules without !important and cannot affect the preview iframe.
• Add two startup regression tests in storybook/.storybook/light-mode.test.mjs, wire them through storybook/package.json, and document the temporary policy and verification procedure in CONTRIBUTING.md.

Preserve explicit nested dark specimens. Do not change SideSheet or any reusable library.

Changeset: N/A — user-approved private-only exemption (2026-09-30). The user explicitly selected “Exempt the private-only Storybook PR (Recommended)” after reviewing the release-planner evidence. The only affected package is @equinor/fusion-react-components-stories (storybook/package.json, private: true); contributor documentation is also updated. Existing Changesets configuration defaults to privatePackages.version: false, and the installed release planner returns no releases for a private Storybook patch entry. Such an entry would be inert. Do not change the repository's private-versioning policy, bump untouched public libraries, or add an empty/inert changeset. No package version bump is included.

Validation completed in the dedicated worktree:

Command	Result
bun install --frozen-lockfile	Passed after the first Storybook command reported missing dependencies; no lockfile change.
bun run build	Passed for all workspace libraries.
bun run --cwd storybook test	Passed, 2 tests.
bun run storybook:build --disable-telemetry	Passed; generated manager and preview HTML contain the startup policies.
git diff --check	Passed.
bun run check -- storybook/.storybook/light-mode.test.mjs	No files processed: the repository intentionally excludes Storybook from Biome; not a lint pass.
node /Users/christian.frene/.copilot/session-state/490877d1-0c04-4928-851e-8d83283486ea/files/storybook-browser.mjs	Passed 15 actual-Storybook Chromium scenarios; no runtime exceptions.

Automated browser evidence covers initial light/dark preferences and live transitions on a textarea story and Docs canvas, manager controls, native/shadow-DOM controls, and an existing body-portaled EDS tooltip. The EDS input token stays #f5f5f5; removing the root selector under dark preference reproduces #0b0b0b. An explicit nested dark specimen remains dark.

Local evidence is retained in /Users/christian.frene/.copilot/session-state/490877d1-0c04-4928-851e-8d83283486ea/files/, including storybook-browser.json, build logs, and light/dark screenshots. The dependency-free browser harness is a local artifact rather than new repository tooling. Browser coverage is Chromium-only against development Storybook; the production build was checked separately.

User-reported manual acceptance (2026-09-30):

Pass — checked Storybook contents and controls stay light

The user checked http://127.0.0.1:46123/?path=/story/data-textarea--basic and http://127.0.0.1:46123/?path=/docs/data-textarea--docs. Contents, textarea, and surrounding Storybook controls stayed light after light/dark reloads and live switching. This is a pass for those checked routes and surfaces only, not every story. It is separate from the automated browser/probe results above; no user browser/version or manual portal-specimen check was reported. The report is retained in the local manual-evidence.md artifact.

Checklist

Create User Story(DevOps) or Issue(Github)

• Describe functional requirements
• Design plan/suggestion (e.g. images, link to eds design or relevant figma links, mention of eds tokens to use)
• Communication with UX (evaluate if needed)

No new visual design is introduced; the change preserves the existing light appearance.

Development

• Describe the component
• Code funtional requirements
• Create stories
• Create snapshots (evaluate if needed)
• Remove unused imports and commented code
• Lint code with Biome (and follow best practises for code quality

Reuse existing stories rather than add a new component or story. Local verification screenshots are retained, but no snapshot baselines are added. Biome excludes Storybook; see the validation result above.

Create Pull Request

• Assign relevant reviewers in Github and Cromatic
• Inform colleagues of pending reviews. We use Teams for this purpose, under fusion-frontend team please tag involved reviewers in the Code review channel

Create a ready-for-review PR under the user's explicit authorization. Leave assignees unset; no reviewer assignment, merge, deployment, or issue closure is part of this change.

Review of Pull Request

• Follow up on comments from code review and implement necessary changes (evaluate if needed)
• Review approved in github (and chromatic)

Publish Code

• Increment version number
• Merge PR
• Consider letting fusion developers know this this shiny new thing exists

Version increment: N/A under the explicit user-approved private-only changeset exemption above.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0d88d2b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR