2 の 60 乗の門棘と純スクリプトの歩哨：一度で恒久の公開トンネル、ペアリング空間の天文学的数字、そして二振してはじめて鳴る軟上限

モバイル端のペアリング経路は、それを載せるデスクトップクライアントの人質だった——クライアントが閉じれば道は死ぬ。昨日の途絶が、今日の勅令を催した。いかなるクライアントにも依存しない道を、一度だけ築いて恒久とする。

一、一条の道：ドメイン、トンネル、常駐サービス

施工そのものは吝嗇と言えるほど抑制的だった。既存のトンネルを再利用し、ドメインレコードを一条、入站規則を一条加え、専用サブドメインを Mac 上の常駐セルフホストサービスへ直通させる——サービスはシステムの常駐項として起動時から立ち、端から端への死活確認は即座に 200。全鏈は上から下までちょうど二層。クラウド層はドメインと暗号化トンネルを、アプリ層は真の入口検証を担う。余分な跳び石も、重複する関所もない——道の形態が単純であるほど、監査は容易になる。

二、門棘：2 の 60 乗と十八億年

門棘の強度は数字で判決された。匿名アクセスは全インターフェースで一律 403、失効済みトークンは 401、ペアリング済みデバイスは 200——三態は明らかで、越境者は窓楣にすら届かない。ペアリングコードは三十二文字表から採られた十二文字で、紛らわしい 0、1、O、I は字母表の段階で剔出され、単回有効・期限付き。組合せ空間は 2 の 60 乗、約 1.15 × 10 の 18 乗。毎秒一千回の総当たりでも、平均して一回の命中まで十八億年。この門棘の数学的意味は、コード推測を確率の問題から宇宙論の問題へ変えたことにある。

三、なぜクラウド層にゲートウェイを掛けないか：一つの反直観的決定

最も反直観的な一歩は、防備を意図的に設けなかったことである。クラウド層は DNS とトンネルのみを担い、アクセスゲートウェイを掛けない。理由はクライアントの天性に潜む。モバイルクライアントはゲートウェイが要求する認証ヘッダを出せない。掛ければ、合法の利用者が自分の城壁の外に置き去りになる。これはモバイル端の先例と完全に同型である。クラウド層は道を門口まで舗装するだけ、門棘はアプリ自身の資格体系（あちらはパスワード、こちらはペアリングコード）が握る。防御の分寸は、各層の職務を見定めることにある——検証を誤った層に押し込めば、防がれるのは敵ではなく身内である。

四、歩哨：純スクリプトの夜巡と二振制の天秤

破られにくいだけでなく、気づかれやすくもなければならない——既定状態では一度の警告も無いことが確認され、歩哨が持ち場についた。その姿は質素そのもの。五分ごとにトンネルのローカル計量エンドポイントを読み、請求数・錯誤数・拒否数の差分を取り、閾値と比べ、超過ならチャット経由で警報する——純スクリプト、CPU はミリ秒級、モデルトークンは一枚も消費しない。閾値の較正は、天秤であって枷ではないことを実演した。初期の五分あたり百二十は、一度のコールドスタート（アプリが数十の資源塊を引き、加えて会話）にその場で突き抜けされた。六百へ引き上げられ、判定は「二窓連続で破れてはじめて警報」へ改められた——単窓超過の模擬では、一振を記すのみで警鐘は鳴らない。緊すぎる警報は狼少年を水没させ、緩すぎる警報は真の狼を招き入れる。二振してはじめて報ずるは、夜巡人が出した第三の答えである。