METHODOLOGY / HOW WE BUILD TRUST

主張は、確認できる経験から。

すべての判断は、運用するサイトのコード・公開画面・Git履歴のいずれかで確認できることに依拠します。憶測と事実を分けます。

一次経験の扱い

BUILD ORBIT の中心データは、実際に運用しているサイト群（Project Atlas）から取ります。構成、インタラクション、配信、修正の各事実は、コード・公開URL・Git履歴で確認可能です。Project dataの記録、画面で見える事実、こちらの解釈を別の層として扱い、実際に起きたことと、今なら変える点を分けて書きます。

AIの利用と検証

Astro、React Islands、Playwright、axe、Lighthouse 等の実装・検証にAI支援（Codex等）を使うことがあります。AIの出力は最終手段ではなく下書きと見なし、build・lint・型検査・テスト・キーボード・320px・canonical・OG・sitemap の確認を経てから採用します。確認できた範囲、未確認の外部状態、公開を止める条件を分け、誰が・何を・どのように検証したかを記録します。

事実・経験則・提案の区別

確認できた事実、複数事例からの経験則、今後の方針としての提案を明確に分けます。「大多数が〜」のような過度な一般化は、サンプル規模（30件）を併記して避けます。

出典（Sources）方針

一次情報（公式ドキュメント、仕様、リポジトリ、公開画面）を優先します。二次記事のみの場合は確度を下げて扱い、引用は最小限にとどめます。各Note・ケーススタディに accessedAt を記録します。外部資料が支える一般論と、BUILD ORBITのProject・Git・生成物から確認した一次経験を同じ文で混ぜず、どの主張をどの証拠が支えるかを近くに置きます。

更新・訂正方針

publishedAt は実際の公開日、updatedAt は内容を実質更新した日とします。表面的な修正で日付を最新にすることをしません。事実の誤りを見つけた場合は、ケーススタディの reviewedAt / reviewedCommit を更新し、訂正履歴を残します。

権威の装いをしない

架空の経歴・受賞・顧客・レビュー・導入事例・数値は使いません。制作・検証のプロセスを透明に示すことが、信頼の根拠です。

判断を試す・使う

構成を試すなら Build Simulator、事例を読むなら Case Studies、集計とテンプレートは Resources から。