Reorganize cdsmcp workspace into docs, templates, and artifacts

Restructure the cdsmcp folder to separate operator guidance, reusable templates, and runtime artifacts into clearer top-level areas.

Move the VMware migration guide and run learnings into docs/, move vmw.yaml into templates/, move the existing log into artifacts/logs/, replace the old index file with a README, and split the former monolithic guide into focused documents for VMware MigrateOps workflow, VM lookup and FC/disk assignment, and CMC install reference.

Update internal references so the reorganized layout remains coherent without changing the underlying operational guidance.

cdsmcp/AGENTS.md

@@ -2,55 +2,51 @@
 
 This folder contains the VMware/vCenter + MigrateOps runbook for CDS MCP workflows.
 
-## Files
-- `esxvm.md`: index file only; points to guide and run-learnings docs.
-- `esxvm-guide.md`: authoritative workflow/rules/checklists/default behavior.
-- `esxvm-runs.md`: run-specific learnings, only when a run adds new information.
-- `vmw.yaml`: base template for `MIGRATEOPS_VMWARE_COMPUTE` operations.
+## Workspace Layout
+- `README.md`
+  - top-level navigation
+- `docs/vmware-migrateops-guide.md`
+  - authoritative VMware compute migration workflow
+- `docs/vm-lookup-and-assignment.md`
+  - VM lookup, datastore reporting, and FC/disk assignment workflow
+- `docs/cmc-install-reference.md`
+  - CMC install, uninstall, and reinstall fallback reference
+- `docs/run-learnings.md`
+  - run-specific learnings only when a run adds new information
+- `templates/vmw.yaml`
+  - base template for `MIGRATEOPS_VMWARE_COMPUTE` operations
+- `artifacts/logs/`
+  - runtime log artifacts kept separate from operator guidance
 
 ## Source Of Truth
-- Use `esxvm-guide.md` for how to execute runs.
-- Use `vmw.yaml` as the starting operation template.
-- Treat `esxvm-runs.md` as evidence/history, not baseline procedure.
+- Use `docs/vmware-migrateops-guide.md` for how to execute VMware compute migration runs.
+- Use `docs/vm-lookup-and-assignment.md` for VM lookup responses and FC/disk assignment requests.
+- Use `docs/cmc-install-reference.md` for CMC install/uninstall commands and fallback reinstall notes.
+- Use `templates/vmw.yaml` as the starting operation template.
+- Treat `docs/run-learnings.md` as evidence/history, not baseline procedure.
 
 ## Required Run Pattern
 1. Confirm source VM in vCenter and power state before IP/SSH actions.
 2. Prepare source host (CDC cleanup + CMC reinstall/registration) and verify source is connected in CDC.
-3. Validate preflight requirements from `esxvm-guide.md` (integration, access node, destination name, datastore/host/network, source NIC).
-4. Create MigrateOps from `vmw.yaml` with request-specific replacements.
-5. Monitor continuously and auto-approve cutover unless user requests manual approval.
+3. Validate preflight requirements from `docs/vmware-migrateops-guide.md`.
+4. Create MigrateOps from `templates/vmw.yaml` with request-specific replacements.
+5. Monitor continuously and auto-approve cutover unless the user requests manual approval.
 6. After terminal state:
-- validate destination login (poll guest IP if needed),
+- validate destination login,
 - archive operation,
 - run offline-host cleanup loop until source/helper cleanup conditions are satisfied,
 - provide final read-only status listing for source/destination/access/helper across CDC and vCenter.
-7. Ask user explicitly before deleting destination VM; never delete without same-run confirmation.
-
-## VM Lookup Requirement
-- Unless user explicitly asks otherwise, scope VM lookup/list responses to cluster `QACL-ATVMCypressONLY`.
-- For vCenter VM lookup requests, always include datastore name and VM notes/annotation in the response.
-
-## VM Disk And FC Assignment Requirement
-- For requests to assign disks and PCI passthrough FC adapters to a VM, use the workflow in `esxvm-guide.md`.
-- Always verify the VM, live ESXi host, and datastore first.
-- Default expected host is `192.168.1.165`, but verify live placement before planning.
-- Unless the operator explicitly specifies alternatives, default to planning these FC adapters:
-- `vmhba7` (`0000:85:00.0`)
-- `vmhba8` (`0000:85:00.1`)
-- Unless the operator explicitly specifies alternatives, default to planning these existing datastore disks:
-- `atvm-DISK_1.vmdk`
-- `atvm-DISK_2.vmdk`
-- The disks must be located in the same datastore as the VM under the `atvm-DISKS` directory.
-- If the default or operator-specified adapters or disks are missing, do nothing and report that no assignment will be performed.
-- Always provide a read-only summary of findings and planned assignment, then wait for explicit approval before any change.
-
-## Update Rules
-- Update `esxvm-guide.md` only when workflow/rules/default behavior changes.
-- Update `esxvm-runs.md` only when a run reveals a new learning/failure pattern/required check.
-- Keep `esxvm.md` as a lightweight index.
+7. Ask the user explicitly before deleting the destination VM; never delete without same-run confirmation.
 
 ## Environment Defaults
 - vCenter: `192.168.0.201`
-- Cluster scope: `QACL-ATVMCypressONLY` unless user overrides.
+- Cluster scope: `QACL-ATVMCypressONLY` unless user overrides
 - Default CDC project: `Skidamarink`
 - Default access node: `atvm-linux-h2h`
+- Default ATVM target reference: `192.168.3.191`
+
+## Update Rules
+- Update `docs/vmware-migrateops-guide.md` only when migration workflow/default behavior changes.
+- Update `docs/vm-lookup-and-assignment.md` only when lookup/assignment workflow behavior changes.
+- Update `docs/cmc-install-reference.md` only when install or reinstall reference behavior changes.
+- Update `docs/run-learnings.md` only when a run reveals a new learning/failure pattern/required check.