# Local DevOps/Security Journey - 2026-03-17

**Perspective**: DevOps or security engineer evaluating Stella Ops as a replacement for custom CI/CD scripts and partial deployment-security tooling.

**Method**
- Fresh local compose runtime using `devops/compose/docker-compose.stella-ops.yml`
- Browser-driven walkthrough with local Playwright automation and screenshot capture
- Minimal document pre-read; product understanding driven primarily by the running system and only enough local documentation to frame the intended architecture

**Environment**
- Date: 2026-03-17
- Host: local developer machine
- Login used: `admin / Admin@Stella2026!`
- Screenshot artifacts: `output/playwright/`

---

## Baseline Findings Recorded Before Deeper Pass

### Runtime readiness
- The product shell is reachable at `https://stella-ops.local`.
- The gateway does not reach full ready state on fresh startup:
  - `/health` returns `ready:false`
  - missing microservice: `vexhub`
- `stellaops-vexhub-web` crashes on startup migration with:
  - `relation "vexhub.vex_sources" does not exist`
- This contaminates VEX-dependent surfaces and means the first-run product experience is already partially broken before a user begins meaningful work.

### Welcome and first-run positioning
- Root navigation lands on `/welcome`.
- The welcome page is visually sparse and brand-heavy:
  - `RELEASE CONTROL PLANE`
  - `ENCRYPTED IDENTITY PIPELINE`
  - `Sign In`
- It does not explain:
  - what Stella replaces in an existing pipeline
  - what the first operator action should be
  - how a user with Docker/Compose or script-based delivery should approach adoption

### First authenticated landing
- Successful login lands on `/mission-control/board`.
- The dashboard shell is broad and polished, but the first impression is mixed:
  - strong top-level information architecture
  - unclear relationship between demo/seed data and real operational state
  - limited guidance on the next concrete action for a fresh install

### First-round product observations
- `/setup` is the strongest onboarding surface found so far because it groups the right domains and exposes a first-time path.
- `/setup/integrations` is one of the clearest product areas because it explains setup order in operator language.
- `/setup/integrations/registries` has a concrete onboarding wizard with useful hints such as Harbor health probing and `AuthRef` secret indirection.
- `/security/scan` accepts an image submission (`alpine:3.19`) and shows a scan ID, but the scan remains `PENDING` without enough user-facing explanation.
- `/ops/policy/vex` renders a real user-facing failure:
  - `VEX Hub error: 503`
- `/docs` explains Stella's value proposition better than `/welcome` or the dashboard.

### Initial product-shaping concerns
- Internal Stella terminology appears before user value is established.
- Demo-like metrics are mixed with honest empty-state data.
- Some surfaces feel operationally credible; others feel seeded or disconnected.
- The product is easier to understand once inside Setup, Integrations, Release, Evidence, and Docs than it is from the initial welcome and dashboard journey.

---

## Investigation Status
- Baseline recorded.
- Deeper route and workflow pass completed for this session.
- Primary breadth artifact: `output/playwright/route-survey-20260317.json`
- Issue screenshots: `output/playwright/deep-route-survey/`
- Focused flow screenshots: `output/playwright/deep-flows/`
- Action-pack artifacts:
  - `output/playwright/action-packs/setup-admin-actions-20260317.json`
  - `output/playwright/action-packs/security-release-actions-20260317.json`
  - `output/playwright/action-packs/evidence-ops-admin-actions-20260317.json`
  - `output/playwright/action-packs/integrations-release-shell-actions-20260317.json`
  - `output/playwright/action-packs/topology-policy-actions-20260317.json`
  - `output/playwright/action-packs/focused-run-actions-20260317.json`
  - `output/playwright/action-packs/micro-run-actions-20260317.json`

---

## Route Survey Summary

### Coverage
- 88 authenticated routes surveyed in a single logged-in browser session.
- Route families covered:
  - Mission Control
  - Setup and Admin
  - Integrations
  - Topology
  - Security
  - Triage
  - Releases
  - Policy
  - Evidence
  - Operations
  - Console Admin
  - User Preferences
  - Docs
  - 403 and 404 recovery pages

### Survey outcomes
- 88 routes loaded without browser-level navigation exceptions.
- 16 routes mutated URL after initial render or otherwise failed the simple stability check.
- 4 routes returned hard HTTP errors from product APIs during normal page load:
  - `/setup/identity-providers` -> 403
  - `/security/risk` -> multiple 404s
  - `/security/unknowns` -> 404
  - `/ops/policy/vex` -> 503
