判断の蓄積を、説明できる形で残す

A. マスタープラン v2 に何を統合するか

• 古い strategy/marketing-master-plan.md（2026-04-23、PLG 前提なし）
• strategy/plg-strategy/ 本編 6 本（今日作成）
• strategy/execution-plan-2026-05.md
• decision-log/orchestration-roadmap.md / 2026-05-08-priorities-and-orchestration.md / 2026-05-11-ttv-redefinition.md の Compiled Truth 部分

B. SoT 階層を 3 層に圧縮（運用上のシンプル化）

• Layer 1: 不変の核 ── insights/05-brand-hypothesis.md
• Layer 2: マスタープラン v2 ── 全戦略の最新版（常に「今これが現状」）
• Layer 3: 個別 deliverables ── PRD / blueprint / evaluation / baseline

C. 新議論を Layer 2 に取り込む判断基準（B1-B4）

• B1 旗との整合: insights/05 の 6 つの核と矛盾しないか？
• B2 4 人体制での実現性: feasibility-check が ✅ を出すか？
• B3 既存 deliverables との重複: 既存ファイルで言及済みか？ あれば更新（新規ファイル作らない）
• B4 実データで裏付け: baseline-2026-04 等の実測値で支持されているか？

D. 取り込み判断は agent 3 者合議で標準化

• feasibility-check（4 人体制で回るか）
• director-{plg/traction/pls}-review（該当戦略との整合）
• nanco-ceo-review（旗との整合・最終判断）

E. 古い文書の扱い

• 統合済みの古い文書は _archive/ に退避（削除しない、参照可能に保つ）
• podcast 版（strategy/plg-strategy/podcast/）は残す（用途が違う）
• decision-log は Timeline として残す（Compiled Truth はマスタープランに集約）

A. 5月の優先度（Top 5、確定）

• 機能 LP 3本（/sumaho, /cloud, /excel-migration）公開 ── 5/13 → 5/16 → 5/18
• 広告 本格稼働 ── 5/13（/sumaho 公開と同期）
• ベースライン文書 分割確定 ── A軸 5/10 / B軸 5/22
• ブランド転換 言語ガイド v1.0 化 ── 5/11
• AEO 実装編 設計書 ── 5月末

B. 整合性問題の解 ── 選択肢 C 採用

• 広告開始 5/13 と LP 公開のズレに対し、 /sumaho を 5/13 に前倒し公開して広告のメイン LP に

C. オーケストレーション・アーキテクチャの方針

• GStack ベースのオーケストレーション層を構築（役者 + Playbook + slash command）
• GBrain の哲学（Compiled Truth + Timeline、Brain/Memory 分離、Dream cycle 儀式化）だけを既存構造に取り込む
• GBrain 自体（PGLite + pgvector + cron）は当面導入しない

D. 役者 9名から開始（razor-thin スコープ）

• 戦略・判断（3）: nanco-ceo-review ／ strategy-router ／ feasibility-check
• Director（3）: director-plg-review ／ director-traction-review ／ director-pls-review
• 実行・審査（3）: copy-creator ／ brand-check ／ analyst

E. ワークフロー設計の原則

• 直列のコンベアベルトを基本（GStack）
• 戦略判断のような並列レビューが価値ある場面は Anthropic の orchestrator-worker パターンを併用
• 人発火が前提（自動オーケストレーションは時期尚早）

F. 新設するディレクトリ

• .claude/agents/ （subagent 定義）
• .claude/commands/ （slash command）
• playbooks/ （タスク → 役者の順序）
• decision-log/ （本ディレクトリ）
• pattern-library/ （学習ループ：勝ち / 失敗パターン）

G. CLAUDE.md 改訂

• 5層 → 6層 + 学習ループに拡張

結論

• HTML mockup を捨てない。捨てがたい用途あり ── 業種別データ差し替え / アニメーション（HyperFrames）/ インタラクティブデモ / LP・ヘルプ埋込
• ただし「ソースとずれない仕組み」を 3階層で入れる

3階層の同期パイプライン

• 階層 1 ── Design tokens（色 / spacing / radius / text style）: extract-flutter-tokens.sh で抽出 → assets/flutter-tokens.css へ書き出し ── ✅ 2026-05-10 構築済
• 階層 2 ── Component reference（Widget の見た目）: flutter test --update-goldens で 1 widget = 1 PNG ── 📅 計画
• 階層 3 ── flutter-source-reviewer agent（構造変更の検出）: razor-thin な 13役者目 ── 📅 計画

