# V3 Migration Execution Tracker v1 Status: active coordination document. This tracker keeps the migration focused on replacing V1 product workflows with V3 production workflows. Demo feedback is useful only when it exposes a V3 workflow gap. Do not keep patching V1 unless it is a demo/internal continuity blocker. ## Current Decision - Canonical product routes live under `/*`. - `/v3/*` mock/reference routes are retired from the current app tree. Historical docs may mention them only as migration evidence, not as active product surfaces. - V1 stays available only as an internal fallback while the remaining V3 workflows are completed. - Platform-control should not receive another V3 deployment until kind validates the next cutover slice. ## Migration Status 2026-05-17 wiring audit update: "Present" below means the V3 production route exists and is broadly API-wired. It does not mean the route is retire-ready. Retirement now requires the wiring, live-smoke, shell-containment, and placeholder/fallback gates in `doc/product/V3_UX_Wiring_Audit_v1.md`. | Area | V3 production status | Remaining work | |---|---|---| | Shell / navigation | Present and cutover-gated with global shell, family local nav, resource back links, documented journey rules, stable local-nav/back-link selectors, an automated route-inventory guard that fails if a legacy product page is neither mapped nor explicitly passed through, and an E2E navigation contract covering representative resource journeys. | Final visual polish and role/default landing validation. | | Workloads | Present with list, kind-aware detail, terminal/app-open, metrics, storage, tasks, unified lifecycle/event evidence, and allocation-detail compatibility resolver for V1 deep links. | Keep hardening null/partial telemetry and app proxy error handling from live kind findings. Backfill richer allocation task/audit stream if V1 allocation timelines still expose events absent from V3. | | Compute catalog / launch | Present with visual SKU cards and production submit handoff. | Ensure inline dependency creation and readiness errors stay actionable. | | Apps catalog / launch | Present with visual featured apps, tabbed app detail, production submit handoff, app runtime operations, member operations, version changes, operation history, safe runtime credential posture, and a project-scoped artifact workbench for publish/register/verify/promote/deprecate/revoke/retire. App runtimes land in the unified workload detail pattern. | Confirm scheduler/runtime app ordering and launch defaults for demo/local seed data. Add credential reconcile/rotate mutations once safe audited contracts exist. Add per-artifact detail/activity drawer only if operators need event history beyond the inventory actions. | | Storage | Present with WEKAFS-first protocol, sharing, grants, attachments, launch wizard, and bucket lifecycle/activity events from bucket posture, mounts, grants, and audit logs. | S3/STS validation remains blocked until WEKA S3 protocol hosts are available. | | Access | Present with memberships, service accounts, credentials, entitlements, project/user quota posture, connectivity, identity, and audit-backed lifecycle events for access-family mutations. | Future network/security, scoped quota writes, and SSO provider write workflows are follow-ups. | | Account | Present with profile, security, billing, sessions. | Full billing overhaul is a separate effort. | | Platform admin / ops | Present as workflow workbenches across Ops, Lifecycle, Config, Evidence, Finance, IAM, dedicated MAAS provisioning routes, first-class per-node activity/capabilities, first-class config lifecycle activity, first-class finance lifecycle activity, per-user IAM workflow detail, MAAS site write workflows, site-scoped direct/batch/discovery onboarding, and provisioning workflow diagnostics. | Validate against kind/live read models; convert any repeated V1 admin fallback into named V3 tasks. Final pass should reduce visual density on admin/operator drill-downs that still feel like data dumps. | | Notifications | Present as a v3 utility route. | Validate live notification retention/WS behavior after core migration. | | Developer docs / API reference | Present with docs portal, downloads, Stoplight Elements reference, Swagger fallback, and Redoc reference. | Keep Swagger as the interactive fallback until Stoplight try-it auth posture is explicitly designed. | | Schedulers | Present as guidance route. | Tenant-shared pilot URLs cut over to the unified schedulers guide until runtime contracts settle. | ## Active Work | Lane | Current owner | Work | |---|---|---| | B-ui | B | Available for next non-overlapping V3 UI migration or polish task. | | C-ops | Codex | V3 migration inventory, route-map/doc alignment, and remaining workflow gaps. | | A-backend | available | Only pick non-overlapping backend/read-model gaps found during kind validation. | ## Next Sequence 1. Keep route-map, cutover docs, and E2E smoke aligned as each remaining V1 URL is retired. 2. Treat lifecycle operation framing as the V3 default for mutable resources. The shared affordance has been applied to the high-risk migrated surfaces: nodes, app runtimes, MAAS sites/profiles, platform config, storage, app artifacts, finance, IAM, quotas, and MAAS fabric assignments. New mutable work must use the same setup/update/maintenance/recovery/destructive/evidence shape instead of isolated action buttons. 3. Validate kind with the V3 default flag: - user workload list/detail, - compute launch, - app launch to task/workload, - browser terminal/app proxy path, - storage attach/read model, - platform ops/lifecycle/config/evidence/finance/IAM, - MAAS site setup, direct one-node onboarding, batch onboarding, discovery onboarding, onboarding detail, decommission/reimage detail, install-output diagnostics, MAAS-event pivots, and cancel/retry controls. 4. Close the remaining migration gaps by category: - backend read models for resource activity/capabilities where V3 currently derives history from facts, tasks, or workflow cards. Node detail and app runtime detail now have first-class activity/capability contracts, storage bucket detail now has a first-class lifecycle event stream, platform config exposes audit-backed activity rows, Access audit exposes membership/service-account/credential/entitlement/identity/connectivity audit events, and Finance now exposes payment-session, ledger, refund, and finance-audit lifecycle rows. - Access/identity/network/security write workflows once contracts exist, - app runtime credential reconcile/rotate mutations without exposing private material, - final UX polish for pages that still feel like data dumps after workflow parity is complete. 5. Record any remaining V1 fallback as a named V3 task. Do not patch V1 unless it blocks internal demo continuity. 6. After kind is stable, decide separately whether to promote to platform-control. ## Resource Lifecycle Coverage Lifecycle and evidence coverage is tracked in `doc/product/V3_Resource_Lifecycle_Evidence_Pattern_v1.md`. Any migrated V3 resource detail should expose current posture, lifecycle activity, and evidence pivots. If the current read model lacks a first-class event stream, derive an activity view from available tasks/workflows/facts now and create a backend read-model follow-up instead of hiding lifecycle in raw tables. Mutable resources must also expose lifecycle operations by intent. Button-only clusters are not enough for V3 retirement. Each operation should describe its preconditions, result, progress surface, failure/compensation path, and evidence pivot. Use that standard before adding more page-specific action controls. Initial implementation is in progress via the shared `LifecycleOperationCard` primitive. Applied surfaces now include node detail operations, MAAS site connection/settings, platform config SKU/image setup/update workflows, and app-backed workload runtime operations including pause/resume/restart/repair/decommission, member scale/drain/remove, version change, and operation history. Storage detail now frames attach/mount, direct-access credential issuance, and lifecycle policy changes as explicit operations, with S3 credential actions hidden unless the provider advertises S3, and its Events tab stitches bucket, attachment, grant, and audit activity into a single timeline. App artifact publish/register plus verify/promote/deprecate/revoke/retire are also framed as lifecycle workflows. Finance support credit/refund recovery and platform IAM role/membership updates now use the same operation framing. Finance also has a first-class lifecycle stream for payment sessions, ledger postings, refund requests, and finance audit actions without exposing provider payment references or raw webhook payloads. Quota policy changes, MAAS provisioning profiles, and MAAS fabric assignments are also operation-framed and platform config now has audit-backed activity rows, so platform setup/maintenance has preconditions, result, failure, and evidence visible before and after mutation. Destructive V3 actions now use typed confirmation instead of browser confirm for node removal/delete and app runtime decommission. Access audit now exposes scoped lifecycle history for membership, service-account, credential, entitlement, identity, and connectivity mutations. Continue applying the same operation-card model to access/service-account write workflows when those mutation contracts become available. ## V1 Workflow Parity Coverage Detailed V1 to V3 workflow parity is tracked in `doc/product/V3_V1_Workflow_Parity_Audit_v1.md`. Treat that audit as the source for deciding whether a V1 fallback is still a missing V3 workflow or an intentional retirement. Do not mark V1 retired until every parity row is either covered, explicitly deferred, or replaced by a named backend/read-model task. Production wiring and placeholder/fallback status is tracked in `doc/product/V3_UX_Wiring_Audit_v1.md`. Treat it as the current gate for deciding whether a V3 page is actually retire-ready after the Pomerium/old-proxy work, because a page can exist and still fail shell containment, live routing, or real-data checks. ## Navigation And Journey Coverage Navigation and return-path behavior is tracked in `doc/product/V3_Navigation_Journey_Contract_v1.md`. Every migrated V3 family with multiple sibling pages should use the shared local-nav pattern, and every drill-down/detail route should expose a stable `ResourceHeader` back target. Do not add one-off back buttons or rely on browser history as the only exit. ## Workflow Consolidation The next migration pass is governed by `doc/product/V3_Workflow_Consolidation_Plan_v1.md`. The recordings from 2026-05-01 showed that broad route parity is no longer the main risk; the risk is carrying V1 admin/entity-dump behavior into V3. Workloads, node onboarding, node lifecycle operations, platform setup, SSH-key prerequisites, app runtime identity, and console/cert recovery must be treated as workflow surfaces before V1 can be retired. ## Immediate Non-Goals - Do not redesign billing inside this migration. - Do not solve Netdata nginx-edge routing inside the V3 UI migration. - Do not implement WEKA S3/STS until S3 protocol hosts are enabled and validated. - Do not build a bespoke Kubernetes UI during this migration. Headlamp support is now tracked as a Pomerium-backed RKE2 console slice in `doc/architecture/Headlamp_RKE2_Pomerium_Integration_v1.md`. - Do not delete V1 route files until the route map and E2E guardrails prove no internal workflow depends on them. ## Done Criteria For V1 Retirement - V3 production route exists for every intentional user/admin/ops workflow. - The cutover route map covers every retired V1 route explicitly. - Default frontend E2E validates V3 workflows and cutover behavior. - V1 E2E is compatibility-only and opt-in. - Historical `/v3` mock pages and canonical product pages are close enough that reviewer feedback no longer depends on mock-only behavior. - Any repeated operator need on a V1 admin page is represented as a V3 workflow/read-model task.