- Several additional routes completed render while background requests aborted or context requests dropped.

### Important interpretation note
- The route survey used one authenticated browser session because replaying saved auth state did not reliably restore protected-route access.
- When a route looks broken in this note, it reflects either:
  - a product/runtime defect confirmed by response codes or clear user-facing error text
  - or a UX/data credibility issue visible to a fresh user
- The `vexhub` startup failure remains an environment contaminant for all VEX-backed flows.

---

## What The Product Teaches Well

### Setup is the strongest self-learning area
- `/setup` does the best job of explaining the system in operator-facing chunks:
  - identity
  - trust
  - integrations
  - topology
  - notifications
  - usage
  - system settings
- The first-time path is visible and sensible.
- The page explains that setup is a journey, not just a card wall.

### Integrations are close to adoptable
- `/setup/integrations` explains setup order well.
- `/setup/integrations/registries` is particularly strong:
  - clear 6-step flow
  - concrete hints for Harbor
  - good secret-handling guidance via `AuthRef`
  - scoped, practical inputs instead of vague platform terminology
- This is one of the few areas that already feels like it could replace bespoke onboarding docs for a real platform team.

### System Settings and Security Data are understandable
- `/setup/system` correctly frames itself as a handoff surface into health, doctor, SLO, and jobs instead of pretending to be the health system itself.
- `/setup/security-data` is concrete and operator-legible:
  - advisory sources
  - mirror
  - Trivy DB
  - version locks
- These pages are examples of Stella working well when it uses plain task language.

### Release, evidence, and operational shells are structurally good
- `/releases/promotions/create` clearly communicates the promotion model:
  - identity
  - target
  - inputs
  - gates
  - approvals
  - launch
- `/evidence/verify-replay` is one of the clearest evidence surfaces because it shows:
  - request replay
  - replay list
  - quick verify
  - determinism framing
- `/ops/operations/doctor` has good information scent even without interaction depth in this pass.
- `/settings/user-preferences` is polished and easy to understand.

### Docs explain Stella better than the product entrypoint
- `/docs` immediately explains the intended buyer/operator:
  - non-Kubernetes container estates
  - Compose/hosts/VMs/scripted automation
  - security + evidence + release governance
- This page explains Stella's value proposition more effectively than `/welcome` or the dashboard.

---

## Core Product Problems Found In The Deeper Pass

### 1. Startup/readiness defects contaminate the first-run story
- The local runtime never reached clean ready state because `vexhub` failed startup migration.
- The product shell remains usable enough to explore, but the user is already inside a partially broken system.
- This matters because Stella's value proposition is operational trust, and the first experience visibly breaks that promise.

### 2. The old route inventory is not reliable enough to be a learning aid
- One of the old-path routes, `/ops/platform-setup/topology-wizard`, bounced to `/welcome` in a fresh authenticated session.
- That confirms the user's instruction to treat prior route notes as referential only.
- A fresh operator cannot rely on hidden route knowledge; the product must teach the path from inside the UI.

### 3. Context propagation is inconsistent across the product
- Several routes drop `tenant` and `regions` from the URL entirely:
  - `/triage/artifacts`
  - `/evidence/verify-replay`
  - `/evidence/exports`
  - `/ops/operations/notifications`
  - `/ops/operations/dead-letter`
  - all `/console-admin/*`
  - `/settings/user-preferences`
  - `/docs`
- Some of those routes also show topbar context drift:
  - `REGION All regions`
  - `ENV No env defined yet`
  - `Policy: No baseline`
- Other pages in the same journey still show:
  - `TENANT Demo Production`
  - `REGION 4 regions`
  - `ENV All environments`
  - `Policy: Core Policy Pack latest`
- To a fresh user, this makes the platform feel internally inconsistent even when the page itself is not obviously broken.

### 4. Demo/seed behavior still leaks into critical operator judgments
- The product mixes strong, honest empty states with seeded operational-looking content.
- Example surfaces that look seeded or at least not grounded in this actual local session:
  - `/security/vulnerabilities` shows named CVEs with reachability/exceptions
  - `/releases/deployments` shows realistic deployment history rows
  - `/mission-control/alerts` and `/mission-control/activity` show plausible but unproven operational narratives
  - `/ops/operations/signals` shows five events and a 60% error rate
