learning
/hp-flow 学習ログ（セルフ進化の蓄積）
このファイルは
/hp-flowが自動で読み書きする学習の記憶。
ユーザーがFB（不満・改善要望・「次からこうして」等）を出すたびに、Claude がここに記録し、恒久ルールはhp-flow.md本体にも反映する。
- 起動時：
/hp-flowはまずこのファイルを Read して過去の学習を継承する- FB検知時：下の「学習履歴」に1行追記
- 恒久化：種別Aは
hp-flow.md本体を書き換え、種別Bは候補として蓄積（同じ趣旨が3回出たら本体昇格）Vault共有 + シンボリックリンク方式のため、ここへの記録は全メンバーの
/hp-flowに伝播する。
現在の確定学習（hp-flow.md 本体に反映済み）
| 確定ルール | 反映先 | 確定日 |
|---|---|---|
| 6ステップ→10ステップに拡張。最初〜公式公開まで全部入り化 | hp-flow.md 全体 | 2026-05-30 |
| Step7 著作権最終監査ゲート（grep指紋監査 + 8項目チェック・クリアしないと公開不可） | hp-flow.md Step7 | 2026-05-30 |
| Step8 公開準備（プリフライト + SEO内部対策 + 公開前NG最終チェック） | hp-flow.md Step8 | 2026-05-30 |
| Step9 本番公開（公式ドメイン・DNS・SSL・MXレコード保護・本番のみ枠使用） | hp-flow.md Step9 | 2026-05-30 |
| Step10 公開後SEO設定（Search Console・GA4・sitemap・Bing・権限付与） | hp-flow.md Step10 | 2026-05-30 |
| 4ステップ→6ステップに再構成。オリジナル化を完全再現の後に分離 | hp-flow.md 全体 | 2026-05-30 |
| 置換漏れゼロ方式（リネームマッピング→全ファイル横断同時置換→grep検証→前後比較） | hp-flow.md Step4 | 2026-05-30 |
| 確認①②を必須化（①完全再現が元と一致 ②オリジナル化後にStep3から不変） | hp-flow.md Step3/Step4 | 2026-05-30 |
| Cloudflare枠を使わない（プレビューはローカルpython http.server/live-server） | hp-flow.md Step3 | 2026-05-30 |
| TERASUオリジナル化（コード指紋ゼロ化）11項目 | hp-flow.md Step4 | 2026-05-30 |
クラス名・id・CSS変数を t-* プレフィックスにリネーム |
hp-flow.md Step4 | 2026-05-30 |
| Prettier整形で元フォーマット癖を除去 | hp-flow.md Step4 | 2026-05-30 |
| セルフ進化プロトコル（FB自動検知→本体書き換え）導入 | hp-flow.md セルフ進化セクション | 2026-05-30 |
| 起動時シンプル化（参考HP送ってだけ表示） | hp-flow.md 起動時の挙動 | 2026-05-30 |
| ローカルプレビューURLはタップリンクで毎回共有（生URL禁止・修正のたび立て直し） | hp-flow.md Step3 + 振る舞いルール | 2026-05-30 |
| 完全mirror手順（STEP0）: wget3欠陥補完（①クエリ付きCSS/JS ②JS動的SVG ③遅延動画）+ network404ゼロ検証ゲート。これ省くとJS駆動サイトは50%再現 | hp-flow.md Step1 STEP0 | 2026-05-30 |
| 全ページ一括方式: Step1でTOP＋全下層を一度に抜き出し→Step4で全ページ一気にオリジナル化。ページ毎に分けない（共通アセット補完1回・リネームマッピング全ページ一貫適用）。STEP0があれば一括でも品質維持 | hp-flow.md 設計思想/全体像/Step1,2,4 | 2026-05-30 |
| 文章工程の強化（SEO/CVコピーライティング）: Step5にSEOキーワード逆算＋問い合わせ導線(CV)設計＋重要コピー複数案、Step10に「文言の最終調整（デザイン不変・SEO最終チェック・CV文言複数案→選定）」を追加。デザインは1pxも変えず文言だけ強くする | hp-flow.md Step5/Step10/全体像 | 2026-06-16 |
着手前「結合度」判定でリネーム方針を分岐（候補→昇格）: 密結合バンドル（minified束/ノーコード生成/data駆動/汎用クラス）は blanket t-*改名を既定で見送り、Stage A（フラット化・ビルドハッシュ→中立名・トラッキング/メタ/CMS/元ドメイン指紋の全除去・CSS変数→--t-*）を必須。検証は before vs after を同一手順で計測しbodyH/全セクション高さ/色/data-count/エラー0の完全一致で1mm不変を証明 |
hp-flow.md Step4「結合度判定」節を新設 | 2026-06-19 |
| 納品前QAゲート化（StockSun品質ガイドライン反映・設定ミス＝サイレント機会損失を構造的に潰す）: Step10を「公開準備」→「納品前QAゲート」に格上げ（フォーム双方向疎通＋スパム耐性＋入力体験／URL正規化 www301・末尾スラッシュ・HSTS／index・noindex方針＋sitemap整合／信頼性ページ／誤字脱字／構造化データ per-page）。Step11にリニューアル時 301リダイレクト移行分岐＋旧サイトバックアップ。Step12を「設定→実測検証」に強化（GA4データ保持14か月・テスト送信でキーイベント発火を目視・電話/LINEクリック計測・GTM／外形監視 UptimeRobot／ドメイン・SSL期限／GSCエラー定期） | hp-flow.md Step10/11/12・全体像・振る舞いルール | 2026-06-24 |
用途分岐（デモ/クライアント）をStep1冒頭に新設: クライアント納品用=全12ステップ不変／デモ用=簡略ルート（トップのみ作成・他メニューは全リンクhref="./"でトップ遷移・流し込みは本番同様だがGitHub立ち上げ(Step5)はスキップしローカルプレビューのみ・著作権監査(Step8)は残す・Lab還元(Step9)が正式ゴール・公開系Step10-12はスキップだがStep10の軽量チェック[リンク切れ0/コンソール0/全メニュートップ遷移]だけ実施）。完成デモは別ワークフローfeedback_terasu_demo_workflowの/demos公開へ橋渡し |
hp-flow.md 設計思想・用途分岐プロトコル新設・全体像・起動時・Step1/2/5/8/9/10/11/12・振る舞いルール | 2026-06-25 |
| Step7「スマホ最適化」→「レスポンシブ対応」にリネーム＋全端末幅へ拡張: 対象を大画面PC(2560/1920)〜小型ノート(1440/1280)〜タブレット(1024/768)〜スマホ(430/360)の全レンジに。「PC不変」→「基準デザイン不変」に整理（基準=確定PCデザインは1px不変／各幅へのフィットはデザイン改変でない）。チェック項目に大画面/小型ノート/タブレット3行追加。標準パック4点・実装テク8項目・自己進化ループ（スマホ帯の蓄積）は中身維持。アイコン | hp-flow.md Step7全体・全体像・description・Step6遷移・横展開例 | 2026-06-29 |
| v1.4: ブラウザ/シェア表示チェック強化＋マルチデバイス確認ビューア＋コマンドver管理導入: ①冒頭に改訂履歴(ver管理)セクション新設(直近3ver＋★・「ver◯に戻して」でgitロールバック)＋セルフ進化に「改修ごとver+1」 ②Step7にマルチデバイス確認ビューア(responsive-check.html・375〜1920ボタン＋任意px・タップリンク共有) ③Step10に「ブラウザ・SNSシェア表示」独立小節(title/favicon/OGP全下層grep網羅＋favicon[svg/png/apple-touch]・OGP画像[1200×630]作成手順＋ラッコツールズ実機シェアプレビュー) ④デモも最小メタ(favicon/title/OGP)必須化(リンクで送るのにStep10スキップで抜けていた穴を塞ぐ) | hp-flow.md 冒頭・セルフ進化・Step7・Step10・用途分岐表・振る舞いルール | 2026-06-29 |
| v1.5: Step10「文言の最終調整」→「ライティング・コピー最終監査」に格上げ＋コピープレイブック新設: TERASUは問い合わせが来るHPを作る会社＝ライティングが最重要差別化。①誤字脱字・表記ゆれ全文チェック ②コピー改善診断(弱いコピーのサイン5型→改善＝自社主語→お客様主語/機能羅列→ベネフィット/抽象→具体数字/命令CTA→ベネフィット型/専門用語→平易) ③改行・読みやすさ設計(一文短く・意味で改行・ひらく・PC/SP両方) ④「問い合わせが来るコピーの型」プレイブック(ヘッドライン公式/ベネフィット変換/CTA設計/不安解消/社会的証明/PASONA-PREP/読みやすさ)。コピーFBも汎用昇格(Step7自己進化のコピー版) | hp-flow.md Step10・全体像・冒頭ver管理(v1.5) | 2026-06-29 |
v1.7: クライアント用は固定プレビューリンク(pages.dev)必須・一時トンネル共有禁止を明記: 発端=クライアント納品HPの共有リンクがtrycloudflare.com(cloudflared一時トンネル)になり「前と違う・1つのリンクに修正入れて完成で本番接続にしたい」。原因=Step5のGitHub立ち上げを飛ばしローカルを一時トンネル共有(毎回URL変わる・消える)。Step3共有リンク[c]に「一時トンネルは自分の確認用のみ・クライアント共有はStep5固定preview link」明記＋振る舞いルール追加 |
hp-flow.md Step3・振る舞いルール・冒頭ver管理(v1.7) | 2026-06-30 |
v1.8: 一時トンネル概念を廃止・クライアント用は最初からGitHub固定プレビューリンクに統一: 大串「一時トンネルって概念がいらない・全部GitHubで接続してクライアント名入れたプレビューリンク作ってそこに改修・本番ドメイン接続できたら接続」。→ Step3から一時トンネル(ngrok/localhost.run/cloudflared/trycloudflare)記述を全削除。クライアント用は案件開始時(Step1着手時)にクライアント名でGitHub立ち上げ→最初からpreview.client-◯◯.pages.devにpushして制作・改修・共有→完成でmain本番接続。ローカルは自分の確認用。デモはローカルのみ。設計思想/全体像/Step3/GitHub立ち上げ見出し/振る舞いルール統一 |
hp-flow.md 設計思想・全体像・Step3・GitHub立ち上げ・振る舞いルール・冒頭ver管理(v1.8) | 2026-06-30 |
v1.9: デモ用もGitHub接続・固定プレビューリンクをクライアント用と同じに統一: 大串「デモ用もgithub接続して、リンクもクライアント用と同じに」（前回v1.1のデモ=ローカルのみGitHubスキップから変更）。→ デモも案件開始時にデモ名(demo-◯◯)でGitHub立ち上げ→固定リンクpreview.demo-◯◯.pages.devにpushして改修・共有(クライアント用と同じ運用)。違いは出口だけ＝デモは本番接続せずStep9 Lab還元＋/demos公開がゴール。用途分岐デモ表/設計思想/全体像/Step3起動時提示・公開コマンド/Step5 GitHub立ち上げ(デモはスキップ→デモも実行)/振る舞いルール統一。デモの簡略化(トップのみ/他メニューtop遷移/公開系Step10-12スキップ)は維持 |
hp-flow.md 用途分岐表・設計思想・全体像・Step3・Step5・振る舞いルール・冒頭ver管理(v1.9) | 2026-06-30 |
| v2.0: 常に最新verで進行する仕組みを導入: 大串「v1.6で作り始めて途中で1.9にアップデートされたらそのセッションはどのverで進む?理想は常に最新」。現状=起動時に読んだ版で固定進行(v1.6のまま)。→ セルフ進化起動時を強化(①git pullで最新化②hp-flow.md自身+learning.mdをRead③現行ver表示)＋「セッション中の最新同期」新設(各ステップ節目で最新版Read→verが上がってたら通知して最新で続行・作業はやり直さず手順だけ乗換)＋起動時挙動に現在ver表示＋冒頭ver管理に「ver今何?」応答。技術上毎瞬完全最新は不可(コンテキストは読んだ瞬間固定)だが節目で読み直せば実用上ほぼ最新 | hp-flow.md セルフ進化プロトコル・起動時挙動・冒頭ver管理・冒頭改訂履歴(v2.0) | 2026-06-30 |
v1.6: Step7に「⑤ PC幅 等比ズーム」新設(標準パック4→5点): iMacとMacBookで余白感が違うFB。当初「中央寄せ(max-width固定で左右余白)＝A案」で焼いたが、大串「左右の余白が気になる。iMac等大画面ではMacBookの画面がそのままズームされる感覚にして」と明確化→等比ズーム(B案)が正解。基準幅(MacBook・通常1440)以上で @media(min-width:1441px){:root{zoom:calc(100vw/1440)}}(堅牢版はJS clientWidth/base でスクロールバー誤差回避)→大画面はMacBook画面を等比拡大＝左右余白ゼロ・余白比率/文字/要素すべてMacBookと相似。基準幅未満は通常レスポンシブ。zoom採用理由＝transform:scaleと違いfixed/スクロール量が正しい・全モダンブラウザ対応。上限キャップmin(...,1.6)は任意。検証=1440/1920/2560で相似・左右余白なし・横スクロールなし |
hp-flow.md Step7(標準パック⑤・チェック項目「等比ズーム」行)・冒頭ver管理(v1.6) | 2026-06-29 |
学習履歴（FB検知の全記録）
| 日付 | FB者 | FB内容 | 種別 | 対応（本体のどこをどう変えたか / 候補のまま） |
|---|---|---|---|---|
| 2026-05-30 | 大串 | コードを裏側で見られた時に「うちの作り方じゃない」とバレるリスク。オリジナル化したい（A案） | A | hp-flow.md Step1/2にTERASUオリジナル化11項目を追加 |
| 2026-05-30 | 大串 | 使うほど自動でコマンドが良くなる設計にしたい。FBはセッション内どこでもOK | A | hp-flow.md にセルフ進化プロトコルを新設。learning.md（本ファイル）を作成 |
| 2026-05-30 | 大串 | hp-flow打ったら、まず参考HP送ってだけ来るシンプルな起動にしたい（4ステップの長い説明は不要） | A | hp-flow.md「起動時の挙動」をB案に変更。起動時はlearning.md読込→「参考にするHP送って」だけ表示。フロー全体説明は省略 |
| 2026-05-30 | 大串 | オリジナル化で置換漏れ→ボタン押せない/再現できない問題。完全再現を先に確認→後でオリジナル化→再確認の流れにしたい。プレビューはCloudflare枠使わない | A | 6ステップに再構成。Step3プレビュー+確認①（完全再現）、Step4オリジナル化+確認②（不変）。置換漏れゼロ方式（マッピング→横断同時置換→grep検証→前後比較）。プレビューはローカル |
| 2026-05-30 | 大串 | Step6後に最終チェック（元サイトとバレる箇所・著作権の監査）を追加。そこから公式ドメイン公開・SEO対策まで全部できる「最初〜最後まで」のコマンドにしたい | A | 10ステップに拡張。Step7著作権最終監査ゲート・Step8公開準備+SEO内部・Step9公式ドメイン公開・Step10公開後SEO設定を追加。manual-terasuの該当章を参照 |
| 2026-05-30 | 大串 | Step1の抜き出し、テキスト空・画像プレースホルダだと元と同じか確認できない。テキストは同じ長さのダミー文を入れる・画像は元のまま残す（あとで変更前提）仕様にしたい | A | Step1/2を「ゼロ化」→「ダミー化」に変更。テキスト=同長ダミー文（空・プレースホルダ禁止）、画像=元のまま。Step3確認①でレイアウト一致を判断可能に。Step7監査Aに「元画像ゼロ確認」を最重要項目として追加（Step5で全差し替え必須） |
| 2026-05-30 | 大串 | リンクタップできない / ローカルホストで毎回デプロイして これルールで | A | Step3に「ローカルプレビュー共有ルール」新設（タップリンク必須・生URL禁止・修正のたび毎回立て直し）。確認①の{URL}をMarkdownリンク形式に。振る舞いルールテーブルに1行追加 |
| 2026-05-30 | 大串 | mont.jp初回再現が5割（page-top.css 75KB欠落・JS動的SVG14個欠落・クエリ付きCSSのMIME破壊）。時間かかっても初回から完全クオリティで出し修正ラリーを減らせ | A | Step1にSTEP0「完全mirror（wget3欠陥補完）」を新設。preview_network 404ゼロ検証ゲート追加。--restrict-file-names禁止明記。「最初からこのクオリティ」を恒久化 |
| 2026-05-30 | 大串 | Step1でTOP＋下層を全部一気に抜き出し→次に全部一気にオリジナル化にしたい（分けてたのは品質懸念だが保てるなら統合したい） | A | 設計思想に「全ページ一括方式」追加。全体像テーブル/Step1（全ページ一括抜き出し）/Step2（量産代表化・仕上げ）/Step4（全ページ一括オリジナル化）を再構成。品質はSTEP0で担保 |
| 2026-05-30 | 大串 | オリジナルコード完成後の修正は ①修正のたびver番号更新(ver◯に戻すやり取りを楽に) ②極力複数パターン提示(ラリー削減) ③本体localhost=正本に採用版だけ反映・選定は専用プレビューリンク・本番ドメイン直結は全修正完了後 ④リンク混同/反映漏れ事故を防ぐ | A | 「改良フェーズ運用プロトコル（ver管理＋複数パターン＋リンク事故防止）」セクションを新設。本体localhost=正本/専用プレビュー=選定用の二層構成・ver+1+backup+ver管理表+ロールバック・複数パターン並列プレビュー・反映漏れ防止5点チェックを明文化。Step6改良ループにも反映 |
| 2026-05-30 | 大串 | ある程度デザイン完成したらSEOの前にスマホ最適化ステップを入れたい。先に最適化してから「スマホで確認してFB」と依頼。注意点はPC見た目が崩れること | A | Step7「スマホ最適化」を新設（改良6の直後・著作権監査8の前=スマホCSSも監査対象）。10→11ステップ化(旧7-10を8-11にrenumber)。最重要注意=PC不変(@media内限定/PCルール非改変/前後PC比較)。先に最適化→その後スマホ実機FB依頼の順を明記 |
| 2026-06-12 | 大串 | TERASUコードオリジナル化の必須前提が抜けてた。「参考にしているHPの構成・デザイン・アニメーションを崩さずにオリジナル化する」。参考にした理由はそのデザイン・構成・動きが良いから。崩したら参考にした意味がなくなる。コードだけ変える・見た目は1ミリも変えないを堅持 | A | hp-flow.md Step4冒頭に「 大原則（絶対前提・違反したらやり直し）」セクションを新設。絶対に変えてはいけないもの5項目（構成/デザイン/アニメーション/インタラクション/レスポンシブ挙動）を表で明示。確認②を厳格版に強化（カテゴリ別5枠で40+項目チェックリスト・「ほぼ同じ」じゃダメ「完全に同じ」じゃないと進めない明記・大原則違反検知ルール追加） |
| 2026-06-12 | 大串 | 専門家でも見抜けないレベルにブラッシュアップしたい。9つのコピー痕跡(DOM構造・CSS値・アニメ・コード順・属性順・ライブラリ・breakpoint・asset命名・コメント)を踏まえて、実装すべきもの・スキップすべきものを判断。前提: 画像/デザインは後から変えるので気にしない、アニメコードはデザイン性が変わらないならやりたい | A | hp-flow.md Step4 手順4を11項目→18項目に拡張。即実装(命名7項目+構造系4項目+スタイル系3項目+コメント差別化1項目+検証1項目+慎重実装2項目)。不採用1項目=Media query breakpoint(レスポンシブ崩れ=大原則違反)。各項目に「見た目1ミリ変えない」担保の方法を明記。CSS値=単位/色表現変換のみ(数値不変)、アニメ=ease-in-out→cubic-bezier等価変換のみ(timing不変)、DOM構造=確認②で前後目視比較必須、ライブラリ差替=動作100%同じ証明できるもののみ |
| 2026-06-12 | 大串 | EMBERデモ「今まであったデザインが消えてるんだけど」: TOP全面再構成(v5)時に元bakeruの特徴セクション(.toWorkIndex=回転大英字+縦書き+VIEW ALL円)を黙って落としていた。元サイトの「目玉デザイン」は参考にした理由そのものなので、再構成で消える=価値が消える | B | v4スナップショットからマークアップ復元(CSSはstyle.cssに残存・無変更)。教訓: TOP再構成・大規模リビルド時は、元サイトの特徴的セクションを落とす場合は事前に「このセクションは外します」と明示し承認を取る。スナップショット(versions/)があったから即復元できた=ver管理の有効性も実証 |
| 2026-06-13 | 大串 | petomoデモ検収「TERASUオリジナルコード化できているかチェックして」→ WordPress痕跡が残存（wp-polyfill系JS参照×4・contact-form-7プラグインCSS×4・media/2023/12 日付型アップロードパス×7）。動作・著作権は無害（全ローカル化済み・OSS）だが、TERASUは「WordPressでない静的サイト」と営業しており技術者がソースを見ると矛盾。大串「消して支障ないなら、これからオリジナルコード化と最終チェックの工程で防ぐように。WordPress以外のCMSも同様」 | A | hp-flow.md Step4に新項目18「元サイトのCMS痕跡を全除去」新設（WP=wp-polyfill/プラグインCSS/wpcf7、日付型uploads/mediaパス→assets移動、他CMS指紋=wixstatic/data-wf-/cdn.shopify/studio.site/jimcdn/mt-static/eccube/generatorメタ、削除後コンソールエラー0検証必須）・旧18(検証系)→19へ。Step8監査Aにgrep #6（CMS痕跡一括検出+日付パスfind）追加。監査B表に「CMS痕跡ゼロ」行追加。hp-template.mdの注意・既知の限界に「CMS痕跡は本スキルでは除去されない→公開前にhp-flow Step4-18+監査A-6を必ず通す」を追記 |
| 2026-06-13 | 大串 | TERASU HP全体オリジナル化(ver20.11)でフォーム系class(wpcf7→t-)リネーム時、form専用CSSだけ連動させテーマCSS本体(style.css)内の.wpcf7系17セレクタを見落とし→ラジオ縦並び崩壊。before/afterピクセル比較が機械検知*→テーマCSS連動で完全一致復元 | A | hp-flow.md Step4の置換漏れゼロ方式に実例追記対象: classリネームの連動範囲は「全CSS横断」(form専用/テーマ/inline全部)+ピクセル比較検証をセットで。動的アニメページの不変証明は「自己差分(同一コード2回撮影)と同bbox」方式。verマーカー文言に旧CMS名を書くとコメント自体が指紋化する点も |
| 2026-06-15 | 大串 | TERASU HPスマホ最適化を大規模実戦(ver20.14-20.19: メニュー再構成/CONTACT kurokitec風/サービス詳細montage非表示/見出し改行/絵文字矢印/速度最適化)。黒montageが多層(serviceBodySlider→tphf→serviceBg)で1つ消すと別の層が出る泥沼を経験→真因はセクション背景serviceBg。CSSセレクタ推測ミス(WHAT WE DOが.p-ism__missionBodyでなく.p-ism__spiritsHeadTitle配下)でtransform効かず。↗がiOSで絵文字化→U+FE0E解決 | A | hp-flow.md Step7に「スマホ実装テクニック集」8項目新設(①背景透けは多層疑い+elementFromPointで実要素特定/②opacity:0>visibility:hidden/③セレクタは実DOM階層確認/④U+FE0Eで絵文字化記号テキスト化/⑤スマホ専用要素HTML編集はPC不変/⑥clampで機種差吸収/⑦@2x画像は表示×2にリサイズ・元最適化PNGは再エンコードで増える注意/⑧PCはheadless1280検証※preview iframeは846pxまで)。+ 別途容量で作業中断禁止ルール(feedback_no_capacity_interruption)を恒久化 |
| 2026-06-16 | session(mont.jp案件) | mont.jp(WordPress/FLOCSS・1162クラス・slick/simplebar内蔵)を全自動オリジナル化(class全t-化)中、Step4 機械リネームで5つの破壊バグを実機computed-style比較で順次検出・修正。① class="..." 正規表現が data-class="..." 内の class= にも誤マッチ→data-class値が二重t-(t-t-js-svg)化しJSセレクタと不一致でchangeSvg注入停止 → (?<![-\w])class=" で境界化 ② 属性セレクタ値prefix時にクォート二重付与([class*="t-x""])でCSS無効化+JS querySelectorAll SyntaxError全停止 → tailに閉じクォート含む前提で1個削除 ③ ベンダーminified module.min.js が is-*/c-objectfit/js-modal/p-form 等サイトクラスをダブルクォートでハードコード(単一クォートgrepが見逃す)→CSSだけリネームで splittext hero が opacity:0 固着 → クォート完全囲み単一クラス("is-shown"/'.js-modal')のみ厳密置換(文字列内部走査はregexリテラル /...'.../ を誤食いしメール正規表現破壊→禁止) ④ 退化トークン -(単一ダッシュ)混入で subLenght - 1 減算や [~-] 正規表現を t-- 誤爆 → is_site_classに「英字1文字以上」ガード ⑤ CSS変数収集 --([a-z]) がBEM .block--modifier の --koe を変数誤認→.pg--t-koe 中間t-化でクラス全体壊れhajimete崩壊 → (?<![\w-])-- で前境界化 |
A→候補 | 検証手法が決定打: headless Chrome(puppeteer-core+system Chrome)で アニメ凍結(*{animation/transition:none})+full-scroll誘発+構造パスキー(tag+nthOfType連鎖)マッチ+svg内部除外 の決定性比較を自作。「元 vs 元」のノイズ床(svg注入順/reveal timing=約99要素)を先に測り、「元 vs リネーム後」が同水準(101)に収束=実差分ゼロと判定。HTTP200やgrep一致では絶対不十分(全バグがHTTP200のまま視覚破壊)。教訓を hp-flow.md Step4 に反映候補(リネーム正規表現の境界5点+ベンダーminified JSは厳密クォート置換のみ+決定性ノイズ床比較を確認②の標準手法に)。feedback_originalize-verify-computed-style / feedback_minified-js-rename-corruption の具体実装版 |
| 2026-06-17 | 大串 | Step9 Lab還元で「毎回プレビューで一回私に見せてから最終でTERASU LABのセクションページに入れて」＝承認なしの push 禁止・必ずローカルプレビュー(実描画/タップリンク)で大串確認→OK後に commit&push。+同セッションで「①キャラクター入れないで ②イラスト入れなくていい、もっと再現度高くして」＝Labスニペットの装飾キャラ/イラストのプレースホルダは入れず、レイアウト/タイポ/罫線/hover挙動の再現度を上げる方を優先 | A | hp-flow.md Step9 Step C を厳格化：(a) entries/img/code-preview/build.py までは作ってよいが、git push は大串の明示OKが出るまで絶対しない（「[1]OK→push」で1と言われて初めて）。(b) 還元スニペットは「キャラ/イラストのダミー丸/顔文字」を入れず、レイアウト・グリッド罫線・タイポ・hover/リビールの再現度で勝負（ダミー装飾は安っぽく再現度を下げる）。本ルールは feedback_preview-before-production-always（本番前は必ずプレビュー）の Lab版。記録のみで learning に留めずStep9本体へ反映済 |
| 2026-06-16 | 大串 | stock-sun.comの清掃業採用事例ブログ→TERASU「HP制作費用相場」解説記事に流し込み完成(hp-flow初のWordPress製サイト×ブログ記事案件)。「一旦そのままで完成」とナビ/フッターは元構成のまま許容。 | A | ①WordPressブログのオリジナル化フロー確立: wget mirror→Pythonでクリーン正規化(クエリ名/cdn-cgi画像proxy/日付パス除去)→PurgeCSSで未使用CSS除去(テーマ計590KB→211KB)→class/var t-化→CMS痕跡(wp-block/wp-emoji/cf7/mw-wp-form salesforce/wp.i18n等)全除去。②[最重要・再発防止]PurgeCSS CLIの--safelist正規表現が効かず、JS動的付与クラス(is-active等)の.X.is-active派生ルールごと削除→ハンバーガーメニューがopacity:0で開かない退化。purgecss.config.cjsのsafelist:{greedy:[/is-/,/js-/,/header/,/menu/,/nav/,/-active/,/-open/,/-show/...]}で解決。CLI safelist使用禁止・config file必須*。検出=「JSでis-active付与されるのにopacity:0のまま+該当ルールがstyleSheetに存在しない」。③ブログ記事流し込みは元ブロック(h2/h3/p/ul/ol/table/quote/cta)をPython関数化して新コンテンツ生成が効率的。④事例型→解説型など構造が違う記事でも、元ブロックデザインclassを使えば見た目を保ったまま全差替可能(H2グレーバー/H3上下ボーダーはタグセレクタ.t-l-single-body h2/h3で効く)。⑤ロゴ/アイキャッチはSVGを自作(TERASUワードマーク+費用ガイド タイトルカード)。Step4にPurgeCSS注意を追記予定 |
| 2026-07-13 | session(01earth案件) | 01earth.jp/web-create/web-design/（WordPressカテゴリ一覧ページ）単一ページを「コードオリジナル化まで」実施（クライアント既存サイトへ下層ページ差込用）。Step4 CSSクラスリネームの置換漏れゼロ方式で新バグ検出・修正：リネーム正規表現 (?<![\w-])\.classname(?![\w-]) の先頭lookbehindが a.classname/li.classname 等「要素.クラス」複合セレクタを誤スキップ（.直前が要素名の英字=[\w-]でlookbehind不成立→拒否）。結果 a.common-cv__inq-btn{background:#15CD8B}（緑CTAボタン本体）が未リネームでHTML側t-クラスと不一致→透明背景+青文字に退化。.classname:after（擬似要素）は.直前が空白/}で正常リネームされ一部だけ壊れ気づきにくい。検出=元mirror(:8766)とオリジナル化版(:8767)の computed-style/section位置を機械比較（common-cv高さ+12・docH+12・btn bg=transparentで発覚）。修正=先頭lookbehind撤去し末尾境界のみ \.classname(?![\w-])（正確なクラス名一致で小数点/hexに誤マッチせず・複合も拾う）。id#idも同様。 |
A→候補 | 教訓：CSSクラスリネームは末尾境界のみ・先頭(?<![\w-])は要素.クラス複合を殺すので付けない。検証は必ず元vsオリジナル化のcomputed-style/section-metrics機械比較(1280+375)＝grep一致/HTTP200では複合セレクタ漏れ(btn:afterだけ残り本体消失=部分退化)を見抜けない。副次:wget無し環境はcurl手動mirror可(HTMLの link/script/img+CSSのurl()/@font-face抽出→実使用font-familyだけDLで160font→10weight=3.9MB)／purge=927rule中138保持で219KB→30KB(他ページ用テーマ除去=collision/fingerprint同時解決・@media内再帰+JS動的クラスsafelist)／zshはfor F in $VARで語分割しない。次回hp-flow.md Step4「手順2」にCSSリネーム正規表現=末尾境界のみ を明記候補 |
| 2026-07-25 | session(ACES whoweare案件) | acesinc.co.jp/whoweare（STUDIO製 Nuxt SPA・SSR本文ほぼ無し=完全CSR／HTMLの日本語140字のみ・画像はランタイムがGCSのJSONから組み立て）をクライアント納品用でStep1-4実施。新バグ「属性セレクタ断線」を発見：id/class を改名しても、CSS/JSの部分一致セレクタ [id^="font_bold_"] [id^="font_en_"] [id^="anchor"] [id*="h3_animation"] は名前の一部しか書かれていないため、名前の完全一致で置換する置換漏れゼロ方式では原理的に検出できず、改名した瞬間に何にもマッチしなくなる。実害＝太字/英字のフォント指定が全部外れる・追従ナビのセクション判定が死ぬ・h3出現アニメが動かない。grepでもHTTP200でも気づけない（"元から当たっていない"状態になるだけでエラーも出ない） |
A | hp-flow.md Step4 置換漏れゼロ方式に手順2-b「部分一致セレクタの追従」を新設（①[attr^= *= $= ~= \|=] を全棚卸し ②id/classの変換規則と同じ関数でパターン側も書き換え ③before/afterでセレクタのマッチ件数を突き合わせて断線ゼロを証明＝旧3件→新3件）。副次学習：①de-STUDIO静的化＝STUDIO製CSRサイトは実描画DOMをスナップショットしランタイム4.5MBごと捨てると自己完結静的HTML(237KB)になり指紋除去も容易（元とbodyH±1px・h1/h2座標完全一致で実証）。②ダミー化は文字数でなく字送りを合わせる＝全角/半角に加え字幅クラス(M/W=幅広, I/J/l=細)まで揃える（"AI"→"AC"で5px広がり折り返しが1行増え全体+60pxズレ／縦書き見出しでは字幅がそのまま行高になり+25px）。③ブラウザペイン非表示ではIO/rAF/setTimeoutが間引かれ非同期JSがタイムアウト→同期JS＋fetchでローカル受け口にPOSTすれば286KBのDOMもコンテキストを汚さず回収できる。④SP幅はリサイズだけだと再計算されずbodyHが3.5倍の異常値→必ずリロードしてから計測。⑤ポートの空き判定は/dev/tcpでなくlsof -nP -iTCP -sTCP:LISTEN（他案件の常駐サーバに当たった） |
| 2026-07-25 | session(sapporo-clinic 便潜血案件) | www.sapporo-clinic.com/bensenketsu（STUDIO製 Nuxt・完全CSR＝curl取得のHTMLは実DOM116字の空div＝通常mirrorでは0%再現）の単一下層ページをクライアント納品用でStep1-4実施。同日のACES案件と同じSTUDIO系だが別の落とし穴を4つ検出。①Vueが「クリック時に動的生成」するメニューはDOMスナップショットに存在しない（開くと要素309→397・style14→15個に増える）→実サイトでクリックし開状態のパネルHTML(10KB)+注入CSS(31KB)を回収して静的埋込＋素JSで再現（_isCloseトグルという元と同一方式）。②回収物は元と同じ祖先に戻さないと全スタイルが死ぬ＝STUDIOのベースCSSは :where(.render-canvas) .sd の祖先限定セレクタ。body末尾に置くとアイコンが素テキスト"close"、リンクが青下線の無スタイル状態に→元と同じ .render-canvas > .modals（空divで実在）へ挿入して解決。③position:fixed で top/left 未指定の要素は「静的位置」依存→body末尾に置くとページ最下部(top=86042px)に飛び画面外。元は上部コンテナ内だったので不要だった＝移設したら top/left を明示。④JSクラス改名の新しい誤爆＝タグセレクタ：querySelectorAll('button') がクラスマップbutton→t-btnで't-btn'に誤変換されメニュー全停止（glowkeyの「JS文字列内class=""」とは逆方向の事故）。⑤data-s-[0-9a-f-]{8,} では data-s-section-inner-<uuid> を取りこぼす→[0-9A-Za-z_-]{6,}に。 |
A | 教訓1：自作JSは改名対象から外し「最初から最終命名で書く」（クォート内文字列の一括置換はタグセレクタ/メソッド名を必ず誤爆する。goodthewhatの.next()・glowkeyのprevArrowに続き3例目＝JS一括改名は原則やらないが確定）。教訓2：動的生成UIの静的化は「DOM回収＋祖先の再現＋fixedのtop/left明示」の3点セット。教訓3：ヘッドレス検証用に ?menu=open 等のクエリで初期表示させる実装を入れると、クリックできないheadless Chromeでもインタラクション状態をピクセル比較できる（メニュー開状態で before/after 0.0000%一致を証明）。副次：ブラウザペインのビューポートが0×0に落ちると bodyH/getBoundingClientRect/rAF/transition が全部死に「実装バグ」に見える→resize_windowで明示指定、直らなければheadless Chromeに切替（ACES案件の"rAF間引き"と同根）。ブラウザ→ローカルサーバへfetch POSTして大きなDOM/CSSをファイル回収（serve.pyに/_save受け口）はACES案件と独立に再確立＝STUDIO系の標準手順として昇格候補。検証は FVピクセル0.0000%＋メニュー開状態0.0000%＋bodyH/要素数396/tallSum123544/画像47完全一致＋アコーディオン3つ実クリック＋console 0。属性セレクタ断線(ACES)は本案件では[style*="padding-top"]のみで改名対象を含まず断線なし**（before/after件数一致で確認） |
| 2026-07-25 | session(sapporo-clinic 便潜血案件・Step5) | 同案件のStep5(流し込み)でmirror/ダミー化スクリプトの3つの重大バグが表面化。①mirrorが <a href> まで取得対象にしていた→他ページ(/colonoscopy等)と#アンカー付きURL(/bensenketsu#positive)を「拡張子なしアセット」として assets/img/ に保存し、元サイトのページHTML20ファイルが配信物に混入（著作権上アウト）。さらに元HTMLの <a href> がそのローカルHTMLを指すよう書き換えられ目次のページ内アンカーが全部断線。broken画像0・HTTP200・コンソールエラー0で一切気づけない（リンクは"存在する別ファイル"を指すので切れない）。検出＝file コマンドで assets配下の実体判定（HTML document text が20件）。②ダミー化が技術系metaまで置換→viewport が content="Dummy Text Sample..." になりレスポンシブが死ぬ。robots/format-detection/og:type/twitter:card も破壊。③数字のみのテキストはダミー化対象外（JA/EN正規表現で弾かれる）→元クリニックの電話番号 011-792-7061 が最後まで残存。加えて外部リンク（元の予約システムdigikar-smart・関連法人・Googleマップ・YouTube埋込）は"アセットではない"ので全工程素通りし、Step8監査まで残る。 |
A | 教訓1：mirrorの取得対象は <link>/<script>/<img>/srcset/url() だけ。<a href> は絶対に含めない（含めると①が起きる）。教訓2：ダミー化のスキップリストに技術系metaを必ず入れる（viewport/robots/format-detection/chrome/og:type/og:url/og:image/twitter:card/generator/google-site-verification）。教訓3：Step5の完了条件に「元サイト由来の実体が0であること」の機械検証を入れる＝①fileでassets配下にHTMLが無いこと ②grepで元社名/地名/電話/郵便番号が0件 ③外部リンク(href="http)が0件 ④<iframe>(元の動画)が0件 ⑤ページ内アンカーのgetElementByIdが全部通ること。本案件では最終的に 元サイト由来テキスト0・外部参照0・アンカー切れ0・broken0・はみ出し0・console0 を達成。教訓4：元サイトのGoogle Search Console認証コード(google-site-verification)は"他人の所有物"なので必ず削除（ダミー化でも消えず残る）。画像は memory hp-flow-placeholder-images 通りブランド物(写真/ロゴ/favicon)のみプレースホルダ化し、汎用装飾SVG(矢印・図形)は残す（LUMEN案件の「極小タイルは対象外」と同じ切り分け） |
| 2026-08-12 | session(未来共創・師業士業分科会) | speelead.com(WP)参考でclient-miraikyousou配下に分科会ページをStep1-6実施。技術学習: ①palt(プロポーショナルCJK)サイトのダミー化は同字数でも幅がズレる→ブラウザで全字グリフ幅実測し「同クラス最近傍幅の文字を選ぶ」幅マッチングで全セクション高さ完全一致 ②aspect-ratio正方形タイルはgridの1frを最小幅爆発で破壊→minmax(0,1fr)+min-width:0必須 ③display:noneにしたbrがChromeで1文字だけの行を作る→固定brより自然折返し ④ブラウザペインは0×0落ち/スクロール後compositor固着が頻発→検証はDOM実測+headless Chrome(ただしheadlessは仮想時間でreveal前の暗転あり=数値優先) ⑤右固定サイドバーのレール帯は各階層にmargin-right:-372px+padding-right:372pxを連鎖させると帯背景が全幅化 ⑥インラインJSの属性セレクタ$('[data-wid-sp]')は手順2-bのJS版として要追従 | A(技術学習) | 幅マッチング/minmax/br知見は次回Step1・Step4の標準手順に昇格候補 |
| 2026-07-22 | session(glowkey案件) | glowkey.co.jp(WordPress独自テーマ・slick/matchHeight/jQuery・13ページ)をクライアント納品用にStep1-4実施。①wget無し環境→Python自作mirror(page-requisites全取得+CSS内url()/@font-face再帰+クロスオリジンfontは_ext)。②Step4=Stage A(構造フラット化 glowkey_wp→/assets・WP/GTM/Gutenbergブロックinline-css/speculationrules/wp-json指紋除去)+Stage B(テーマclass530/id36を t- 全改名)。新バグ検出: slickの prevArrow:'<div class="ar-prev">PREV</div>' のようにJS文字列内に埋め込まれたHTML class="" が改名漏れ*→CSSは.t-ar-prev化済で不一致→スライダー矢印が素テキスト"PREV"化。検出=baseline(:8796)とオリジナル化(:8795)のservice/ec FVスクショ比較。修正=js_renameに「JS内 class="..." 属性文字列もトークン改名」を追加。 |
A | 教訓: クラス改名のJS対象は『引用符内セレクタ』『addClass等の引数』に加え『JS文字列内の class="" HTML属性』も必須(slick prevArrow/nextArrow等)。安全設計=関数ベース単一パス(マップに在る語だけ改名→HEX#fff/URL拡張子.png/プロパティ.indexを自動不変)・CSSクラス末尾境界のみ\.name(?![\w-])・idはHTMLのid=""から取得。検証=before/after構造メトリクス(docH/tallCount/tallSum一致)+FVスクショ。副次: mac http.serverはos.getcwd()がGoogle Drive配下でPermissionError→自前chdir ThreadingHTTPServer必須(単一HTTPServerはmp4 keep-aliveで詰む)。 |
| 2026-08-16 | session(demo-positive案件) | positive.co.jp(WP・WebGL2 canvas FV・Three.js)をデモ用でStep1実施。新バグ2種検出・修正: ①ダミー化のタグ退避regex <[^>]+> が既存の <STASH-n> トークン自身を二重退避→1パスの復元で19トークンが未展開のまま残りscriptタグ3本が全部消失（main.js不実行＝pin-spacer/ロゴ複製/KVが全死・grepのSTASH残存数だけが検出手段）。修正=タグ退避を <(?!STASH-\d+>)[^>]+> にし復元をwhileループで反復。②インラインscript注入のJS設定（window.kvSlideInfo等のwp_localize系）が絶対URL（https://元ドメイン/テーマパス/）でアセットを持つ→ミラーでは cross-origin となり Three.js の crossorigin=anonymous テクスチャロードがCORS失敗→WebGL canvas FVが真っ黒（HTTP200・console静音・grep素通り。resource timingの responseStatus=0 が唯一の手がかり）。修正=https://元ドメイン/テーマパス/→/テーマパス/ を全置換（ページhrefは元ドメイン+別パスなので誤爆しない）。技術学習: ③WebGL FVサイトはテクスチャがJS動的fetch（KV img1-5・light1-4・location.json）＝HTML grepゼロ→preview_networkの404と resource timing status=0 の両方を見る。④canvas黒はペインrAF完全停止でも起きる（サイトバグと誤診しない・スクショでペイン前面化すると描画される）。⑤モリサワ有料フォント(A1ゴシック)は403で取得不可→Zen Kaku Gothic New＋源ノ明朝=Noto Serif JPの家族名差し替えCSS（fonts/substitute.css）で近似・全woff2ローカル化。⑥このPC(咲輝)はCloudflareトークンファイル無し→mikke方式=wrangler OAuth＋ChatGPT.app同梱nodeでローカルpages deploy（--branch=previewでpreview.demo-◯◯.pages.devの固定エイリアスが出る） | A(技術学習) | ①②はmirror/dummify標準スクリプトに反映済み（タグ退避のSTASH方式と同型）。次回テンプレ化候補 |
| 2026-08-13 | session(未来共創privacy/terms案件) | kobako-design.com/privacy(静的・jQueryアニメ語彙型)を参考に未来共創の/privacy/+/terms/をStep1-6実施（本番反映は大串保留中・preview ver193）。新バグ3種検出・修正: ①JS/CSSからのクラス収集がURL内トークンを誤認＝JS文字列の.googleapis・CSS @import url(...)の.googleapisをクラスと誤収集→t-googleapis.comに改名され外部フォント断線（ERR_NAME_NOT_RESOLVED）。収集も適用も「://や/を含む文字列は除外」＋CSSは@import行を除去してから収集が必須 ②ダミー化のmetaスキップ/置換対象にog:site_nameが漏れブランド名残存（DUMMY_META相当に追加） ③コメント退避プレースホルダ\x00STASH\x00が文字置換に巻き込まれ復元不能→タグ形式<STASH-n>にする。技術学習: ④ブラウザペインのprefers-color-scheme:darkで「bodyに背景色を指定しないサイト」は下地が透けて真っ黒に見える（サイトのバグではない）→resize_window colorScheme:lightで検証 ⑤本物サイト側もリサイズ後リロード必須（古いmedia query適用結果が残りfContact高さ等が偽差分に見える） ⑥IntersectionObserver出現アニメはジャンプスクロール（アンカー移動含む）で通過した要素に発火しない→スクロール位置ベース（rect.top<vh*0.9 or rect.bottom<0で発火）が堅牢 ⑦rmtree→copytreeで再生成するとchdir式ローカルサーバが死ぬ→再生成後はサーバ再起動 ⑧未来共創固有: 共通site-footer.jsの部品を一部だけ消したい時はページ内CSSでsection.mkcta .mkcta__ttl{display:none}等ピンポイント非表示（本体は不変）・法的リンク(プライバシーポリシー/利用規約)はt-fnr__legal2で復元済み(site-footer.js v188・利用規約=/terms/も新設済み) | A(技術学習) | URL除外・@import除外・STASHタグ形式は次回mirror/originalize標準スクリプトに反映。ペインdark下地・IOジャンプ非発火はStep3/検証の標準注意に昇格候補 |
学習候補（種別B・3回出たら本体昇格）
| 趣旨 | 出現回数 | 初出日 | 直近日 | メモ |
|---|---|---|---|---|
| ~~結合度の高いminified/ノーコード生成バンドルのサイトは Step4 を「Stage A優先」で~~ → 【昇格済 2026-06-19】hp-flow.md Step4「結合度判定」節へ | 3 | 2026-06-16 | 2026-06-19 | ①studio.design(STUDIO自己完結+Nuxt) ②ntvart(WordPress+Alpine+WebGL) ③ai-model.jp/movie(Vite minified束・data-*駆動・JS動的生成クラス)で3回目→hp-flow.md本体に昇格完了。ai-model案件でbefore/after完全一致(bodyH31988/全セクション/色/accordion)を実証し検証手順も本体化 |
運用メモ
- 記録のlock: このファイルを編集する前に必ず
ai_session_lock.sh acquire vault claude-codeでロック取得 - 肥大化対策: 学習履歴が100行を超えたら、古い確定済みは「確定学習」表に集約して履歴を圧縮する
- 矛盾時: 過去の確定ルールと矛盾するFBが来たら、消す前にユーザーに1回確認
- 他コマンドへの横展開: この「セルフ進化プロトコル」が有効に機能したら、
agenda等の他コマンドにも同じ仕組みを移植する（将来）
| 2026-06-13 | 大串 | TERASU Lab セクション還元ステップが無く、案件で作った良いセクションがLabに蓄積されず流れていた。「HP完成したらLabのセクションに細分化して入れる→そこからドメイン/SEO。デモこそLab強化」と指示。分類は既存6カテゴリ(layoutdesign/preloader/motion/fv/navbar/footer)、メディアは画像+動画、1サイトは細分化して別々に1entry、コード/プレビューリンク/スクショ/動画を完璧に揃えて一発登録、人間が最終意思決定。共有メモは廃止予定なので対象外 | A | hp-flow.md を11→12ステップに拡張。Step8(著作権監査)の後に Step9 "TERASU Lab セクション還元" を新設(全セクション列挙→星推奨→人間が選択→cats確認→png/mp4/自己完結code/SECTIONS配列追記→lab-terasuプレビュー→デプロイ)。旧9/10/11を10/11/12へ繰下げ。概要テーブル/description/全見出し/Step8次へポインタも更新。デモはStep9が実質ゴール |
| 2026-06-13 | 大串 | Step9 Lab還元の設計、Claudeが「再利用価値」を自動判定するのをやめてほしい。全セクション自動列挙＋⭐推奨も不要。「何を入れるかはこっちで判断する」。シンプル設計に: ①Claudeは「Labセクションに追加したい箇所をスクショ/動画で送って(複数可)」とだけ依頼 ②送られた箇所を忠実に間違えず特定し、その部分のコードを正確に入れる ③問題ないか確認→修正なければ完成。狙いは「送った箇所を忠実に再現したコードがLabに入り、他HP作成時にそのまま入れられる」 | A | hp-flow.md Step9の「処理フロー(漏れなく・自動列挙・⭐推奨)」を撤廃→「スクショ/動画ドリブン・人間が選ぶ・Claudeは忠実に再現」へ全面書換。StepA依頼(これだけ出す)→StepB登録(送られた箇所を忠実特定→実コード正確抽出→自己完結スニペット→png/mp4配置→cats確認→SECTIONS追記)→StepC確認(修正なければ完成)。再利用価値評価は完全削除 |
| 2026-06-16 | 大串 | デザイン工程は完璧だが文章工程がまだまだ。SEOで取りたいキーワードから逆算＋問い合わせが来る文言の改変案を複数＋デザイン変えない範囲で文言の最終調整ステップを入れたい | A | hp-flow.md Step5に「SEO/CVコピーライティング」(KW逆算/CV導線設計/重要コピー複数案/デザイン不変)、Step10に「文言の最終調整」(デザイン不変・SEO最終チェック・CV文言複数案→選定・崩れゼロ確認)を追加。全体像テーブルのStep5/Step10も更新 |
| 2026-06-29 | session(koba-clinic Astroデモ) | Step2デモ「メニュー→トップ遷移」化で re.sub(r'href="[^"]*"', ./) の雑な一括置換を使い、<a>だけでなく <link rel=stylesheet href=/_astro/*.css> まで ./ に書き換え→全CSSがトップHTMLを読みに行き0ルール化・レイアウト全崩壊（ナビが素のbullet list・bodyH 6358→52179暴走）。大串「なんかバグってない？」で発覚。原因切り分け＝document.styleSheets各sheetのcssRules.length・link[rel=stylesheet]のhref実値確認で href="./" を特定。クリーン原本から <a\b[^>]*> 単位の置換に修正して復旧 | A | hp-flow.md Step2デモ節に:LiSiren恒久ルール追加「href置換は<a>タグ内のみ・<link>(stylesheet/modulepreload/icon/canonical)/SVG use/xlink:hrefは絶対に触らない・雑な一括regex禁止」＋置換後検証3点（link stylesheet href grep・scopedルール数>0/computed style・コンソール0、HTTP200だけで判断しない）。横展開＝全Astro/ノーコード/任意デモで再発する汎用バグ |
| 2026-06-16 | session(goodthewhat.com案件) | WordPressサイトのオリジナル化＋class/idリネームの2大落とし穴と決定的検証法を確立(技術学習)。goodthewhat.com(デザイン事務所/WP製/全48ページ/theme=gtw2022/Typekit/MailPoet/mw-wp-form)をStep1-4実施。Step4で「ピクセル不変が前提なのに静的キャプチャで差が出る」沼を経験 | A(技術学習) | ①de-WordPress: /wp/wp-content/themes/<theme>/→/assets/、uploads/YYYY/MM/→media/libNN(日付dir→中立名1:1リネームで衝突0＆日付指紋除去)、wp-includes/プラグイン資産も/assets/へ。CSS内url()は相対(../img/)ならcss↔img関係保持で書換不要。②指紋スクラブ: AIOSEOコメント/generator/wp-json/oembed(json+oembed型は別regex)/RSS/canonical/og:url+image/wpemoji/GA(UA-+G-+gtag)/WP class(wp-image/attachment/size-/align)を一括除去。未使用Gutenberg block CSS(wp-block使用0なら安全除去・要確認)。③落とし穴1=複合セレクタ: rename_cssの否定後読み(?<![\w-])\.が#fv.contentsの.contents(直前=単語文字v)を取りこぼし→CSS#t-fv.contents/HTMLt-contents不一致で184px余白消失が全下層に伝播。後読みを外す(先頭[A-Za-z_]で.5等の数値除外・map外トークンは不変なので値中.svgも安全)。④落とし穴2=JSメソッド/クラス名衝突: nextがpaginationのCSSクラスかつjQueryメソッド→rename_jsが$(this).next()を.t-next()に誤変換しaccordion破壊(クリック時throw・ロード時console無音)。rename_jsは「クォート内文字列のみ」に限定すべき(getElementById('id')は別途対応)。vendor/Google Maps JSは触らない(.iconプロパティ等が誤爆)。⑤Typekit→無料化(kitId指紋＋他社Adobeアカウント=ライセンス必須): din-2014→Archivo / kinuta-maruminold-stdn→Shippori Mincho / yu-gothic-pr6n→システムYu Gothic。.wf-loading未使用ならtypekit script除去で表示崩れ無し。⑥決定的検証法(最重要): 自動再生カルーセル＋スクロール連動アニメ＋Typekitフォント非同期ロードで素のbefore/afterピクセル比較は信頼不可(全テキストがフォント差でリフロー)。→v0原本と変換版の両方に同一オーバーライド(*{animation:none!important;transition:none!important;opacity:1!important;transform:none!important;font-family:sans-serif!important} ＋ [class*=answer]{display:block!important}でアコーディオン強制展開)を適用しheadless差分→6/7ページ0.0000%一致で「リネーム=ピクセル完全」を証明。カルーセルページは「同一サーバ2回撮影の自己ノイズ床」(projects=28%)と比較し、cross差(1.4%)が床を大きく下回れば破壊でなくノイズと判定。要素座標(getBoundingClientRect)が全項目「定数Npxシフト」なら原因は上部1要素と特定可。⑦インタラクション検証: 静的画素一致だけでは不十分(.t-next()バグは画素では出ない)→accordion/carousel/scroll-reveal/menuを実ブラウザで個別動作確認必須。将来hp-flow.md Step4置換漏れゼロ方式へ「複合セレクタ後読み除去」「rename_jsはクォート内限定」「決定論オーバーライド検証」を昇格候補 |
| 2026-06-17 | 大串 | Lab還元(Step9)は本番pushの前に毎回プレビューを大串に見せOKをもらってから入れる。FB原文「毎回プレビューで一回私に見せてから最終でTERASULABのセクションページに入れて」。発端=goodthewhat-service-saki-0617登録時、StepC確認OKを大串から待たずに先にcommit&pushして本番反映してしまった（結果は見せたが順序が逆＝事後報告だった）。大串は「載せる前に確認したい」 | A | hp-flow.md Step9冒頭に恒久ルール新設「①ローカルでスニペット完成→②大串にプレビュー(タップリンク＋スクショ)→③大串のOK/入れて→④初めてgit commit&push」を毎回厳守・承認前push禁止と明記。StepCの[1]OKは「大串からのOK」の意と定義。例外は大串が「もう入れていい/確認不要」と明示時のみ。memoryにもfeedback_lab-preview-before-push記録 |
| 2026-06-16 | session(studio.design案件) | STUDIO/ノーコード生成サイト＋Nuxtサブページのオリジナル化手法を確立(技術学習)。studio.design全45ページ=STUDIO自身製の自己完結サイト(インラインCSS17ブロック+インラインVueランタイム72KB+GCS画像2072点)で、wget3欠陥に悩まず高品質再現できた | A(技術学習) | ①ミラー: 自己完結HTMLなので内部リンクをローカル相対化するだけで高再現(画像はGCS絶対URLのまま=「元画像そのまま」準拠)。②sd-接頭辞リネームの安全証明法: sd-はハイフン故JS識別子になり得ず、監査(URL内0件・var/let/const sd=0・sd-前後文字が全て文字列/セレクタ/data-/--文脈)で算術破壊リスク0を確認→全域一括sd-→t-置換が安全(22.4万箇所をHTML/inlineCSS/ミニファイランタイム同時一貫リネーム)。\b単語境界は__sd-N(アンダースコア前)を取りこぼすので注意。③検証法: 「遅延画像(data-t-img-src)が全ロード=ランタイム↔HTML結合の動作証明＋JSエラー0＋静的ページ(料金)画素一致＋メニューモーダル開閉」。④Nuxtサブページ(store): 外部_nuxtCSS/JS(280チャンク)依存で崩れる→CSS3つだけミラー→<script>/modulepreload/__NUXT_DATA__島を全除去してde-Nuxt静的化が最適(API依存で動的部は静的化不可だがSSR構造は再現、Nuxt指紋一掃)。⑤Tier分け: generator meta/トラッキング(GTM/GA/firstpromoter/独自analytics endpoint)=即除去/低risk、sd-*/data-sd-*/sd*識別子=要監査だが安全、汎用クラス(box/text/modal)=ミニファイJS衝突risk大×指紋価値低=非実施推奨、ブランド文字/画像/SNS/loginリンク=コンテンツ=Step5。将来hp-flow.md Step4へ「ノーコード生成サイトのオリジナル化パターン」節として昇格候補 |
| 2026-06-17 | 大串 | Lab還元スニペットは「スクショ近似」厳禁・実コードを読んで100%再現せよ。ntvartデモの4セクション(gallery/service/cta/nextpage)を最初スクショから近似実装(gallery=自動マーキー/service=ホバー浮上)→大串「全てやり直し。再現度100% コードをちゃんと見て再現して提出して」と却下。実物の動きと別物だったのが原因(serviceは本当はホバー3Dフリップ、galleryは本当はスクロール連動ピン留め横スクロール)。前回Step9 preview-before-pushに続く再現度FB | A | ①手法=ワークフローで各セクション専任エージェントが実コード逐語再現: 各agentが index.html等の実HTML構造＋app.css(ミニファイ)から該当クラスの全ルールをbalanced-brace抽出して色/px/transition/@keyframes/grid-template-areasを逐語コピー＋実モーションを特定して素JSで再現。②実モーションの正体: service=perspective:5000px+--frontside/--backsideのrotateY+backface-visibility:hidden+.4s cubic-bezier(.6,0,.4,1)の3Dフリップ／gallery=app.jsのpinnedScroll式scrollLeft=progress×Lを素JS移植(縦スクロール→横移動)／cta=@keyframes translateY 0→-40%→0のper-char delay(--0〜--10)バウンド／nextpage=ベールrgba(29,29,29,.2)+scale(1.1) .6s。③検証で実バグ検出: galleryのsticky pinが効かない(.t-works__bgがheight:auto→stickyのピン領域ゼロ)→height:100%で修正(stickyは親の高さ分しかピンしない)。④headless検証の罠: プレビュー(非表示タブ)はrequestAnimationFrameが間引かれ発火しない＋window.scrollToがscrollイベントを出さない→スクショも撮れない。eval実測(track.scrollLeft/elevatorTop/getBoundingClientRect)で検証し、rAF非依存にonScrollで直接scrollLeft=targetも入れて堅牢化。⑤教訓: Lab還元は実セクションのHTML+CSS値+動きの仕組みを「読んで」再現。スクショ近似・generic版は必ず却下される。フォント代替/画像プレースホルダのみ不可避の残差として正直に明示 |
| 2026-06-19 | session(ai-model.jp/movie案件) | ai-model.jp/movie（WP本体とは別のVite製単一ページLP・data-駆動・minified JS 208KB・スクロール連動/Lenis/GSAP）をStep1-4まで実施。密結合バンドル学習候補の3回目→本体昇格。技術学習多数 | A | ①完全mirror（wget無環境）: curlで全アセット網羅DL(466個)。JS動的読込のfont/font.cssが拡張子regex漏れで欠落→preview_network 404が唯一の検出手段(STEP0の教訓再確認)。about_img@2x.jpgは元サイト自体が404の既存バグ(picture webpが表示)＝忠実継承。②結合度判定: clip(JS80回)=clipPathGSAPで別トークン/casesArticle(12)=JS内部プロパティ$casesArticle/accordion(7)=[data-accordion]セレクタ+動的id生成/visuallyHidden(4)=JSがclass=動的生成 → blanket改名は破壊リスク大と判定しStage Aに切替。③Stage A実施: /movie/→ルートflatten・Viteハッシュ名→app.css/app.js・GTM(AW-969382687)/gtag全除去・notranslate meta除去・og/twitter/favicon/本文CTAの元ドメイン→相対or#・prtimes企業ID除去・CSS変数15個→--t-。④検証: original別port配信→before/after同一手順計測でbodyH31988・全11セクション高さpx・color(#f2f2f2/#131313)・img199/broken0・accordion5動作・error0が完全一致＝1mm不変を証明。CSS変数はbefore/afterのvar()使用数86:86一致で静的整合も証明。⑤環境: wget/brew無し→curl mirror、Google Drive下はNG→~/dev作業、launchd常駐(8975)でoriginal版配信 | learning確定表+本体Step4「結合度判定」節へ昇格済 |
| 2026-06-19 | 大串(LUMEN案件)+session | ai-model/movie に架空ブランドLUMEN(次世代映像制作)をStep5流し込み。大串「レイアウト/フォント/アニメ崩さず元内容(ロゴ/文言/画像)を全消し・配色は依頼書反映・画像/動画スロットは細枠＋中央に小さく"画像"/"動画"と明示」。重大教訓: テキストgrep指紋チェックはアウトライン文字SVGを検出できず、reelマーキーの"AI MODEL & MOVIE"(viewBox3451×212の21path)を危うく公開しかけた | A | ①流し込み手法(密結合Vite): 235スロットをextract_slots.pyでindex付JSON化→old はJSONからindex取得(再入力ミス0)・new のみ記述→regex (>\s*)old(\s*<) 境界置換でPC/SP一括・構造/JS/空白完全保持。②ワードマーク: AI ModelのSVGパス(SvgLogo90×14 / hero・footer aiModel763×110・337×49)をElevenEleven-Lightの<text textLength lengthAdjust=spacing fill継承>LUMEN</text>に置換(Movie/×は汎用で残置)。色はCSS svg:not([fill]){fill:currentColor}＋.header_logo svg{fill:white}で継承、hero/footerは暗grad上で見えず→.fv_word.-aiModel text{fill:white}明示。③画像: Pillow(webp対応)で446ラスター全て正寸の「細枠＋中央"画像"/"ロゴ"」プレースホルダに上書き=レイアウト1px不変で全ブランド画像除去。日本語ラベルは/System/Library/Fonts/ヒラギノ角ゴシック W3.ttc。④CSSタイルテクスチャの罠: common_cover.webpは4×4の繰返しオーバーレイ(background-repeatで.fv_bg:after等)。これを明色プレースホルダ化したらサイト全面が明色化→透明webpに。CSS background-image/url()で使う極小タイルはプレースホルダ対象外にする。⑤::after競合: 動画ラベルを::afterで足したらapp.cssの.fv_bg:after(common_cover)と競合→frameは::before、ラベルは::after(content上書き)で解決。⑥最重要=アウトライン文字SVG指紋: text-grepは0でも、ブランド名が<path>化されたSVG(reelマーキー)が残る。全inline SVGを viewBox+path数+aspectで走査→path多/横長を炙り出し→1枚に並べてheadless描画して目視で判読(WHAT WE DO/FLOW/COMPANY等は汎用でOK、AI MODELだけ指紋)→<text textLength lengthAdjust=spacing>LUMEN ＆ MOVIE</text>置換。hp-flow.md 監査A-7(SVG走査+描画目視)として本体昇格済。⑦検証: before(original)/after(lumen)同手順計測でbodyH31988→31915(0.2%・テキスト長差)・全セクション寸法一致・broken0・error0・accordion5動作・横スクロール無(375-2560)・指紋ゼロ(text+SVG)。⑧未了申送り: 下層6ページ未作成(単一LP・CTAは#)、実Reel動画/実画像は制作側用意、動画footageはffmpeg無で不透明枠"動画"化 | hp-flow.md 監査A-7新設(アウトライン文字SVG走査)＋本記録 |
| 2026-06-20 | 大串(jillion/GISTデモ) | Step6で頼まれていない「全面ダーク化」を勝手にやって却下された。GIST依頼書に「ダークトーン基調」とあり元jillionが明暗混在設計だったため、Step6改良で明色節を完全ダーク反転(override CSS extras-dark.css・トークンスワップ＋カード25種＋ナビピル＋CTA＋チャートを全19ページ)→大串「全面ダーク化やめて」で即revert。教訓: ブリーフのトーン語(ダーク/プレミアム/高級等)は"コンテンツ・コピーの方向性"であって、参考HPのデザイン(明暗構造/セクション配色/レイアウト)を再スキンする許可ではない。流し込み(Step5)も改良(Step6)も参考デザインの忠実保持が大原則。配色反映は「アクセント1色差し替え」等の局所に留める。 | A | hp-flow.md Step5に「 配色・トーン反映の範囲（大規模リスキン禁止）」ガードレール新設: 依頼書の配色/トーン語で全面ダーク化/グレースケール反転/セクション配色の大規模変更/リスキンを勝手にやらない。やるなら着手前に1問確認 or 1セクションだけサンプル提示→OK後に展開。feedback_no-unsolicited-arrangementsのhp-flow版。memory feedback_no-wholesale-redesign記録。スナップショット(site_v2_lightmix)で即revert可＝ver管理の有効性も再実証 |
| 2026-06-24 | 大串 | StockSun「Webサイト制作ガイドライン」(品質評価基準・56p)を読み、HP制作コマンドの「最終納品・設定ミス防止」領域にアップデート余地ありと判断。「デザインや初期擦り合わせよりも、最終の納品・細かなミスがないかの部分。設定ミスがあると機会損失がデカい」。差分5🔴＋4🟡＋4🟢を全部本体に入れる指示 | A | hp-flow.md Step10を「納品前QAゲート」に格上げ(🔴1フォームQA=双方向疎通[ユーザー成功表示＋管理者/CRM実受信]/スパム耐性[reCAPTCHA・honeypot・CSRF・同一IP5分3回ブロック]/入力体験[電話メール住所バリ・郵便番号→住所・16pxズーム防止]・🔴4 URL正規化[www301・末尾スラッシュ・HSTS]・🔴5 index/noindex方針+sitemap整合・🟢信頼性ページ監査[privacy/運営会社/特商法/監修者/公的リンク/2クリック]・🟢誤字脱字最終レビュー・構造化データper-page精緻化)／Step11にリニューアル時 旧URL→新URL 301移行分岐＋旧サイトバックアップ＋公開後301全件検証(🔴3)／Step12を「設定→実測検証＋監視＋期限」に強化(🔴2 GA4データ保持14か月・実テスト送信でキーイベント発火を目視・電話/LINEクリック計測・GTM経由・🟡外形監視UptimeRobot・ドメイン/SSL有効期限リマインダー・GSCエラー定期)／全体像テーブル・振る舞いルールに3ルール追加。StockSunガイドライン章7〜13に対応。8章(検証=本番サーバー同一)/10-3(オートスケール)/9-4(WordPress)はTERASU=Cloudflare Pages静的のため大半N/Aと明記。設計核＝設定ミス=サイレント機会損失を構造的に潰す |
| 2026-06-25 | 大串 | HPコマンドの用途は「デモ」か「クライアント」の2つ。Step1でまずどっちか聞きつつサイトも送る形にしたい。クライアント向けは現状でバッチリ。デモは変えた方がいい点あれば変更案出して→確定: デモはトップページだけ作る(数を量産するから)・他メニューver押してもトップに遷移・公開手順(Step11/12)もいらない。AskUserQuestionで確認: デモ共有=ローカルのみGitHubスキップ／デモのテキスト=依頼書を作って送る(流し込みは本番同様) | A | hp-flow.mdに用途分岐を新設。①設計思想に用途分岐bullet②新セクション「用途分岐プロトコル」(クライアント=全12不変/デモ=簡略ルート表)③全体像テーブルにデモ注記④起動時の挙動を「①デモ/クライアント②参考HP」を聞く形に⑤Step1=デモはトップのみ抜き出し(mirrorもトップ依存だけ)⑥Step2=デモは下層再現せず「全メニューのhrefを./でトップ遷移」処理に置換⑦Step5=デモはGitHub立ち上げスキップ・ローカルプレビューのみ(流し込みは本番同様)⑧Step8=デモも著作権監査必須(制作実績で外部公開=指紋ゼロ)⑨Step9=デモの正式ゴール+完成後は/demos公開ワークフローへ橋渡し⑩Step10=デモはスキップだが軽量チェック3点(リンク切れ0/コンソール0/全メニュートップ遷移)のみ実施⑪Step11/12=デモなし⑫振る舞いルールに用途分岐ルール追加。クライアント納品ルートは一切変えず(大串「現状でバッチリ」) |
| 2026-06-25 | 大串 | デモはStep9(Lab還元)完了時に「TERASU HPのデモ内に入れたいからサイト管轄の方にプレビューリンクお送りください」と渡すアクションを入れて渡し漏れを防ぎたい。「ここだけ修正」 | A | hp-flow.md Step9完了確認ボックスに「【デモ・渡し漏れ防止】完成デモのプレビューリンクをサイト管轄の方へ送付」行を追加＋デモゴール説明行に「完了時に必ずプレビューリンクを添えて渡す」を明記。完了テンプレに焼き込み=Step9完了で必ず画面に出る=渡し漏れ防止 |
| 2026-06-29 | 大串 | Step7スマホ最適化の言語化後「見た目は絶対変えない上で各端末幅に合わせる、が今めっちゃいい。でもスマホだけでなくPCの大きさでも調整かけれたらベスト→名前もレスポンシブ対応がいいかも」 | A | hp-flow.md Step7を「スマホ最適化」→「レスポンシブ対応(全端末幅で崩さない)」にリネーム。対象を大画面PC/小型ノート/タブレット/スマホの全レンジに拡張。冒頭に全幅定義追加・最重要リスクを「基準デザイン(確定PC)が崩れること」に整理し『PC幅調整≠デザイン改変』を明示・チェック項目に大画面/小型ノート/タブレット3行追加・進め方/完了確認/全体像/description/Step6遷移/横展開例を全幅表記に統一・アイコン化。中身(標準パック4点・実装テク8項目・自己進化ループ)は大串「今めっちゃいい」で維持。ついでに振る舞いルールの誤記「Step7著作権ゲート」→「Step8」に修正 |
| 2026-06-29 | 大串 | Chromeで表示される一文(title)・開く際のアイコン(favicon全下層)・リンク送った時の画像(OGP)のチェックを入れたい。見栄え/中身はバッチリだがリンクシェア時やブラウザアイコン未設定が問題。+前要望2つ(端末選んで見れるビューア/コマンドver管理)も「3つ全部まとめてv1.4」 | A | 【現状確認で正直報告: title/OGP/faviconは既にStep10にあった→新ステップ作らず既存強化】v1.4実装: ①冒頭にver管理(改訂履歴)セクション+セルフ進化に改修ごとver+1 ②Step7にマルチデバイス確認ビューア(responsive-check.html自己完結テンプレ・端末幅ボタン+任意px・タップリンク)+シェアプレビュー導線 ③Step10「ブラウザ・SNSシェア表示」独立小節(全下層title/favicon/OGPのgrep網羅+favicon[svg/png/apple-touch]とOGP画像[1200×630]作成+実機シェアプレビュー+og:image 200確認) ④最大の穴=デモはStep10スキップでメタ全抜け→デモ表とStep10デモ注記に最小メタ(favicon/title/OGP)必須を追加(デモこそ/demosでリンク送るため)。振る舞いルールにver管理+ブラウザ/シェア表示の2ルール追加 |
| 2026-06-29 | 大串 | ライティングチェックのステップあったっけ?誤字修正＋コピーライティング(問い合わせが来る文章)で「この文言こう変えたらもっと良くなる」＋改行タイミングのステップ。うちは問い合わせが来るHPを作る会社だから超重要。ここ強化して | A | 【現状確認: ライティングはStep5(初稿)/Step10(最終調整)/Step7(SP言い換え・改行)に分散・誤字もStep10にあった→新ステップ作らず既存を格上げ強化】v1.5: Step10「文言の最終調整」→「ライティング・コピー最終監査」に格上げ(A誤字脱字・表記ゆれ全文/B SEO最終/C コピー改善診断[弱いコピー5サイン→改善の型+例]/D 改行・読みやすさ設計[PC/SP]/E デザイン不変)＋「問い合わせが来るコピーの型(プレイブック)」新設(ヘッドライン公式/ベネフィット変換/CTA設計/不安解消/社会的証明/PASONA・PREP/読みやすさ)。全体像のStep10表記も更新。コピーFBは汎用昇格でプレイブックが育つ |
| 2026-06-30 | 大串 | クライアント納品用HPの共有リンクがhockey-tiles-household-protest.trycloudflare.comになってた。前作った時と違う原因は?→毎回プレビューリンクの1つのリンクに修正入れていって完成したら本番ドメイン接続の流れにしたい | A | 【原因特定: trycloudflare=cloudflared一時トンネル。Step5のGitHub立ち上げを飛ばしローカルを一時トンネルで共有=毎回URL変わる・消える。大串の望む流れ=コマンドのクライアント用設計(Step5 GitHub→固定preview.client-X.pages.dev→pushで同URL更新→完成でmainマージ本番)そのものだが今回守られず】v1.7: Step3の共有リンク[c]を「一時トンネル=自分の一時確認用のみ・クライアント/大串共有は一時トンネル禁止(URL変わる/消える)→Step5でGitHub立ち上げ固定preview link」に明記。起動時提示にも注記。振る舞いルールに「クライアント用の共有URLは固定preview link」追加。trycloudflare/cloudflaredもngrok/localhost.runと同じ一時トンネルと明記 |
| 2026-06-30 | 大串 | 一時トンネルって概念がいらない。全部GitHubで接続してクライアント名入れたプレビューリンク作ってそこに改修していく。本番ドメイン接続できたら接続。改めて見直して今のコマンドの完成形を言語化して送って | A | v1.8: 一時トンネル(trycloudflare/ngrok/localhost.run/cloudflared)記述をStep3から全削除＝概念廃止。クライアント用は案件開始時にクライアント名でGitHub立ち上げ→最初から固定preview.client-X.pages.devにpushして制作・改修・共有→完成でmainマージ本番接続(ローカルは自分の確認用)。デモはローカルのみ。Step3公開コマンド/起動時提示/設計思想/全体像/GitHub立ち上げ見出し(会社名確定時→案件開始時に前倒し)/振る舞いルールを統一。完成形を言語化して大串に送付 |
| 2026-06-30 | 大串 | デモ用もgithub接続して、リンクもクライアント用と同じにして欲しい | A | 【前回v1.1のデモ=ローカルのみGitHubスキップから方針変更】v1.9: デモも案件開始時にデモ名でGitHub立ち上げ→固定リンクpreview.demo-◯◯.pages.devにpushして改修・共有(クライアント用と同じ運用・slugはclient-→demo-)。違いは出口のみ＝デモは本番ドメイン接続(Step11)せずStep9 Lab還元＋/demos公開がゴール。デモ表(GitHubスキップ→GitHub接続)/設計思想/全体像/Step3起動時提示・公開コマンド/Step5 GitHub立ち上げ見出し・冒頭注記(デモはスキップ→デモも実行)/振る舞いルールを統一。デモの他の簡略化(トップのみ/他メニュー→トップ遷移/Step10-12スキップ/Step9ゴール)は維持。※Pages枠は完成デモを/demosに統合後にプロジェクト削除で返せる |
| 2026-06-30 | 大串 | ver1.6のときに作り始めたものが途中で1.9にアップデートされたらそのセッションはどのverで進行する?理想は常に最新verでできたら理想 | A | 【現状確認: Claudeは起動時に読んだ版でセッション進行=v1.6のまま固定。起動時にlearning.md読むだけでgit pull/途中再読込/ver表示なし】v2.0: セルフ進化起動時を強化=①git -C ~/dev/scale-brain pullで最新化②hp-flow.md自身+learning.mdをRead③現行ver(冒頭改訂履歴最上段)確認し「現在vX.Y」表示。+「セッション中の最新同期」新設=各ステップ節目で最新hp-flow.md再Read→verが上がってたら「vX→vYに更新されました最新で続けます」通知して最新手順で進行(作業成果はそのまま手順だけ乗換・後方互換)。+起動時挙動「HP制作フロー開始(現在v{現行ver})」表示。+冒頭ver管理に「ver今何?と聞かれたらpullして現行ver答える」。正直な但し書き=毎瞬完全最新はコンテキスト固定で不可だが節目再読込で実用上ほぼ最新と明記 |
| 2026-06-29 | 大串 | 「レスポンシブ対応はiMacとMacBookで余白感が違うのが気になったけど対応してる?」→現状Step7は「大画面で間延びしないか」程度で型が弱かった。当初「中央寄せ(max-width固定・左右余白)＝A案」で焼いたら、大串「左右の余白が気になる。iMac等の大画面ではMacBookの画面がそのままズームされる感覚にして」と明確化→A案撤回・等比ズーム(B案)で確定 | A | 【横展開Yes＝全HP共通の汎用→Step7標準パックに昇格】v1.6: 標準パック4→5点に。⑤ PC幅 等比ズーム新設＝基準幅(MacBook・通常1440)以上で zoom:calc(100vw/1440)(堅牢版JS clientWidth/base)→大画面はMacBook画面を等比拡大で左右余白ゼロ・余白比率/文字/要素すべて相似。基準幅未満は通常レスポンシブ。zoom採用(transform:scaleと違いfixed/スクロール正しい・全モダンブラウザ対応)。上限キャップ任意。チェック項目に「等比ズーム」行。検証=1440/1920/2560で相似・左右余白なし・横スクロールなし。教訓: 「余白を揃える」には中央寄せ(余白を残す)と等比ズーム(余白を消す)の2方針があり真逆。ユーザーが"左右余白が気になる"なら必ず後者。最初に方針を取り違えたが即訂正(ver管理で1verに収束) |
2026-07-22 既存オリジナル化コードの流用ルート（v2.3）
- FB: 「過去にベースにしたHPをまた使いたい場面が多い。1からやり直すのは時間の無駄」→ 起動時の選択肢として組み込む。
- 設計: ①用途 / ②ベース（[A]参考HPから新規 / [B]既存オリジナル化コードあり）の2問。[B]の渡し方は [b-1]プレビューリンク / [b-2]コード全文 の2択。
- 却下した案: ③に「なし/あり」のyes/noを置く形 → 「③を選んだ時点であるってこと」＝冗長。選択肢は排他2択に畳む（番号の重複・yes/no二重問いはNG）。
- 流用ルートの肝: Step1〜4（mirror/ダミー化/オリジナル化）をスキップしても、①元リポ直接編集禁止（必ずコピー）②前案件痕跡ゼロ化ゲート ③流用元がオリジナル化済みかの検証（未済なら通常Step4へ） は必須。Step8著作権監査も省略しない。
2026-08-17 置換エンジンの境界条件で"静かに壊れる"4事故（v2.6）
| 日付 | FB者 | FB内容要約 | 種別 | hp-flow.md の変更 |
|---|---|---|---|---|
| 2026-08-17 | session(frontier採用サイト デモ) | オリジナル化後、grep全項目クリア・DOM計測(851要素×38プロパティ)も全一致なのに画面が真っ白。原因は body{opacity:0} を打ち消す body.is-loaded{opacity:1} が改名されず切れていたこと（.の直前が英字だと置換しない先読み条件のせい＝複合セレクタが全滅）。子孫だけ走査する検査では body 自身の opacity を見ないため検出不能だった |
A | v2.6: Step4に手順2-c 境界条件4点セット新設（①./#は数字だけ除外②CSS変数--xは英字直後禁止③idはHTML実在のみ④vendor束はクラス置換対象外）＋確認②に実描画スクショ必須＋html/body自身を突合に含める＋セレクタ単位の前後照合を手順3に追加 |
| 2026-08-17 | session(同) | 同案件で連鎖的に踏んだ3件：#fff を id と誤認して #t-fff に破壊（全色無効）／GSAPの.in/.out/.inOut誤爆で power2.out 解決不能→アニメ全停止／.link--arrow の中の --arrow をCSS変数と誤認して破壊 |
A | 同上（4点セットに全部収録）。教訓＝「逆マッピングして差分ゼロ」は過剰改名を原理的に検出できないので、セレクタ写像の実在確認が必須 |
| 2026-08-17 | session(同) | in-appブラウザペインが非表示だと visibilityState:hidden で描画が止まり、スクショが白く写って誤診の元になる。headless Chrome での撮影＋ファイルサイズが数KB=白紙のサインという判定が有効だった。実ブラウザ(claude-in-chrome)での確認が最終的な地上検証になった |
A | v2.6 確認②に「headless Chromeコマンド例／数KB=白紙／実ブラウザ確認」を明記 |
| 2026-08-17 | session(同) | 二分探索ハーネスを作った際、対照実験（変換なし）を先に通さなかったため、ハーネス自体の不具合で「about が原因」という誤った結論が出た | B→A | v2.6 確認②に「対照実験を必ず先に通してハーネスの不具合を除外」を明記 |
2026-08-24 wget非搭載PC＋ダミー化のDOCTYPE破壊（igoods採用サイト案件）
| 日付 | FB者 | FB内容要約 | 種別 | hp-flow.md の変更 |
|---|---|---|---|---|
| 2026-08-24 | session(咲輝PC・igoods) | STEP0のmirrorコマンドが動かないPCがある。咲輝PC(oogushisaki)には wget も Homebrew も無く command not found で無音終了（バックグラウンド実行だと exit 0 に見えて「取得0件」に気づきにくい）。→ curl+python3(bs4) の代替mirror ~/hp-flow-work/bin/curl_mirror.py を作成して解決（264件取得・404ゼロ）。副産物としてwgetの欠陥①(クエリ付きCSS/JS)を設計段階で回避できる（クリーン名保存＋参照書換を最初からやる）ので、wget版より素直 |
B | 本体未変更（候補）。mirror直後に find site -type f | wc -l が0でないかを必ず見るのは既存手順どおりで、今回それが効いた。3回出たらSTEP0に「wgetが無ければcurl_mirror.py」を昇格 |
| 2026-08-24 | session(同) | ダミー化スクリプトが <!DOCTYPE html> をテキストと誤認して破壊（This に置換）。bs4 の Doctype は NavigableString のサブクラスなので find_all(string=True) に含まれる。isinstance(node, Comment) だけ除外する実装では素通りする。DOCTYPEが消えるとquirks modeでレイアウトが崩れるのに、grepでもHTTP200でも検出できない典型の"静かに壊れる"系 |
B | 本体未変更（候補・v2.6手順2-cと同種の境界条件）。対策＝除外を (Comment, Doctype, CData, ProcessingInstruction, Declaration) に広げる／ダミー化後に head -c 60 でDOCTYPE生存を必ず確認。3回出たらStep1に昇格 |
| 2026-08-24 | session(同) | ダミー英文の切り出し末尾が空白になり、元とダミーで幅がわずかにズレる（Entry(5) → This）。切り出しオフセットをずらして「先頭/末尾が非空白」の塊を選ぶだけで解消。対応表CSVで「元文字数 vs ダミー文字数」の不一致0件を機械検証するのが有効だった |
B | 本体未変更（候補）。ダミー化の検品として「文字数不一致0件」を出すのは他案件でも効く |
2026-08-24 v2.6境界条件①の欠陥を実測で発見 → v2.7で訂正（TERASU採用サイト案件 / 参考=recruit.i-goods.co.jp）
| 日付 | FB者 | FB内容要約 | 種別 | hp-flow.md の変更 |
|---|---|---|---|---|
| 2026-08-24 | session(TERASU採用) | v2.6の「.の直前は数字だけ除外」がそのまま事故になった。 クラス名が数字で終わるサイト（c-person2 c-arrow2 p-card2 c-title8＝日本語サイトに頻出）だと .c-person2.-xsmall の2つ目の.が数字直後→モディファイアだけ改名されず静かに死ぬ。実害＝該当CSSが全部初期値に戻り font-size 12→10px・padding 26→0・gap→normal・bodyH −816px。grepもHTTP200も素通りし、セレクタ照合も検証器が変換器と同じ正規表現を共有していたため誤って合格した |
A | v2.7: 手順2-c①を訂正＝先読み (?<![0-9]) は禁止。「.の直後が英字/-/_か」だけで判定する（数値リテラルは直後が数字なので構造的に除外済み＝先読みは元々不要）。教訓: 検証器と変換器で同じ実装を共有すると同じバグで両方すり抜ける |
| 2026-08-24 | session(同) | 収集フェーズで全文字列を走査したら "assets/js/module.min.js" から min js をクラスとして拾い、置換で .t-min.js に破壊しかけた。また --swiper-pagination-*（Swiper本体が読むCSS変数）まで改名対象に入っていた |
A | v2.7: JSからの収集は classList / querySelector の引数だけに限定・拡張子/ドメイン断片の除外リスト・vendor prefix はクラスとCSS変数の両方で除外を明記 |
| 2026-08-24 | session(同) | アニメーションが常時動くサイトは headless の DOM計測が時刻で揺れる。 GTM削除で読み込みが速くなり、フッター切替パネル7枚が計測時点で 0px→「壊した」と誤診しかけた（待機を1.5→6秒で753pxに復帰＝実害ゼロ）。同一ページを2回測るだけで27件のノイズが出る前提で設計すべきだった | A | v2.7: 確認②に切り分けの型を追記（①2回測ってノイズ集合を確定②待機を変えて再測③アニメ停止CSSを注入④変換を個別適用した検体を並べて一気に測る＋無変換の検体を必ず混ぜる）＋最終判定は実ブラウザで、元サイトも同手順で開いて三者比較 |
| 2026-08-24 | session(同) | ダミー化スクリプトが <!DOCTYPE html> をテキストと誤認して破壊（bs4 の Doctype は NavigableString のサブクラス）。quirks mode でレイアウトが崩れるがgrepでは見えない |
B | 本体未変更（候補・2回目）。除外を (Comment, Doctype, CData, ProcessingInstruction, Declaration) に広げる＋ダミー化後に head -c 60 でDOCTYPE生存を確認 |
| 2026-08-24 | session(TERASU採用) | CSS変数を --t-* に改名したのに、JS側の getPropertyValue('--mqUp-lg') setProperty('--area-height',…) {thisWidthVarName:"--width"} が旧名のまま16箇所残っていた。 JSエラーは出ない・見た目もほぼ同じ・確認②（セレクタ照合/bodyH/画像/JSエラー）を全部通過した後に、JS命名の棚卸し中にたまたま発見。放置すればメディアクエリ判定とサイズ計算が死んだまま納品していた |
A | v2.8: 手順2の「全部同時に変える」表にJSが文字列で読み書きするCSS変数を追加＋手順3の検証に「JS内の '--xxx' が全て新名か（vendorの --swiper-* だけ残ってよい）」「実ブラウザで getPropertyValue('--t-xxx') が空でないこと」を追加 |
| 2026-08-24 | session(同) | data-wpel-link が219箇所（WordPressプラグイン WP External Links の痕跡）。JS/CSSからの参照ゼロ＝削除して安全だった。CMS痕跡grepの語彙に wpel が無く、wp-content だけ見ていたら見落としていた |
B | 本体未変更（候補）。Step4-18/Step8のCMS痕跡grepに data-wpel|wpel を足す価値あり。data-*属性の棚卸しを必ずやると芋づるで見つかる |
| 2026-08-24 | session(同) | 18項目のうちやらない判断をしたものとその理由: ①CSSルール並び替え＝同一詳細度の後勝ちが変わりカスケードが壊れる ②JS定義順の組み替え＝巻き上げ/実行順依存で壊れる ③px→rem単位変換＝既にrem主体で効果が薄くリスクが上回る ④timing等価変換＝対象がease系7件のみで効果が無く、linear は linear-gradient と誤爆する ⑤画像ファイル名のt-*化＝Step5で全差し替えするので無意味 ⑥index.htmlのPrettier整形＝inline-block間の空白でレイアウトが変わるリスク（bs4再出力で元の癖は既に消えている） |
B | 本体未変更（候補）。18項目は「全部やる」ではなく「効果とリスクで取捨し、やらない理由を残す」運用が実態に合う。3回出たら本体に注記 |
| 2026-08-24 | session(TERASU採用) | 属性セレクタの盲点が3種類まとめて出た。 [class*=xxx]（引用符なし）だけ処理する実装では、①header[class*="p-hero"]（引用符付き）②[data-class="js-svg"]（属性の"値"がクラス名）③[data-popup="'+t+'"]（文字列連結）が全部素通りし9箇所が断線。しかも is-anchor-current は改名され is-anchor-contain は残る、という隣り合う設定値で片方だけ改名される不整合が起きた（後者はCSS未定義でマップに載らなかったため） |
A | v2.9: 手順2-bに3形式を追加＋検出コマンド（JS/CSSから属性セレクタ形式の文字列を全部抜いて旧名と照合）を明記。教訓: マップは「CSS/HTMLに実在する名前」からしか作れないので、CSS未定義のJS専用クラスは必ず取りこぼす → 属性セレクタと設定オブジェクトの目視棚卸しが要る |