Architectural Prompt Engineering

This page documents the Architectural Prompt designed for xcsh (xcsh -p). Entering this prompt into a clean xcsh session instructs the LLM to generate the entire modular Terraform codebase for this deployment — including the root module, all six child modules, the tenant environment guard script, and the cloud-init bootstrap YAML — with zero external memory cache or Python generator scripts.

Overview & Optimization Results

Observed 2026-08-05. Optimization statistics:

Through automated autoresearch iterations benchmarked against xcsh -p, terraform init -backend=false, terraform validate, and terraform plan, the prompt was compressed and optimized:

• Original Baseline Prompt: 8,249 characters
• Final Optimized Prompt: 4,783 characters (42.0% character reduction)
• Plan Equivalence: Generates 54 files producing a valid 62-resource terraform plan.

For the plain-English, human-readable specification of these architectural requirements, see the Engineering Specification.

Why filename lists are omitted in Section 6

Earlier versions explicitly enumerated all 38 file paths. Autoresearch proved that xcsh -p infers and writes the complete modular file layout when supplied with exact HCL resource and schema triggers (such as namespace = "" on data sources, private_ip_address_allocation on NICs, and network_option.site_local_network on XC sites), saving 2,000+ characters.

---

The Engineered Prompt

Copy and paste the prompt below into a clean xcsh session:

Act as an expert F5 Distributed Cloud (XC) and Microsoft Azure Infrastructure-as-Code architect.

Write the complete, modular, production-grade Terraform codebase under `terraform/` for an Active/Active eBGP/ECMP F5 XC Customer Edge (Secure Mesh v2) deployment on Azure with a parallel Canadian regional extension.

### Core Architectural Specifications

1. **Versions & Providers** (`versions.tf`, `providers.tf`):
   - Terraform CLI `>= 1.10.0`.
   - Providers: `f5-sales-demo/xcsh` (`>= 3.81.1`, setting `api_url = local.xc_api_url` derived from
     `var.expected_xc_tenant` -> `https://${var.expected_xc_tenant}.console.ves.volterra.io`),
     `azurerm` (`~> 4.0`, features {}, subscription_id), `azuread` (`~> 3.0`),
     `external` (`~> 2.3`), `random` (`~> 3.0`).
   - Partial backend: `backend "azurerm" {}` with `backend.hcl.example`.

2. **Tenant Guard & Safety Checks** (`data.tf`, `main.tf`, `scripts/xc-env-tenant.sh`):
   - Executable script `scripts/xc-env-tenant.sh` (`chmod +x`) outputs `{"tenant":"<label>","api_url_set":"<bool>"}`
     from `XCSH_API_URL`.
   - `data "external" "xc_env_tenant"` with `lifecycle { postcondition }` asserting `self.result.tenant` matches
     `var.expected_xc_tenant` (`f5-sales-demo`).
   - Checks: `check "vip_outside_vnet_cidrs"` (`var.vip` `10.250.0.10` outside `10.0.0.0/16` and `10.1.0.0/16`) &
     `check "ca_vip_outside_vnet_cidrs"` (`var.ca_vip` `10.250.1.10` outside `10.200.0.0/16`).

3. **Cloud-Init** (`cloud-init/ce-node.yaml`):
   - `#cloud-config` writing `/etc/vpm/config.yaml` (`0600`, root:root) with `Vpm` (`ClusterType: ce`,
     `ClusterName: ${cluster_name}`, `Token: ${token}`, `MauriceEndpoint: https://register.ves.volterra.io`,
     `MauricePrivateEndpoint: https://register-tls.ves.volterra.io`,
     `CertifiedHardwareEndpoint: https://vesio.blob.core.windows.net/releases/certified-hardware/azure.yml`)
     & `Kubernetes` (`EtcdUseTLS: true`, `Server: vip`, `CloudProvider: disabled`).
   - Renders `/var/home/admin/.ssh/authorized_keys` (`0600`, admin:admin).