- Example surfaces that are honest-but-empty or clearly disconnected:
  - scans stay `PENDING`
  - audit log remains `0`
  - decision capsules say create a release first
- The inconsistency is the trust problem, not the existence of fixtures by itself.

### 5. Some pages are clearly broken in user-visible ways

#### `/setup/identity-providers`
- User-facing message:
  - `Failed to load providers`
  - `Identity Provider API error: Unknown error`
- Under the hood this is a 403 from `/api/v1/platform/identity-providers`.
- This is exactly the kind of page a new admin would try early in setup.

#### `/security/risk`
- Multiple 404s during page load:
  - `/authority/risk/risk/status`
  - `/authority/risk/risk`
  - `/api/gate/verdict`
  - `/api/risk-budget/kpis`
  - `/api/risk-budget/snapshot`
- This is not a subtle UX issue; it looks like an unimplemented or miswired feature surface.

#### `/security/unknowns`
- Still broken with scanner unknowns API 404.
- Fresh users see a real failure instead of a usable explanation or disabled state.

#### `/ops/policy/vex`
- Visible `503` because VEX Hub is down.
- The UI shows the failure, which is honest, but the product path is still broken.

#### `/console-admin/tenants`, `/console-admin/clients`, `/console-admin/tokens`
- These routes render headings and then remain in indefinite loading states:
  - `Loading tenants...`
  - `Loading OAuth2 clients...`
  - `Loading tokens...`
- That makes the whole Console Admin area feel half-connected.

### 6. Report and dashboard surfaces still blur posture, reporting, and action
- `/security/reports` exposes `Export CSV` and `Generate PDF`, which is better than the earlier first pass suggested, but the page still behaves like a security-posture workspace more than a true report center.
- `/security/reports` and `/security` share very similar content structure and headings.
- For a fresh user, the distinction between:
  - posture
  - report generation
  - evidence export
  is still not as crisp as it should be.

### 7. The scan flow still does not close the loop
- Submitting `alpine:3.19` creates a scan ID and moves to a progress view.
- The resulting status remained `PENDING` during this session.
- The page does not adequately explain whether:
  - the engine is intentionally simulated
  - the job is queued
  - or the scan path is not fully wired in local compose mode
- A technically competent evaluator reads this as "stuck" unless explicitly told otherwise.

### 8. Audit/evidence trust is undermined by a silent emptiness gap
- `/evidence/audit-log` still reports `0 Total Events (7d)`.
- The page even lists the kinds of actions that should appear automatically:
  - release seals
  - promotions
  - approvals
  - policy changes
  - VEX decisions
  - integration changes
- Given that the local product was actively used during this session, the empty audit log feels suspect, not reassuring.

---

## Route Family Notes

### Mission Control
- `/mission-control/board`
  - Broad shell is strong.
  - Still suffers from trust problems because its numbers and status cards are not obviously tied to anything the user has just done.
- `/mission-control/alerts`
  - Reads like a plausible operational summary.
  - Good copy, but not clearly tied to real local state.
- `/mission-control/activity`
  - Nicely grouped by release runs, evidence, and audit.
  - Again feels more like a prepared story than an earned activity stream.

### Setup And Admin
- `/setup`
  - Best first-time self-learning surface.
- `/setup/identity-access`
  - Useful and understandable.
  - Good explanation of least privilege and canonical clients/tokens.
- `/setup/trust-signing`
  - Better than expected in this pass.
  - Not empty; shows a meaningful overview with key counts and tabs.
- `/setup/notifications`
  - Strong distinction between setup-time configuration and operations-time runtime monitoring.
- `/setup/system`
  - Good "handoff, not verdict" framing.
- `/setup/security-data`
  - Good operator language and strong task grouping.
- `/setup/identity-providers`
  - Broken by 403.

### Integrations
- `/setup/integrations`
  - Strong overview and order guidance.
  - URL mutated after initial load; likely context injection, not a blocker by itself.
- `/setup/integrations/registries`
  - Wizard remains one of the strongest product flows.
- `/setup/integrations/runtime-hosts`
  - Late URL mutation, but page renders.
- `/setup/integrations/advisory-vex-sources`
  - Loaded with grouped categories and looked materially populated.
  - Late URL mutation observed.

