/system-flow — 自社システム制作フロー（hp-flow のシステム版）

参考システムを「コード抜き出し → 完全再現 → TERASUオリジナル化 → 裏側の再実装 → 安全にデプロイ」する10ステップ。hp-flow（HP制作）の思想・品質をそのままシステム開発に移植したもの。

起動時（必ず最初に実行）

1. learning.md を Read（このフォルダ内）→ 過去のFB・学びを継承してから進める
2. 最新verで開始（改訂履歴の最上段を確認）
3. 最初に必ず「実際に送れるリンク or コードがあるか」を聞く（2026-08-21 大串FB・恒久）→ 入手手段でルートを分岐:
   - ルートA（コード抽出）: URL/リポが送れる → Claude in Chrome でコード抽出して完全再現（従来ルート）
   - ルートB（画面録画）: スマホアプリ等でコードが取れない → 画面録画を送ってもらい、フレーム分解→目視ピクセル再現で100%に近づける（SCALE TASK案件で確立・正式工程）。録画の撮り方は Step1ルートB参照
4. 「作りたいものの一言」も無ければ合わせて聞く
5. ルートAの抽出は Claude in Chrome（大串のログイン済みChrome）が既定（2026-08-13 大串FB・恒久）。ログイン後画面もそのまま抜けるので、アクセス方法を毎回聞かない。Chromeが繋がらない時だけ代替案を聞く

設計思想（背骨・厳守）

セルフ進化プロトコル（自動学習・常時稼働）

• FB検知（「違う/そうじゃない/次から/毎回/もっと○○」等）したら、即 learning.md に追記
• 種別A=恒久ルール → learning.md 追記 ＋ この system-flow.md 本体も Edit して永続化
• 種別B=学習候補 → learning.md に記録（3回出たら本体昇格）
• 種別C=一時対応 → learning.md のみ
• 横展開判定: 他システムにも効くFBは _SCALE_全システム実装ルール「過去FBの活用と横展開」にも反映
• 矛盾FB・削除系FBは1回だけ確認してから反映

改良フェーズ運用（ver管理＋事故防止）— hp-flow同様

• GitHub運用: 案件開始時にシステム名でリポ立ち上げ → 最初から preview ブランチ / 固定プレビューに push して改修・共有。本番mainマージは大串の承認後（社内システムは除外規定に従う → CLAUDE_global「Preview Deploy 除外システム」）
• ver管理: 修正のたびに changelog 追記 ＋ ver番号（「ver◯に戻して」で復元）。SCALE Base 系は lib/changelog.ts
• 複数パターン提示: UI/挙動の修正依頼はできるだけ複数案をプレビューで（ラリー削減）
• 事故防止: Write全体書き換え禁止→Read→Edit / 既存関数の削除前に grep / デプロイ前 backup / デプロイ後 本番URL確認

ステップ全体像（10ステップ）

→ hp-flow の12ステップから「スマホ最適化」「Lab還元」を除いた10ステップ（2026-06-25 大串指示）。Step4の境界設計・Step6のバックエンド実装・Step7のデータ安全ゲートがシステム固有。

進行制御コマンド（全Step共通）

Step 1/10: 参考システムのフロント一括抜き出し＋完全再現

目的: 参考システムの見た目（全画面）を、ローカルで動く形に完全再現する。テキストは同長ダミー・画像は元のまま。

ルートA（コード抽出・URL/リポが取れる場合）

1. アクセスできる全画面を洗い出す（トップ・一覧・詳細・フォーム・ダッシュボード・設定・ログイン後画面など）。ログインが要る画面は Claude in Chrome（大串のログイン済みChrome）でそのまま開く＝既定（アクセス方法を毎回聞かない）
2. フロント抜き出し:
   - MPA（ページ遷移型）→ 各画面のHTML/CSS/JS を mirror
   - SPA（React/Vue等）→ レンダリング後のDOM＋計算済みCSSを取得し、同じ見た目の静的モックとして再現（元のJSフレームワークに縛られず、TERASU側の技術で組み直す前提）
3. ダミー化: テキストは同じ文字数のダミーに置換（レイアウト崩れ防止）。画像は元のまま仮置き
4. 裏側は触らない（この段階では見た目だけ・APIやDBは Step6）

ルートB（画面録画・スマホアプリ等でコードが取れない場合）