カバレッジ

• 色 / spacing / 角丸 / 影 / 文字サイズ ── ✅ 自動追従
• 構造変更（リスト行レイアウト変更等）── ⚠️ tokens は OK、HTML 構造は要手動
• 新画面の追加 ── ❌ mockup の新規作成が必要

確定した配置

• Skill: render-app-screen.md（中核：画面 template + dataset → HTML + PNG）
• Skill: extract-flutter-tokens.md ／ verify-flutter-source-fidelity.md ／ generate-item-images.md
• Templates (UI): skills/templates/app-screens/{list, counter-input, item-detail}.html
• Templates (data): skills/templates/datasets/{cafe, landscape, ...}.md
• Playbook: playbooks/app-screen-as-asset.md（薄いラッパー）
• Anti-pattern: pattern-library/anti-patterns.md A-006（子 widget 読み逃しの教訓）

Plan A → A' へのルール照合

最初に提案した Plan A は 2 点でルールから外れていた。 A' で修正:

役者数 12 警告ラインへの対応

• 子 widget 読み落とし問題に、当初は flutter-source-reviewer agent（13役者目）を提案
• しかし「役者 > 12 で警告。本当に新しい役者が必要か / 既存役者のスコープ拡張で済まないか自問」のルールに従い、自問プロセスを実施
• 結論: 役者を増やさず Skill 化で対応（verify-flutter-source-fidelity skill）。 art-director / demo-data-curator がこの skill を呼び出す

結論

• 既存の production component に story を書くだけで動く
• 必要な mock は QueryClientProvider 1 つ + production の scroll container class（.overflow-y-auto.h-full）1 つだけ
• ItemTable は 7 行ピクセル一致で描画
• production refactor は不要

Root cause（silent failure）

• VirtualizedGridTable は production の page layout 上にある .overflow-y-auto.h-full 親要素を document.querySelector で自分で探す設計
• Storybook で見つからないと scrollElement が null → useVirtualizer が空 → 行ゼロ（エラーも投げない silent fail）
• decorator に該当 className を追加することで解決

v1 の誤りと教訓（anti-pattern A-007 候補）

• 30 分の time-box に縛られて深掘りを諦めた
• 1 要素の見落とし（className）を「アーキ的結論」として framing した
• 姉崎の「ちゃんとチェックしてるの? 意図通り?」で再調査、 root cause 特定 → 動いた
• 教訓: スパイク失敗時に「アーキ的結論は出た」と framing するのではなく、 source を読んで root cause を特定するまでが spike

A. 価値の 3 層モデル（PLG 戦略書から再掲）

• Layer 1 超短期 Quick Win（3-5 分）: アイテム 1 個登録 / バーコード 1 回スキャン → ✅ 30_update_count で計測中
• Layer 2 望ましい体験価値（初日〜 1 週間）: Excel 一括投入 / 複数アイテム登録 / 2-3 回再訪 → ❌ 未計測
• Layer 3 習慣化（数週間〜数ヶ月）: チーム招待 → 招待された側が更新 / 月末棚卸し短縮 / 発注判断軽減 → ❌ 未計測（本物のゴール）

B. 確定した運用

• 現実装の Layer 1 計測は継続。 数値そのものへの過剰な PDCA は今は回さない（オンボ新版が出るまで本番じゃない）
• ダッシュボードに「Layer 1 暫定指標」のバナーを追加 → 数値を見た人が「26% だから即対策！」と早まらないように
• derive_recommendations の rank=1 を「Quick Win 定義の見直し（Layer 2/3 の合意形成）」に差し替え
• Layer 2/3 の具体的イベント追加は今は実装しない（イベント定義そのものが未確定）
• 戦略書 v1.0 はまだ書き換えず、 本 decision-log を「Layer 2/3 への拡張は v1.1 で扱う」というクッションとして使う

C. Open Questions

• Layer 2 のトリガー: 「Excel n 行以上」「2 回目ログイン在庫更新」「初回 24h 後再訪」のどれか
• Layer 3 の「招待されたメンバーが更新した瞬間」を PostHog で識別可能か
• ダッシュボード呼称「TTV 分析」→「PLG ファネル基盤」に変えるか

