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>
This commit is contained in:
master
@@ -0,0 +1,102 @@
|
||||
# Sprint 20260317-001 - Local Journey Deep Dive
|
||||
|
||||
## Topic & Scope
|
||||
- Run a fresh-install local product journey from the perspective of a DevOps or security engineer evaluating Stella Ops as a replacement for custom CI/CD and deployment-security scripts.
|
||||
- Capture concrete UX defects, broken flows, confusing terminology, and credibility gaps between demo fixtures and real operations.
|
||||
- Write repo-tracked QA notes with route-level evidence and screenshot artifacts so follow-up product work is auditable.
|
||||
- Working directory: `docs/qa`.
|
||||
- Expected evidence: local compose runtime checks, route survey notes, Playwright screenshots under `output/playwright/`, and a dated QA deep-dive note.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on the local compose stack in `devops/compose/docker-compose.stella-ops.yml`.
|
||||
- Safe to run in parallel with backend/frontend implementation work because this sprint is docs-only; findings must reference observed runtime defects without reverting or masking active code changes.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/README.md`
|
||||
- `docs/ARCHITECTURE_OVERVIEW.md`
|
||||
- `docs/modules/platform/architecture-overview.md`
|
||||
- `docs/qa/feature-checks/FLOW.md`
|
||||
- `docs/code-of-conduct/TESTING_PRACTICES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### DOCS-JOURNEY-01 - Capture baseline fresh-install findings
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: QA
|
||||
Task description:
|
||||
- Record the first-pass local findings already confirmed during the initial fresh-install walkthrough so the deeper investigation can build on a stable baseline.
|
||||
- Include environment readiness observations, startup defects, onboarding impressions, and the first set of product-surface findings that shaped the deeper test plan.
|
||||
|
||||
Completion criteria:
|
||||
- [x] A dated QA note exists in `docs/qa/` for the 2026-03-17 journey.
|
||||
- [x] The note records the initial runtime defect set and first-run UX observations.
|
||||
|
||||
### DOCS-JOURNEY-02 - Execute deeper workflow investigation
|
||||
Status: DONE
|
||||
Dependency: DOCS-JOURNEY-01
|
||||
Owners: QA
|
||||
Task description:
|
||||
- Continue the local journey with significantly broader and deeper coverage across onboarding, setup, integrations, topology, scanning, release creation, policy, evidence, operations, docs, and cross-cutting UX.
|
||||
- Favor user-task continuity over route counting: identify whether a new technical operator can discover what to do next, understand what is real versus seeded, and move from setup to secure promotion without prior tribal knowledge.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The note captures a materially expanded surface review with route families, flow depth, and concrete defects.
|
||||
- [x] The note distinguishes runtime breakage from UX/product-shaping issues.
|
||||
- [x] The note records artifact locations for screenshots or other captured evidence.
|
||||
|
||||
### DOCS-JOURNEY-03 - Produce prioritized follow-up backlog
|
||||
Status: DONE
|
||||
Dependency: DOCS-JOURNEY-02
|
||||
Owners: QA
|
||||
Task description:
|
||||
- Distill the deeper investigation into an actionable backlog for product and platform teams.
|
||||
- Separate startup/runtime blockers, adoption blockers, trust/credibility issues, and lower-severity UX polish so future implementation work can sequence correctly.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The QA note contains a prioritized defect and product-gap backlog.
|
||||
- [x] Sprint Decisions & Risks link to the final note and highlight any environment contamination risks.
|
||||
|
||||
### DOCS-JOURNEY-04 - Execute action-level product exploration
|
||||
Status: DONE
|
||||
Dependency: DOCS-JOURNEY-02
|
||||
Owners: QA
|
||||
Task description:
|
||||
- Move beyond route loading and exercise visible user actions across the main product shells.
|
||||
- Focus on actions a real evaluator would try:
|
||||
- setup and onboarding CTAs
|
||||
- tab switches
|
||||
- filters and search
|
||||
- create/test/replay/export buttons
|
||||
- wizard progression
|
||||
- context and preference controls
|
||||
- Record which actions work, which fail, and which are technically successful but confusing.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The QA note contains action-level findings across core product areas.
|
||||
- [x] At least the highest-value flows have concrete interaction evidence, not just route snapshots.
|
||||
- [x] New blockers or confusing action chains are separated from previously known route-level defects.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-17 | Sprint created for deeper local fresh-install journey review; baseline findings captured and deeper route/flow pass started. | QA |
|
||||
| 2026-03-17 | Deep route survey completed across 88 authenticated routes; expanded QA note written with route-family findings, context drift analysis, runtime blockers, and prioritized backlog. | QA |
|
||||
| 2026-03-17 | Sprint reopened for action-level exploration across visible UI controls, wizards, filters, and task chains. | QA |
|
||||
| 2026-03-17 | Added action-pack evidence across Setup/Admin, Security/Release, Evidence/Ops/Admin, Integrations/Release/Shell, Topology/Policy, and focused run-actions; QA note expanded with action-level findings and backlog updates. | QA |
|
||||
|
||||
## Decisions & Risks
|
||||
- Working directory remains `docs/qa`; screenshot artifacts are captured under `output/playwright/` and referenced from the QA note.
|
||||
- The local runtime is not fully healthy: `vexhub` fails startup migration (`relation "vexhub.vex_sources" does not exist`), so VEX- and readiness-dependent flows must be interpreted with contamination risk.
|
||||
- `src/Web/AGENTS.md` is missing. This does not block docs-only QA notes, but it is a coordination gap for future module-scoped autonomous work touching the web application.
|
||||
- Primary note target: `docs/qa/LOCAL_DEVOPS_SECURITY_JOURNEY_20260317.md`
|
||||
- Action evidence now includes:
|
||||
- `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`
|
||||
|
||||
## Next Checkpoints
|
||||
- Convert the highest-confidence action failures into product/engineering implementation tickets.
|
||||
- Re-run the journey after `vexhub` startup migration is fixed to separate environment contamination from product UX defects.
|
||||
@@ -0,0 +1,63 @@
|
||||
# Sprint 20260317-002 - Journey Problem Clusters Action Report
|
||||
|
||||
## Topic & Scope
|
||||
- Turn the three local journey reports into a grouped action report that is suitable for engineering planning.
|
||||
- Correlate observed UX/runtime failures with code paths, route contracts, scope policies, and local gateway behavior.
|
||||
- Separate confirmed code defects from product-model gaps and from findings that now appear stale or partially fixed.
|
||||
- Working directory: `docs/qa`.
|
||||
- Expected evidence: one dated grouped report in `docs/qa/` with root causes, solution options, and recommended sequencing.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on `docs/implplan/SPRINT_20260317_001_DOCS_local_journey_deep_dive.md`.
|
||||
- Safe to execute in parallel with implementation work because this sprint is docs-only; it must not revert or mask active code changes.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/README.md`
|
||||
- `docs/qa/JOURNEY_NOTES_20260316.md`
|
||||
- `docs/qa/DEEP_JOURNEY_UX_FINDINGS_20260316.md`
|
||||
- `docs/qa/LOCAL_DEVOPS_SECURITY_JOURNEY_20260317.md`
|
||||
- `AGENTS.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### DOCS-JOURNEY-CLUSTERS-01 - Correlate journey findings to technical causes
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: QA, Project Manager
|
||||
Task description:
|
||||
- Read the three journey reports together instead of in isolation, identify recurring failures, and check the active code paths that back them.
|
||||
- Favor planable outcomes over route narration: each recurring problem should either have a confirmed root cause, a narrowed hypothesis, or an explicit "likely stale" disposition.
|
||||
|
||||
Completion criteria:
|
||||
- [x] The grouped analysis covers the three journey reports.
|
||||
- [x] The analysis distinguishes confirmed defects from lower-confidence product or UX hypotheses.
|
||||
- [x] The analysis records concrete code or route evidence for the highest-impact items.
|
||||
|
||||
### DOCS-JOURNEY-CLUSTERS-02 - Publish dense action report
|
||||
Status: DONE
|
||||
Dependency: DOCS-JOURNEY-CLUSTERS-01
|
||||
Owners: QA, Project Manager
|
||||
Task description:
|
||||
- Publish a dense action-oriented report that groups the journey problems into clusters suitable for backlog creation.
|
||||
- For each cluster, include observed symptoms, technical cause, solution options, and a recommended path or sequencing note.
|
||||
|
||||
Completion criteria:
|
||||
- [x] A dated report exists in `docs/qa/`.
|
||||
- [x] The report includes grouped problem clusters, solution options, and recommended execution order.
|
||||
- [x] The sprint Decisions & Risks section links to the report.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-17 | Sprint created to convert the local journey reports into a grouped action report. | QA |
|
||||
| 2026-03-17 | Correlated runtime, route, scope, context, audit, and UX findings with active web, platform, router, timeline, authority, scanner, and VexHub code paths. | QA |
|
||||
| 2026-03-17 | Published grouped action report with root causes, solution options, and recommended sequencing. | QA |
|
||||
|
||||
## Decisions & Risks
|
||||
- Primary output: `docs/qa/JOURNEY_PROBLEM_CLUSTERS_ACTION_REPORT_20260317.md`
|
||||
- This sprint is analysis-only. It does not change runtime behavior; some findings remain subject to local-environment contamination, especially VEX-related flows while VexHub startup is broken.
|
||||
- Several findings from the 2026-03-16 reports appear partially fixed in current code. The grouped report marks those separately so follow-up planning does not duplicate already-landed work.
|
||||
|
||||
## Next Checkpoints
|
||||
- Convert the P0/P1 recommendations from the grouped report into implementation sprints by owner area: VexHub, Web, Router, Platform, Timeline/Audit, and Product UX.
|
||||
- Re-run the full local journey after the clean-start and contract fixes land to confirm which trust and discoverability gaps remain.
|
||||
@@ -0,0 +1,230 @@
|
||||
# Sprint 20260317-003 — Journey Problem Cluster Fixes
|
||||
|
||||
## Topic & Scope
|
||||
- Implement all P0, P1, and P2 fixes identified in the Journey Problem Clusters Action Report (`docs/qa/JOURNEY_PROBLEM_CLUSTERS_ACTION_REPORT_20260317.md`).
|
||||
- Covers VexHub migration repair, gateway route fixes, scope alignment, audit normalization, stage persistence, posture error tracking, navigation vocabulary, command palette, scan UX, welcome page, and release flow clarity.
|
||||
- Working directories: `src/VexHub/`, `src/Web/`, `src/Platform/`, `src/Timeline/`, `devops/compose/`.
|
||||
- Expected evidence: all three C# services build clean (0 warnings), TypeScript compiles clean (no new errors), all journey cluster items addressed.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on `docs/implplan/SPRINT_20260317_002_DOCS_journey_problem_clusters_action_report.md` (analysis).
|
||||
- No upstream sprint blockers — all changes are self-contained.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/qa/JOURNEY_PROBLEM_CLUSTERS_ACTION_REPORT_20260317.md`
|
||||
- `AGENTS.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### P0-1 - VexHub migration mismatch repair
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Migration 002 references `vexhub.vex_sources` but 001 creates `vexhub.sources`.
|
||||
- Added `003_fix_source_backoff_columns.sql` with `IF NOT EXISTS` for idempotency.
|
||||
- Added `ConsecutiveFailures` and `NextEligiblePollAt` properties to `VexSource.cs`.
|
||||
- Added EF column mappings in `VexHubDbContext.cs`.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Migration 003 exists and uses correct table name
|
||||
- [x] EF model has backoff column mappings
|
||||
- [x] VexHub service builds clean (0 warnings, 0 errors)
|
||||
|
||||
### P0-2 - Console-admin gateway route
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Frontend calls `/console/admin/*` but gateway had no explicit route, causing requests to fall through to Platform (404).
|
||||
- Added `/console/admin` → `authority.stella-ops.local/console/admin` route before the generic `/console` route.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Gateway config has `/console/admin` route with correct specificity ordering
|
||||
|
||||
### P0-3 - Unknowns path fix (client + gateway)
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Web client called `/api/v1/scanner/unknowns` but scanner exposes `/api/v1/unknowns`.
|
||||
- Changed client base URL to `/api/v1/unknowns`.
|
||||
- Added gateway route `^/api/v1/unknowns(.*)` → scanner service.
|
||||
- Updated test script references.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Client uses `/api/v1/unknowns`
|
||||
- [x] Gateway has explicit unknowns route
|
||||
- [x] No stale `scanner/unknowns` references in `src/Web/`
|
||||
|
||||
### P0-4 - Identity Providers scope fix
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Backend requires `platform.idp.admin` scope but `stella-ops-ui` client didn't include it.
|
||||
- Added `platform.idp.read` and `platform.idp.admin` to `allowed_scopes` in `04-authority-schema.sql`.
|
||||
- Added both scopes to the OIDC `scope` string in `config.json`.
|
||||
|
||||
Completion criteria:
|
||||
- [x] SQL seed includes IDP scopes
|
||||
- [x] Web config requests IDP scopes during login
|
||||
|
||||
### P0-5 - Risk dashboard URL construction
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Client built risk URLs from `authorityBase + '/risk'` → double-pathed `/authority/risk/risk/status`.
|
||||
- Changed `app.config.ts` to use gateway base and `/api/risk`.
|
||||
- Removed duplicate `/risk` prefix from all `risk-http.client.ts` endpoint paths.
|
||||
|
||||
Completion criteria:
|
||||
- [x] `RISK_API_BASE_URL` resolves to `/api/risk` via gateway
|
||||
- [x] No duplicate `/risk/risk` paths in client
|
||||
|
||||
### P1-1 - Audit module normalization + Authority source
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- `NormalizeModule` mapped "evidencelocker"→"sbom" and "notify"→"integrations" (wrong).
|
||||
- Fixed to preserve original module names.
|
||||
- Added `evidencelocker` and `notify` to the known modules catalog.
|
||||
- Fixed hardcoded module labels in `HttpUnifiedAuditEventProvider`.
|
||||
- Added Authority audit fetcher (`/console/admin/audit`) as a new source.
|
||||
- Wired `AuthorityBaseUrl` config in `Program.cs`.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Module names are 1:1 with actual modules
|
||||
- [x] Authority audit events are fetched
|
||||
- [x] Timeline service builds clean
|
||||
|
||||
### P1-2 - Stage persistence full chain
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Stage was tracked in web store but never sent to backend or persisted in DB.
|
||||
- Added `Stage` to `PlatformContextPreferencesRequest` and `PlatformContextPreferences`.
|
||||
- Added stage to SQL upsert in `PlatformContextService.cs`.
|
||||
- Added EF model property and column mapping.
|
||||
- Added `stage` to `buildPreferencesPayload()` in TypeScript store.
|
||||
- Created migration `059_UiContextPreferencesStage.sql`.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Stage round-trips: web store → API → DB → API → web store
|
||||
- [x] Platform service builds clean
|
||||
- [x] Migration file exists and is embedded
|
||||
|
||||
### P1-3 - Security posture degraded-data tracking
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- `SecurityRiskOverviewComponent` used `catchError(() => of([]))` silently converting API failures to zeros.
|
||||
- Added 5 per-source error signals and a `hasDegradedData` computed signal.
|
||||
- Each `catchError` now sets its error signal before returning the fallback.
|
||||
- Error signals are cleared on each load cycle.
|
||||
- Added degradation banner in template.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Per-source error tracking in place
|
||||
- [x] Degradation banner shows when any source fails
|
||||
- [x] TypeScript compiles clean
|
||||
|
||||
### P2-1 - Rename Triage to Findings in navigation
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Changed top-level nav group label from "Triage" to "Findings".
|
||||
- Updated breadcrumb display text for `/triage/` segments.
|
||||
- Left route paths and internal IDs unchanged.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Navigation shows "Findings" instead of "Triage"
|
||||
- [x] Breadcrumbs show "Findings"
|
||||
- [x] No route path changes
|
||||
|
||||
### P2-2 - Command palette plain scan search
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Plain text "scan" returned no quick actions (only `>` prefix did).
|
||||
- Added `inlineMatchedActions` signal for mixed-mode results.
|
||||
- Plain text queries now show matching quick actions above search results.
|
||||
- Fixed scan quick action routes: `scan` and `scan-image` now route to `/security/scan` instead of triage pages.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Typing "scan" shows quick actions + search results
|
||||
- [x] Scan actions route to `/security/scan`
|
||||
- [x] Keyboard navigation works across both sections
|
||||
|
||||
### P2-3 - Scan local-mode limitation messaging
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Scan UI waited 60 polls (~3 minutes) before showing any explanation.
|
||||
- Added `pollCount` signal, `scanInProgress` and `showQueueHint` computed signals.
|
||||
- Immediate info banner on scan start explains local-mode queue behavior.
|
||||
- After 10 polls (~30s), a queue hint banner appears with link to Jobs Engine.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Info banner visible immediately after scan submission
|
||||
- [x] Queue hint appears after ~30 seconds
|
||||
- [x] Both banners disappear on scan completion
|
||||
|
||||
### P2-4 - Post-seal promotion CTA
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Sealing a release didn't explain that promotion is the next step.
|
||||
- Added explanation text distinguishing sealing from deployment.
|
||||
- Added primary "Request Promotion" button linking to `/releases/promotions/create` with `releaseId` pre-filled.
|
||||
- Demoted secondary links (view promotions, back to versions) to outline style.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Post-seal section explains sealing vs. promotion
|
||||
- [x] "Request Promotion" CTA with pre-filled release ID
|
||||
- [x] Visual hierarchy: primary CTA > secondary links
|
||||
|
||||
### P2-5 - Welcome page operator adoption rewrite
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Welcome page was brand-heavy with generic chips. Didn't explain what Stella does for operators.
|
||||
- Added "Get Started" journey: Connect Registry → Scan Artifact → Governed Release → Promote with Evidence.
|
||||
- Added "What Stella Replaces" section: manual scripts → policy-gated promotions, scattered scans → unified posture, trust-me deploys → verifiable evidence.
|
||||
- Kept sign-in button, docs link, auth notice, and existing layout structure.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Welcome page answers "what do I stop scripting?" within 20 seconds
|
||||
- [x] Four concrete first steps visible
|
||||
- [x] Before/after value props visible
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-17 | Sprint created from Journey Problem Clusters Action Report. | Developer |
|
||||
| 2026-03-17 | P0 items implemented in parallel (5 agents): VexHub migration, gateway routes, IDP scope, unknowns path, risk URL. All verified — 3 C# services build clean, TS compiles clean. | Developer |
|
||||
| 2026-03-17 | P1 items implemented in parallel (3 agents): audit normalization + Authority source, stage persistence full chain, posture degraded-data tracking. All verified — builds clean. | Developer |
|
||||
| 2026-03-17 | P2 items implemented in parallel (5 agents): Triage→Findings rename, command palette scan fix, scan local-mode messaging, post-seal promotion CTA, welcome page rewrite. All verified — TS compiles clean. | Developer |
|
||||
|
||||
## Decisions & Risks
|
||||
- VexHub migration 003 uses `IF NOT EXISTS` for idempotency — safe on both fresh and partially-migrated databases.
|
||||
- IDP scope changes only take effect on fresh DB (INSERT ON CONFLICT DO NOTHING). Existing deployments need manual `allowed_scopes` update or volume reset.
|
||||
- Authority audit endpoint (`/console/admin/audit`) response shape was inferred from ConsoleAdminEndpointExtensions — may need runtime verification.
|
||||
- Risk dashboard: the gateway route exists for `/api/risk/*` but some dashboard summary endpoints (`/api/risk/status`, `/api/risk/aggregated-status`) may not exist in the backend yet. The URL construction is now correct, but 404s may persist until backend endpoints are implemented.
|
||||
- Welcome page content is operator-focused but may need product review for messaging alignment.
|
||||
- Pre-existing TS error in `trust-score-config.component.spec.ts:234` is unrelated to this sprint.
|
||||
|
||||
## Next Checkpoints
|
||||
- Rebuild affected Docker images (vexhub, platform, timeline, router-gateway, console).
|
||||
- Reset DB volume and verify fresh-start VexHub health.
|
||||
- Run full local journey re-test to confirm fixes resolve the reported issues.
|
||||
- Product review of welcome page copy and Findings/Triage vocabulary decision.
|
||||
Reference in New Issue
Block a user