### Topology
- `/setup/topology/overview`
  - Good information structure but it mutates URL after initial load.
  - Content still leans heavily on degraded/unknown status without enough explanation.
- `/setup/topology/map`, `/setup/topology/targets`, `/setup/topology/agents`
  - Similar late URL mutation pattern.
- Topology as a concept is present, but a fresh user still does not get a crisp "here is how you model your current Docker/host estate" guided path from the normal navigation alone.

### Security And Triage
- `/security`
  - Strong shell, but still fixture-heavy or trust-ambiguous.
- `/security/findings`
  - Weak compared with the rest of Security.
  - No clear heading in the route survey and the surface starts from a "no baseline recommendations" framing, which is not a first-time user's mental model.
- `/security/vulnerabilities`
  - Richer, but clearly showing seeded-looking CVE content.
- `/security/risk`
  - Broken.
- `/security/unknowns`
  - Broken.
- `/security/disposition`
  - Loaded in the route survey; not broken in that pass.
- `/triage/artifacts`
  - Still a compelling concept, but it drops URL context and therefore feels slightly detached from the rest of the scoped application shell.

### Releases
- `/releases/versions`
  - Good catalog framing.
- `/releases/runs`
  - Good concept and filters.
- `/releases/deployments`
  - Looks operationally real but likely fixture-backed.
- `/releases/approvals`
  - Honest empty state.
- `/releases/promotions`
  - Honest and well explained.
- `/releases/promotions/create`
  - Strong conceptual wizard.
- `/releases/bundles`
  - Good explanation of digest-first identity and validation gates.
- Release management as a category is one of Stella's clearest strengths.

### Policy
- `/ops/policy/overview`
  - Still a strong shell.
- `/ops/policy/governance` and `/ops/policy/simulation`
  - Loaded cleanly and present a serious operator-facing control plane.
- `/ops/policy/vex`
  - Broken by upstream runtime failure.
- Policy pages also show context drift through the topbar's `Policy: No baseline`, which clashes with other shells showing `Core Policy Pack latest`.

### Evidence
- `/evidence/overview`
  - Strong overview but context drift is visible.
- `/evidence/capsules`
  - Honest empty state: create a release first.
- `/evidence/verify-replay`
  - Strong concept surface but drops URL context.
- `/evidence/exports`
  - Useful structure, but also drops URL context and shows aborted background requests.
- `/evidence/audit-log`
  - Well explained, but the all-zero event story damages trust.

### Operations
- `/ops/operations`
  - Good summary shell.
- `/ops/operations/doctor`
  - Promising and informative.
- `/ops/operations/signals`
  - Reads like realistic ops data but may be seeded; trust ambiguity remains.
- `/ops/operations/feeds-airgap`
  - Good operator language and healthy-looking structure.
- `/ops/operations/notifications`
  - Strong separation from Setup Notifications, but it drops tenant/region context in the URL and topbar.
- `/ops/operations/data-integrity`
  - Interesting concept, but title duplication (`Data Integrity - StellaOps - StellaOps`) and aborted background requests make it feel less finished.
- `/ops/operations/health-slo`
  - Weak snapshot in this environment: no services available despite a clearly running system.
- `/ops/operations/dead-letter`
  - Functional shell, but context drift is again visible.

### Console Admin, User Preferences, Docs, Recovery Pages
- `/console-admin/*`
  - Mixed quality.
  - Branding works best.
  - Tenants/clients/tokens feel incompletely wired.
- `/settings/user-preferences`
  - One of the cleanest and most polished pages in the product.
- `/docs`
  - Best explanation of Stella's purpose.
- `/console/profile`
  - Good 403 page with sensible recovery links.
- `/nonexistent`
  - Good 404 page with recovery links.

---

## Action-Level Findings

### Shared shell controls are more real than the first pass suggested, but not always legible
- Global search behaves more like AI or knowledge retrieval than command navigation. Searching `scan` from User Preferences returned:
  - `Best answer`
  - `Related Questions`
  - `Ask AI`
  - knowledge snippets and endpoint references
- That behavior is useful, but it is a surprise if the user expects `Ctrl+K` or the shell search box to act like a route launcher.
- The region control is not a simple single-select picker. Toggling `EU West` from `REGION 4 regions` resulted in:
  - URL change to `regions=apac,us-east,us-west`
  - topbar change to `REGION 3 regions`