A. master-plan v1 → v2 の主な変更

B. project-manager 役者の新設（同日追加）

• 姉崎質問「スケジュールをたてるのって誰がやってる？」で発覚 → 既存役者は誰も担っていなかった
• 姉崎判断「プロマネが絶対必要だね」で確定
• スコープ: スケジュール策定だけ（Top N 提案 / Mermaid Gantt / 容量チェック / A/B/C 選択肢）
• 戦略・判断レイヤー 4 番目（14 役者目、警告閾値超過の継続を許容）
• 2026-05-08 で削除した pm-orchestrator（自動オーケストレータ）とは別物（人発火・razor-thin・起案だけ）

C. planning-cycle Playbook 新設

• 不定期の優先度再整理ルート（戦略転換 / 想定外の遅延 / 新規大型タスク）
• 6 Phase 構成（入力整理 → 戦略軸並列整理 → 容量チェック → PM 起案 → 並列審査 → 最終承認）
• 月次・四半期は別 Playbook（monthly-review / quarterly-strategy-review）に PM 起動を組み込む方針

D. 残る Open Questions

• §11 直近の優先順位と execution-plan-2026-05.md の二重管理解消
• §7 オンボーディング節の独立 doc 格上げタイミング
• 役者追加（pricing-reviewer / customer-voice / competitor-watch）の §4 反映の仕組み
• master-plan / execution-plan / strategy-selection-rule の役割境界のさらなる明文化

A. 新設した役割と仕組み

• Linear Marketing team（key: MARK、 private、 姉崎個人）✅ 作成済
• 戦略軸 label plg / traction / pls（Marketing team scope）✅
• 試験 issue 5 件（MARK-1〜5、v2.1 §11 直近の優先順位上位）✅ 起票済
• PM v0.2 = v0.1 + Linear 連動（Phase 5-7）+ COO 思想部分採用 ✅
• linear-sync skill v0.1（PM が呼ぶ Linear 操作の手の道具）✅
• planning-cycle Playbook v0.2 = Phase 6.5（Linear 現状把握）+ Phase 7（Linear 反映 + 整合性チェック）✅

B. PM v0.2 の scope 拡張

• 役割: スケジュール策定 only → スケジュール策定 + Linear 反映 + 全体整理
• Phase 数: 4 → 7 / 評価軸: 5 → 8（軸 6 Linear 起票判定 / 軸 7 二重簿記禁止 / 軸 8 必ず締める）
• Tools: Read / Grep / Glob + Linear MCP 12 tools
• razor-thin は「同一意思決定経路を切らない」原則で維持

C. なぜ案 A（PM v0.2 に取り込む）を採用したか

• 姉崎判断: 「プロマネ」が「スケジュール策定 + Linear 反映 + 全体整理」を 同一担当 でやるのが現実的
• 役者数 14 を維持（15 に増やさない、 警告閾値超過の継続を回避）
• 個別タスク実現性は引き続き feasibility-check、 戦略主担当は strategy-router、 戦略整合性は 3 Director、 旗印整合と最終判断は nanco-ceo-review が担う

D. nanco-agent COO 思想の部分採用

• ✅ Linear = SoT、 二重簿記禁止、 必ず締めるプロトコル
• △ decompose, don't execute（Linear MCP に限定、 file write / browser は禁止）
• ✅ AI-INSUFFICIENT 判定 5 基準（戦略骨格 / 旗印影響 / 5 回 retry / 法務・契約 / クリエイティブ最終判断）
• ❌ 完全な agent 分離（COO ≠ PM の独立役者）── 役者数増加を避けたため

A. 役割の明示

• Linear Pulse / Status Update: 1 cycle / 1 project / 1 issue 単位、 issue 進捗（Done / In Progress / Backlog）、 Linear 自動生成、 チーム内（hidemaro / fukaishi / Maro）、 Linear UI、 短命（cycle archive）
• nanco-reports: 週次 / 月次 / 四半期 / 全戦略横断、 数値傾向 + 戦略コメント + chart、 AI ドラフト + 姉崎レビュー、 姉崎 / 外部レビュー、 HTML 共有、 長命（時系列で蓄積）

