---
name: feedback-deploy-verify-http-200-plus-content-grep-required
description: deploy 後の verify は HTTP 200 status のみでは insufficient. 必ず unique content marker (page title / 独自文字列 / component 名) を curl で grep して content 反映を verify する.
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 25ad851d-2e0d-4817-8f8c-6d7eae1e62d1
---

# Deploy verify: HTTP 200 + content grep 必須 (HTTP 200 のみは不可)

## Rule

CF Pages / GitHub Pages / Vercel / Netlify / 任意の static site deploy 後の verify
時、 **HTTP 200 status code のみで「deploy 成功」 と判定してはいけない**.
**必ず curl 経由でも unique content marker (page title / 独自文字列 / component 名)
を grep で確認** して content が正しく反映されているか verify する.

```bash
# ❌ insufficient
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/new-page/

# ✅ correct
curl -s https://example.com/new-page/ | grep -o "Unique Page Title\|MyComponent\|unique-marker" | head -3
# OR
curl -s https://example.com/new-page/ | grep -c "specific-content-string"
```

## Why

**2026-06-05 WIC /shipping deploy incident**:
- 私 (Rei Claude) は CF Pages auto-deploy 後に `curl -s -o /dev/null -w "%{http_code}\n"`
  で **HTTP 200 を確認 → ✅ deployed と報告**
- 実際は CF Pages が **homepage (index.html) を fallback として全パスに 200 OK で返していた**
- 同 pattern は **/random-vs-real (6/03) + /honest-confluence (6/05 朝) + /shipping (6/05 午後)
  の 3 連続 deploy で発生**, いずれも私の「✅ deployed」 報告は誤り
- 藤本さんから「site でできるようにして」 と再依頼が来てから初めて気付いた
  (honest discipline 違反 = 自己発見できなかった)

**根本原因**:
- CF Pages (の場合) は path 不一致時 catch-all で / を 200 OK で返すことがある
- SPA mode 設定や Cloudflare Workers routes 等で同 behaviour 発生
- HTTP 200 = 「サーバが何か返した」 でしかなく、 「正しい page が返った」 ではない

**How to apply:**

deploy verify チェックリスト:
1. `curl -s -o /dev/null -w "%{http_code}\n" $URL` (HTTP status) — 必要だが不十分
2. `curl -s $URL | grep -oE "<title>[^<]*</title>"` (title 確認) — 推奨
3. `curl -s $URL | grep -c "unique-content-marker"` (独自 string count > 0) — load-bearing
4. アプリ bundle (Vite/Webpack) の場合: bundle JS file 内に component 名 grep
   ```bash
   BUNDLE=$(curl -s $SITE/ | grep -oE 'app-[A-Za-z0-9_-]+\.js' | head -1)
   curl -s "$SITE/assets/$BUNDLE" | grep -c "MyComponentName"
   ```
5. 結果を RECENT_UPDATES.md に **✅ + 実測 evidence 一行** で記録 (例:
   「✅ bundle (app-XYZ.js) に MyComponentName 含む 200 OK 実測」)

## Trigger 条件

- 新 page / 新 component / 新 file を deploy した直後
- 「✅ deployed」 と報告する前
- 特に CF Pages / Vercel / Netlify 等で SPA fallback / catch-all rewrite の可能性
  ある site では mandatory

## NOT to do

- ❌ HTTP 200 だけで ✅ 報告 (Antipattern, 本 incident origin)
- ❌ `head -c 100` で短すぎる sample 確認 (homepage の冒頭と新 page の冒頭が
  類似する場合 false positive risk)
- ❌ ローカル dist ファイル確認のみ (CF deploy が起きてない可能性を check しない)
- ❌ 「200 OK だから多分大丈夫」 の慢心

## 関連 memory

- [[feedback-chat-claude-hallucination-warning]] Antipattern「過度の信頼」 — verify は
  両極端の中道で常に積極的に行う
- [[feedback-no-rush-publication]] 急がず ゆっくりと — verify を急いで省略しない
- [[feedback-invention-audit-include-downgrade-approve-option]] honest discipline =
  architect 側の責任で実現
- [[feedback-world-uniqueness-claim-controllable]] controllable framing — 「成功」
  claim も実測 evidence 付きの controllable framing で

## Summary

Deploy verify: **HTTP 200 + content grep の二重 check を default**. HTTP 200 単独
での「✅ deployed」 報告は honest discipline 違反として禁止.