- The control appears to behave as a multi-select toggle, but the shell does not explain that model clearly.
- The window control works well. Selecting `7d` updated the topbar to `WINDOW 7d` and added `timeWindow=7d` to the URL.
- The stage control exposes `All / Dev / Stage / Prod`, but choosing `Prod` left the shell at `STAGE All`. This looks like a real state-application defect.
- Deep-link scope hydration is still inconsistent. In different authenticated runs:
  - `/releases/versions/new` loaded with `REGION All regions` and `ENV No env defined yet`
  - `/releases/promotions/create` loaded once with `REGION No regions defined`
  - later in-session navigation to the same routes kept the active `3 regions / All environments / 7d` scope correctly

### Setup and admin actions reveal some of Stella's strongest product design
- Guided setup entry works and feels approachable:
  - `Welcome to Stella Ops`
  - autodetection steps
  - simple "ready" state
- The weak point is that the autodetection copy is theatrical rather than informative. It does not tell the operator what was actually detected or what it means for next steps.
- Identity & Access is one of the strongest action surfaces in the product:
  - `Users` explains enrollment flow clearly
  - `Add User` opens an inline create form
  - `Roles` exposes built-in permissions in a way an operator can actually inspect
  - `OAuth Clients` and `API Tokens` explicitly explain that setup is read-only here and point the user to the canonical admin routes
  - `Tenants` shows a real, editable tenant row with suspend and branding actions
- Trust & Signing improves once actions are tried:
  - `Watchlist` opens a real workspace with tuning guidance, noisy-rule framing, and a return path to notifications
  - `Audit Log` opens and shows example trust events
- The weaker part of Trust & Signing is discoverability inside the overview. `Signing Keys`, `Trusted Issuers`, and `Certificates` did not obviously move the user out of the overview in action testing, while `Watchlist` and `Audit Log` clearly did.
- Setup Notifications and Ops Notifications are one of the best paired workflows in the product:
  - setup clearly owns lifecycle, templates, throttles, and routing design
  - ops clearly owns live delivery validation and test sends
  - both pages link to each other cleanly
- Console Admin Branding is another strong page:
  - practical token editing
  - live preview
  - safe, understandable scope
- Console Admin Tenants remains weak:
  - heading loads
  - `Create Tenant` button renders
  - body still says `Loading tenants...`

### Evidence and operations actions split cleanly into "genuinely useful" and "still suspicious"
- Export Center is one of the strongest true action surfaces in Stella.
- `Create Profile` opens a real modal with:
  - profile name
  - description
  - export format choices
  - include/exclude content switches
  - schedule options
- `Run Now` is not just decorative. It created a new completed export run and surfaced output details such as:
  - `StellaBundle (OCI referrer)`
  - completed run ID
  - output path under `/exports/...`
  - download action
- Audit Log `View All Events` works and exposes:
  - module filters
  - action filters
  - severity filters
  - date-range filters
- The trust problem remains: the event table still showed `0 events loaded` after extensive product use in this session.
- Doctor Diagnostics is one of the clearest examples of a real, valuable action path:
  - `Quick Check` ran successfully
  - result set was not a no-op
  - output showed `7 passed / 1 warnings / 1 failed / 5 skipped / 14 total / 1.1s`
- This is important because it proves at least some cross-service operator workflows are wired and useful in local mode.
- Replay & Verify still has a real action-level problem:
  - the page surfaces a visible `Start Verification` button
  - both locator-based and text-based attempts found the control
  - the button remained effectively unclickable because the element sat outside the usable viewport/drawer geometry
- That looks less like a missing feature and more like a layout or interaction defect in the quick-verify panel itself.
- The 403 and 404 recovery pages behave well once authenticated:
  - `Go to Dashboard` from `/console/profile` returns to Mission Control
  - `Go to Dashboard` from `/nonexistent` does the same

### Integrations, releases, and promotions hold up much better once actions are pushed
- The registry onboarding flow is stronger than the earlier route-only pass suggested.
- The wizard starts directly in `Connection & Credentials`, even though the stepper still shows:
  - `1 Provider`
  - `2 Connection`
  - `3 Scope`
  - `4 Schedule`
  - `5 Preflight`
  - `6 Review`
