docs: fix roadmap and setup reference direction

Remove setup runbook references from prod roadmap docs so roadmap remains design intent only. Keep setup-to-roadmap links, but normalize them to explicit relative paths.

roadmap/prod-env/01-swarm-init-multinode.md

@@ -114,7 +114,7 @@ docker node update --label-add db-index=03 iklim-db-03
 
 > DB nodes are Swarm **workers** only — they never become managers.
 > DB services are pinned to them via `node.labels.role == db` placement constraint.
-> See `08-prod-db-cluster-setup.md` for DB stack deployment.
+> DB services are deployed by the current root production stack `docker-stack-infra_db-prod.yml`.
 
 ## Step 6 — Verify
 
@@ -154,4 +154,4 @@ SWAG and cert-reloader are pinned to `iklim-app-01` (the Floating IP node) becau
 
 ## Historical / Superseded by Setup
 
-Older notes that referred to `docker-stack-infra.yml`, `docker-stack-infra.prod.yml`, or `docker-stack-db.prod.yml` as the active prod deployment model are superseded by `../../setup/08-prod-db-cluster-setup.md` and `../../setup/09-prod-runner-ha-and-swarm.md`.
+Older notes that referred to `docker-stack-infra.yml`, `docker-stack-infra.prod.yml`, or `docker-stack-db.prod.yml` as the active prod deployment model are superseded by the current root production stack and workflow model.

roadmap/prod-env/02-godaddy-credentials.md

@@ -58,7 +58,7 @@ To get the Floating IP: `terraform output prod_floating_ip`
 
 Logic: for each record, pipeline queries the current value via GoDaddy API. If already correct, it skips. Otherwise it creates/updates the record.
 
-> The Floating IP is assigned to `iklim-app-01` (`06-prod-terraform-iac.md` — `floating_ip.tf`).
+> The Floating IP is assigned to `iklim-app-01` by `terraform/hetzner/prod/floating_ip.tf`; use the production Terraform output for the `PROD_FLOATING_IP` value.
 > If failover is needed, the Floating IP can be reassigned to another app node; DNS does not change.
 
 ## Notes

roadmap/prod-env/03-infra-stack-changes.md

@@ -6,7 +6,6 @@ This document records the production infrastructure target that is now implement
 
 Current references:
 
-- Setup source: `../../setup/08-prod-db-cluster-setup.md` and `../../setup/09-prod-runner-ha-and-swarm.md`
 - Main infra and DB stack: root `docker-stack-infra_db-prod.yml`
 - Vault stack: root `docker-stack-vault.yml`
 - Vault bootstrap: root `init/vault/vault-bootstrap.sh`, called through `init-infra-prod.sh`
@@ -54,7 +53,7 @@ Grafana uses `/mnt/storagebox/grafana/data` through `GRAFANA_DATA_DIR` so dashbo
 
 APISIX uses the DB-node etcd cluster through overlay DNS aliases such as `etcd-01`, `etcd-02`, and `etcd-03`. Patroni and APISIX use different etcd prefixes, so their data does not collide.
 
-The app subnet to DB subnet firewall rule for etcd client traffic is part of the current production firewall model. See `../../setup/06-prod-terraform-iac.md`.
+The app subnet to DB subnet firewall rule for etcd client traffic is part of the current production firewall model in `terraform/hetzner/prod/firewall.tf`.
 
 ## Redis and RabbitMQ
 

roadmap/prod-env/04-swag-nginx-configs.md

@@ -2,7 +2,7 @@
 
 ## Context
 
-Production uses the same SWAG template files as test, with production subdomain values and StorageBox-backed output directories. The current setup source is `../../setup/09-prod-runner-ha-and-swarm.md`.
+Production uses the same SWAG template files as test, with production subdomain values and StorageBox-backed output directories.
 
 ## Required Environment Variables
 

roadmap/prod-env/06-cert-reloader.md

@@ -2,7 +2,7 @@
 
 ## Context
 
-The production certificate flow is implemented in the current infra stack and setup runbooks. See `../../setup/09-prod-runner-ha-and-swarm.md`.
+The production certificate flow is implemented by the current infra stack, cert services, and Vault stack.
 
 ## Current Flow
 

roadmap/prod-env/07-vault-raft-plan.md

@@ -6,7 +6,6 @@ Production Vault is a 3-node Raft cluster, but it is no longer initialized throu
 
 Current references:
 
-- Setup source: `../../setup/09-prod-runner-ha-and-swarm.md`
 - Stack file: root `docker-stack-vault.yml`
 - Bootstrap script: root `init/vault/vault-bootstrap.sh`
 - Template: root `init/vault/vault-template-v2.json`

