4フレーム（前提 → 課題 → 施策 → 目指す姿）で全体を置く。
Event 形式に正規化して合流させる| 要件 | 効いてくる機構 | |
|---|---|---|
| 1 | どこでもいつでもシームレスに思考の整理ができる ← 最優先・未充足（Q-11） | A 入力 / F 表現 |
| 2 | 24時間自律的に思考してアップデートさせる | E 思考 / G 制御 |
| 3 | 極力多くのコンテキストを集約（音声・PC作業ログ） | A 入力 / B 正規化 |
| 4 | 見て思考できる表現。HTMLが理想 | F 表現 |
| 5 | この取り組み自体を型にしてプロダクト化 | C 抽出 / D 合流 / E 思考 |
| 層 | 役割 | 既にあるもの | 足りないもの |
|---|---|---|---|
| L1 Capture | どこからでも入る | inbox / _captures / Gmail・Calendar・Drive / Claude会話ログ | モバイル投入口、作業ログ、音声の定常化 |
| L2 Store | 事実と論点をMDで持つ | context/ · org/ | 未解決の問いを構造で持つ形式 |
| L3 Reason | 定時に読み・考え・更新 | process.py（手動） | スケジューラ、常時ホスト |
| L4 Render | HTMLの作業台 | フォーマットの型（分解済み） | ビルダー、状態の書き戻し |
音声も作業ログも、そのまま貯めても思考は1ミリも進まない。L1→L2 で必ず Fact 化を挟む。Odyssey の Facts → Derived → Surface と同じ構造を踏む。
生データはローカル、構造化MDだけが Git に乗る（既存ルールと一致）。
既存の「HTML自動生成NG」が禁じていたのは pandoc のような素の変換で、理由は「グラフ・図が出ないから」。原則そのものは MD → HTML の一方通行（HTML側を編集してMDに戻さない）。
思考作業台も同じでいい。ただし毎日データが動くので手作業では破綻するため、コンポーネント語彙を持つビルダーで生成する。素の変換ではないので、NGの理由には抵触しない。
毎朝全文再生成されたページは読まれない。エージェントが1日にやるのは「未解決の問いを1つ進める」こと。進んだ差分だけを通知する。
正規化が要だからといって、正規化が完璧になるまで先に進まないのは誤り。文字起こしが7割の精度でも通す。そのために Event は confidence を持ち、下流が精度を見て自分で判断する。精度向上は独立したタスクとして、パイプラインを止めずに進める。
ユニット境界は分業境界でもある。 精度向上を切り離せることと、担当を切り離せることは同じ性質。CTO・Platform などの担当Agentに丸ごと委譲できる単位で切る（担当の割り当ては論点 Q-10）。
4層をさらに機構単位に割る。チャネルを増やしても下流を書き直さないための分割。
黒く塗った B・C・D・E が売り物になる部分。A・F・G はコモディティ（既存ツールで代替が効く）。
| チャネル | 取得 | 所在 | 機密度 | |
|---|---|---|---|---|
| A1 | 音声（会議録音・ボイスメモ） | イベント | ローカル | 高（同席者あり） |
| A2 | AI会話ログ（Claude Code / Claude.ai） | 自動 | ローカル | 中 |
| A3 | PC作業ログ（シェル履歴・Gitコミット・アプリ使用時間・ブラウザ履歴） | 常時 | ローカル | 中 |
| A4 | 画面キャプチャ | 手動＋常時化可 | ローカル | 高 |
| A5 | 外部（Gmail / Calendar / Drive） | 自動 | クラウド | 中 |
| A6 | 手動投入（inbox・モバイルからのクイックメモ） | 手動 | 両方 | 低 |
A1・A3・A4 はローカルにしか存在しない。ここだけは常駐エージェントが要る。クラウドと二段構えになる。
ここが全体設計の要。これを飛ばすとチャネル追加のたびに下流を全部書き直すことになる。
Event = { id, ts, source, actor, modality, raw_ref, text, confidence, privacy }音声の文字起こし・話者分離はここ。要約はここでやらない — 要約は情報の破壊なので、抽出より前に置くと戻せなくなる。raw_ref は生データへのポインタで、生データ自体はGitに乗せない。
5種に分ける。Fact（起きたこと・数字・決定）/ Question（未解決の問い）/ Claim（仮説）/ Task / Entity（人・会社・案件）。
すべてに source_event_id を必ず持たせる。なぜその結論に至ったかを生データまで遡れること — Odyssey の Fact-first と同じ原則。後から足せないので1号機で入れる。
無設計だと同じことが何度も書かれて腐る。3操作に分解する。
| 操作 | 内容 | |
|---|---|---|
| D1 | 同定 | この Fact はどのトピックの話か（案件マップによるルーティング） |
| D2 | 突合 | 既存記述に対して 追加 / 更新 / 矛盾 の3値判定 |
| D3 | 昇格 | 壁打ち（contexts）→ 正本（org）へ上げるかの判断 |
1回の実行でやるのは「未解決の問いを1つ選んで進める」だけ。不足情報の特定 → 調査 → 仮説更新 → ステータス変更。出力は差分と、新しく生まれた問い。
問いの選び方＝優先度関数（重要度 × 鮮度 × 行き詰まり度）。ここが将来いちばんの知財になる。
ビルダーが MD + YAML を読み、コンポーネント語彙（4-Frame / pipeline / per-table / callout / knowledge-card）に変換する。ページ種別は3つ。
公開ビルドと手元ビルドを出し分ける。私用タブはCSSで隠すのではなく、公開ビルドでは出力しない。
スケジューラ、ホスト、シークレット、実行ログ、失敗時の挙動。書き換え権限は org と同じ A（自律）/ P（起案→承認）/ H（人間専決） をそのまま使う。
横断でプライバシー等級（クライアント機密＝Arcbridge 等は別扱い）と生データ保持期間を持つ。
| 1号機で作る | 後回し | |
|---|---|---|
| A | A6 inbox ＋ A2 会話ログ ＋ A1のうち既存の会議録音 | A3 作業ログ、A4 常時キャプチャ、A1 常時録音 |
| B | Event スキーマ確定 ＋ 文字起こし | 話者分離、マルチモーダル |
| C | Fact / Question / Task の3種 | Claim / Entity、関係グラフ |
| D | D1 ルーティング ＋ D2 の簡易版 | D3 自動昇格 |
| E | 1日1問 | 優先度関数の高度化 |
| F | テーマページ ＋ 日報 | ポータル、状態の書き戻し |
| G | ローカル cron | 常時ホスト、権限分離 |
source_event_id を必ず持たせる（C）— 遡れなくなってからでは足せない必要なのはストレージではなく常時起動と実行環境。NASはCPUが弱くエージェントを回すのに向かず、CTO方針（自前サーバを持たない・サーバーレス原則）とも衝突する。
| 手段 | コスト | いつ | |
|---|---|---|---|
| 1 | 既存Macを常時起動 ＋ launchd | 0円 | まずこれで足りる |
| 2 | Gitリポに対するスケジュール実行（クラウド） | 従量 | workspace が既にGitなので相性が良い |
| 3 | Mac mini を思考ホスト専用に | 10万弱 | 1・2で足りなくなったら |
| 4 | NAS | — | 音声・画面の生データを年単位で貯める段になってから |
順序の理由：一番壊れやすいのは Step 3。先に収集（Step 4）を広げると、思考にならないゴミが溜まるだけで終わる。
原則：環境に依存する部品は1つだけにする。 それ以外は Git 集約とクラウドで解く。
BF の稼働基盤の結論（2026-07-31・GCE常駐は不採用、イベント取り込みはサーバーレス）と同じ方針。 そこで既に動いている配管に相乗りすると、思考OS側で新規に作るものが大きく減る。
| 機構 | 環境依存 | 実現手段 |
|---|---|---|
| A1 音声 | なし | BF の TLDV webhook が既に稼働（社員第1号が議事録を自動投稿中） |
| A2 AI会話ログ | あり | ローカル吸い上げバッチ |
| A3 PC作業ログ | あり | ローカル吸い上げバッチ |
| A4 画面キャプチャ | あり | ローカル吸い上げバッチ |
| A5 外部API | なし | サーバーレスで取得 |
| A6 手動投入 | なし | BF の Slack Events API に相乗り |
| B〜G | なし | Git ＋ CI ＋ サーバーレス |
ローカル常駐が必要なのは A2・A3・A4 の吸い上げだけ。 Mac が落ちていても他は止まらない （Event は append-only なので、復帰後に追いつける）。設計原則4がここで効く。
MD と HTML の整合を人間の記憶に依存させない。ルールを Git に置き、パイプラインが毎回それを読む。
規約は2枚に分けてある。判断はルール、変換はコードという境界を守る。
| ファイル | 持つもの | 実装 |
|---|---|---|
rules/update.md | 触っていい場所・3値判定・論点の状態遷移・重複禁止・出典・文体 | LLM が読む |
rules/render.md | 一方通行・公開/非公開・記法・コンポーネント語彙・タブ構成 | build.py が実装 |
CI（.github/workflows/thinking-os.yml）が incubation/thinking-os/ への push で ビルドし、公開先へ反映する。MDが変わってHTMLが変わっていない状態が構造的に起きない。**
Step 1 の成果物。incubation/thinking-os/ に構造がある。
| 場所 | 役割 |
|---|---|
pages/ *.yaml | 正本。人間とAIが編集するのはここだけ |
core/ | ページ骨格・コンポーネントCSS・作業台JS |
build.py | MD/YAML → HTML。公開用と手元用を出し分ける |
dist/local/ | file:// で開く手元用（私用タブを含む） |
dist/public/ | docs.plangers.com 公開用（私用タブは出力しない） |
MD の中に生HTMLを直接書けるので、4-Frame や pipeline のような視覚コンポーネントは作り込める。pandoc 的な素の変換ではない。
この設計が乗っている既存の資産と前提。ここを読めば、なぜこの形になったかが分かる。
個人のビジネスアイデア集（GitHub Pages）を分解したもの。価値は事業内容ではなく「1テーマ＝1HTML を、読み物ではなく潰していく作業台にしている」という一点。
骨格は5つ。固定TOC＋820px1カラム、タブで思考を層に割る、h3の折りたたみ＋理解済みチェックと論点の進捗表示、意味を持つコンポーネント語彙（4-Frame・phase・per-table）、そして公開／非公開の同居。
A 思考整理 / B 議論喚起（叩き台） / C 合意記録（正本）/ D 共有伝達 / E 実行指示。B と C は作り方が真逆で、混同が一番の事故要因。
このページは B。だから清書していない。ポジション（Answer仮説）を置き、論点を晒し、余白を残す。完成させた瞬間に議論が閉じる。
分ける基準は「何のために集めるか」。Odyssey はあなたを理解するために集め、本構想はあなたの問いを前に進めるために集める。同じ音声を食っても目的が違えば別プロダクト。
BF の語彙にそのまま乗る — 職種＝参謀職、context蓄積＝L2、日報（daily-digest）＝L4のHTML作業台、1on1＝論点の棚卸し、面接→persona.md＝何を考えたい人間なのかの初期設定。BF は「初日から働く → 育つ → 戦略相談相手」の段階論を持つが、3段目を実装するジョブがまだ無い。
副産物として接続する。思考ログは Stated（書いたこと）と Revealed（実際に何に時間を使ったか）が同時に取れる希少なデータで、Trait 供給源としては最高品質。
ただし主目的にはしない。Odyssey を主に置くと「理解のためのデータ収集」に引きずられ、肝心の思考が進まなくなる。
禁じていたのは pandoc のような素の変換で、理由は「グラフ・図が出ないから」。原則そのものは MD正本 → HTML の一方通行（HTML側を編集してMDに戻さない）。
思考作業台はコンポーネント語彙を持つビルダーで生成し、MD の中に生HTMLで図を書けるようにしてあるので、NGの理由には抵触しない。ピッチ資料（手作り込み）とは別カテゴリとして扱う。
「どこでも誰でも同じようにAI開発できること」が技術の最上位原則。サーバを持った瞬間にインフラの面倒を見る人間が必要になる。全サービス GCP(Firebase) 統一、AWS は Route 53 のみ。
本構想はこの方針と一部衝突する — PC作業ログ・画面・音声はローカルにしか存在しないから。だから「収集だけローカル常駐、思考と表現はクラウド」の二段構えにして、方針の例外を収集ユニットに封じ込める。
docs.plangers.com（Firebase Hosting の docs ターゲット、ソースは corporate-site/pitch/）。auth.js による簡易パスワードゲートが全ページに掛かる。
ただしこれはクライアントサイドの気休め認証で、HTMLのソース自体は取得できる。だから私用タブは公開ビルドに含めない。認証で隠すのではなく、そもそも出力しない。
未決のものだけをここに置く。決着したら下の「決着済み」へ移す。 Q-01 と Q-03 が他をブロックしている。
案1会議録音のみ（既存運用の延長。すぐ始まる）
案2会議＋ボイスメモ（移動中の思考が拾える。ここが一番おいしい可能性）
案3常時録音（情報量は最大。だが同席者のプライバシー・容量・法務が一気に重くなる）
判断材料：クライアント同席の会話が混ざる以上、機密等級を Event に持たせないと Arcbridge 等が事故る。
全部にすると D1（同定）のルーティング先が増え、判定が難しくなる。一方、資産・不動産・家族の判断は既に topics に入っていて、思考としては地続き。
暫定：既存の topics 構成をそのままルーティング先にする＝生活も含む。ただし収集チャネルは仕事側から広げる。
BF の稼働基盤の結論に合わせる（2026-07-31・GCE常駐は不採用、イベント取り込みはサーバーレス ＝Cloud Functions ＋ Slack Events API ＋ TLDV webhook）。思考OS だけ別のホストを持つ理由がない。
残るのはローカル吸い上げバッチ（A2/A3/A4）を何で回すかだけ。これは Mac の launchd で足りる。 落ちても Event は append-only なので復帰後に追いつける。
NAS も Mac mini も当面不要。常時起動が要るのは「即応の壁打ち」だけで、それも BF の Slack Events API に相乗りすればサーバーレスで済む。
後から足せないフィールドと、後から足せるフィールドを切り分ける必要がある。id / ts / source / raw_ref は必須。confidence と privacy は、後付けすると過去分が全部欠損するので最初から入れるべき。
actor（誰の発言か）は音声を入れる段で要るが、1号機では null 許容でよいか。
案1日報に混ぜる（見落とす。数が増えると流れる）
案2専用の「未決キュー」を持ち、溜まった件数を常に表示する（無視できなくする）
設計原則3（出力は差分だけ）と衝突しないよう、矛盾は差分とは別の導線にするのが筋に見える。
案1MD の frontmatter に持つ（1ファイル完結。だが人間の編集とぶつかる）
案2YAML サイドカー（
ブラウザからファイルは書けないので、どちらにせよローカルの受け口が要る。公開版は読むだけになるため、状態を持つのは手元ビルドのみという割り切りもあり得る。ここが決まるまでは localStorage のまま。
Q-11（どこでもブラッシュアップ）に直結する。 localStorage のままだと端末ごとに状態が食い違い、「どこでも同じように」が成立しない。優先度は Q-11 に引きずられて上がる。
精度をゲートにしないと決めた以上、「何%なら通す」ではなく「低精度のEventが下流でどう扱われるか」を設計する話になる。
暫定：confidence が閾値未満の Event から作られた Fact は、正本に昇格させない（D3で止める）。表示はするが、判断の根拠には使わせない。
暫定：自分で3ヶ月回して型が抽出できてから。基準の候補は「自分が毎朝開いているか」「人間が起動せずに論点が進んだ回数」。
先に製品化すると、自分でも使わないものができる。1号機は自分用に振り切る。
案1BF内で完結（アカウント認証・HTML出力・壁打ちUI・Slack連携をBFのコンソールが持つ）
案2自前ドメインに出す（docs.plangers.com のように、成果物だけ外に置く）
案3選べるようにする（BF側は出力先を切り替えるだけ）
BF を「AI社員」として見ると、認証・HTML出力・壁打ち・各種セットアップ（Slack接続等）は 参謀職に固有の機能ではなく、どの職種にも要る共通コンソール。だから BF 本体の機能として持つのが筋。
その上で出力先は顧客ごとに変わる（自社ドメインに出したい顧客もいる）ので、 出力先を選択制にするのが素直に見える。案3が有力。
先の話だが、ここを先に決めておくと F（Render）の実装が出力先非依存になる。 いま dist を local / public に出し分けている構造は、そのまま出力先プラグインに拡張できる。
ユニット分割の目的の半分は分業。CTO・Platform・PdM 等の担当Agentに丸ごと委譲できないなら、 分割が甘い。
粗い当たり：A/B（収集・正規化）と G（実行基盤）は CTO 配下、C/D/E（抽出・突合・思考）は知財なので PdM 側、F（表現）は誰でも触れる。ただし未検証。
要件1がいま一番満たせていない。閲覧はどこでもできるが、外で更新ができない。 これが解けると構想全体が加速するので、他の論点より優先度が高い。
動作を3つに分けると、必要なものが違う。
| 動作 | 必要なもの | 実装コスト |
|---|---|---|
| 投げ込み（思いつきを捨てる） | 遅延OK。ポーリングで足りる | 小 |
| ブラッシュアップ（書き換える） | 正本リポへのアクセス＋文脈 | ゼロ |
| 壁打ち（即応の対話） | 常駐ホスト | 中（Q-03 依存） |
暫定結論：3つを別々の手段で解く。1本にまとめようとしない。
plangers/plangers-workspace）に乗っている。Claude Code の web／モバイルからこのリポを直接触れば、手元と同じ文脈で pages/ を書き換えられる。 実装ゼロで今日から成立する。 これが要件1の本体
conversations.history をポーリングして Event 化し、論点に紐付け、HTML を再生成してスレッドに差分を返す。 常駐不要（cron だけ）なので Q-03 を待たずに作れる
サイト上での編集は作らない。 Firebase Hosting は静的配信で書き込めず、 auth.js は気休め認証なので書き込み権限の根拠にできない。Functions ＋ 本物の認証 ＋ チャットUI を作ることになり、Slack の再発明になる。
Slack から正本を直接書き換えさせない。 Bot は提案を出し、承認したものだけコミットする。 D2（矛盾は人間に返す）と同じ思想。ここを自動化すると正本が静かに壊れる。
現状7セクション24本。分類軸が混ざっていて MECE でない。
| セクション | 実際の軸 |
|---|---|
| Start Here | 状態（読む順） |
| Pitch Decks | 形式 |
| Fundraising 2026-04 | 時期 |
| Internal Strategy | 読み手 |
| Organization & Operations | 主題 |
| Brand & Design | 主題 |
| Products | 主題 |
さらに data-tags（investor / hiring / internal）が別の分類として重なっている。 新しい文書をどこに置くか毎回迷う状態は、分類が機能していない証拠。思考OS も 置き場所がなく Internal Strategy に間借りしている。
方向：セクションは主題1軸に統一し、読み手はタグに寄せる。時期は日付列で表現できるので セクション名から外す。ここを直さないと、思考OS がテーマを量産し始めた時点で破綻する。
分ける基準は「何のために集めるか」。Odyssey は理解のため、本構想は問いを進めるため。Odyssey へは副産物として流す。 2026-09-03
HTML側を編集してMDに戻さない。思考作業台はビルダーで生成する（素の変換ではないのでNG理由に抵触しない）。 2026-09-03
設計を進める作業と、器の型を確定する作業が同時に片付く。 2026-09-03
精度はユニット内部の性質。差し替え可能に作り、精度向上は独立して進める。 2026-09-03
私用タブは認証で隠すのではなく、公開ビルドで出力しない。 2026-09-03