🤖 AI運用ルール

section

最終更新 2026年08月20日 ／ 22_AI運用ルール/コマンド集/section/section.md

/section — TERASU Labセクション追加（hp-flow式・実コード抽出ベース）

ユーザー（大串）の入力：$ARGUMENTS

目的: TERASU Lab（lab.terasu.scale-group.co.jp/sections）の「セクション集」に、参考HPの好きな箇所を hp-flow と同じ品質で足す。

2026-08-18 大串FB（7点・このコマンドの最優先ルール）

「精度が低いのが多い。修正しないで一発で格納できるのは10％〜20％ほど。修正に時間はかけたくないから精度をあげて」
「これルールとして保存しておいて／他のセッションでも同じ指摘ないように」
→ 以下7点は全セッション共通・毎回必ず守る。 破ると同じ指摘が繰り返される。

# ルール 実装場所
① テキストはダミーにせず本文をそのまま使う 設計思想4 ／ Step1
② 素材が揃ったら「これで合っていますか？」を聞かず即着手 設計思想6 ／ Step0
③ 送られたスクショ・動画は1件残らず全部作る（動画ぶんだけ作られない事故が多い） 素材は全部作る
④ 作り終わったら1件ずつ Chrome で開ける公開プレビューURLを送る Step2
⑤ 勝手にLabに格納しない（大串のOK後にだけ add_section.py を実行） Step2 ／ Step4
⑥ 一発で格納できる精度にする（＝崩れる原因10パターンを毎回機械で潰す） 一発格納率を上げる
⑦ 違うHPのプレビューを送らない（複数サイト同時実行で混線した） Step0 作業ディレクトリ分離 ／ Step4 id規則

④と⑤は両立する。code-previews/<id>.html を push すると、entries/<id>.json（＝一覧への登録）を作らなくても
https://lab.terasu.scale-group.co.jp/code-previews/<id>.html でChromeで開ける（build_lab.py が code-previews を丸ごと配信するため。
実際に entries 205件に対し code-previews は 465件あり、未登録プレビューの運用は既に一般的）。
＝プレビューは公開URLで見せられる／/sections 一覧には出ない＝「格納していない」状態。

設計思想（厳守）

  1. 「寄せる」（推測自作）は禁止。実コードをそのまま使うが前提。
    - 動画/写真を見て"それっぽく自作"・CSSを見て"書き直す"は絶対にやらない。
    - DOMから抜き出した実コード（HTML/CSS/JS）をそのままコピーして土台にする（2026-06-30 大串FB）。
    - URLが無い（画像だけ）ときにゼロから作るのは禁止。2026-07-22 に「画像から再現するモードB」を
    試したが再現度が出ず廃止した（詳細＝learning.md）。URLをもらってから着手する。

  2. 該当セクションを正確に特定してから抽出する（2026-06-30 大串FB）：
    - 動画・スクショを受け取ったら、まずDOMで該当セクションのクラス名・構造を目視で特定してから抽出する。
    - 「横に動いていく」→ FVスライダー（.p-top__mv）か横スクロールギャラリー（.p-top__scroll）か、など外見から正確に判断する。
    - 間違ったセクションを抽出してしまうのがよくある失敗パターン。

  3. ベース設定(rem基準等)は"拾うが、スコープ化して"持ってくる（2026-06-30 大串FB＋2026-07-19 崩れFB）：
    - html { font-size: 10px } などのベース設定が抜けると rem が効かずデザインが全崩壊する。→ 必ず拾う。
    - ただし html / body / reset.css / * を丸ごとコピーするのは禁止（実HPに貼ると全体崩壊する）。ベース設定は sec-<id>{ font-size:10px } のように sec-<id> 配下へスコープ化して残す。
    - 詳細は下記「 セクションは"貼っても崩れない"形で抽出する」を必ず適用する。

  4. 「再現するもの」と「オリジナルにするもの」を明確に分ける：

実コードから忠実に再現（変えない） オリジナル化する
DOM構造・タグ・class名・id（→ Step3でリネーム） class名・id（固有のものを汎用名に変更）
CSS全部（余白/サイズ/間隔/角丸/影/font-size） 外部CMS固有のアセットパス・data属性ID
レイアウト・配置・グリッド・動き・JS設定値 リンクhref（# に無効化）
画像（参考元URLをそのまま使う） ―（画像は差し替えない）
テキスト本文（原文のまま維持） ―（ダミー化しない） 
**テキスト本文はダミー化せず原文のまま**（2026-08-17 大串FB同日2回で昇格 → **2026-08-18 に3回目の指摘＝完全に確定・恒久**）。

Labはデザイン実例集＝実際の文字組・文字量がそのまま分かる状態が価値（画像を原URLのまま残すのと同じ思想）。
参考元は caption の会社名と詳細ページの参考元URLで明示されるため、本文に社名が残っていてよい。

  1. 画像は参考元URLをそのまま使う（絶対・2026-06-30 大串FB）：
    - Lab はデザイン実例集 → 実際の見た目が分かる状態が正解。
    - CSSプレースホルダー・ダミー画像への差し替えは禁止。Step1でも Step3でも画像は触らない。

  2. 着手前の確認は禁止＝素材が揃ったら即着手（2026-08-18 大串FB②・恒久）：
    - コマンド＋URL＋スクショ/動画を受け取った時点で「これで合っていますか？」「この箇所ですね？」の確認は一切しない。すぐ作り始める。
    - 箇所の特定に迷いがあっても止めない。一番確からしい解釈で作り切る（外していたら作り直す方が、大串を待たせるより速い）。
    - どうしても割れる時は両方作って両方見せる（聞くより作る）。
    - リネームマッピング作成・オリジナル化の方針も確認を挟まずそのまま実行する（2026-06-30 大串FB）。
    - 止まるのは「作り終えてプレビューURLを送った後、格納の可否を待つ」1回だけ（Step2＝確認①）。

  3. 抽出できない実装は最初に弾く（Step0）。canvas/WebGL で描画される箇所は HTML/CSS として抜き出せない → 大串に判断を仰ぐ。

セクションは"貼っても崩れない"形で抽出する（恒久・絶対）

背景（2026-07-19）: 参考サイト（cosok/isomurass等）の <head> にある reset.css・サイト全体CSS・未使用@font-face・ライブラリCSSを丸ごとコピーしてしまい、code-previews/<id>.html が4000〜6600行に肥大化。中に html{} / body{} / 全称 *,*::before,*::after{} / 素の要素セレクタ（a,p,ul,li,h1..h6,section,button…）への"ページ級リセット"が混入した。単独プレビューでは完璧に見えるが、実HPに貼るとこの外来グローバルCSSがホストHPの既存スタイルを上書きして全体崩壊する。"長い"と"崩れる"は同じ原因の裏表。→ 外来グローバルCSSを剥がして sec-<id> 配下にスコープ化すれば両方直る。

