Fixes #9

[fzoll]

Summary

Adds a measured capabilities.browser field to the public /.well-known/t3/environment descriptor so cc_runner's capability-based dispatch can demote nodes whose declared config has drifted from reality, per #9.

• ok: a Chromium binary was found (Playwright's downloaded browser cache is checked first, falling back to a well-known system install path) and it launched successfully — reports binaryPath + version.
• degraded: a binary was found but either it failed to launch, or only a system Chromium exists while the Playwright browser cache is missing/incomplete — reports binaryPath + details.
• absent: no Chromium binary could be found anywhere.

The probe (apps/server/src/environment/BrowserCapabilityProbe.ts) is lazy and cached for 6 hours via Effect.cachedWithTTL, so it never runs on every health-check poll. ExecutionEnvironmentCapabilities.browser is an additive optional field in packages/contracts/src/environment.ts; existing web/desktop clients tolerate it.

Detection is filesystem + process based only (directory scan of the Playwright cache, well-known system paths, then a --version spawn) — no playwright-core dependency was added to apps/server. Installation/telepítés-kezelés and cc_runner's dispatch/demote logic stay out of scope per the issue.

Decisions

• Test tier: unit, focused on apps/server, with mocked FileSystem/ProcessRunner (matches the issue's ## Test note). First commit (c2550a5c) adds BrowserCapabilityProbe.test.ts alone and is red (imports a module that doesn't exist yet); the second commit adds the implementation and wiring.
• "degraded" semantics: chose to treat both "binary found but failed to launch" and "only a system Chromium exists, no Playwright cache" as degraded, since either way the automation stack that actually needs to drive the browser (Playwright) can't be trusted yet — matches the issue's example (RPi has both apt chromium and the ms-playwright cache → ok).
• Cache key/TTL: a single process-lifetime Effect.cachedWithTTL(..., "6 hours") per server instance, as specified.

Manually verified

scripts/agent-verify.sh does not exist in this repo, so per instructions I ran pnpm lint and the relevant test suites directly.

$ pnpm --filter @t3tools/contracts typecheck
$ tsgo --noEmit
(clean, no output)

$ cd apps/server && pnpm exec vp run typecheck
~/apps/server$ tsgo --noEmit ⊘ cache disabled
(clean, no output)

$ cd apps/server && pnpm exec vp test run src/environment/ src/server.test.ts
 Test Files  5 passed (5)
      Tests  132 passed (132)

$ pnpm lint
(only pre-existing warnings in apps/web, unrelated to this diff; exit 0)

Pre-existing, unrelated flake found while running the full pnpm test

Running pnpm test at the repo root (which fans out to every workspace package in parallel) reproduces one failing test twice in a row:

FAIL apps/mobile/src/features/diffs/nativeReviewDiffHighlighter.test.ts
  > highlightNativeReviewDiffVisibleRows > keeps grammar state across inline comment rows

I confirmed this is not caused by this PR:

• git diff main -- apps/mobile/src/features/diffs/nativeReviewDiffHighlighter.ts apps/mobile/src/features/diffs/nativeReviewDiffHighlighter.test.ts is empty — neither file is touched by this branch.
• Running apps/mobile's full test suite alone (cd apps/mobile && pnpm exec vp test run), twice, passes cleanly both times: 520 passed (520).
• It only reproduces when pnpm test runs 4+ workspace packages' Vitest processes fully in parallel in this sandbox and fails identically both times I tried, which points at CPU-contention-sensitive timing inside the shared Shiki/JS-regex highlighter singleton under heavy load (the failing assertion shows coarser, less-tokenized output consistent with a tokenizer time budget being hit), not a logic bug in the diff.

I did not attempt a fix for it here since it's unrelated to #9's scope and I couldn't get a reliable, isolated repro to validate a fix against — flagging it explicitly rather than silently leaving it. Given the issue's own acceptance criteria (measured ok/degraded/absent browser capability, lazy 6h-cached probe, unit test coverage) are fully met and verified above, I'm titling this "Fixes #9"; happy to split the mobile flake into a separate follow-up issue if preferred.

Closes #9

Summary by CodeRabbit

• New Features

  • Server environment information now includes detected Chromium availability and usability.
  • Server versions can display build identifiers for more precise troubleshooting.
  • Version checks distinguish release mismatches from build-level differences, reducing false warnings for remote environments.
  • Connection diagnostics now log version mismatches before establishing sessions.

• Bug Fixes

  • Improved reliability when multiple Git operations target the same repository, preventing conflicting worktree and fetch activity.
  • Browser detection reports clear states when Chromium is unavailable, degraded, or fully operational.

[fzoll]

Opened against the wrong repo (upstream instead of the fork). Closing; correct PR opened against fzoll/t3code.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 51942644-08ee-4741-86b0-87566e2e5e63

📥 Commits

Reviewing files that changed from the base of the PR and between cfeaca4 and 14b8c38.

📒 Files selected for processing (14)

• apps/server/src/environment/BrowserCapabilityProbe.test.ts
• apps/server/src/environment/BrowserCapabilityProbe.ts
• apps/server/src/environment/ServerBuildSha.test.ts
• apps/server/src/environment/ServerBuildSha.ts
• apps/server/src/environment/ServerEnvironment.ts
• apps/server/src/vcs/GitVcsDriverCore.test.ts
• apps/server/src/vcs/GitVcsDriverCore.ts
• apps/web/src/components/ChatView.tsx
• apps/web/src/components/settings/ConnectionsSettings.tsx
• apps/web/src/connection/platform.ts
• apps/web/src/versionSkew.test.ts
• apps/web/src/versionSkew.ts
• apps/web/vite.config.ts
• packages/contracts/src/environment.ts

---

📝 Walkthrough

Walkthrough

The PR adds browser capability detection, Git-based build metadata, version-skew handling, and per-repository Git operation locks. It updates server descriptors, web connection checks, build configuration, contracts, and related tests.

Changes

Environment observability and version identity

Layer / File(s)	Summary
Browser capability contract and probe packages/contracts/src/environment.ts, apps/server/src/environment/BrowserCapabilityProbe.ts, apps/server/src/environment/BrowserCapabilityProbe.test.ts	The environment contract adds browser capability states and fields. The server probes Playwright and system Chromium binaries, reports launch results, and caches the result.
Git build version resolution and descriptor wiring apps/server/src/environment/ServerBuildSha.ts, apps/server/src/environment/ServerBuildSha.test.ts, apps/server/src/environment/ServerEnvironment.ts, apps/web/vite.config.ts	The server and web build resolve a validated Git SHA and append its prefix to the application version. The server descriptor includes the browser capability result.
Build metadata comparison and connection reporting apps/web/src/versionSkew.ts, apps/web/src/versionSkew.test.ts, apps/web/src/components/ChatView.tsx, apps/web/src/components/settings/ConnectionsSettings.tsx, apps/web/src/connection/platform.ts	Version comparison can include build metadata. Primary environments compare Git metadata, remote threads use release-level comparison, and connection loading logs mismatches.

Per-repository Git synchronization

Layer / File(s)	Summary
Per-repository Git operation locking apps/server/src/vcs/GitVcsDriverCore.ts, apps/server/src/vcs/GitVcsDriverCore.test.ts	Git worktree creation, fetching, and remote tracking resolution share a semaphore per repository. Tests verify same-repository serialization and concurrent operation across different repositories.

Estimated code review effort: 4 (Complex) | ~45 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant WebBuild
  participant ServerEnvironment
  participant ServerBuildSha
  participant BrowserCapabilityProbe
  participant WebClient
  WebBuild->>ServerBuildSha: resolve git SHA during build
  ServerEnvironment->>ServerBuildSha: resolveServerBuildSha()
  ServerEnvironment->>BrowserCapabilityProbe: probe()
  BrowserCapabilityProbe-->>ServerEnvironment: BrowserCapability
  ServerEnvironment-->>WebClient: environment descriptor with serverVersion
  WebClient->>WebClient: compare release and build metadata

Loading

Suggested reviewers: juliusmarminge

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

🟡 Medium environment/BrowserCapabilityProbe.ts:31

On Ubuntu hosts using the Chromium Snap, the probe reports state: "absent" and incorrectly demotes the node when no Playwright cache or legacy /usr/bin/chromium wrapper exists. Add /snap/bin/chromium to the Linux system-binary candidates so the working browser is probed.

Suggested change

	"/usr/bin/chromium",
	"/snap/bin/chromium",
	"/usr/bin/chromium",

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/environment/BrowserCapabilityProbe.ts around line 31:

On Ubuntu hosts using the Chromium Snap, the probe reports `state: "absent"` and incorrectly demotes the node when no Playwright cache or legacy `/usr/bin/chromium` wrapper exists. Add `/snap/bin/chromium` to the Linux system-binary candidates so the working browser is probed.

[macroscopeapp]

🟡 Medium environment/BrowserCapabilityProbe.ts:48

When PLAYWRIGHT_BROWSERS_PATH is set to "0" and the hermetic Chromium is the only browser available, this probe returns absent (or incorrectly degraded when a system Chromium exists), causing capability-based dispatch to demote the node. The condition at line 48 discards Playwright's hermetic-install marker and scans only the OS cache; resolve node_modules/playwright-core/.local-browsers for this mode as well.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/environment/BrowserCapabilityProbe.ts around line 48:

When `PLAYWRIGHT_BROWSERS_PATH` is set to `"0"` and the hermetic Chromium is the only browser available, this probe returns `absent` (or incorrectly `degraded` when a system Chromium exists), causing capability-based dispatch to demote the node. The condition at line 48 discards Playwright's hermetic-install marker and scans only the OS cache; resolve `node_modules/playwright-core/.local-browsers` for this mode as well.

[macroscopeapp]

🟠 High

t3code/apps/server/src/vcs/GitVcsDriverCore.ts

Line 991 in 14b8c38

yield* fetchRemoteForStatus(cacheKey.gitCommonDir, cacheKey.remoteName);

Status refreshes still mutate refs/remotes/* outside repoGitLocks, so a concurrent fetchRemoteForStatus can race with resolveRemoteTrackingCommit and reproduce the ref-read failure. Protect fetchRemoteForStatus with the same per-repository semaphore before running its fetch.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/vcs/GitVcsDriverCore.ts around line 991:

Status refreshes still mutate `refs/remotes/*` outside `repoGitLocks`, so a concurrent `fetchRemoteForStatus` can race with `resolveRemoteTrackingCommit` and reproduce the ref-read failure. Protect `fetchRemoteForStatus` with the same per-repository semaphore before running its `fetch`.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces a production browser-capability probe used for automated node demotion, changes version and Git concurrency behavior, and adds a static-analysis suppression directive. Unresolved detection gaps and a remaining Git ref-race risk further warrant human validation.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}