# Codex Adversarial Review (5回目) — アーキテクチャレベル反論

- 対象: `13_v3_アーキテクチャ根本監査.md`（CC自己監査）
- 実行日: 2026-04-17
- モデル: Codex (openai-codex plugin 1.0.3) via `/codex:adversarial-review`
- 目的: **コード diff ではなくアーキテクチャ選択と戦略判断** への反論
- 参照元: ユーザーからの指摘「修正すれば修正するほど次から次へと修正が必要になるのはなぜか」

---

Target: branch diff against 603a49f
Verdict: **needs-attention**

**No-ship for v3 as a 100-store bridge.**

真の答え: 「毎回の fix が次の fix を生む」のは、**v3 がそれらを提供していないプリミティブとフローから、atomicity / idempotency / authenticated authority / bounded memory / operational recovery を合成しようとしている**から。

**推奨パス: 4番目の選択肢 δ（第4案）** — v3 を学習用に freeze、v2 は本番稼働中のスケールで cap、v4 のアーキテクチャ決定/プロトタイプを CC の bug-fix を続ける前に開始する。

---

## Findings by Section

### 🔴 5.3 Verdict: **Disagreed** — β は credible ではなく store ceiling も hand-wavy

**指摘**: α/β/γ のフレーミングが「店舗数」をスケール変数として扱っているが、実際の変数は以下:
- 同時承認数
- アップロードサイズ
- 予約投稿の瞬間集中
- Instagram outage 時のリトライ嵐
- 攻撃トラフィック
- audit write レート
- 運用 recovery 時間

β は特に弱い: 監査ドキュメント自身が「R1〜R4 は v3 で未解決」と認めており、Codex 4回目 (12.md) で audit serialization / login PBKDF2 fan-out / upload pre-enforcement buffering が HEAD=603a49f で依然 open。つまり **50〜80 店舗は希望であってエンジニアリング的主張ではない**。

γ の 200〜300h も auth 再設計 / migration / test harness / load test / observability / runbooks / tenant data lifecycle / production cutover を含めるなら optimistic すぎる。

**Recommendation**: β を reject。store-count ceiling を **load envelope + Go/No-Go gate** に置き換える:
- max concurrent uploads
- scheduled publishes per minute
- retry storm behavior
- login attack rate
- audit append throughput
- recovery RTO/RPO
- tenant isolation tests

v4 見積は phase 分割: architecture spike → core invariant prototype → production hardening → migration/cutover。

---

### 🟠 5.1 Verdict: **More-nuanced-than-that** — R1〜R4 は正しいが incomplete

R1〜R4 は scheduler / approval / audit / login / upload に渡る繰り返し failure を正しく捉えている。しかし **まだ implementation-centric** で、より大きい missing root causes は:

1. **Irreversible Instagram side effect の invariants 不在**
   - outbox
   - fencing token
   - idempotent publish attempts
   - Graph API reconciliation
   - retry semantics

2. **R4 は auth 問題を understate している**
   - bearer URL vs session の二項対立ではない
   - actor identity
   - role/tenant authorization
   - approval accountability
   - session lifecycle
   - abuse controls

3. **Observability と recovery も root cause**
   - operational polish ではない
   - duplicate publish / audit fork / upload loss が起きた時、アーキテクチャが **detection と rollback/reconciliation を可能にする** 必要がある

**Recommendation**: root causes を **invariants** として reframe:
- single writer where required
- idempotent external side effects
- authenticated actor/tenant boundary
- bounded media path
- durable audit/recovery trail
- observable operations

R1〜R4 はこれらの invariants 下の **症状** として扱う。

---

### 🟠 5.2 Verdict: **More-nuanced-than-that** — Cloudflare primitives は plausible だが提案形状は未検証

**DO + Queues + R2 自体は over-engineered ではない**（Queues は scheduled/retry work に適合、R2 は正しい media boundary、DO は KV/D1 polling に無い single-writer coordination を提供）。

**ただし提案アーキテクチャは依然 risk を over-concentrate している**:
- **singleton AuditAppenderDO が全テナントをシリアライズ → global blast radius 化**
- **per-post PublishOrchestratorDO は Instagram idempotency と post-crash reconciliation を解決しない**

シンプルな 100店舗デザイン案:
- **Fly.io/Railway container + Postgres + queue + object storage**
- **Supabase/Vercel + Postgres advisory locks + storage**
- → **1つの transactional database** が今 CF プリミティブに分散している invariants の多くを表現できる

**コスト観点**（Codex が公式ドキュメントで確認）:
- Workers Paid min $5/mo
- Queues $0.40/M ops（無料枠後）
- R2 $0.015/GB-month + request charges
- Turnstile は本番ほぼ無料
- DO の request/storage は 100店舗なら気にならない水準
- **WAF/Logpush tier と人件費運用時間が真のコスト変数**

