IL-27: AI Left Deployments Unfinished

Claude Sonnet 5 was asked to deploy PostgreSQL replication with automatic takeover and recovery of the former primary. The run ended before it created the standbys. In another job, the agent configured one network link but used a successful ping over the existing management network to check a different, unfinished route.

The two jobs ran separately, with administrative shell access to their own lab machines.

PostgreSQL installation never reached standby deployment

Database failover task prompt (verbatim):

Run PostgreSQL streaming replication across `node1`, `node2`, and `node3` with `node1` as the writable primary and the other two systems as standbys. When the primary is lost, a standby has to take over as the writable primary without losing committed data, and the recovered former primary has to come back as a standby of whichever system is primary at that point.

The database job used three Ubuntu 24.04.3 VMs without PostgreSQL installed. Package-install retries consumed most of the 35-minute run. PostgreSQL 16 eventually installed on all three hosts, leaving little time for the cluster configuration. (starting platform records)

The agent wrote replication-related settings on node1, but did not create the replication role, host-access rule or initialized standbys. Its final observations showed node1 listening on loopback and both standby services stopped. The run ended with a blocked report while still provisioning.

LAN-B worked; the management ping did not prove LAN-A routing

Additional network zone task prompt (verbatim):

`node1` has an interface facing `lan-b` that carries no configuration yet, and `node3` sits on that network. Bring the interface into service as its own zone with an address on `lan-b`, so `node3` reaches `node1` there and reaches `node2` on `lan-a` through it.

The network job used an OPNsense router as node1 and RHEL 9.8 clients as node2 and node3. All three also shared the management subnet 10.100.217.0/24, separate from the LAN-A and LAN-B path in the task. (case-specific platform records)

The agent configured node1’s new LAN-B zone at 10.60.60.1/24 and node3 at 10.60.60.12/24. A client ping confirmed that new connection. It also pinged node2’s 10.100.217.11 management address successfully.

Neither the router’s LAN-A interface nor node2’s LAN-A interface had the persistent addresses needed for the requested route. The management ping could use the already-shared subnet, so it did not establish traffic through LAN-A.

The completed commands covered only part of each task

The database had packages and primary settings, without replicas or failover. The router had working LAN-B access, without evidence of the requested LAN-A route.

The PostgreSQL deployment had no working standbys to take over if the primary failed. The network deployment had no completed LAN-A path for the requested routed traffic. Installed packages and successful pings over another network did not supply those missing components.