Inspect environment state and routing before you guess.
Polystro exposes environment resolution and routed hostname state as explicit product surfaces. That matters because preview failures are often not browser bugs or agent bugs. They are environment drift, missing overrides, or service routing mismatches.
Environment Surface
The Environment panel is a workstream tool, not a hidden config file viewer. It lets you inspect the resolved variables currently attached to the selected workstream and see where each value came from.
Instead of wondering whether a value came from a repo file, a workstream override, or a service-specific override, you can inspect the resolved result directly inside the shell.

Profiles and Scopes
The panel supports profile switching for common environments like development, staging, production, and test. That gives you a faster way to inspect how one workstream behaves under different runtime assumptions before you start changing files by hand.
Global scope
Use global overrides when a value should apply across the whole desktop runtime.
Workstream scope
Use workstream overrides when one repo needs different values from the rest of your local setup.
Service scope
Use service overrides when only one routed service should change without mutating the entire workstream.
Resolved source tracking
The Environment panel shows where the winning value came from so you can avoid duplicate or conflicting overrides.
Diagnostics and Diff
The diagnostics tab exists for first-run and drift debugging. It can surface missing variables, compare the current environment against a template, and point to values that should be added as overrides.
The diff tab compares the current resolved environment with the global baseline, which is useful when a workstream behaves differently from the rest of your machine and you need to see exactly what changed.
Use this before blaming the preview
Routing Overview
Routing Overview is the cross-workstream dashboard for stable local hostnames. It shows which services exist, which routed hosts they own, which actual ports they currently map to, their runtime status, and how many environment overrides are attached at the workstream and service level.
That makes it the fastest way to answer questions like "which workstream owns this hostname?", "did the service move ports?", or "is the preview route broken or is the service simply not running?"
First Preview Debug
This is the shortest useful loop when a preview does not load or loads the wrong behavior the first time.
Open the workstream environment
Check the resolved values for the current workstream before changing files or restarting services.
Compare diagnostics and diff
Look for missing template keys, unexpected overrides, or values that differ from the global baseline.
Open Routing Overview
Confirm the routed hostname, actual backing port, service status, and whether service-specific overrides exist.
Return to the preview browser
Retest from the integrated browser so the workstream route and browser identity stay attached to the same context.
Recommended Debugging Loop
Open the Environment panel
Confirm the values you expect are actually resolved in the current workstream and profile.
Check Diagnostics and Diff
Look for missing template keys, changed values, or overrides that should be moved to the right scope.
Open Routing Overview
Verify the routed hostname, service status, actual port, and whether the workstream has service-specific overrides.
Return to the preview
Once the environment and route look correct, test again from the integrated browser so identity state stays attached too.
Run the services workflow
Go back to the service task flow for scan, launch, logs, and preview handling.
Review the broader settings surface
See where CLI behavior, browser settings, notifications, and worktree defaults live.
Start from symptoms
Use the troubleshooting index when you know what feels broken but not which product surface owns the fix.