roadmap/prod-env/08-deploy-pipeline-update.md

@@ -2,7 +2,7 @@
 
 ## Context
 
-The production deploy pipeline is no longer a pending set of step additions. The current source of truth is the root `.gitea/workflows/deploy-prod.yml`, with the operational explanation in `../../setup/09-prod-runner-ha-and-swarm.md` and root `prod_env-ci_dc-pipeline.md`.
+The production deploy pipeline is no longer a pending set of step additions. The current source of truth is the root `.gitea/workflows/deploy-prod.yml`, with the operational overview in root `prod_env-ci_dc-pipeline.md`.
 
 ## Current Pipeline Order
 
@@ -93,4 +93,4 @@ The following earlier plan items are superseded:
 - Storing prod env in `prod/secrets/iklim.co/.env.prod`.
 - Deploying microservices with `docker-stack-service.yml` plus `docker-stack-service.prod.yml`.
 
-Keep this file as a roadmap summary. For exact commands, use the root workflow and `../../setup/09-prod-runner-ha-and-swarm.md`.
+Keep this file as a roadmap summary. For exact commands, use the root workflow and root operational documentation.

roadmap/prod-env/09-verify.md

@@ -2,7 +2,7 @@
 
 ## Context
 
-Run these checks after a successful production pipeline deployment. The current setup source is `../../setup/09-prod-runner-ha-and-swarm.md`.
+Run these checks after a successful production pipeline deployment. This roadmap keeps verification intent; exact execution belongs to the current production workflow and operational runbooks.
 
 ## 1 — Swarm Cluster Health
 

setup/09-prod-runner-ha-and-swarm.md

@@ -117,7 +117,7 @@ Before the deploy pipeline runs, the following template files must exist in the
 - `template/swag/site-confs/rabbitmq.conf.tpl`
 - `template/swag/site-confs/grafana.conf.tpl`
 
-These files are created in the test environment (`test-env/04-swag-nginx-configs.md`); they are not created separately for prod. Template files are shared by both environments; prod-specific values are injected with environment variables during deploy.
+These files are created in the test roadmap (`../roadmap/test-env/04-swag-nginx-configs.md`); they are not created separately for prod. Template files are shared by both environments; prod-specific values are injected with environment variables during deploy.
 
 Verify that the `prod/secrets/iklim.co/.env` file on StorageBox contains the following variables:
 
@@ -141,7 +141,7 @@ The following prerequisites must be satisfied before deploy.
 
 #### init.sh SSL Block
 
-The `ssls/1` PUT block and the `dev` SSL block inside `init/apisix-core/init.sh` must be removed. This change is made in the test environment (`test-env/05-apisix-remove-ssl.md`); the same `init.sh` file is also used in prod, so no separate change is required for prod.
+The `ssls/1` PUT block and the `dev` SSL block inside `init/apisix-core/init.sh` must be removed. This change is tracked in the test roadmap (`../roadmap/test-env/05-apisix-remove-ssl.md`); the same `init.sh` file is also used in prod, so no separate change is required for prod.
 
 #### Custom APISIX Image
 
@@ -166,7 +166,7 @@ If the image requires a rebuild because `config.yaml` changed, run from the proj
 bash ops/push-harbor-custom-images.sh
 ```
 
-During deploy, `init/apisix-core/init.sh` is run once by the pipeline. It writes the APISIX configuration to Patroni etcd with the `/apisix` prefix; the 3 replicas in prod read this etcd state commonly, so no separate init per replica is required. Detail: `roadmap/prod-env/05-apisix-remove-ssl.md`.
+During deploy, `init/apisix-core/init.sh` is run once by the pipeline. It writes the APISIX configuration to Patroni etcd with the `/apisix` prefix; the 3 replicas in prod read this etcd state commonly, so no separate init per replica is required. Detail: `../roadmap/prod-env/05-apisix-remove-ssl.md`.
 
 ## Deploy Serialization with Gitea Concurrency
 
@@ -416,7 +416,7 @@ SWAG connects to APISIX through the Docker Swarm service name with `proxy_pass h
 
 `Prometheus` is intentionally not exposed externally through SWAG. Access uses Grafana, whose internal connection is `http://prometheus:9090`, or an SSH tunnel.
 
-Detay: `Environment_Infrastructure/roadmap/prod-env/04-swag-nginx-configs.md`.
+Detay: `../roadmap/prod-env/04-swag-nginx-configs.md`.
 
 ## Post-Deploy Verification