- That step numbering is slightly confusing because the provider choice is implicit rather than visibly completed.
- After filling:
  - endpoint
  - `AuthRef URI`
  - project / namespace
  the `Next` button enabled and advanced successfully into `Discovery Scope`.
- Discovery Scope uses a good guardrail:
  - repositories / namespaces / tag patterns are explicit
  - creation is blocked until at least one scope is defined
- Release creation also works once the form is driven by actual input placeholders instead of label-based automation:
  - filling release name, version, and target environment advanced from `Basic Info` to `Components`
  - this confirms the earlier failure was mostly selector/accessibility related, not a broken route
- Promotion creation is similarly real:
  - entering a release ID
  - clicking `Load Target Environments`
  advanced the flow to `Select Region and Environment Path`
- That means the release and promotion shells are not just static demos; they can be driven into later steps by a fresh operator.

### Topology and policy are more operational than the initial dashboard impression
- Topology Overview -> `Open Regions & Environments` works and lands on a usable region-first inventory page.
- The topology map has working zoom and reset controls, but not consistently:
  - `+` worked
  - `Reset` worked
  - `-` was not reliably clickable by visible text
- That suggests an accessibility or control-labeling issue, not a dead feature.
- Agent Fleet still has a control problem:
  - `Groups` and `All Agents` are visible
  - `All Agents` was not interactable in the action pass
- Policy studio top-level navigation works well:
  - `Governance`
  - `Simulation`
  - `Release Gates`
- Governance sub-tabs also work and expose meaningful content:
  - `Validator`
  - `Playground`
  - `Audit`
- The Governance page is more mature than it first appears. It exposes:
  - current risk-budget utilization (`72%`)
  - contributors
  - alerts
  - budget acknowledgements
- Simulation sub-tabs are also real:
  - `Console`
  - `Lint`
  - `Coverage`
  - `Promotion Gate`
- Several simulation actions do real work:
  - `Run Lint` returned a concrete lint result set with `1 error / 1 warning / 1 info`
  - `Run Tests` on Coverage did not materially change visible counters, which makes the action feel more like a refresh over seeded data
  - `Check Requirements` on Promotion Gate returned a real blocked state with actionable reasons
- Policy Lint is especially strong. It produced specific issues and suggested fixes, including:
  - missing explicit shadow target environment
  - coverage floor below the recommended baseline
  - operator override missing evidence reference
- Policy Promotion Gate is also credible:
  - blocked because shadow mode is not active
  - coverage passed
  - lint still has a blocking issue
  - security review passed
  - override path exists, with required reason capture
- Policy Simulation Console can be made to run if the operator provides actual input:
  - select policy pack
  - select SBOM
  - set environment
- After that, `Run Simulation` succeeded and returned:
  - `Completed 187ms`
  - `4 Total Findings`
  - `1 deny`
  - `3 warn`
  - one changed component under diff-versus-active policy
- Release Gates is less cohesive at the action layer:
  - clicking `Reachability` jumps out of the policy shell into `Security / Reachability`
  - `VEX` and `Freshness` are not directly clickable from the visible gate summary
- That cross-shell jump can be justified, but it weakens the "one operator shell" promise stated on the Policy overview.

### Action realism is now easier to separate from seeded behavior
- Actions that felt genuinely live in this session:
  - Doctor `Quick Check`
  - Export Center `Run Now`
  - registry wizard progression
  - release wizard progression
  - promotion target loading
  - policy lint
  - policy promotion requirement check
  - policy simulation console run
- Actions that still feel seeded, blocked, or trust-ambiguous:
  - audit log event counts
  - replay verification CTA geometry
  - policy coverage rerun
  - parts of the dashboard and reachability data

---

## Cross-Cutting UX / Product Findings

### FRESH-01 - Stella hides its adoption story behind docs instead of leading with it
Severity: HIGH

What a new technical user needs to learn immediately:
- what part of the current CI/CD pipeline stays in CI
- what Stella takes over
- how to start if they deploy with Compose, hosts, or scripts

Where Stella explains this well:
- `/docs`

Where Stella should explain this but does not:
- `/welcome`
- first authenticated landing on `/mission-control/board`

### FRESH-02 - Context is not trustworthy enough across shells
Severity: HIGH

Problems observed:
- some routes keep tenant/region query context
- some silently drop it
- some shift topbar state from concrete scope to `All regions / No env defined yet`
- policy indicator changes between `Core Policy Pack latest` and `No baseline`

