docs: record DK family acceptance and Telegram coexistence hold

agents/codex/done/2026-10-24-dk-family-telegram-readiness.md

@@ -0,0 +1,33 @@
+# Denmark: family exit accepted; Telegram coexistence held
+
+Owner explicitly authorized DK setup for both family VPN and Telegram on24 October2026. This supersedes the previous DK exclusion. FI and DE configurations and existing Telegram device/session were not changed. No new KAgent run was started.
+
+## Server and management
+
+Ubuntu24.04.5, about1.6GiB RAM,15GiB root filesystem. Deployment used six hash-recorded scripts from canonical Forgejo main `ef6abdea15ab4f06b1543fbcb11c100680fffaf7`, whose automatic CI was green. Copenhagen timezone,2GiB swap, IPv4 inbound firewall, key-only SSH64646, password sudo, root SSH disabled. Operator and owner public keys installed; owner private PPK was not read. Full owner PuTTY signing/login remains a device-side check.
+
+During SSH setup the script's service-state check failed; an orphan listener remained. A subsequent operator socket/service conversion interrupted fresh connections. The pre-armed rollback restored access. The orphan listener was then removed under a separate guard, the managed service reloaded, and fresh64646 key/password-sudo sessions verified. Port22 is closed and no longer listens. Temporary python-only sudo exception removed. This incident is retained rather than represented as a clean first-pass install.
+
+SSH, UFW, fail2ban and x-ui are active and enabled. Initial direct management through the current DE exit intermittently closed before authentication; RU management jump worked. Final direct64646 key login succeeded as well. No claim of a proven provider filtering mechanism. Existing owner console session was not terminated.
+
+3x-ui installed with verified pinned supply-chain payloads. Panel2053 binds loopback, subscriptions disabled on this exit; installer credentials and path rotated through authenticated CSRF API. Panel HTTP200 login page verified over a temporary loopback SSH forward, then the test forward stopped. Private credentials and owner instructions stay exclusively under the designated protected operator directory. No domain panel or public management listener was added.
+
+Root-only pre-change archive, consistent SQLite checkpoints, and initial step7 snapshot retained. Initial archive SHA256 check and database integrity check passed. Backup schedules remain disabled. Boot service enablement checked; this task did not reboot DK and does not claim post-reboot acceptance.
+
+## Family VPN
+
+DK VLESS+Reality TCP24443 uses independent keys and an enabled unlimited RU-hub client. Firewall allows this listener only from the existing RU server. Unused public443 rule removed. Target and SNI agree on `www.microsoft.com`; verified certificate and TLS1.3. Three isolated real RU→DK egress probes plus HTTPS204 passed before any RU write.
+
+RU adds only outbound `vpn-dk`, fixed DK inbound24445 and its rule, client attachment, sort index and firewall/managed-port entry. Existing DE outbound, Russian routing rules, selectors and failclosed fallback remain identical. Native Xray validation passed before applying and on the resulting panel-generated configuration. No generated config was manually patched.
+
+Exactly five existing global clients retained their UUID, subId, names, limits, expiry and settings. Their existing HTTPS subscription URLs and panel/subscription settings are unchanged. Order is Auto, Germany, Denmark, Russia. All five TLS subscription downloads have four profiles and update interval12h. All20 profile tests passed: foreign destination uses the expected foreign exit (Auto may choose DE or DK), while Russian destination uses RU; Russia profile exits RU for both. This is actual operator-network traffic, not phone/carrier acceptance.
+
+Protected live failover test blocked only RU→DE TCP24443 for60seconds; independent cleanup was active before an atomic nft batch. Home DE443 and SSH were outside scope. Auto used DK in the first successful sample at1.3seconds;13 of14 samples used DK and one failed at13.1seconds. All14 Russian-direction samples remained RU; fixed DK and Russia profiles worked. No silent RU foreign egress observed. Cleanup occurred automatically, fixed Germany recovered, and Auto continued on a valid foreign exit. This does not prove zero packet loss, sticky exit selection, or continuous mobile notification delivery. The RU change rollback was stopped only after functional and preservation checks passed.
+
+## Telegram HOLD — review and deployment inputs required
+
+Canonical Telegram main `430a18521881f81c28665acc59f5ecbbd6c38d9a` is green. Coexistence PR108, exact head `b7d965aaadce71038e53b0816f65fc97b55e8aab`, is still unmerged. The accepted main node firewall has a default-drop policy without the extra VPN listener allow-list. Deploying that role here would break the newly accepted family service. No candidate/unreviewed branch was deployed and no reviewer gate was bypassed.
+
+Node ports8443/API and8444/proxy remain reserved but unopened. Production controller origin/CIDRs, reviewed node binary, TLS identity and node/controller key inventory have not been supplied; existing server-ready examples contain placeholders. No public controller was invented or bridged to the home KVM. No new Telegram device/outage/OTP/incoming test or session change was performed. Complete node registration and real Telegram acceptance only after the coexistence change is accepted and actual production inputs are available.
+
+Physical Beeline/MTS phone testing, including VPN inclusion/IPv6 behavior and background Telegram notifications, remains a separate pending acceptance. The earlier original Telegram live PASS is not evidence for this new DK deployment.