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¶

V3 production routes under /v3-prod/* are the migration target.
/v3/* mock routes stay available for visual comparison until production parity is accepted.
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¶

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, Swagger console, and Redoc reference.	Stoplight Elements integration remains a deferred post-migration task.
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¶

Keep route-map, cutover docs, and E2E smoke aligned as each remaining V1 URL is retired.
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.
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.
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.
Record any remaining V1 fallback as a named V3 task. Do not patch V1 unless it blocks internal demo continuity.
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.

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 replace Headlamp/Kubernetes UI during this migration; research task is deferred.
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.
/v3 mock and /v3-prod production 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.