Impact:
- makes deep links and mental model of scope unreliable
- especially damaging for evidence, ops, and admin surfaces

### FRESH-03 - Broken setup/security pages appear too early in the journey
Severity: HIGH

Broken or partially broken pages a new operator is likely to visit early:
- Identity Providers
- Risk
- Unknowns
- VEX
- Console Admin Tenants

Impact:
- creates the impression of unfinished product edges before the user reaches Stella's strongest capabilities

### FRESH-04 - Seed realism is a double-edged sword
Severity: HIGH

Positive:
- avoids a dead empty product
- helps pages look complete

Negative:
- makes it hard to know what Stella actually did during this session
- blurs the difference between seeded narrative and earned evidence

### FRESH-05 - Several pages mutate URL after initial render
Severity: MEDIUM

Affected route families include:
- integrations
- topology
- security
- operations

Likely cause:
- late context/state injection or route normalization

Impact:
- makes the product feel less deterministic than its messaging promises

### FRESH-06 - Some surfaces overuse Stella-internal wording
Severity: MEDIUM

Examples:
- Decisioning Studio
- canonical shell
- digest-first identity
- mutable VEX actions
- release-control plane

These terms are defensible after onboarding, but they arrive too early and too often for a first evaluator.

---

## Prioritized Backlog From This Session

### Critical / Immediate
1. Fix `vexhub` startup migration so local runtime reaches clean ready state.
2. Repair `/security/risk` so the page is not built on 404s.
3. Repair `/security/unknowns` or replace it with a truthful disabled/empty state.
4. Repair `/setup/identity-providers` so first-time admin setup does not hit a 403 dead end.
5. Fix or intentionally hide broken `/console-admin/tenants`, `/console-admin/clients`, and `/console-admin/tokens` loading states.

### High
1. Rewrite `/welcome` around adoption outcomes, not Stella-brand phrasing.
2. Make the dashboard teach the next action explicitly for first-time users.
3. Normalize tenant/region/policy context behavior across Evidence, Ops, Admin, Docs, and Triage.
4. Make seeded/demo content visibly labeled or switch more surfaces to honest empty state.
5. Explain scan simulation or queue semantics directly on `/security/scan` while local engines are incomplete.
6. Ensure audit log reflects actual local actions or clearly explain why it does not.
7. Fix the Replay & Verify quick-verify button so the visible CTA is actually clickable.
8. Clarify whether the shell search and `Ctrl+K` are route navigation, knowledge search, or AI answer surfaces.
9. Make deep-link scope hydration consistent on release and promotion routes.

### Medium
1. Reduce late URL mutation where possible.
2. Make `/security/findings` more legible for first-time use.
3. Sharpen the distinction between Security Posture, Security Reports, and Evidence Export.
4. Reduce duplicate or inconsistent topbar state such as `Policy: No baseline` versus `Core Policy Pack latest`.
5. Clean up low-fidelity details like the duplicated title on Data Integrity.
6. Make region selection semantics explicit; the control currently behaves like a multi-select toggle but reads like a single picker.
7. Fix the stage selector so choosing `Prod` or `Stage` actually applies to shell state.
8. Make the registry wizard's implicit provider step less confusing or reflect the true current step.
9. Ensure the Agent Fleet `All Agents` view switch is keyboard- and click-accessible.
10. Decide whether policy coverage reruns are computed live or fixture-backed and label that behavior clearly.

---

## Session Verdict

Stella Ops has enough depth that the product still looks serious after a much larger investigation. The strongest areas are:
- Setup
- Integrations
- Release Management
- Evidence / Replay
- Operations Doctor
- Docs

But the first-run experience still has too many trust-breaking edges for a fresh evaluator:
- startup not clean
- critical setup/security pages broken
- context drift across shells
- scan flow not closing
- audit story not matching real activity
- ambiguity about which data is real versus seeded

This deeper pass now has action-level evidence behind it. Stella is not failing because it lacks surface area; it is failing the first-time evaluation because too many of its genuinely strong workflows are hidden behind startup defects, inconsistent scope handling, and a few key trust-breaking action gaps. When the actions do work, the strongest parts of Stella are now clear:
- registry onboarding
- release and promotion progression
- export generation
- doctor diagnostics
- policy linting and promotion-readiness checks
- policy simulation with actual result output