## Context

The playbook has three host groups: `relay`, `landing`, and a `localhost` play for generating client configs. Trojan variables (`trojan_domain`, `trojan_port`, `trojan_password`, `trojan_fallback_port`) live in `group_vars/landing.yml`, scoped only to the `landing` group. The Surge template on `localhost` references these variables, but `localhost` is not in the `landing` group, so the variables are undefined.

## Goals / Non-Goals

**Goals:**
- Make trojan variables available to the `localhost` play without duplicating values
- Keep server-side variables (TLS cert paths, allowed ports) scoped to `landing` only

**Non-Goals:**
- Restructuring the entire inventory or variable hierarchy
- Changing the Surge template itself

## Decisions

**Move trojan variables to `group_vars/all.yml`**

These variables are consumed by two consumers: the `landing` server role and the `localhost` template render. `group_vars/all.yml` is the simplest way to share them. The alternative approaches considered:

1. **Add `vars:` inline to the localhost play** — would duplicate values already in `landing.yml`
2. **Use `hostvars[groups['landing'][0]]` in the template** — works but makes the template harder to read and debug
3. **Add `localhost` to the `landing` group** — semantically wrong, localhost isn't a landing server

Moving to `all.yml` is the cleanest: single source of truth, no duplication, template stays readable.

## Risks / Trade-offs

- [Variable scope broadening] → Only the four trojan connection variables move; TLS paths and firewall rules stay in `landing.yml` to avoid polluting unrelated plays