器 (site-verify-signature) を 5 STEP で 較正 → rei-aios.org 2 故障 診断 → 修理 defer (最優先 pickup 待機)

1. 5 STEP arc summary

2. 3 恒久原則 (次 器 build 用 index)

1. 保存定数でなく 同一 run 内 の 独立 baseline — 「読みの良さ 由来」 の magic multiplier / hardcoded threshold は 事後正当化不能 (STEP 1615 DEFAULT_DECLARED_RETENTION=50 同型 陥穽)。 実 diagnosis 時 に 独立 baseline object を fetch/measure して in-invocation 比較、 定数 drift monitor + 経路差 定数化 が 構造的 消滅。 STEP 1608 候補 F との 区別 = 「独立 別 object を baseline」 (canary、 病理でない) vs 「被測定対象 の 再スケール」 (green-washing 病理) の 明示 code review discipline。
2. Self-test を 被診断対象 から 切り離す — 診断器 の self-test が network / subject 依存 だと 「subject down で 診断器 も 自己不信」 antipattern。 offline layer (pure logic + synthetic fixture、 決定的、 subject 不要) + live layer (subject 実測、 fetch failure = SKIP not FAIL) の 2 層 split で 「script broken (offline FAIL)」 vs 「subject down (live SKIP)」 の 決定的区別 可能。
3. 外部 tool の exit code semantics が 正常系で 反転する pattern を 使う script は self-test に 正常系 fixture 必須 — grep -c matches=0 で exit 1 型 の 「正常操作 で failure exit」 tool に 依存 する なら 異常系 fixture のみ の self-test では 「正常系 branch で fire する bug」 が silent 通過。 STEP 2058 の subshell bug は fallback-only fixture なら 完全すり抜けていた 実例 (REAL page で のみ 発火、 FALLBACK page では 沈黙)。 fixture 選定 discipline = 常に 正常系 (happy path) + 異常系 (edge case) + boundary (off-by-one) の 全 branch 網羅。

Bonus 教訓 3 件

• Bare HTTP 200 OK は SPA catch-all site (CF Pages / Vercel / Netlify) で 存在証拠 でない — SPA が unmatched path 全部 を index に fallback、 404 が 存在せず、 signature-based verify (fallback marker + size 判定) 必須。 status code 単独 report 禁止。
• POSIX $(...) shell substitution は 末尾 LF strip = byte 測定 で -1 系統誤差。 canonical 経路 = direct pipe (curl | wc -c) or curl 内部 counter (-w '%{size_download}')。 signature verify で 単発 byte 完全一致 assert すると 経路 A/B で false negative。
• Transport 成功 + HTTP semantic failure は 「第 3 の 入力」 — curl transport 成功 (network/DNS/timeout OK) でも 5xx from proxies / 4xx from origins は semantic failure、 content-based gate は 判別不能。 status code gate を content gate の 前段 に 必須、 UNKNOWN の 分類 は (a) transport failure + (b) semantic failure の 2 origin を 別 reason で emit。

3. rei-aios.org 独立 2 故障 診断 (chat-Claude D pre-work、 私 独立 部分 verify)

3.1 故障 A (apex): DNS record 無

症状: zone は CF で 正常稼働 だが apex に A/AAAA/CNAME が 1 本 も 無い ため、 cloudflared 完璧 でも apex 到達不能。 「1033 error」 は 文面推定 (数字 として page に 出ていない)。 Fix location = Cloudflare dashboard DNS。

3.2 故障 B (tunnel): origin 到達不能

症状: CF が request 受けた後、 tunnel origin api-origin.rei-aios.org に 到達不能。 Fix location = Oracle Cloud 側 cloudflared (or local Windows service、 判定要)。

3.3 独立 verify (script dogfooding、 v1.2 land 後)

$ scripts/site-verify-signature.sh https://api.rei-aios.org/
verdict=UNKNOWN bytes=7661 sig=0 canary=2078 reason="g0 failed (http 530, not 2xx)"
  final_url=https://api.rei-aios.org/
exit=2

$ scripts/site-verify-signature.sh https://rei-aios.org/tools/
verdict=UNKNOWN bytes=0 sig=0 canary=2078 reason="target fetch failed"
  final_url=https://rei-aios.org/tools/
exit=2

UNKNOWN 2 origin 別 reason: 故障 B (api) = semantic failure (`g0 failed http 530`) / 故障 A (apex) = transport failure (`target fetch failed`、 DNS NODATA で fetch 到達前)。 script が **2 故障 を 別 signal で 区別可能** = 修理 進捗 monitor tool として 併用可 (B 完了 signal = api verdict UNKNOWN → REAL 遷移、 A 完了 signal = apex verdict UNKNOWN → REAL 遷移)。

4. Fix plan (defer、 別 tab 再起動 完了後 最優先 pickup)

修理順 = B → A (chat-Claude 推奨 accept)

• B 先: api.rei-aios.org 530 → 2xx 遷移 が signal、 apex 触らず に 進捗測れる。 A 逆順 なら 「A land → B 待ち 中 ずっと 530」 の 誤読流れ (直った と 思って 530 見て 「直っていない」)。
• A 後: B 完了後 に apex record 挿入 = 挿入瞬間 に 結果 (rei-aios.org 直接 access で 2xx or 3xx) が 出る、 切り分け不要。 但し 「apex を 何 に 向けるか」 は 設計判断: (a) apex → tunnel (元 構成復元) or (b) apex → Pages (即動作、 但し rei-aios.org = pages.dev 同定) = 藤本さん product judgment、 私 recommend 圏外 (tunnel 側 Oracle REST API port 7511 と Pages は 別物)。