B. 具体例

• Linear Status Update: 「Cycle 1 (5/18-5/24): 11 issue 投入、 8 done / 2 in progress / 1 carry over」
• nanco-reports/weekly-plan-2026-05-25.html: 「先週の Cycle 1 完了率 73%、 inner ring 候補で /sumaho が CTR 8.2% でリード。 PLG 軸の B 軸 baseline 確定 → 来週からエンプティステート A/B 着手」

C. 採用予定の運用フロー（週次）

• 金曜夕方: Linear が week summary を自動生成
• 月曜朝: nanco-daily-sync routine が前週 Linear data を取得
• 月曜朝: AI が weekly-plan-YYYY-MM-DD.html を生成（前週総括 + 今週計画）
• 月曜朝の朝会: 姉崎レビュー → 公開

A. 採用 7 案（stable/ 配置）

• hero-champion.webp（hero 第 1 候補、 由来 v15/08）
• hero-successor.webp / hero-controlled.webp / hero-warm.webp
• industry-zoen.webp / industry-cafe.webp / industry-manufacturing.webp

B. 廃止した旧方針

• ❌ industry-painterly / industry-photo（背景が UI を奪う、 6 業種 × 2 = 12 ファイルの保守も無理）
• ❌ organic-{teal,mint,...} + 手描き curves（「波・地形・モチーフ」として読まれ NG）
• ❌ watercolor-wash（AI ぽさ / OpenAI 模倣に振れすぎる）
• ❌ 業種コラージュ（Granola 流）を hero メインに据える ── React-only の選択肢としては残す

C. 制約と原則

• iOS / Android / Web マルチプラットフォーム → OS 固有の照明（Apple 風 radial glow）は避ける
• 4 人運用 → 重い asset（動画 / Lottie / 大判 WebP）は使わない、 CSS / inline SVG ベースで完結
• LP コードは stable/ を変動なく参照、 ファイル差し替えのみで採用更新可

A. 標準スタック

• 実装方式: React + Tailwind 4 in nanco_hp_2026/components/mockups/
• 主 component: MobileListScreen.tsx（data-prop driven）
• LP 用 wrapper: MockupCard（背景白 / 影 / 角丸を統一）
• 影: SHADOWS['comeau-hero']（Joshua Comeau "large" × 3 scale、 グレー 50%、 X=0 真上、 5 層 doubling、 opacity 0.2 一律）
• 角丸: 14px（最初 28px → 姉崎「大きすぎる」→ 14 に縮小）
• ステータスバー: showStatusBar={false}（cursor / linear / notion 流、 OS 非露出）
• デバイスフレーム: 無しが標準。 iPhone explicit が要る時のみ PhoneFrame、 light bezel なら MinimalFrame
• 画像準備: sips --cropToHeightWidth 120 120 --cropOffset 19 19 で右下 cutout 残骸を排除した *-clean.png
• Icon: nanco-flutter と同じ lucide-react

B. 旧 HTML mockup workflow との位置づけ

• LP 上 live mockup → 本決定（React + Tailwind in hp_2026）
• OGP / SNS / メール用 PNG → 旧 HTML mockup or storycap
• オンボ動画用 HTML 入力 → 旧 HTML mockup（HyperFrames に渡す）

A. Cycle 2 の位置づけ

• 収束フェーズ: Cycle 1 で立ち上げた LP（/sumaho /cloud /excel-migration）+ Google Ads + B 軸 baseline を支える ブランド言語 + AI 引用基盤 + オンボ基盤を 1 週間で仕込む
• 最重要: MARK-46 positioning-rebrand v0.1 → v1.0 化（月火で終われば MARK-47/48 の Traction 連鎖と MARK-27-30 の AEO 子が解放）

B. CEO 修正提案（採用）

修正理由: MARK-40（monthly-review Playbook 構築）は横断インフラで旗印に直接連結しない。 MARK-25 FAQ 設計は AEO 収束の責任ページ基盤で旗印「AI と共進化する」 に直結

C. win-pattern 候補

• 「収束フェーズでは 連鎖ブロッカー解消を優先し、 横断インフラ（Playbook 構築）はコアから外す」

A. master style 要点