4. **Modules** (`modules/`):
   - `ce-topology`: Expands `ce_count` (1..3) -> `hostname` (`<prefix>-0<n>`),
     `site_name` (`<prefix>-<region>0<n>`), `slo_ip` (`cidrhost(mgmt_prefix, 4+i)`), `az` (1..3),
     `interface_name`
     (`ves-io-securemesh-site-v2-`
      `<site_prefix>-<region>0<n>-`
      `network-<hostname>-0<n>-eth0-0`).
   - `azure-hub`: RG `rg-<component>-<deployer>` (`<deployer>` from Azure AD 4-tier fallback in `locals.tf`),
     VNet `hub-vnet`, subnets (`snet-hub-management`, `snet-hub-external`, `snet-hub-internal`, `RouteServerSubnet` `/27`, `AzureBastionSubnet` `/26`),
     Azure Route Server (`<component>-rs`, ASN `65515`, Standard PIP), Bastion (`<component>-bastion`, `tunneling_enabled = true`, `ip_connect_enabled = true`).
   - `ce-node`: UserAssigned Identity, 3 NICs (mgmt/SLO, external, internal; IP forwarding on, accelerated networking off, `private_ip_address_allocation` Static for mgmt / Dynamic for external/internal),
     `azurerm_linux_virtual_machine`
     (`volterraedgeservices/`
      `volterra-node/volterra-node`,
      64GB `StandardSSD_LRS` OS disk,
      `custom_data = base64encode(cloud_init)`).
   - `xc-site`: `xcsh_securemesh_site_v2` (explicit eth0 interface in `azure.not_managed.node_list.interface_list` with `ethernet_interface` and `network_option.site_local_network` bound to mgmt NIC MAC,
     `terraform_data.ce_vm` parking VM instance ID for `lifecycle { replace_triggered_by = [terraform_data.ce_vm] }`), `data.xcsh_site_registration`, `xcsh_registration_approval` (when found), `xcsh_bgp` (CE ASN `64512`, RS ASN `65515`, peer port 179).
   - `azure-route-server-bgp`: `azurerm_route_server_bgp_connection` connecting Route Server to CE mgmt IP.
   - `client-vm`: Ubuntu test client in `snet-hub-internal` (`private_ip_address_allocation = "Dynamic"`).

5. **App Tier & Canada Extension**:
   - Token `xcsh_token.ce` (`mcn-ce-registration` in `system` namespace, no type argument), `data.xcsh_namespace.mcn` (`multi-cloud-networking`, `namespace = ""`), origin pool `xcsh_origin_pool.this` (`var.origin_ip:var.origin_port`),
     HTTP LB `xcsh_http_loadbalancer.this` (`mcn-ce-ha-f5se`, `domains = [var.lb_domain]`, `advertise_custom` VIP `10.250.0.10` on `SITE_NETWORK_OUTSIDE` per CE site, `depends_on = [module.xc_site]`).
   - Canada (`enable_canada = true`): Parallel Hub VNet (`10.200.0.0/16` in `canadacentral`), 3 CE VMs, Canada Route Server, BGP connections, Client VM, `xcsh_virtual_site` (`canada_re` cities `toronto`,`montreal` & `canada_ce`), Origin Pool & HTTP LB (`mcn-ce-ha.f5-sales-demo.ca` VIP `10.250.1.10/32`).

6. **Outputs**:
   - Export node maps, private/public IPs, route server IDs, BGP peer IPs, domain names, VIPs, sensitive `ce_registration_token` and `site_console_admin_passwords`.

Run `terraform fmt`, `terraform init -backend=false`, and `terraform validate` after creation.

---

How to Execute

To invoke prompt-driven generation:

# Run xcsh in print mode with the prompt content
xcsh -p "$(cat prompt.txt)"

Verification & Validation

After generation completes, verify the output codebase:

cd terraform

# 1. Format HCL
terraform fmt -recursive

# 2. Initialize provider plugins (no backend credentials required)
terraform init -backend=false

# 3. Validate syntax and constraints
terraform validate

# 4. Generate plan
terraform plan -var="origin_ip=203.0.113.10" -var="lb_domain=example.com"

---

Key Enforcements Encoded in the Prompt

Constraint / Pattern	Why it is explicitly enforced
f5-sales-demo/xcsh >= 3.81.1	Ensures xcsh_registration_approval derives passport server-side and xcsh_token exposes Computed uid.
data "external" "xc_env_tenant"	Executes scripts/xc-env-tenant.sh to enforce var.expected_xc_tenant (f5-sales-demo) and prevent accidental tenant cross-contamination.
replace_triggered_by = [terraform_data.ce_vm]	Couples xcsh_securemesh_site_v2 lifecycle to the Azure VM instance ID, preventing UniqueSecondaryIndexViolation on node rebuilds.
CertifiedHardwareEndpoint in Cloud-Init	Renders /etc/vpm/config.yaml with azure.yml endpoint required by vpmd on marketplace volterra-node images.
namespace = "" on data.xcsh_namespace	Required by the xcsh_namespace data source schema to prevent HCL validation errors.
private_ip_address_allocation	Enforces explicit static/dynamic IP allocation syntax for Azure network interface resource blocks.