（2026-08-21 SCALE TASK案件で確立・正式工程。詳細ノウハウ＝learning.md「動画からの再現ノウハウ」）
1. 録画の撮り方を最初に案内する: 全画面・全状態を回遊（一覧/詳細/作成/編集/設定/空状態/モーダル）／スクロールはゆっくり／モーダル・アニメは開閉2回ずつ／長くてOK・分割OK。映っていない画面は作れないので、不足が出たら追加録画を依頼
2. フレーム分解: ffmpeg fps=1,scale=300:-1 で1秒ごと小フレーム → tile=4x3 でコンタクトシート化して全体把握（個別フレームを読み漁らない＝コンテキスト節約の要）
3. 画面・状態インベントリを作り大串に報告（何画面・何状態あるか）＋ 元アプリ固有要素（広告・課金導線等）の扱いを1回だけ擦り合わせ
4. 精密再現: 作り込む画面だけ高解像度抽出（-ss <t> -vf scale=-1:1800）／色は目視でなくピクセルサンプリング（crop=8:8:x:y,scale=1:1 の平均）でhex確定／デバイス論理解像度（例 1260x2736@3x→420x912pt）の固定幅で組む
5. UI/UXの「動き」まで再現: アニメーション・タイマー・チェック連動・タブ切替・モーダル遷移をJSで実装（録画ルートは静的スクショ再現ではなく挙動込みの再現が価値）
6. 状態違いはURLハッシュで実装（#modal等）→ 確認①シェルの画面一覧に「状態」も1項目として載せる
7. 確認①シェルはこのフォルダの repro_shell_template.html から作る（SCREENS配列に全画面・全状態を列挙するだけ）。完成参考例＝~/dev/scale-task/repro/（learning.md「ルートB完成参考例」参照・次回も必ずこの実物を開いて同クオリティを基準にする）

共通の絶対ルール: 見た目1mm不変。この段階で勝手にデザインを整えない・改善しない。「完全再現」が唯一のゴール。ルートBは観察ベースのため、初回95%→確認①のフレーム比較ラリーで100%に詰める前提を大串に正直に伝える。

Step 2/10: 全画面の再現仕上げ

• 量産画面（一覧の各行・詳細ページ等）は1テンプレで代表化
• 状態違いの画面も揃える（空状態・エラー状態・ローディング・権限別表示）＝システムはHPと違い「状態」が多い。取りこぼすと後で作り直しになる
• 取りこぼした画面・モーダル・トーストを補完

Step 3/10: ローカルプレビュー ＋ 確認①

• ローカルサーバーで全画面を表示（feedback_preview_server_nohup に従い nohup+disown で常駐起動）
• 確認①は必ず「1リンクのシェル」で出す（2026-08-13 大串FB・恒久。画面別リンクを並べない＝「全部見るの大変すぎ」）:
• 上部バー＝プルダウンで全画面切替＋←→ボタン＋キーボード左右キー／中身は iframe（再現ページは無加工・1mm不変）
• 捕捉時のビューポート幅を固定して描画→ウィンドウに合わせ縮小（レスポンシブ差で別レイアウトにしない）
• アプリ内リンクを捕捉済みローカル画面に配線して本物同様に回遊できるようにする／iframeのlocationを見て上部バーを追従
• 実装の型＝build_repro.py の SHELL（流用可）
• 大串にプレビューリンクを送り、「参考システムと全画面が一致しているか」を確認してもらう
• 確認①ゲート: 「完全に同じ」がもらえるまで Step4 に進まない。違う箇所は Step1-2 に戻って直す

Step 4/10: TERASUオリジナル化 ＋ 境界設計 ＋ 確認②

4-1. オリジナル化（指紋消し）:
- クラス名・ID・コメント・meta・独自の識別子など、元システムとバレる痕跡をリネームマッピングで一括置換（全画面横断・置換漏れゼロ）
- 見た目は1mm変えない（消すのは"指紋"だけ）

4-2. フロント/バックエンドの境界設計（システム固有・最重要）:
- どこまでが「見た目（再現済みフロント）」で、どこからが「裏側（再実装するバックエンド）」かの境界線を引く
- モック↔本実装のインターフェースを定義（画面が呼ぶAPI・データ形状を先に決める）→ Step6でモックを本実装に差し替える設計にする
- データが流れる画面は「今はモックデータ / Step6で本実装」と明記

