[bagrat]

What

• The browser now resolves from, highest first:
  1. --browser;
  2. SEDUM_BROWSER (the process environment, then the project .env);
  3. the selected environment's new browser key;
  4. the top-level browser;
  5. the default, chrome.
• sedum doctor accepts --browser. Its browser check says where the setting came from, e.g. chromium is available (from SEDUM_BROWSER).
• When the configuration doesn't load, doctor shows the first config diagnostic instead of a bare "could not be loaded".
• The Chrome-to-managed-Chromium fallback now recognises Playwright 1.63's Chromium distribution 'chrome' is not found at … error.

Why

We run the same suite on macOS, where Chrome is installed, and in Linux containers (Claude Code cloud sessions, CI), where it isn't.

• The browser could only be set in the shared config's top-level key or with --browser on run, so a Linux machine needed a flag on every command. doctor couldn't be told at all.
• With browser: chrome on Linux, doctor said "chrome is available", because findBrowserExecutable falls back to managed Chromium. But launch didn't recognise Playwright 1.63's missing-distribution message, so it never fell back, and every run failed.

Verification

• pnpm typecheck and pnpm lint are clean, and pnpm test passes 1,450 tests (new: precedence, .env vs process, an invalid value per source, doctor --browser, the doctor config message, the Linux fallback).
• On Linux, installed into a project with browser: chrome:
  • doctor reports (from browser), (from SEDUM_BROWSER) and (from --browser) correctly;
  • SEDUM_BROWSER=firefox gives "Project configuration could not be loaded: SEDUM_BROWSER must be chrome or chromium."
• On macOS (arm64) with Google Chrome 156, installed into the same project:
  • doctor reports (from browser), (from SEDUM_BROWSER) and (from --browser), and the firefox error;
  • a run with no --browser used real Chrome;
  • a run with SEDUM_BROWSER=chromium used managed Chromium;
• Real isolated runs on Linux passed with no --browser flag (the fallback) and with SEDUM_BROWSER=chromium.
• Not yet checked on macOS with Chrome.

[coldtea-pr-lens]

• Redraw · drawn at 8df897c, the branch has moved on

Architecture

Data flow

Tip

Set github.draw: on-demand in .github/pr-lens.yml and PR Lens stops drawing pull requests on its own. Comment @pr-lens draw on a pull request when you want that one drawn

🪧 More tips

• Run npx skills add coldteadotai/pr-lens, then tell your coding agent: "Diagram the change you just made with PR Lens and attach it to the pull request."
• Run npx @coldtea/pr-lens-cli analyze --base origin/main on a branch, then npx @coldtea/pr-lens-cli render .pr-lens/graph.json. Same lenses, your own model key, before the pull request exists
• Click the link under each diagram to open it on a canvas you can zoom, pan and step through
• The diagrams are links. Click one to open it on the canvas, then press W or click play to walk through the change
• Open a diagram on the canvas, then press W or click play to walk through the change one step at a time
• The CLI's render reads .github/pr-lens.yml and applies your renames, exclusions and lane pins at draw time
• Set github.comment.collapsed: true in .github/pr-lens.yml to fold the comment behind one View architecture and data flow row. Drawing still runs as before
• Add .github/workflows/pr-lens.yml with coldteadotai/pr-lens/packages/action@v0 and your model provider's key as its api-key to run PR Lens from your own CI. Any /chat/completions endpoint works
• After a push, tick Redraw to draw the latest commit
• Switch GitHub to dark mode and the diagrams follow. The moving dots are this pull request's data in motion

_{Thanks for using PR Lens! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out on X, Bluesky, Mastodon, Reddit or LinkedIn}

[mintlify]

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit b4cca2c.

Approve preview