Thinking Patterns — 思考パターン
「事実（複数回観測）」と「推測（1回のみ／根拠が弱い）」を分けて記録する。
確認済み（複数案件・複数回で観測）
TP-001 目的から入る
指示・設計の起点に必ず「何のためか」を置く。
「なんでこんなこと言ってるかっていうと、目的としては台本を作ってるんだけど…紐付けたい」(2026-08-14)
効果: AIが未知ケースで自走できる。弱点: 目的は言うが、完了条件は言わない（→ FP-001）。
TP-002 実測 → 削る
推測で機能を作らず、まずデータを測り、その数字で機能を減らす方向に動く。
観測: 2026-08-14 reel_catalog（20GB実測 → ショット分割を削除）
TP-003 撤退が速い
「うまくいかない」と分かったとき、改善に粘らず方式ごと乗り換える。
観測: 2026-08-14（38%を見て精度改善を諦め、連番伝播へ）
これは希少な資質。 多くの人は投下時間を惜しんで粘る。
TP-004 UX側から品質を検出する
コードを読めない代わりに、初見ユーザーの目線で欠陥を見つける。
「初めてやる人からすると、この情報はここにいらない」(2026-08-14)
技術力の不足を補う最大の武器。 north-star.md の「要件定義/UX/ROI（継続）」に直結。
TP-005 言語化を思考の道具に使う
作ったものを他人向けに説明させることで、自分の設計原則を抽出している。
観測: 2026-08-14 の非エンジニア向け artifact →（同日）この Decision OS の着想へ
推測寄り（観測2回）。要追跡。
要注意パターン
TP-101 好きな順に時間を使う
事業価値の順ではなく「0→1で作るのが楽しい」順に時間が配分される傾向。
観測: 2026-08-14（売上直結の案件に最短時間、未検証プロダクトに最長時間）
1回の観測。次回以降、時間配分と事業価値の順位が一致するかを毎日チェックする。
TP-102 スコープが逐次膨張する
動くものを見ると、その場で機能を足したくなる。
観測: 2026-08-14 mise-list（7分で4機能を追加要望）
TP-103 並列数の上限を決めない
待ち時間ゼロを優先するあまり、自分が把握できる本数を超える。
観測: 2026-08-14（15セッション並列、セッション取り違え1回発生）