• カラー: pure #FFFFFF bg / #367976 線 / #89BCBC 主塗り / #EBF5F0 副塗り / #111111 髪・脚 / #F2942F アクセントのみ
• 線質: hand-drawn wobble、 ink-pressure 変化、 コーナー gap/overshoot 許容、 フラット塗り
• キャラ: NO MOUTH / 小さい顔 / 大きな黒髪マス / 長い黒い脚 / Hook ハンド / 編集寄り elongated
• 構図: 60-30-10（主体 / 浮遊要素 / キャラ）、 スマホ画面は blank pure white
• 装飾: sparkle dots / star / 封筒 / 紙 / ベル（アラート専用）/ トロフィー（受賞専用）

B. 確定セクション素材 5 種

• 使いやすさで受賞（ZO3, Victory pose）
• アイテム属性（ZK2, Bottle + 3 attribute tags）
• 在庫アラート（ZL1, Box + bell + !）
• エクセル取り込み（ZM3, Excel rows → smartphone list）
• みんなで共有（ZQ 系、 選定中）

C. ロードマップ

• Phase 1（今週）: SoT 化 ── 3 ファイル作成 ✅
• Phase 2（今月）: /sumaho LP への適用、 半自動モデル（40 案 + AI フィルタ + art-director コメント + CEO 30 分判断）の実証
• Phase 3（7 月、 Phase ε4）: skills/design-exploration.md 新設、 playbooks/lp-creation.md Phase 2.5 統合

A. 引き継ぎ対象（全て main マージ済）

• Visual master style spec / 探索パターン P-006 / 確定経緯（visual-master-style-confirmed）
• 確定セクション素材 5 枚（design-exploration/samples/feature-mobile-app/assets/generated/c-section-z*.png）
• candidate-27 LP base（HTML）
• 既存 /sumaho draft（⚠️ 2026-05-07 時点、 最新戦略と要再照合）

B. 新 PC でのセットアップ手順

• repo 取得 → OpenAI API key（gpt-image-1 用）配置 → Chrome / Python + PIL / gh CLI / git 確認
• Claude Code 起動後の最初のメッセージはハンドオフ doc を参照する形式

C. なぜハンドオフ doc を decision-log に置くか

• Cursor / 別 Claude Code セッションが起動時に最初に読む箇所として、 decision-log/ は SoT 階層の中で参照頻度が高い
• 従来「README に書く」→ 散在しがち、 「session に書く」→ 終了時に埋もれる、 「decision-log」→ 経緯と参照点がセットで残る

A. 衝突した 2 session

統合解: 両思想を 1 ドキュメントで両立。 render-app-screen v1.1 として 3 路線整理（A: LP 同居 / B: PNG 派生 / C: 動画フレーム入力）に再構成、 各路線の運用 skill を明示

B. 解決の手順

• main の uncommitted を stash 退避 → sweet-kowalevski を main にマージ → stash pop → render-app-screen で再衝突
• 手動マージで「3 路線整理」として両思想統合: 冒頭に A/B/C 路線表 + 各路線の運用 skill 明示 + 改訂履歴 v0.1 → v1.0 → v1.1 整理
• intelligent-babbage 由来の他 32 files を代理 commit（4abb778）

C. 残る運用ルール

• 同じ skill ファイルに同時に走る 2 セッションを許容するが、 マージ時は 両思想を 1 ドキュメントで両立可能か検討（即座にどちらか棄却しない）
• 「deprecated」 という強い語は使わず、 「A/B 用途は派生 skill に移管、 C 用途は本 skill で継続」 という位置づけ表現を採用

A. 確定した 10 知見（重要度・横断性が高いもの）

• 内部座標オーバーレイ原則（極高 / 全 mockup overlay 系で効く） ── overlay は target component と 同じ @container + 同じ transform scale の下に置く。 % 換算しない
• State machine + useRef pattern（stale closure 回避）
• AnimatePresence + custom={direction}（2 兄弟が direction を共有して同時スライド）
• iOS transition cheat sheet（forward / back / sheet の y/x parallax 比率）
• Material Design bounded ripple（4 効果合成）
• Frame geometry 整合（MinimalFrame.screenHeight + MobileListScreen.topPadding）
• Data 整合性 chain（buildDemoData で folder/counter/detail を連鎖）
• Per-industry シナリオ多様化（SCENARIO_STEPS[industryKey]）
• Delta 色マッピング（Flutter diff_helper.getDiffColor 準拠）
• タイミング設計の経験則（600ms タップ間隔 / breathing / ripple 完走 / sheet close）

