ANKRA NEXT / OPERATIONS & NODES — NODES REDESIGN V2 14 October 2026 Open index.html or run node serve.mjs (http://127.0.0.1:4194). 87 linked frames: 50 redesigned Nodes, 33 Operations views, and 4 shared evidence/access states. Eight journey shortcuts start from the operator's task. Search, chapter filters, keyboard navigation, linked actions, zoom, SVG downloads and PDF export follow the main storyboard index format. EXPLORABLE OPERATION STEPS 21 linked step details across failed monitoring, its running retry, GitOps validation, inventory, ingress and node-group scaling. Every displayed step opens its own recorded result, timing, scoped output and resource evidence. The step rail, dependencies, previous/next links and return-to-operation link are interactive. Waiting steps explain why no output exists; accepted writes and resource health remain separate. Steps run no infrastructure commands. WHAT CHANGED The original Nodes chapter treated nodes as Kubernetes records with a maintenance flow. Ankra also owns the machines: provider instances, groups, control planes, bastions and independent VMs. This revision puts that whole lifecycle into the Nodes workspace, with different views when the provider or another controller owns the infrastructure. THE EIGHT JOURNEYS 1. Know the fleet: provider and Kubernetes inventory, ownership, zone topology. 2. Add capacity: Pending workloads, compatible groups, count, quota, price, review, provisioning and separately observed usable capacity. 3. Resolve provisioning: provider running versus not joined; timed SSH probes, cloud-init availability, bastion path, scoped Ankra investigation. 4. Manage groups: fixed count versus autoscaling, quota ceiling, labels/taints, zonal storage, GPU placement, instance upgrade, blocked scale-down, multiple staged changes and partial-write recovery. 5. Maintain a worker: conditions, requests versus usage, workloads, disruption budgets, reviewed cordon, receipt and separate return to scheduling. 6. Control plane: independent count and size capabilities, rolling three-node resize, offline count change, quorum and Kubernetes version upgrade. 7. Bastion and VMs: access-path diagnosis, gated bastion resize, private VM creation, independent VM lifecycle, data-aware removal review. 8. Ownership variants: managed pools, UKS external autoscaler, explicit ownership handback, imported clusters and split-source read failures. SOURCE BASIS Visual: signed-in live Ankra Next shell inspected 14 October 2026; dark Ink, 224px rail, 56px top bar, quiet surfaces, row collections and exception colour. Capabilities: portal origin/develop 35cfefc21d35dc6baeee29e081d336614fc75a4c; cluster origin/develop d38a92b91edf927d5b1c66b868768e2dd21ad449; Ankra cloud-clusters, managed-kubernetes and platform-principles skills. Relevant portal source under src/implementations/clusters/cluster/imported/ [clusterId]/nodes/: NodesOverview, nodesSectionConstants, FleetTable, NodeGroupsPanel, ControlPlanePanel, VmsPanel, AddVmDialog, MaxOutControl, standaloneVms, provisioningProgress and ZoneHealthCard. Related settings/nodes/: NodeGroupCard, NodeGroupsSaveAll, controlPlaneCapabilities, node-group update and provider capability readers. Related kubernetes/nodes/[name]/: node profile, GPU metrics and pod readers. CAPABILITY BOUNDARIES This is a storyboard, not deployed product functionality. All names, readings, prices and operation IDs are sample data, not live pricing or infrastructure. Provider catalogue choices and eligible versions must be discovered per account. A GPU example is a separate GPU-capable OVH context; it is not an assertion that the UpCloud example offers that hardware. UKS does not expose Ankra-managed autoscaling: its external controller owns count when marked so. Existing Ankra capabilities ground groups, fixed scaling, bounds, quota reads, placement settings, provider inventory, provisioning evidence, control-plane capabilities, bastion diagnosis/resize and standalone VM lifecycle. PROPOSED UI / CONTRACT WORK - Join workload scheduler reasons, placement and disruption evidence into a capacity or maintenance review, with provenance and fresh validation. - Present multi-group drafts and partial submissions without implying atomicity. - Carry the correct scoped evidence into an Ask draft; sending remains explicit. - Provide fresh accepted-versus-observed receipts for every lifecycle action. - Standalone durable PDB-aware drain still needs backend work (ankra-b6t0n9). The current Classic browser pod-delete loop is NOT this safe drain contract. The blocked maintenance scene illustrates the desired flow; no false shipped drain or automatic force bypass is claimed. SOURCE OF TRUTH AND SAFETY Show the actual owner and configuration source. Git-backed persistent settings need the reviewed source-change path; provider/runtime operations must record which Ankra definition and action they change. Do not promise universal Git writeback for endpoints that do not return it. Match node identity, refresh capabilities and ownership, and revalidate before submission. Accepted count, provider allocation, Kubernetes readiness and workload recovery are separate. A zone-spread control plane is not proof of application resilience. Provider Running is not node Ready. Cordon is not drain; uncordon is not a rebalance. VMs and bastions are not unready Kubernetes nodes. Unknown cost is not zero. Rebuild: node scripts/build.mjs Verify/export: node scripts/verify.mjs (serve.mjs running on port 4194) Version 1 is preserved in ../ankra-operations-nodes-v1/.