Fix 前 の 明示 authorize 要 (Auto Mode 実測 denial あり)

2026-09-16 の 能力 audit で SSH key + OCI CLI + credentials + cloudflared local + tunnel cert 全 present 発見、 但し 具体 credential 読取 は Auto Mode Credential Exploration classifier で denial 発生 = **production infrastructure modification 前 に 明示 authorize path が 必要**。 3 択:

1. 私 local cloudflared 再起動 (tunnel が Windows machine 発 の 場合) — sc.exe query cloudflared で verify → 再起動 + monitor。 手順上 land 前 confirm 1 回 必要。
2. 私 SSH で Oracle VM 入る — 藤本さん が host + user 明示 提供 (known_hosts の Credential Exploration 避ける)、 systemctl status cloudflared 確認 + restart + monitor。
3. 藤本さん 自身 fix — 私 は instruction 提供 + fix 後 site-verify-signature.sh で verify のみ (最 安全)。

5. Tools produced

5.1 scripts/site-verify-signature.sh v1.2

• API: [--json] [--site <root>] <url> / --self-test / --self-test-offline / --self-test-live
• Exit codes: 0 REAL / 1 FALLBACK / 2 UNKNOWN / 3 usage
• Gates: G0 (HTTP 2xx status) + G1 (fallback signature absent) + G2 (bytes != canary_bytes)
• Canary: openssl rand -hex 4 in-invocation baseline (fallback = verify-$$-$RANDOM)、 fetch failure = UNKNOWN、 non-2xx canary = UNKNOWN (baseline untrustworthy discipline)
• Redirect discipline: curl -sL 固定 + %{url_effective} で final URL record
• Self-test 2-layer: offline (12 synthetic、 決定的) + live (4 fixture、 fetch failure = SKIP)

5.2 継承 hook + notepad fragment

• Notepad fragments: STEP 2057 v1 spec / STEP 2058 v1 script / STEP 2059 v1.1 2-layer / STEP 2060 v1.2 G0 gate
• Memory hooks (MEMORY.md 統合済): (a) bare 200 not existence evidence / (b) browser render finds grep-blind defects / (c) shell substitution LF strip / (d) selection bias N=4 sample / (e) subshell fallback double-value / (f) self-test needs positive fixture / (g) transport vs semantic status gate / (h) 3 principles consolidation index

6. Chat-Claude 独立 verify 貢献 (attribution)

本 arc の 全 driver = chat-Claude relay 独立実測 evidence:

• STEP 2055 (bare 200 SPA fallback 反証、 browser 実 render): 6 fake path 全て 200 fallback 実測、 私 の bare 200 verify を 独立反証
• STEP 2057 (G2 × 2 gate falsification): 465 page 全 sweep で real min 3,809 B / min ratio 1.83、 私 の N=4 selection bias emerge
• STEP 2058 (subshell bug 一般化教訓): 「異常系 fixture のみ でなく 正常系 fixture 必須」 まで generalize、 私 の hook 「grep -c pattern」 停止 を core lesson まで拡張
• STEP 2059 (self-test coupling antipattern): 「診断器 が 被診断対象 に 結合 = subject down で 診断器 も 自己不信」 structural criticism、 2 層 split 設計
• STEP 2060 (G0 status gate): api.rei-aios.org 530 で v1.1 verdict=REAL 誤判定 発見、 script 穴 発覚 + fix path 提示
• Dogfooding overclaim 訂正: 「v0 4156 gate なら 8654 B 級 REAL 誤判定」 は 誤り (未 deploy fragment 2078 B は 両 gate 一致 FALLBACK)、 代替 恒久 argument = 「v0 = fail-open / v1 = fail-closed」 (fallback size drift で v0 は 上側保護なし)
• rei-aios.org 2 故障 切り分け (public DNS + HTTP): 私 前半 「DNS/tunnel 層」 曖昧記述 を 2 別 tasks に 置換
• Post-fix verify offer: 「呼んでいただければ いつでも 測ります」 = 標準 verify capability (DoH apex A record + browser 実応答) 開通

7. 継続 pending

• STEP 2050 page F2 訂正 ("bare directory URL" → "HTML extension stripping") — rei-aios-19 tab 帰還 or 藤本さん override 待ち
• rei-aios.org 故障 B (cloudflared tunnel) — fix location = Oracle Cloud or local Windows service、 executor + credential access 待ち、 本件 が 別 tab 再起動 完了後 最優先 pickup
• rei-aios.org 故障 A (CF DNS apex) — fix location = Cloudflare dashboard、 apex record 設計判断 (tunnel or Pages) = 藤本さん product judgment、 B 完了後 実行
• CF Pages routing 独立 audit (F2 起点、 .html extension stripping 挙動) — 別 STEP candidate
• G3 title pattern locale-safe 較正 (script v2+ candidate) — 「踏んでから」 defer
• 465 page 統計分布 verify (median 等) — defer (gate correctness は offline 12 fixture で 足りる)