B. 守るべき制約（skill 化時の scope ガード）

• ❌ M3 ROI gate（6/30）通過前に MP4 / GIF / SNS 動画化はしない
• ❌ 3 軸並列 A/B はしない（Week 1-4 は「ScriptedDemo あり vs なし」の 1 変数のみ）
• ⚠️ CLS / Core Web Vitals 影響を要確認
• ✅ 業種別 LP 量産は M3 通過後、 skill 経由で量産

C. シナリオ設計

• 4 scene state machine: home → folder → counter → folder → itemDetail
• 12 秒 loop で 6 業種クロスフェード巡回（zoen → cafe → apparel → bakery → beauty → manufacturing）

A. 決定事項

• 「簡単」をヒーロー訴求語として使う方針には戻さない（positioning-rebrand-2026.md §4-1 NG 指定を維持）
• 「在庫管理 簡単」単体 KW（100/月）を新規 LP で取りに行く計画は立てない（棚卸しクラスター 30,000+/月 や 機能 LP「在庫管理アプリ」3,400/月 にレバレッジ 40-150 倍）
• 例外 2 箇所のみ「簡単」を限定使用: (1) /inventory/template Body コピー内（サブ KW「在庫管理表 見やすい 簡単」400/月）、 (2) AI Overview / FAQ 形式の本文（問い形式で補助語として）
• 代替表現 5 語彙を機能 LP の標準推奨に: 「迷わず使える」「スマホで完結」「30 秒で登録」「当日から動く」「バーコードをスキャンするだけで完結」

B. Ahrefs JP データ抜粋

• 在庫管理 簡単: 100/月 ／ 在庫 管理 簡単 系: 計 150 ／ 在庫管理表 見やすい 簡単 系: 400 + ロングテール 750
• 在庫管理 シンプル / わかりやすい / アプリ シンプル: 各 0
• ロングテール合計でも 700-800/月（棚卸し系の 1/40 以下）

C. 保留事項

• AI Overview 側「Q&A 形式本文 + 構造化データ」の具体は Month 3 の AEO 検証フェーズで再検討
• 「在庫管理 アプリ」3,400/月 の比較記事系 SERP への割り込み戦略は別議論

A. 5 論点の判断結果

• 論点 1（D 採用）: プロダクトツアー（S7）を v0.1 から外す。 ウェルカム + スタートガイドで全体像を伝える（24h 勝負 + ツアー = 割り込みの原則と整合）
• 論点 2（廃止）: Path D 役割選択を廃止 → 全員非管理者として同じ単一フローに統合（「ワークスペースを最初に作った人 = オーナー = 管理者」 という前提）
• 論点 3（C 採用）: 質問駆動スキップ後の戻り口 = エンプティステートに「業種を選んでサンプル生成 ・ 30 秒」 リンク併設、 アイテム 1 個以上で自動消去
• 論点 4（候補 B + 母数条件、 CEO 裁定）: Path D 活性化率目標を 0% → 15%（v0.1 後 1 ヶ月、 N≥10）→ 25%（v2.0 後 1 ヶ月、 N≥15）→ 40%（Phase 2）。 タイミング軸を月別 → リリース版別
• 論点 5（A 採用）: 業種数 7 → 8（設計建築・施工 追加）を v0.1 から含める。 プリセット v0.2 を正本

B. 論点 4 の CEO 裁定軸（候補 A vs 候補 B）

CEO 判断の核: 候補 A は「達成手段が存在しない目標を公式 KPI とする」 = 旗印核 5「現場に足を運んで、 お客さんの声で作る」 の対極。 数字を作るために現実を無視しない

C. 学習ループ反映

• pattern-library/win-patterns.md に P-009 追加: 「ディレクター 2 名一致でも CEO 裁定で旗印整合性を確認すると核軸が出る」。 PLG / Traction 両者一致時でも CEO は「到達手段と目標の誠実な紐づけ」 という新判断軸を提示する
• 反例の教訓: PRD と詳細設計 doc の更新タイミングずれで古い目標値が「公式 KPI 風」 に残る。 SoT 同期プロセスを Playbook に組み込む課題