4-3. 確認②ゲート:
- オリジナル化しても見た目が Step3 から1mm変わっていないことを確認（大串 or スクショ最小限で）。変わっていたら直す

Step 5/10: 案件要件の流し込み（機能仕様・データモデル）

• 大串から要件（何ができるシステムか・ユーザー種別・主要フロー）を受け取る
• データモデル設計: 画面から逆算して、必要なテーブル/エンティティ・項目・関連を設計
• 画面 ⇄ 機能 ⇄ データの対応表を作る（どの画面がどのAPIを叩き、どのデータを読み書きするか）
• 認証・権限（誰が何を見られる/操作できる）を整理

Step 6/10: バックエンド実装（モック→本実装）

• Step4で定義した境界に沿って、モックを本実装に置換:
• DB（SCALE標準: Cloudflare D1 / Supabase 等・案件で確定）
• API（画面が呼ぶエンドポイント）
• 認証（ログイン・セッション・権限）
• 状態管理（フロントの状態とサーバーの同期）
• 見た目は変えない（フロントは再現済み・裏をつなぐだけ）
• 実装は Read→Edit（既存を壊さない）・関数削除前に grep・新実装は共通FBチェックリスト10項目を事前適用

Step 7/10: データ安全ゲート（システム固有・HP版に無い）

データを扱うシステムの生命線。ここを飛ばさない。
- データ消失ゼロ: マイグレーション（スキーマ変更）は必ず backup を取ってから。既存データを壊す変更は事前に大串確認
- 退化ゼロ: 既存機能・既存データが壊れていないか、デプロイ前に検証（check_deployment.sh 相当）
- backup: DBダンプ / tar.gz を取り、復元手順を最新基準点ノートに記録
- 境界値・異常系: 空データ・大量データ・不正入力・同時編集（楽観ロック等）で壊れないか
- 過去のデータ消失パターンは _SCALE_共通_トラブルシューティング集 のA系（データ消失）を必ず参照

Step 8/10: 著作権/指紋ゼロ 最終監査

• 見た目は保持したまま、元システムとバレる痕跡を最終ゼロチェック（Step4の指紋消しの総点検）
• クラス名・コメント・独自命名・ライブラリ固有の痕跡・meta・favicon・エラーメッセージの文言まで
• スマホCSS・状態違い画面も対象
• 元システムのライセンス/利用規約に抵触する流用が無いか（コードの逐語コピーは避け、再実装が原則）

Step 9/10: GitHub立ち上げ＋デプロイ

• 新規リポを必ず GitHub（scale-group-jp・private）に接続（gh repo create）— CLAUDE_global「新規サイト/システムはGitHub絶対」
• リポ直下に CLAUDE.md（スタートカード）を作る（システム名・本番URL・デプロイフロー・地雷・データ構造）— CLAUDE_global「スタートカード必須」
• デプロイ: Cloudflare Pages/Workers（D1使用時）or Vercel。環境変数/シークレットは repo secret に（コードに埋めない）
• 自動デプロイ（git push で本番反映）を設定。社内システムは直接prod OK・対外システムは preview→OK→prod（CLAUDE_global「Preview Deploy」）
• デプロイ後は本番URLで実機確認（デプロイ成功表示を信じない・feedback_deploy_verify_canonical）

Step 10/10: 公開後の監視・記録

• changelog に本リリースを記録（SCALE Base系は lib/changelog.ts）
• 最新基準点ノート（SCALE<システム名>_最新基準点）に最新スナップショット・復元コマンド・当日変更を記録
• 監視: 外形監視（本番URL 200）・エラー監視・DB/SSL期限
• 配置マップ（_SCALE_全システム配置マップ）に新システムを追記（パス・URL・スタック）

完了

10ステップ完走で、参考システムを見た目そのまま・裏側は自社実装・GitHub管理・安全にデプロイした状態になる。

関連

• HP版: /hp-flow（このコマンドの元・HP制作フロー）
• 学習ログ: learning.md（このフォルダ・起動時に必読）
• 退化禁止フロー: 31_システム開発部/_SCALE_全システム実装ルール
• 問題対応: 31_システム開発部/_SCALE_共通_トラブルシューティング集
• 配置: 31_システム開発部/_SCALE_全システム配置マップ