You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,23 @@ All notable changes to Viaduct should be documented in this file.
4
4
5
5
This changelog tracks published releases and the major implementation milestones that shaped the current repository state.
6
6
7
+
## [1.6.0] - Unreleased
8
+
9
+
### Workspace-First Operator Flow
10
+
- added a first-class pilot workspace model that persists source connections, discovery snapshots, dependency graph output, target assumptions, readiness results, saved plans, approvals, notes, and exported reports
11
+
- added tenant-scoped API routes for listing, creating, updating, and exporting pilot workspace state without introducing a parallel product surface
12
+
- added persisted background jobs for workspace discovery, graph generation, simulation, and plan generation so the operator workflow can survive page refreshes and produce reproducible state
13
+
14
+
### Dashboard And Auth Bootstrap
15
+
- reworked the dashboard so the first operator experience is create workspace, discover, inspect, simulate, save plan, and export report
16
+
- added runtime dashboard authentication bootstrap using service-account or tenant keys instead of relying on build-time-only configuration
17
+
- strengthened loading, empty, retry, and request-correlation-aware error handling across the workspace flow
18
+
19
+
### Lab, Contract, And Release Surface
20
+
- added a deterministic `examples/lab` end-to-end smoke flow for workspace creation through report export
21
+
- updated the published OpenAPI contract, quickstart flow, lab assets, configuration guidance, and operator docs to match the new workspace APIs and runtime auth flow
22
+
- added v1.6.0 release-note draft material and release-facing screenshot assets for the workspace-first operator application
The sample config already points the KVM source at the local lab fixtures.
27
+
The lab config points the KVM source at the local fixture set. For any non-demo environment, configure `state_store_dsn` and use PostgreSQL for persistence.
This seeds the deterministic service-account key `lab-operator-key`.
66
+
41
67
## 6. Start The Dashboard
42
68
43
69
```bash
@@ -46,7 +72,11 @@ npm ci
46
72
npm run dev
47
73
```
48
74
49
-
The dashboard expects the API at `/api` and can use `VITE_VIADUCT_API_KEY` from [web/.env.example](web/.env.example) when tenant-scoped access is enabled.
75
+
The dashboard expects the API at `/api` and opens on the pilot workspace route. The first screen is a runtime auth bootstrap flow.
76
+
77
+
Authenticate with:
78
+
-`Service account`: `lab-operator-key`
79
+
-`Tenant key`: `lab-tenant-key`
50
80
51
81
For normal dashboard and pilot use, prefer `VITE_VIADUCT_SERVICE_ACCOUNT_KEY`. Keep `VITE_VIADUCT_API_KEY` for tenant bootstrap or break-glass admin access.
52
82
@@ -62,7 +92,28 @@ Use the tenant key only when you are bootstrapping the tenant or intentionally u
Copy file name to clipboardExpand all lines: README.md
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,13 +12,14 @@ Broadcom's VMware licensing changes forced many teams into urgent platform decis
12
12
## Project Status
13
13
Viaduct is ready for broad evaluation, design-partner pilots, and community contribution. The repository includes multi-platform discovery, dependency graphing, declarative migration orchestration, warm-migration primitives, lifecycle remediation, backup portability, multi-tenancy with service accounts and quota controls, plugin hosting, a web dashboard, a standalone public site, reproducible release packaging, and a shared release gate for CI and local verification.
14
14
15
-
The current early-product wedge is VMware-exit mixed-estate discovery and migration readiness assessment with approval-ready pilot planning. Discovery, planning, operator visibility, and packaged evaluation are the strongest current surfaces. Live execution paths should still be validated in a lab or pilot environment before they are treated as routine production automation.
15
+
The current early-product wedge is VMware-exit mixed-estate discovery and migration readiness assessment with approval-ready pilot planning. Discovery, planning, operator visibility, and packaged evaluation are the strongest current surfaces. The default dashboard path is now a first-class pilot workspace that keeps source connections, snapshots, graph output, readiness results, saved plans, approvals, notes, and report exports in one operator-owned record. Live execution paths should still be validated in a lab or pilot environment before they are treated as routine production automation.
16
16
17
17
## Supported Capabilities
18
18
- Discovery engine: Collects normalized inventory from VMware, Proxmox, Hyper-V, KVM, Nutanix, and Veeam-related backup systems into a universal schema.
19
19
- Dependency mapping: Builds graph views across workloads, networks, storage, and backup relationships to support safer migration planning.
- Lifecycle analysis: Evaluates cost, policy, and drift, then turns those signals into remediation guidance and simulation output.
22
+
- Pilot workspace workflow: Ties together assessment state, source connections, discovery baselines, readiness simulation, saved plans, operator notes, approvals, and exported reports.
22
23
- Multi-tenancy and extensibility: Provides tenant-scoped API access, service-account and role-based access controls, persistent state backends, and a gRPC-based plugin host for community connectors.
23
24
- Operator surfaces: Exposes the same core workflows through a CLI, REST API, and React dashboard.
24
25
- Operability: Ships request correlation, tenant-scoped audit and reporting routes, Prometheus-style metrics, an OpenAPI reference, deployment examples, and packaged release metadata.
@@ -45,7 +46,7 @@ See [docs/architecture.md](docs/architecture.md) for the detailed architecture v
The local KVM lab under [examples/lab](examples/lab) gives you a first-run workflow without needing a live hypervisor. Start with [QUICKSTART.md](QUICKSTART.md) for the top-level guide or [docs/getting-started/quickstart.md](docs/getting-started/quickstart.md) for the detailed walkthrough.
63
64
65
+
For the workspace-first dashboard flow, bootstrap the lab tenant and service account from `examples/lab/`, then authenticate through the dashboard's runtime bootstrap screen. The full operator path is documented in [docs/operations/pilot-workspace-flow.md](docs/operations/pilot-workspace-flow.md).
66
+
64
67
## Build And Test
65
68
```bash
66
69
go mod tidy
@@ -83,6 +86,7 @@ make release-gate
83
86
- Quickstart: [QUICKSTART.md](QUICKSTART.md)
84
87
- Upgrade: [UPGRADE.md](UPGRADE.md)
85
88
- Release process: [RELEASE.md](RELEASE.md)
89
+
- Pilot workspace flow: [docs/operations/pilot-workspace-flow.md](docs/operations/pilot-workspace-flow.md)
Copy file name to clipboardExpand all lines: RELEASE.md
+8-3Lines changed: 8 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,15 +10,18 @@ This document describes the stable packaging and release process for Viaduct.
10
10
-`make plugin-check`: validate plugin manifest compatibility against the host version
11
11
-`make contract-check`: verify the published OpenAPI reference still covers the stable operator routes
12
12
13
+
On Windows, `make release-gate` still builds `bin/viaduct.exe`, but it validates the CLI smoke commands through a LocalAppData-staged `go run ./cmd/viaduct` helper because some operator workstations enforce Application Control policies that block freshly built unsigned binaries from direct execution or from `%TEMP%`.
14
+
13
15
## Release Checklist
14
16
1. Ensure the working tree is in the intended state and public docs are current.
15
17
2. Run `make release-gate`.
16
18
3. Inspect the generated bundles in `dist/`.
17
19
4. Verify `release-manifest.json`, `dependency-manifest.json`, and `SHA256SUMS.txt`.
18
20
5. Smoke-test the packaged binary with `viaduct version` and `viaduct --help`.
19
-
6. Confirm install docs, upgrade docs, rollback docs, and deployment examples still match the artifact layout.
20
-
7. Verify the plugin manifest check and OpenAPI contract check remain green.
21
-
8. Tag and publish only after the verification and smoke checks are clean.
21
+
6. Confirm install docs, upgrade docs, rollback docs, deployment examples, and the pilot workspace guide still match the artifact layout.
22
+
7. Confirm the release notes draft, changelog entry, and screenshot assets are present and aligned with the shipped workflow.
23
+
8. Verify the plugin manifest check and OpenAPI contract check remain green.
24
+
9. Tag and publish only after the verification and smoke checks are clean.
22
25
23
26
## Bundle Contents
24
27
The release bundle should include:
@@ -37,6 +40,8 @@ The standalone public site under [`site/`](site/README.md) is published through
37
40
- summarize operator-visible changes
38
41
- document compatibility, migration, or upgrade concerns
39
42
- call out any connector-specific caveats
43
+
- include the workspace-first operator flow and runtime-auth bootstrap changes when they are part of the release
44
+
- include current screenshot assets when the dashboard experience changed materially
40
45
- update [CHANGELOG.md](CHANGELOG.md) with notable release information
@@ -38,4 +39,7 @@ This directory contains the detailed Viaduct documentation set. The repo-root do
38
39
## Historical Roadmaps
39
40
-[Roadmap Archive Index](roadmaps/README.md)
40
41
42
+
## Release Drafts
43
+
-[Release Draft Index](releases/README.md)
44
+
41
45
If you are starting from the repository landing page, also see [../INSTALL.md](../INSTALL.md), [../QUICKSTART.md](../QUICKSTART.md), [../UPGRADE.md](../UPGRADE.md), and [../RELEASE.md](../RELEASE.md).
For the local lab, the only required source is the built-in KVM fixture path:
33
+
For the local lab, the config only needs the built-in KVM fixture path. For a persistent pilot environment, configure `state_store_dsn` and use PostgreSQL.
34
+
35
+
## 3. Start The API And Seed Auth
32
36
33
-
```yaml
34
-
sources:
35
-
kvm:
36
-
address: "examples/lab/kvm"
37
+
```bash
38
+
export VIADUCT_ADMIN_KEY=lab-admin
39
+
./bin/viaduct serve-api --port 8080
37
40
```
38
41
39
-
## 3. Run Discovery
42
+
In another terminal, create the lab tenant and operator service account:
This loads the sample XML fixtures, normalizes them into the universal schema, and saves a snapshot to the configured state store.
46
-
47
-
## 4. Inspect A Migration Spec
58
+
## 4. Start The Dashboard
48
59
49
60
```bash
50
-
./bin/viaduct plan --spec examples/lab/migration-window.yaml
61
+
cd web
62
+
npm ci
63
+
npm run dev
51
64
```
52
65
53
-
This validates the example spec and shows the execution window, approval gate, and wave-planning shape that Viaduct will use.
66
+
Open the dashboard in your browser at the Vite URL shown in the terminal. The dashboard proxies API calls to `http://localhost:8080`and opens on the pilot workspace route.
54
67
55
-
## 5. Start The API And Dashboard
68
+
Authenticate through the runtime bootstrap screen:
For packaged or persistent environments, prefer `VITE_VIADUCT_SERVICE_ACCOUNT_KEY` over `VITE_VIADUCT_API_KEY` so operator activity is attributable to a named service account instead of the tenant-wide admin credential.
58
73
59
-
```bash
60
-
./bin/viaduct serve-api --port 8080
61
-
```
74
+
## 5. Run The Workspace-First Operator Flow
62
75
63
-
In another terminal:
76
+
1. Create the first pilot workspace from the prefilled lab defaults.
77
+
2. Run discovery to save workspace snapshots.
78
+
3. Inspect the workload table and dependency graph.
79
+
4. Run readiness simulation.
80
+
5. Save the migration plan.
81
+
6. Export the pilot report.
64
82
65
-
```bash
66
-
cd web
67
-
npm ci
68
-
npm run dev
69
-
```
83
+
The seeded API request body for the same intake is available in `examples/lab/pilot-workspace-create.json`.
70
84
71
-
Open the dashboard in your browser at the Vite URL shown in the terminal. The dashboard will proxy API calls to `http://localhost:8080`.
85
+
## 6. Optional CLI Corroboration
72
86
73
-
For local lab use, the default tenant may work without explicit credentials. For any real tenant-scoped dashboard usage, prefer `VITE_VIADUCT_SERVICE_ACCOUNT_KEY` over `VITE_VIADUCT_API_KEY` so operator activity is attributable to a named service account instead of the tenant-wide admin credential.
./bin/viaduct plan --spec examples/lab/migration-window.yaml
90
+
```
74
91
75
-
## 6. Explore Operator Flows
76
-
- Inventory and dependency views: confirm the lab workloads appear in the dashboard.
77
-
- Lifecycle views: review cost, policy, drift, and remediation panels.
78
-
- Migration planning: use the migration wizard to run preflight, create a migration, and inspect checkpoints.
79
-
- Tenant reporting and trust context: call `/api/v1/tenants/current` and `/api/v1/summary` with a service-account key if you want to validate multi-tenant flows without falling back to the tenant-wide admin credential.
92
+
This validates the same local fixture set through the CLI.
0 commit comments