refactor(workloads): rename chaos-network.go to chaos_network.go

docs/architecture.md

@@ -31,7 +31,7 @@ graph TD
         NET["internal/workloads/network.go\niperf3 server/client"]
         TPS["internal/workloads/tps.go\nnetperf TCP_RR + HTTP"]
         CDISK["internal/workloads/chaos_disk.go\nfill/release loop"]
-        CNET["internal/workloads/chaos-network.go\ntc/netem latency + loss"]
+        CNET["internal/workloads/chaos_network.go\ntc/netem latency + loss"]
         CPROC["internal/workloads/chaos_process.go\nrandom signal killer"]
     end
 
@@ -523,7 +523,7 @@ virtwork/
 │   │   ├── network.go             # iperf3 server/client pair (MultiVMWorkload)
 │   │   ├── tps.go                 # netperf TCP_RR + HTTP file transfer (MultiVMWorkload)
 │   │   ├── chaos_disk.go          # Fill-and-release disk pressure loop
-│   │   ├── chaos-network.go       # tc/netem latency + loss injection
+│   │   ├── chaos_network.go       # tc/netem latency + loss injection
 │   │   └── chaos_process.go       # Random kill loop with excluded process patterns
 │   └── testutil/
 │       ├── testutil.go            # Shared test helpers (namespace, connect, cleanup)

docs/chaos-workloads.md

@@ -265,7 +265,7 @@ Chaos workloads are recorded in the audit database exactly like any other worklo
 Source files:
 
 - `internal/workloads/chaos_disk.go` — `ChaosDiskWorkload` struct, `chaosDiskScript`, `chaosDiskSystemdUnit`
-- `internal/workloads/chaos-network.go` — `ChaosNetworkWorkload` struct, `chaosNetworkStartScript`, `chaosNetworkStopScript`, `chaosNetworkSystemdUnit`
+- `internal/workloads/chaos_network.go` — `ChaosNetworkWorkload` struct, `chaosNetworkStartScript`, `chaosNetworkStopScript`, `chaosNetworkSystemdUnit`
 - `internal/workloads/chaos_process.go` — `ChaosProcessWorkload` struct, `chaosProcessScript`, `chaosProcessSystemdUnit`
 - `internal/workloads/registry.go` — `DefaultRegistry()` registers all three under the names `chaos-disk`, `chaos-network`, `chaos-process`
 

docs/guide/01-overview.md

@@ -269,7 +269,7 @@ If you want to dig deeper into how each component works:
 
 | I want to understand... | Look at... |
 |------------------------|------------|
-| How workloads define themselves | `internal/workloads/` — `Workload` and `MultiVMWorkload` interfaces in `workload.go`; implementations in `cpu.go`, `memory.go`, `disk.go`, `database.go`, `network.go`, `tps.go`, `chaos_disk.go`, `chaos-network.go`, `chaos_process.go` |
+| How workloads define themselves | `internal/workloads/` — `Workload` and `MultiVMWorkload` interfaces in `workload.go`; implementations in `cpu.go`, `memory.go`, `disk.go`, `database.go`, `network.go`, `tps.go`, `chaos_disk.go`, `chaos_network.go`, `chaos_process.go` |
 | The `diskSetupScript` helper for storage-backed workloads | `internal/workloads/workload.go` — generates the wait/format/mount/fstab script for `/dev/disk/by-id/virtio-<serial>` |
 | How VMs are built from workload data | `internal/vm/vm.go` — `BuildVMSpec()` and `CreateVM()` |
 | The CLI orchestration flow | `cmd/virtwork/main.go` — `runE()` and `cleanupE()`, including `namespaceDataVolumes` for per-VM DV naming |