stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity
Files
8e6cbeab97e558d21e99353a9c6fe9c72db56c81
git.stella-ops.org/docs/qa/LOCAL_DEVOPS_SECURITY_JOURNEY_20260317.md
master 8e6cbeab97 Polish UI across all route groups + redesign welcome page 
- Welcome: split-panel layout with Sign In always above fold, feature cards, trust badges
- Release Control: dashboard, releases, promotions, approvals — design token alignment
- Security: posture, findings, scan submit, unknowns, reports — compact tables, severity badges
- Operations: ops hub, jobengine, scheduler, doctor, notifications, feeds — consistent styling
- Audit & Evidence: evidence overview, audit log, export center, replay — shimmer loading
- Setup & Admin: topology, integrations, identity, trust, system — hover lift, focus rings
- Shared: buttons, tabs, forms, colors — unified design tokens (btn-primary, tab-active, focus-ring)
- Archive 3 completed sprints (SPRINT_20260317_001/002/003)
- Add QA journey reports and route map

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-18 00:04:38 +02:00

33 KiB
Raw Blame History

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