scopeClass = "sec-<id>"（例: id=product-news-ogushi-0719 → sec-product-news-ogushi-0719）。

やること（4手順・視覚は元と不変に保つ）

  1. マークアップ: セクション描画に必要な要素だけ残し、単一ルート <div class="sec-<id>"> … </div> で包む（既に単一ルートならそこに class を付与）。<html><head><body>/doctype の器は自己完結のため残してよいが、body直下の実体は必ず <div class="sec-<id>"> 1個に収める。

  2. <style> から外来グローバルCSSを削除（漏れの本体・これが最重要）:
    - reset.css ブロック全体・素の html{…} body{…}
    - 全称 *, *::before, *::after {…}
    - スコープ無しの素の要素セレクタ（ul,li,h1..h6,p,a,img,section,button,input,figure…）への全体指定
    - このセクションが使っていない @font-face / 未使用CSS 全部
    - document直下に html / body / 素の * を対象にするルールを1つも残さない

  3. 必要なリセットは"捨てず・スコープ版に変換"して残す（見た目を崩さないため最重要）:
    - 全体 *{box-sizing} → sec-<id> *, sec-<id> *::before, sec-<id> *::after { box-sizing:border-box; }
    - reset由来の margin:0/padding:0/list-style:none 等 → sec-<id> :where(h1,h2,h3,h4,h5,h6,p,ul,ol,li,figure){ margin:0; padding:0; } のようにスコープ内限定で再現
    - html{font-size:10px} 等の rem 基準は捨てずに sec-<id>{ font-size:10px } へ寄せる（rem が効かなくなる崩れを防ぐ）

  4. セクション本体の全CSSを sec-<id> 接頭辞でスコープ化:
    - .title{…} → sec-<id> .title{…}
    - :root{--x} → sec-<id>{--x}、body{…} 指定 → sec-<id>{…} に寄せる
    - @media は残すが中のセレクタも同様にスコープ化。@keyframes / 使用中の @font-face はそのまま可（名前衝突を避けるため名前を <id> 由来にリネームすると安全）

ライブラリ（Swiper/GSAP等）

  • そのセクションが実際に使う物だけ残す。使ってないCDN/JS/CSSは削除。
  • 残す場合、init/セレクタは sec-<id> 配下に限定し、ライブラリCSSも可能な範囲でスコープ化 or 名前空間化。使用中の swiper-icons 等の base64 フォントは正当なので残してよい。