参照:
- https://developers.cloudflare.com/workers/platform/pricing/
- https://developers.cloudflare.com/queues/platform/pricing/
- https://workers.cloudflare.com/product/r2/
- https://developers.cloudflare.com/turnstile/plans/
- https://developers.cloudflare.com/waf/rate-limiting-rules/

**Recommendation**: CF-all-in を決める前に **short ADR/prototype**:
1. publish state machine
2. media upload
3. rate limiting
4. audit append
5. recovery path

を **Cloudflare と Postgres-based alternative の両方で実装**し、**invariants を最もシンプルに表現できる方** を選ぶ（プラットフォームプリミティブが多い方ではない）。

---

### 🟠 5.4 Verdict: **Agreed, with a stronger conclusion** — v3 継続は payoff が poor

**v3 は useful evidence であって useful bridge ではない**。4回の Codex レビューで、修正が同じ failure class を繰り返し別サブシステムに移動させている:
- scheduler → audit
- approval → token confirmation
- upload cap → formData buffering
- KV counter → PBKDF2 fan-out

これは **abstraction boundaries が間違っている設計パターン そのもの**。

**v2（本番稼働・10店舗）+ v4（100店舗狙い greenfield）** の方が、v3 を 3つ目の operational shape として加えるより cleaner。v3 が v2 で安全にサポートできない business feature を含むのでなければ、v3 は ship しない。

Cloudflare 公式ドキュメントの prior art は方向性を支持するが、**Instagram 自動化 SaaS を CF-native end-to-end で作るべきと証明はしない**。

**Recommendation**: v3 を商用 bridge としてリリースしない。narrow な business need と risky envelope より下の hard cap が明示的にあれば別。
**v3 から抽出**:
- テスト
- migration lessons
- domain code

**本番は v2、並行で v4 設計**。

---

### 🟠 5.5 Verdict: **Agreed** — handoff の分業が backwards

4回の Codex → CC fixes → more Codex findings は **CC が症状治療をしている**証拠。

- CC は「invariants と platform decisions が固定された後の scoped implementation」で effective
- Codex は「invariants と failure paths の adversarial review」で effective
- **どちらも disputed architecture に patch round を produce し続けるべきではない**

**子安氏は v3 コードが書かれる前、プラットフォーム判断の時点で巻き込まれているべきだった**。現状の loop は symptom closure を incentivize し、**各ラウンドは local bug を honestly fix できるがシステムは unfit のまま** という false confidence を生む。

**Recommendation**:
- **CC の feature/fix 作業を停止**（known risks の文書化と有用テストの保存を除く）
- **子安氏を architecture ADR に引き込む**: 明示的 invariants / alternatives / cost-ops model / 小さい prototype
- **Codex を ADR と prototype failure modes の adversarial review に使う**（実装拡大の前に）

---

## Next Steps（Codex推奨・最終）

### 🎯 新しい選択肢 δ（第4案・Codex推奨）

1. **v2: production-only with hard scale cap**
   - 現行 10店舗のまま継続、30店舗 cap を設定
2. **v3: freeze as reference material**
   - コミット済みコードは参考資料として保存、ship しない
3. **v4: start now after ADR/prototype**
   - Cloudflare-native vs Postgres-based architecture の比較 ADR
   - リスクの高い path を time-boxed な spike で検証

### v4 invariants を choosing tools の前に定義

非妥協事項:
- authenticated actor model
- tenant isolation
- media storage boundary
- idempotent publish state machine
- retry/reconciliation
- audit append semantics
- abuse controls
- observability
- migration rollback

### Architecture spike を time-box（full product ではなく risky path のみ）

最優先検証:
- scheduled publish retry storm
- duplicate Instagram publish prevention
- upload path
- approval authorization
- audit append under concurrency
- recovery after worker crash

---

## 📊 5回ラウンドのまとめ

| ラウンド | 指摘 | レベル | 修正後の状態 |
|---|---|---|---|
| 1 | 5件（lock/schedule/approval/version/cron） | 主にhigh | 🟢 修正済み |
| 2 | 11件（スケール+セキュリティ） | critical/high/medium | 🟡 部分対応、B1過大評価 |
| 3 | 5件（handleFailure/token/upload/audit/limit） | high/medium | 🟡 方向性OK、実装瑕疵 |
| 4 | 5件（audit再発/migration/limit/upload） | high/medium | 🟡 **依然未解決（Codex 4回目）** |
| **5** | **アーキテクチャ判定** | **critical/high** | **🔴 v3 のまま ship 不可と確定** |

---

## 💬 ユーザーへの straight answer

**「なぜ修正すれば修正するほど次が出るのか」への直答:**

> v3 のアーキテクチャ（Workers + KV + D1 中心）は、100店舗商用SaaSが要求する **atomicity / idempotency / authenticated authority / bounded memory / observability** を **それ自体では提供しないプリミティブで合成しようとしている**。個別 fix は成立しても、同じ欠損 invariant が別サブシステムで再発する。これは「CC が下手」でも「Codex が厳しすぎる」でもなく、**アーキテクチャ選択が要件に合っていない**というシステム設計の必然。