完成条件

  • (a) 単独で開いた時プレビューが元と同一に見える（視覚不変）
  • (b) 任意のホストHPに貼っても CSSが sec-<id> の外へ漏れない・html/body/* へのページ級リセットを宣言しない
  • (c) 依然として1ファイルで自己完結（単独でも開ける）
  • (d) 行数が大幅に減る（外来CSS除去分。base64フォント等の正当な重量は残ってよい）

目安: 外来CSS混入で数千行になっていたら抽出ミス。以前の正しいセクションは概ね100〜300行。

素材は全部作る（取りこぼし禁止・2026-08-18 大串FB③・恒久）

起きていたこと: スクショと動画をまとめて送ったのに、動画ぶんのセクションだけ作られていないことが多かった。
静止画は目に入るが、動画は「動きの参考資料」と誤解して1件としてカウントしないのが原因。

受領直後にやること（着手前の唯一の作業・確認は挟まない）

  1. 素材を1件ずつ番号付きで棚卸しする。動画も静止画と同じ「1件＝1セクション」として数える。
    受領素材：スクショ3枚＋動画2本＝計5件 ①<スクショ1> → id: <site>-fv-<担当>-<MMDD> ②<スクショ2> → id: <site>-price-<担当>-<MMDD> … ④<動画1> → id: <site>-slider-<担当>-<MMDD> ← 動画も必ず1件 ⑤<動画2> → id: <site>-megamenu-<担当>-<MMDD>
  2. この素材⇔id対応表を作業中ずっと保持し、完了時に「受領N件／作成N件」を必ず照合する。数が合わなければ報告しない。
  3. 動画が「静止画と同じ箇所の動きを写しただけ」で明らかに重複する時だけ1件に統合してよい。ただし
    統合したことを報告に明記する（黙って減らさない）。判断に迷ったら分けて2件作る（作る方が安全）。
  4. 抽出不可（canvas/WebGL）で作れない件があっても他は止めない。その件だけ理由を添えて報告に残す。

「動画は参考資料」ではない。動画1本＝作るべきセクション1件。

一発格納率を上げる（2026-08-18 大串FB⑥・最重要）

大串FB: 「精度が低いのが多い。修正しないで一発で格納できるのは10〜20%ほど。修正に時間はかけたくないから精度をあげて」
真因: 崩れる原因は毎回ほぼ同じ10パターンで、learning.md に実証済みで蓄積されているのにコマンド本体に昇格していなかった
＝毎回同じ所で踏む。→ 以下を Step1 直後に毎回チェックする（目視でなく機械で確認できるものは機械で）。

崩れる原因トップ10（全部が過去に実害を出したもの・毎回確認する）

# 症状 真因 対処
1 色が全部おかしい :root{--var} の定義が落ちた（cssutils等は変数定義を捨てる）。var(--x,#1D7FB7) のフォールバック色が出る :root{…} を正規表現で生抽出し sec-<id>{…} にして先頭に置く
2 サイズが全部おかしい rem基準の取り違え。html{62.5%}＝10px基準と html{1rem}＝16px基準がある 元サイトの html の font-size を必ず実測してから sec-<id> に移す。確認せず10pxを足すのは禁止
3 大見出しが小さく潰れる sec-<id> *{font-size:…} を敷いて継承チェーンを切った（親にサイズ・子pに継承の構造が壊れる） font-size はルート sec-<id>{…} にだけ。* に敷かない
4 背景・矢印アイコンが消える CSS内の相対 url(../images/…) を絶対URL化していない（404） CSSファイルのURLを基準に urljoin で全部絶対化。HTMLの src だけ直して満足しない
5 レイアウトが総崩れ ルールが .home .xxx .archive .xxx .top .xxx .clinic .xxx とbodyクラス文脈前置で書かれ、抽出条件に合わず落ちた ページのbodyクラスをスコープルートとして読み替え（先頭除去）or ルート要素に付与して抽出
6 中身が見えない／真っ白 登場アニメの発火クラス。.appear は外すと表示、.is-visible は付けると表示、#wrapper.is_loaded 前提など 方式を特定し、末尾にフォールバックJSを入れる（例 setTimeout(()=>document.querySelectorAll('.appear').forEach(e=>e.classList.remove('appear')),2500)）
7 全要素 opacity:0 で真っ白 @keyframes 名の一括リネームが .fadeInDown というクラス選択子まで壊した keyframe名は原則リネームしない（同一定義なら共有して安全）
8 ヘッダーが透明／位置がおかしい 単独プレビューでは前提が無い指定（opacity:0＋JSで表示、FVに重なる position:absolute、top:-100px） 単独用に打ち消す（opacity:1 / relative+min-height / top:0）
9 背景色や外枠が抜ける footer{} section{} のようなクラスもidも無い素タグのルート指定が抽出条件（クラス集合一致）から漏れた 素タグのルート要素は手動で補完する
10 スライダーの矢印が「➤」の文字になる CDNのテーマCSS（slick-theme等）を使い、元サイト独自のテーマCSS（::beforeが1pxの線）を持ってきていない 実サイトのテーマCSSをスコープ化して同梱（JSだけCDNでOK）

完全一致を「目視」でなく「数値」で証明する（登録前ゲート・省略禁止）

learning.md で「今後これを標準にする」と書かれていた手法を正式ゲートに昇格（2026-08-18）。目視では4pxのズレも文字数のズレも取れない。

元サイトと再現HTMLの同じ要素の getBoundingClientRect() を突き合わせる。同じ幅（1440）で両方を headless で開き、
主要要素（セクション器・見出し・本文・画像・ボタン・スライド）の w / h / x を出して比較する。

# 例: 元サイトと再現物の主要要素の寸法を並べて出す（差が出たらそこが崩れている箇所）
node -e '
const {chromium}=require("playwright");
(async()=>{const b=await chromium.launch();
for(const [tag,url] of <span class="wikilink-dead">&quot;元&quot;,process.argv[1</span>,["再現",process.argv[2]]]){
  const p=await(await b.newContext({viewport:{width:1440,height:900}})).newPage();
  await p.goto(url,{waitUntil:"networkidle"}); await p.waitForTimeout(2500);
  console.log(tag, await p.$$eval(process.argv[3],els=>els.slice(0,8).map(e=>{const r=e.getBoundingClientRect();
    return `${e.tagName}.${(e.className||"").toString().split(" ")[0]} ${Math.round(r.width)}x${Math.round(r.height)} x${Math.round(r.x)}`;})));
  await p.close();}
await b.close();})();
' "<元サイトURL>" "http://localhost:<port>/<id>.html" "<比較セレクタ>"
  • 数値が一致するまで直す。「ほぼ同じ」で次へ進まない（＝これが一発格納率を上げる本体）
  • 一致しない時は上のトップ10表の該当症状から真因を引く（推測で修正を積まない）
  • フォント差は再現度の最大の支配要因（learning.md 実測）。@font-face／Google Fonts が実際に読めているかを最初に確認する

登録前セルフチェック（この5つが全部通ってから大串に見せる）

  1. check_responsive.mjs が ✅（Step3.5）
  2. スコープ漏れ grep がゼロ件（Step3-6）
  3. 固有クラス名・CMSパスの残存がゼロ件（Step3-3）
  4. 数値照合で主要要素の寸法が一致（上記）
  5. 参考元ドメイン照合が一致（下記「違うHPを混ぜない」）

違うHPのプレビューを混ぜない（2026-08-18 大串FB⑦・恒久）

起きていたこと: 「いろんなHPを一気に /section で使った時に、違うHPのプレビューが送られてくることが結構あった」。
真因は2つとも構造的なもので、どちらも本体の書き方が原因だった：
- 旧 Step0 が取得先を /tmp/dom.html / /tmp/site.css に固定していた → 2サイト目を取得した瞬間に上書きされ、前のサイトのDOMを見て作る
- 旧 id 規則が <主題>-<担当>-<MMDD>（社名を使わない）→ 汎用主題（contact-form 等）が別サイト間で衝突して上書き（2026-07-26 ksart×UMICAHI で実際に発生し、大串が別案件のフォームを見た）

守ること（3点・機械で担保する）

  1. 作業ディレクトリをサイトごとに分ける（/tmp/dom.html 固定は禁止）
    bash SITE=<サイト識別スラッグ> # 例: tomatec / kaunis / acot WORK=/tmp/section_$SITE ; mkdir -p "$WORK" "$CHROME" --headless=new --no-sandbox --virtual-time-budget=6000 --dump-dom "<URL>" > "$WORK/dom.html" 2>/dev/null curl -sL "<該当CSSのURL>" -o "$WORK/site.css"
  2. id の先頭にサイト識別スラッグを必ず入れる＝<site>-<主題>-<担当>-<MMDD>（例 tomatec-fv-ogushi-0818）。
    旧ルールの「参考元社名は使わない」より衝突回避を優先する（実害＝上書き事故／別サイトのプレビュー送付）。
  3. 送る前に参考元ドメインと中身を機械照合する（1件ずつ）
    bash # そのidの中に出てくる外部ホストを列挙 → 参考元ドメインと一致するか目で1秒確認 grep -oE 'https?://[a-zA-Z0-9.-]+' code-previews/<id>.html | sort -u | head
    参考元と無関係のドメインが主要画像に出ていたら、別サイトの素材が混入している＝送らずに作り直す。

報告の直前にも素材⇔id⇔参考元URLの対応表を突き合わせる。URLとプレビューの組が合っていることを確認してから送る。

起動時のお約束（毎回・最初にやる）

コマンド定義そのものを最新にしてから始める（2026-07-23 大串指示）。
メンバー全員が同じ最新版で動くための仕組み。~/.claude/commands/*.md は Vault への symlink なので、
Vault を pull すれば全員のコマンドが同時に最新になる。

git -C ~/dev/scale-brain pull --ff-only    # ① コマンド定義を最新化（これを忘れると古い手順で動く）
  • ② 最新化したら、この .md を読み直してから着手する（途中でアップデートされていても取りこぼさない）
  • ③ 冒頭で現行ver（下の変更履歴の最上段）を1行で伝える。「ver今何？」と聞かれたら①をやってから答える
  • ④ 作業リポも同様に最新化する（各コマンドの「現在地把握」ステップ）

起動フロー（最初の1回）

入口は2つある（2026-07-22 大串指示で追加）。
A. 通常（ゼロから）: 下の募集メッセージを返してURL＋箇所をもらう。従来どおり・URL必須。
B. /mikke から流れてきた場合: mikke!への追加直後に「セクションに追加したい部分は？」と誘導した結果、
スクショ/動画だけが送られてくる。この場合は URLを聞かない＝参考元URLは登録済みなので
~/dev/terasu-lab/core/data/reference-sites/<slug>.json の url をそのまま使う（jq -r .url）。
送られた画像/動画は「そのサイトのどの箇所か」の特定に使い、Step0のDOM取得からいつも通りに進める。
※ 実コード抽出（完全再現）の前提は同じ。URLが手に入る経路が違うだけで、品質基準は一切下げない。

$ARGUMENTS が空 or 素材が無いときは、まずこれだけ返して素材を待つ：

セクション追加、はじめます。

参考にしたいHPと、その中で「セクションに足したい箇所」を教えてください。指定方法はどれでもOK：

1. 文面で　… 「○○ってサイトの料金表のところ」「このURLのFV」など（URLがあると最速・確実）
2. 写真で　… その箇所のスクショ
3. 動画で　… 動き（アニメ/ホバー）も含めて

**同じサイトから複数箇所をまとめて追加できます**（「FVと料金表とフッター」のように列挙OK）。
該当箇所の実コードを抜き出して完全再現 → TERASUオリジナル化 → Labに足します。
※**URLは必須です**（実コードを抽出して完全再現するため）。写真/動画は「どの箇所か」の特定と動きの確認に使います。

1サイトから複数箇所をまとめて追加する（2026-07-25 大串指示・恒久）

狙い: 「1つのサイトから複数セクションを足したい」場面が多い。精度は1個ずつと完全に同じまま、
同じサイトで重複する作業（DOM/CSS取得・git push・デプロイ）だけを1回にまとめる。
品質を担保する工程は1件も省略しない（確認①・機械検証・レスポンシブ検品・サムネは各件で必ず実施）。

何が「まとまる」／何が「各件」か

まとめる（1回だけ） 各セクションごとに必ずやる（省略禁止）
DOM取得・CSS取得（同一サイトなので1回） Step1 実コード抽出・原文維持（sec-<id> スコープ化）
ローカルサーバー起動（全件を一度に並べる） Step3 オリジナル化＋grep機械検証（汚染ゼロ）
git add / commit / push / デプロイ / CI待ち（1回） Step3.5 レスポンシブ検品（機械ゲート）
反映確認（/sections を1回見る） サムネ生成（shoot_section.mjs＋normalize_thumbs.py）

進め方（確認①は「全件まとめて1回」）

  1. Step0で全箇所をまとめて特定する。DOM/CSSは1回だけ取得し、指定された箇所を箇条書きで一覧提示する
    （「① FV=.p-mv ② 料金=.p-price ③ フッター=footer.l-footer の3つで合ってますか？」）。
    - canvas/WebGL等で抽出不可の箇所は、その件だけ「不可」と明示して外す（他は止めずに進める＝2026-07-25 大串決定）。
  2. 各件を個別にStep1〜Step3.5まで完走させる（idは箇所ごとに一意 <箇所>-<担当>-<日付>）。
    - 1件でも機械検証やレスポンシブ検品でFALLしたら、その件だけ止めて直す。成功した他の件は巻き込まない。
  3. 全件そろったら Step2 の方式で一括提示（2026-07-25 大串決定＝一括提示 ／ 2026-08-18 改定＝公開URLを1件ずつ）。
    code-previews/ だけを push して CI を待ち、各件の https://lab.terasu.scale-group.co.jp/code-previews/<id>.html を1行ずつ並べて送る
    （localhostでは送らない・entries は登録しない＝まだ格納しない）。
    「N件できました（各検品PASS）。気になる箇所があれば言ってください、OKなら格納します」
    → OKが出た件だけまとめて格納へ。個別に直したい件があればその件だけStepに戻る。
  4. Step4はまとめて1回：全件 add_section.py → 全件サムネ → core/build_core.py && build.py →
    1回の commit（全件を列挙）→ pull --rebase → push → CI待ち1回。
  5. Step5報告：作った全件のプレビュー／一覧リンク。不可でスキップした箇所があれば理由を明記。

1件だけのときはこのセクションを気にせず従来フローでよい（複数指定されたときだけ適用）。

複数「サイト」を一気に処理するとき（2026-08-18 FB⑦・混線事故の発生場面）

上の表は同一サイト内での話。別サイトが混ざる時は"まとめる"対象が変わる：

別サイトでも1回でよい サイトごとに必ず分ける（混ぜたら事故）
git push / デプロイ / CI待ち（最後に1回） 作業ディレクトリ（/tmp/section_<site>/・/tmp/dom.html 固定は禁止）
反映確認（/sections を1回） DOM・CSSの取得（サイトごとに取り直す）
id の接頭辞（<site>-…・汎用主題の衝突＝上書き事故を防ぐ）
素材⇔id⇔参考元URL の対応表（送る直前に必ず突き合わせる）

サイトAの作業中にサイトBのDOM/変数を使い回さない。 送る前に「このURLのプレビューはこのid」で1件ずつ照合する
（→ 上の「 違うHPのプレビューを混ぜない」）。

複数人・複数セッションで同時に使うとき（2026-07-22 大串指示・恒久）

セクション追加は同時実行しても基本的に安全。セクションは entries/<id>.json の1件=1ファイルで、
Lab は git push → CIが最新mainからビルドして配信するため、mikke!のような「本番から消える」事故は構造的に起きない。
ただし次の3点だけ守ること。

cd ~/dev/terasu-lab && git pull --ff-only                  # ① 着手前に必ず最新化
cd core && git fetch origin && git reset --hard origin/main && cd ..   # 共通部分(core)も最新に
~/Obsidian/scripts/ai_session_lock.sh list       # ② 誰が何を触っているか確認
  1. 着手前に git pull。push直前にもう一度 git pull --rebase（他の人のセクションを巻き戻さない）。
  2. セクションidは必ず一意に＝<内容>-<担当>-<日付>（例 about-spotlight-ogushi-0718）。担当名が入るのでidは衝突しない。
  3. 集約JSON（sections-data.json）のコンフリクトは気にしない → 全件再生成なので python3 build.py で解消する。
    tools/contributors.json を編集した場合だけは、片方が消えていないか push 前に確認する。

mikke!への追加（/mikke）を同時にやる日は、デプロイだけロックが要る
（bash tools/deploy_mikke.sh 経由・詳細は /mikke のステップ6）。

処理フロー（順番厳守・作業ディレクトリ ~/dev/terasu-lab）

Step 0 抽出可否＋セクション特定（最初に必ず）

  1. 素材を棚卸しして即着手する（確認は挟まない＝FB②③）。スクショ・動画を1件ずつ番号付きで数え、動画も1件として id を割り当てる
    （詳細＝上の「 素材は全部作る」）。「これで合っていますか？」は聞かない。

  2. 参考URLを Chrome headless でレンダリング後DOMを取得。 保存先はサイトごとに分ける（/tmp/dom.html 固定は禁止＝別サイトのDOMを上書きして"違うHPのプレビュー"事故になる・FB⑦）：
    bash CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" SITE=<サイト識別スラッグ> # 例: tomatec / kaunis / acot（idの接頭辞と同じものを使う） WORK=/tmp/section_$SITE ; mkdir -p "$WORK" "$CHROME" --headless=new --no-sandbox --virtual-time-budget=6000 --dump-dom "<URL>" > "$WORK/dom.html" 2>/dev/null curl -sL "<該当CSSのURL>" -o "$WORK/site.css"
    複数サイトを同時に扱う時は、必ず $WORK を切り替えて作業する（同じ変数を使い回さない）。

  3. 大串が指定した箇所のクラス名・HTML構造を目視で特定する（抽出前に必ず確認）：
    - 動画・スクショと DOM を照合して「このセクションで合っているか」を先に確認する。
    - 似た名前のセクションが複数ある場合（FVスライダーと横スクロールギャラリー等）は特に注意。

  4. 該当箇所の実装方式を判定：
    - HTML/CSS で描画 → ✅ 抽出可。Step1へ。
    - <canvas> / WebGL で描画 → ⛔ 抽出不可。 ここで止まって返事を待たない（FB②）。その件だけ外し、残りは全部作り切る。
    報告時に「①はcanvas描画のため抽出不可＝作っていません」と理由を明記して伝える（大串が次を決める）。
    - 複数箇所を指定されたときは、DOM/CSS取得は1回だけ行い、指定された全箇所をここでまとめて特定・一覧提示する。
    抽出不可（canvas等）の箇所はその件だけ「不可」と明示して外し、残りは止めずに進める（詳細＝上の「1サイトから複数箇所をまとめて追加する」）。

  5. URLが無く写真/動画だけのときは、URLをもらってから着手する（勝手にゼロから作らない）。
    例外＝/mikke から流れてきた場合（入口B）。参考元URLは data/reference-sites/<slug>.json に登録済みなので
    聞かずにそこから取る（jq -r .url data/reference-sites/<slug>.json）。大串に同じURLを2度送らせない。
    「そのセクションが載っているページのURLを教えてください。実コードを抜き出して完全再現します」と伝えて返事を待つ。
    → 2026-07-22 に画像だけから再現する方式を試したが再現度が出ず廃止した（learning.md 参照）。
    URLさえあれば完成度は非常に高いので、URL待ちが最短ルート。

Step 1 実コード抽出（本文・画像とも原文維持）

抽出ルール（そのままコピー・ただしスコープ化）：
- DOMから該当セクションのHTMLをそのまま切り出す（クラス名・タグ構造・img/svgを保持）→ 単一ルート <div class="sec-<id>"> で包む
- 元CSSから該当セクションが実際に使うルールだけを拾い、すべて sec-<id> 配下にスコープ化する（html { font-size: 10px } 等の rem基準は sec-<id>{ font-size:10px } に変換して残す）。reset.css / サイト全体CSS / 素の html・body・全称 * / 未使用@font-face を丸ごとコピーしない（貼ると崩れる → 上記「 貼っても崩れない形で抽出する」を必ず適用）
- そのセクションが実際に使うフォント（@font-face/Google Fonts）・インラインstyle・JS設定値（Splide等）だけコピー（未使用は入れない）
- これらを自己完結HTML 1ファイル（code-previews/<id>.html）に組み立てる

原文維持ルール（2026-08-17 大串FB同日2回で昇格・旧ダミー化ルールを廃止）：
- テキスト/コピー → 原文のまま維持（ダミー文への差し替えはしない）
- 画像 → 元の画像URLをそのまま残す（差し替え禁止）
- リンク → href="#" に無効化（外部PDF・CMSパスへ飛ばさない）
- class名・id・タグ構造・CSS・アニメ・JS は完全再現のまま変えない

Step 2 公開プレビューURLを1件ずつ送る＋確認①（唯一止まる場所）

実行順に注意（2026-08-18 改定）: 番号ではなく Step0 → Step1 → Step3（オリジナル化）→ Step3.5（レスポンシブ検品）
→ 数値照合・トップ10チェック → この Step2 で大串に提示 → OK後に Step4（格納） の順で回す。
完成品（オリジナル化・検品済み）を見せるのが前提。途中の状態を見せて確認を取らない。

2026-08-18 改定（FB④⑤）: 大串に見せるのは Chromeで開ける公開URL。
localhost・スクショ・ファイル添付で止めない（feedback-preview-chrome-url-always と同じ）。
そしてこの時点ではLabに格納しない＝add_section.py はまだ実行しない。

自分の検証はローカルで済ませる（Step3.5・数値照合・トップ10チェックまで全部通す）：

cd ~/dev/terasu-lab
python3 -m http.server 8080 --directory code-previews &   # ポートが埋まっていたら空きポートを使う
# → http://localhost:8080/<id>.html で自己確認（大串にはこのURLを送らない）

確認基準（自己確認・"だいたい"は不可）：
- 元HP（実サイト）と同じ幅で並べて比較。レイアウト・フォント・配色・余白・アニメ・ホバーが一致しているか
- 数値照合（getBoundingClientRect() 比較）で主要要素の寸法が一致していること（→「一発格納率を上げる」）
- 「ほぼ同じ」「だいたい寄った」はNG

大串に見せる手順（プレビューだけ公開・一覧には出さない）：

cd ~/dev/terasu-lab && git pull --rebase
git add code-previews/<id1>.html code-previews/<id2>.html   #  entries/ は触らない（＝Labに格納しない）
git commit -m "Add <id1>, <id2> previews (確認①用・一覧登録はまだ)"
git push
gh run watch $(gh run list --limit 1 --json databaseId -q '.[0].databaseId') --exit-status --compact   # 約1分
curl -sL -o /dev/null -w "%{http_code}\n" "https://lab.terasu.scale-group.co.jp/code-previews/<id1>.html"  # 200確認
  • code-previews/ は build_lab.py が丸ごと配信するので、entries/<id>.json を作らなくても公開URLで開ける
  • /sections 一覧には出ない＝「勝手に格納していない」状態（FB⑤を満たす）
  • git add -A は禁止（他セッションの作業を巻き込む）。自分のidのファイルだけ明示add

送り方（FB④・1件ずつ）：

できました（N件）。Chromeで開けます。

① FV（<参考元URL>）
   https://lab.terasu.scale-group.co.jp/code-previews/<id1>.html
② 料金表（<参考元URL>）
   https://lab.terasu.scale-group.co.jp/code-previews/<id2>.html
…

OKなら格納します。直すところがあれば言ってください。
  • 1件につき1URL。まとめて1リンクにしない（FB④「一つ一つ」）
  • 各URLにその件の参考元URLを添える → 送る前に組み合わせが合っているか照合（FB⑦の再発防止）
  • 200を確認してから送る（開けないURLを送らない）

ここで止まり、「OK／格納して」が来てから Step3・Step4 へ進む。
複数箇所のときも同じ＝全件そろえてから一括で提示する（1件ずつ止めない）。OKが出た件だけ格納へ。

Step 3 TERASUオリジナル化＋確認②

実行タイミング＝Step1の直後・Step2（大串に見せる）より前。オリジナル化まで済ませた完成品を見せる。

大原則：構成・デザイン・アニメを崩さず、コードだけ変える

確認なしでそのまま一気に実行する：

  1. リネームマッピング表を作成：
変更前（参考元） 変更後（TERASU汎用）
固有のclass名・id 内容を表す汎用名
固有ブランドフォント（必要な場合） 代替フォント or そのまま
外部CMSパス・WordPressパス（CSS/JSに残っているもの） 除去

  1. 全ファイル横断で同時置換（HTML/CSS/JS）（1個ずつ順番に変えない）

  2. grep で固有クラス名・CMSパスの残存ゼロを機械検証（本文は原文維持なので対象外。社名由来のclass名＝-kurokawa のような修飾子も対象）：
    bash grep -n "<固有クラス名>\|<WordPress/CMSパス>" code-previews/<id>.html # → ゼロ件であること（テキスト本文・画像URLに含まれる社名/ドメインは残ってよい）

  3. CMS痕跡除去：WordPressパス・固有アセットパス・data属性ID・生きた外部リンクが残っていないか確認（本文テキストは触らない）

  4. 画像は触らない（参考元URLのまま維持）

  5. スコープ漏れの機械検証：<style> 内に html/body/全称 * を対象にした素のルールが残っていないかを確認（残っていたら "貼ると崩れる" ＝ 必ずスコープ化する）：
    bash grep -nE '^\s*(html|body)\s*[,{]|^\s*\*\s*[,{]|[,}]\s*(html|body)\s*[,{]' code-previews/<id>.html # → ゼロ件であること

  6. 確認②（自己確認・大串には聞かない）：リネームでレイアウト崩れ・アニメ消滅がないかローカルで再確認。問題あれば直してから次へ。

Step 3.5 レスポンシブ検品（登録前の機械ゲート・省略禁止）

2026-07-24 新設。元サイトのPC前提の指定を抜き出したまま登録すると、タブレット/スマホで横スクロールが出る。
これまで確認する工程が無く、あとから10件まとめて直す羽目になった（同日 48件検出→本物10件を修正）。
登録の前にここで必ず止める。

cd ~/dev/terasu-lab
node tools/check_responsive.mjs <id>      # PC(1440)/タブレット(768)/スマホ(390) の3幅で検品
  • ✅ が出るまで Step 4 へ進まない（要確認が1件でもあると exit 1 で止まる）
  • 落ちた時の直し方（実地で効いた型・元サイトの見た目は変えない）:
出方 よくある真因 直し方
タブレットだけ横スクロール 元サイトが body{min-width:…} でPC版を横スクロールさせる設計 その帯だけ min-width:0 で打ち消す
固定幅が縮まない 親が grid で、max-width:100% が効かない min-width:0 を添える／その帯だけ1カラムに戻す
装飾やスライドインが外へ出る 切ってくれる親が無い 器に overflow-x: clip（縦のstickyを壊さない）
中身が並びきらない PC前提の列数のまま 1023px以下の列数を減らす＋中身に max-width:100%
  • 直すのは元サイトのPC表示ではなく「抜き出した後の収まり」。PC(1440)の見た目は変えないこと
  • 逆に、マーキーやカルーセルの中身が画面外にあるのは正常（親が切っている＝横スクロールは出ない）。
    検品はそれを除外済みなので、⛔ が出たら本物の崩れだと思ってよい

Step 4 TERASUlabのセクションに格納（大串のOK後にのみ実行）

勝手に格納しない（2026-08-18 大串FB⑤・恒久）。Step2でプレビューURLを送り、
「OK」「格納して」という明示の返事が来てからこのStepに入る。返事が無いうちに add_section.py を実行しない。
（プレビューHTMLのpushは済んでいる＝ここで足すのは entries/<id>.json と サムネ＝一覧への掲載）。

cd ~/dev/terasu-lab
python3 tools/add_section.py --id <id> --kinds <分類30種から1〜2つ> --cats <旧語彙・互換用> \
  --caption "<分類｜会社名：説明>" --url "<参考元URL>" \
  --author ogushi --contributor <ogushi|saki|hosokawa>
node tools/shoot_section.mjs <id> && python3 tools/normalize_thumbs.py <id>   # サムネ生成（4:3・2倍）
python3 core/build_core.py && python3 build.py    # 共通データ→Labデータの順で集約
git add entries/<id>.json img/sections/<id>*.png code-previews/<id>.html   #  `git add -A` 禁止（他セッションの作業を巻き込む）
git commit -m "Add <id> section" && git pull --rebase && git push
# push で GitHub Actions が本番へ自動デプロイ（約1分）。完了を待ってから確認する:
gh run watch $(gh run list --limit 1 --json databaseId -q '.[0].databaseId') --exit-status --compact
curl -sL -o /dev/null -w "%{http_code}\n" "https://lab.terasu.scale-group.co.jp/code-previews/<id>"  # 200確認

反映確認は「一覧ページ」で見る。sections-data.json を見ない（2026-07-23 実地で誤認）。
ルート直下の sections-data.json は現在ページから参照されていない残骸で、CDNに s-maxage=604800（1週間）で
古い内容がキャッシュされ続ける。これを見て「反映されていない」と誤判定しないこと。正は本番の /sections。

--kinds は必須（絞り込みの正。入れないと一覧の分類で探せない）。使える30種:
header / fv / problem / service / case / reason / flow / price / qa / cta / footer / company / news / contact / numbers / pricetable / access / bloglist / blogpost / download / breadcrumb / sidebar / megamenu / drawer / pagination / error / chart / heading / imgtext / bgimage

--url は純粋なURLだけ（「（実コード抽出→…）」等の注記を付けない＝詳細ページでリンクが壊れる）。

複数箇所をまとめて格納するときは、add_section.py＋サムネを各件ぶん回してから、集約とpushは1回だけにする：

cd ~/dev/terasu-lab
for id in <id1> <id2> <id3>; do   # 各件 add_section.py は個別引数が要るので実際は1件ずつ実行する
  node tools/shoot_section.mjs "$id" && python3 tools/normalize_thumbs.py "$id"
  node tools/check_responsive.mjs "$id"     # 各件レスポンシブ検品（1件でも落ちたらそこで止めて直す）
done
python3 core/build_core.py && python3 build.py
git add entries/<id1>.json entries/<id2>.json entries/<id3>.json img/sections/<id1>*.png img/sections/<id2>*.png img/sections/<id3>*.png   # -A 禁止
git commit -m "Add <id1>, <id2>, <id3> sections (from <サイト名>)" && git pull --rebase && git push
gh run watch $(gh run list --limit 1 --json databaseId -q '.[0].databaseId') --exit-status --compact  # CI待ちも1回

→ DOM取得・push・デプロイ・CI待ちが1回で済む（同時作業の衝突リスクも減る）。品質工程は各件で完了済み。

  • id: <サイト識別スラッグ>-<主題>-<author>-<MMDD>（例 tomatec-fv-ogushi-0818 / kaunis-qa-saki-0818）
  • 先頭のサイト識別スラッグは必須（2026-08-18 FB⑦）。旧ルール「参考元社名は使わない」は衝突事故のため廃止：
    汎用主題（contact-form 等）が別サイト間で衝突して既存プレビューを上書きし、大串に別サイトのプレビューが送られた（2026-07-26 ksart×UMICAHI）。
  • 配置前に既存id衝突を必ず確認する: ls code-previews/<id>.html entries/<id>.json 2>/dev/null → 何か出たら別idにする
  • cats: fv / heading / navbar / logos / features / service / works / gallery / testimonial / pricing / qa / news / cta / footer / access / layoutdesign / motion（動きあり＝motionも付与）
  • caption（タイトル）＝ 分類｜会社名：説明（2026-07-23 大串決定・恒久）
  • 分類＝下記30種の日本語ラベルそのまま（FV ヘッダー CTA サービスの特徴 …）。複数該当するときは主たる1つを先頭に。
  • 会社名＝参考元サイトの正式名称。URLから機械的に取る（og:site_name → title の最短要素 → 参考HP集(core/data/reference-sites)に同じドメインがあればその name）。
    自社デモ由来は TERASUデモ。社名を業種で代用しない（旧データは「企業サイト｜…」等が混在していたので2026-07-23に全97件を書き換え済み）。
  • 説明＝あってもよい（詳細ページの「どんなセクション？」に出る）。無くても可。
  • 例) FV｜こばクリニック：耳・鼻・喉を有機シェイプで選択、ホバーで色切替 / CTA｜JILLION（株式会社ジリオン）
  • 一覧カードに出るのは「：」より前＝分類｜会社名。カード幅263px・13pxで約18字を超えると「…」で切れるので、会社名が長い時は正式名称の主要部分にとどめる。
  • ** contributor（追加者・評価軸）: 誰がLabに還元したかを必ず入れる**（大串=ogushi / 咲輝=saki / 細川=hosokawa）。/sectionsの追加者フィルタで「誰が積極的に還元したか」の評価に使う。
  • 判断ルール: 文脈で誰の成果か分かれば --contributor で明示。分からなければ大串に1問だけ聞く（「これは誰の分ですか？ 大串/咲輝/細川」）。
  • 省略時: git user.email が個人アカウントで tools/contributors.json に登録済みなら自動特定。ただし現状の共用アカウント(backoffice@…)では特定できず「未設定」になるので基本は明示指定する。
  • サムネは tools/shoot_section.mjs ＋ tools/normalize_thumbs.py で撮る（2026-07-23 大串指示で刷新・旧 tools/shoot.sh は廃止）
    bash node tools/shoot_section.mjs <id> # 実際の高さを測って撮影（4:3・2倍・自動検品） python3 tools/normalize_thumbs.py <id> # 余白トリミング→4:3(2880×2160)へ正規化
  • なぜ刷新したか: 旧 shoot.sh は高さを人が手で渡す方式で、実測すると比率が 1.00〜2.29 でバラバラ・等倍・検品なしだった。
    カードは4:3なので比率が合わないと上下左右が切れる。セクションは画像で選ぶので、ここが体験を決める（大串）。
  • コードを変えたら必ず撮り直す（古いサムネが残ると一覧が実物と食い違う）
  • 検品に落ちた（単色・空白）ものは保存されない＝既存の正しい画像は壊れない。落ちたら原因を直して撮り直す

Step 5 報告（事実だけ）

リンクは局面で使い分ける（2026-08-18 整理）:
- Step2（格納前・確認①） → https://lab.terasu.scale-group.co.jp/code-previews/<id>.html を1件ずつ（まだ詳細ページは存在しない）
- Step5（格納後） → 詳細ページ /section/<id>/ を1件ずつ

  • 追加セクション名 / 詳細ページ / /sections一覧
  • 作った件数と受領素材の件数を照合して書く（例「スクショ3＋動画2＝5件、5件とも追加」）。作れなかった件は理由を明記（FB③）。
  • 各セクションのリンクは「詳細ページ /section/<id>/」で送る（2026-07-25 大串FB「①②送るときはそれぞれのセクションの詳細ページのリンクにして」）。code-previews/<id>.html（生プレビュー）を第一リンクにしない＝詳細ページの方が分類・参考元リンク・共通点などが見られるため。
  • 「次は？[1][2][3]」は付けない。

退化禁止・順守

  • 既存 entries/code-previews は壊さない（新規 id で足すだけ・git add -A 禁止＝自分のidのファイルだけ明示add・push前 git pull --rebase）
  • 「寄せる」近似・CSS書き直しで完成扱いにしない（最大の禁止事項）
  • コード変更後は必ずデプロイ・本番URLで反映確認
  • 勝手にLabへ格納しない（entries登録は大串のOK後）／着手前の確認で止まらない（素材が来たら即作る）／送られた素材は全件作る（動画も1件）

自動学習

知見・大串FB・うまくいった抽出/オリジナル化パターン・抽出不可だった実装方式は 22_AI運用ルール/コマンド集/section/learning.md に追記。

関連

  • 22_AI運用ルール/コマンド集/hp-flow/hp-flow（品質基準の本体）
  • ※ 旧 /design-decode（スクショの精密分析）は 2026-07-20 廃止。分析はこのコマンド内の Step0〜1 で行う
  • 正本リポ ~/dev/terasu-lab（GitHub: scale-group-jp/terasu-lab・git push で本番自動デプロイ）
    共通部分は submodule core/（scale-group-jp/terasu-web-core）＝参考HPのデータ・カード・絞り込み・お気に入り
  • ツール: tools/add_section.py（登録）/ tools/shoot_section.mjs + tools/normalize_thumbs.py（サムネ）/ tools/check_responsive.mjs（レスポンシブ検品＝登録前ゲート） / core/build_core.py → build.py（データ集約）
    ※ 旧 tools/shoot.sh は 2026-07-23 廃止（高さを手渡し・比率バラバラ・検品なしだったため）

変更履歴（★=大きな変化）

ver 日付 変更内容
v2.7 2026-08-20 ★「追加者の件数が日によって変わる」を根治（大串FB）。原因は3つ重なっていた。①KVと正本JSONの二重管理＝画面で付け替えた追加者は Cloudflare KV に貯まり、表示時に上書きする作り。sync_meta.py で正本へ書き戻す設計だったが、リポ分離(7/23)で参考HPの正本が core/data/ へ移ったのにツールが旧パスを見たままで、以後1件も書き戻せていなかった（96件が毎回スキップ）。結果、画面の数字はKVの読み込みが間に合ったかで変わる（実測 さき 19⇔95）。→ パスを修正し134件を書き戻してKVを空にし、数字を一意にした。追加者を画面で付け替えたら python3 tools/sync_meta.py --apply → 再ビルド → デプロイまでを必ずセットで行う。②lab-deleted はブラウザのlocalStorageだけに保存され、サーバと同期しない＝端末ごとに表示件数が違う（実測92件が非表示・うち参考HP20件で さき95→83・大串315→307）。件数を照合するときは必ず「どの端末で見た数字か」を確認する。③追加者の記録が無いものは build_lab.py が自動で大串に寄せる（2026-07-23 大串指示・仕様）。
正確な数字の出し方＝画面のサイドバーではなく、build_lab.py の contribs_of() を正本JSONに当てて数える（画面と同じ計算式・端末差の影響を受けない）
v2.6 2026-08-20 ★サムネの比率崩れを根治（大串FB「サムネ拡大されすぎ」）。撮影はセクションの実際の高さで撮るため、中身が低いと 2880x960（3:1）のような横長画像になり、4:3のカードに載せると横が大きく切られて拡大表示に見える。直すのは normalize_thumbs.py（引き伸ばさず背景色で上下を足す）だが、「撮影→正規化」が人の2コマンド運用だったため2つ目を忘れると必ずこの不具合になっていた（実測14件が4:3でなかった）。→ shoot_section.mjs の末尾で normalize_thumbs.py を自動実行するよう一体化し、忘れようがなくした。あわせて②詳細ページは __detail.png / __sp.png という別ファイルを使う＝カード用の1枚だけ差し替えても詳細ページは古いまま。プレビューの見た目を変えたら3枚セットで作り直す。③出現アニメで位置が決まるセクション（段違いカード等）は freezeAnim が0秒で固定するため重なったまま撮れる→アニメを止めず素撮りして差し替える
v2.5 2026-08-20 ★「サムネと違う／中身が崩れている」の2大原因を根治（大串FB11件の調査で判明）。①@font-face の base64 が二重に書き込まれると、その1行でCSSが全滅する＝format("woff2");base64,… という残骸が残り、ブラウザは2ルールしか解釈しない（残り数万字が全部死ぬ）。実測16件が被害。プレビューが「文字だけ・リンクが青い下線」に見えたらまずこれを疑う。検出＝grep -l 'format("woff2");base64,' code-previews/*.html／検証＝style.sheet.cssRules.length が二桁あるか。②カードを横に並べるスライダーは oneSlide で1枚に潰される＝サムネだけカード1枚・プレビューは4枚という不一致になる。shoot_section.mjs に --keep-slider を新設（既定はON のまま・並列カード系だけに付ける）。③ヘッダー/メガメニュー単体のセクションは、閉じた状態だとサムネが真っ白になり採用ゲートに落ちる→開いた状態を撮ってサムネにする。④本番の検証で ?f= 等のクエリを付けない（Labは0バイトを返すため「直っていない」と誤判定する）。CI完了を gh run list で待ってから検証する
v2.4 2026-08-18 ★大串FB7点を恒久ルール化（冒頭に最優先ブロックを新設）。①本文は原文のまま（3回目の指摘で確定）／②素材が来たら確認せず即着手（「これで合っていますか？」禁止・canvasで止まらない）／③送られたスクショ・動画は全件作る（動画も1件＝棚卸し表と件数照合を必須化）／④完成後は1件ずつChromeで開ける公開URLを送る（localhost禁止）／⑤勝手に格納しない＝code-previewsだけpushして一覧未登録の公開URLで見せ、OK後にadd_section.py／⑥一発格納率10-20%の改善＝learning.mdに埋もれていた「崩れる原因トップ10」とgetBoundingClientRect()数値照合を本体に昇格し登録前ゲート化／⑦違うHPのプレビュー混入を構造的に防止＝/tmp/dom.html固定を廃止しサイト別作業ディレクトリ＋idにサイト識別スラッグ必須＋送信前のドメイン照合。あわせて git add -A 禁止を全コマンド例に反映
v2.3 2026-08-17 ★テキスト本文のダミー化を廃止＝原文のまま維持（大串FB「ダミーテキストじゃなくて本文入れて」同日2セッションで2回→昇格）。Labはデザイン実例集＝実際の文字組がそのまま分かる状態が価値。Step1は「抽出＋原文維持」に、Step3のgrep検証は固有クラス名・CMSパスのみ対象に変更（本文・画像URLの社名/ドメインは残ってよい）。リンクは従来どおり # に無効化
v2.2 2026-07-25 ★1サイトから複数箇所をまとめて追加できるように（大串指示）。DOM/CSS取得・push・デプロイ・CI待ちは1回にまとめ、抽出・確認①・機械検証・レスポンシブ検品・サムネは各件で必ず実施＝品質は1個ずつと同じ。確認①は「全件そろえてから一括提示」、抽出不可(canvas等)の箇所はその件だけ外して他は止めない。1件だけのときは従来フローのまま
v2.1 2026-07-24 ★Step 3.5 レスポンシブ検品を新設（登録前の機械ゲート・省略禁止）。tools/check_responsive.mjs を PC/タブレット/スマホの3幅で必ず通し、✅ が出るまで登録に進まない。落ちた時の直し方（body の min-width 打ち消し／grid の子は min-width:0／装飾は overflow-x:clip／1023px以下の列数を減らす）も表で明記。同日の全件検品で 106/106 合格を確認済み
v2.0.1 2026-07-23 実地で見つかった定義の食い違いを修正: 関連ツール欄が廃止済み shoot.sh のままだったのを是正／Step4のコマンド例を実仕様に一致（--kinds 必須・URL注記禁止・core/build_core.py 追加・CI待ち）／反映確認は /sections で見る（sections-data.json は残骸・CDNに1週間キャッシュされ誤認の原因） を明記
v2.0 2026-07-23 ★リポ分離に追従（~/dev/terasu-lab＋共通は submodule core/）。タイトルの命名規則を 分類｜会社名 に統一し、add_section.py に --kinds 必須・URL注記の禁止・18字チェックを追加。サムネは shoot_section.mjs＋normalize_thumbs.py（4:3・2倍・採用ゲート）に刷新。起動時にコマンド定義を最新化する手順を追加
v1.9 2026-07-22 /mikke からの入口B（スクショだけで来た場合はURLを聞かない）を追加
v1.8 2026-07-19 セクションは sec-<id> にスコープ化して抽出（貼っても崩れない形）を恒久ルール化