基本文書 は何をしますか？
基本文書は、プロジェクト、または製品ファミリーを、形式的かつコンパクトに提示します。どのようなニーズに対応するのか、なぜ開発に値するのか、何であるのか、どのような状況で価値を発揮するのか、何がそれを裏付け、何を実証する必要があるのか。プロジェクトの参照説明書です。
ビジョン文書（スキル documento_vision）とは、以下の3点で異なります。
- 物語的な駆動はありません。 ケース、シーン、プロローグはありません。ドシエのような秩序立った説明です。
- より形式的です。 ドメインに関するすべての主張には参照が付き、公開された事実、設計目標、計算上の仮定は常に分離されます。
- 作成者と共有のため。 作成者（および将来のセッションでのClaude）にとって、コンパクトで気が散らない説明として役立ち、協力者、パートナー、または資金提供者にそのまま提供できます。
この2つは共存します。ビジョンはプロジェクトを物語で伝え、基本文書はそれを説明します。一方が変更された場合、もう一方も見直されます。
このスキルは、基本文書に含まれる内容とその書き方を示します。ジェネレーター、リソースとその構文、テーマ、ツール、およびチェックは、crear_documentos で共通のものを使用します。crear_documentos はこれと併せて参照してください。
配置場所
プロジェクトの基本文書は、docs/specs/vision/（SFの方法論「共通文書構造」による）にまとめて配置されます。ビジョン、基本文書、および技術インフォグラフィックは infografias/ に配置されます。
- プロジェクト用：
docs/specs/vision/fundacional-<プロジェクト>.mdとその.html。 - 製品ファミリーの各製品用（ある場合）：
fundacional-<製品>.md。
.md がソースです。.html は生成され、手動では編集しません。既存のPDFまたはHTMLから始める場合は、.md に変換し、元のファイルはその隣または _respaldo/ に保持します。
モデル。 プロジェクトにこれらのルールを適切に適用する基本文書がすでにある場合、別の文書を作成またはレビューする際の例として読みます。そのドメインに固有の内容はコピーしません。
セクション
すべての基本文書が持つ核となるセクションと、プロジェクトが必要とする場合に含めるオプションのセクションがあります。出現順に番号が付けられます。付録は最後に「付録A・…」というラベルで配置されます。
順序：最初に説明し、その後で正当化する。 読者は、議論を評価する前に製品が何であるかを知る必要があります。冒頭（目的があればそれ、および開発する理由の散文：アイデア、違い、テーゼ）の後、説明するセクションが続きます。システムまたはファミリー、製品とその機能、シナリオと代替案。その後、正当化するセクションが続きます。文書化されたニーズと問題のコスト、影響、規模、リスク、および「実証すべきこと」。文書化されたニーズのカードは、冒頭ですでにテーゼが要約されている場合は、製品の後、独自のセクションに配置することもできます。
質素な表紙。 ブランド、名前、モットーを標準フォント（1行または2行）で表示します。それ以外はありません。ヘッダーを低く抑えるためです。アイデアと目的は最初のセクションの導入部として開き、バージョンとステータスはフッターに配置し、数字の行（カードや証拠を数えることは在庫であり、議論ではありません。数字が議論の一部である場合は本文に含めます）はありません。
グローバルスコープの注記（文書のどの部分が設計目標であり、何が検証されているか、またはテキスト全体に適用される基準）は、すべてのセクションの外側、先頭に配置されます。# 名前 と最初の ## の間に引用 > として記述します。ジェネレーターはこれらをセクションの前にボックスとして配置します。
核
-
開発する理由。 カードの前、サブタイトルなしで、最初の散文から始めます。
- アイデアと目的を導入部として。
- 既存の代替案に対する違いを、1段落で、参照と代替案ごとに1フレーズで説明します。
- 開発テーゼ：今、何に資金を提供し、構築する価値があり、どのような条件で価値を持つのか。散文で記述し、ボックスにはしません。そして、「正当化」します。文書内のどの事実（数字と参照付き）に基づいているか、そしてまだわかっていないこと、つまりパイロットが測定すべきことは何かを示します。
その後、文書化されたニーズ（測定された問題、介入能力、結果）を示す2〜3枚のカードを、それぞれに参照を付けて配置します。この形式（議論する散文、次に正当化されたカード）は、すべてのセクションのモデルです（「編集ルール」参照）。
-
製品。 数値で簡潔に何であるか（容量、自律性、範囲…）、サブシステムごとの機能、アーキテクチャ、主要機能、進化の仕方（ファミリー、プラットフォーム、検証/再構成/再設計）、および何を行わないか。
-
使用シナリオ。 製品が価値を発揮できる状況。それぞれにコード（S1、S2…）を付け、文書の他の部分で引用できるようにします。各シナリオについて：いつ価値を発揮するか、議論の限界、何を測定するか、および文書ベース。シナリオは互いに互換性があります。独立した母集団として合計することはできません。
-
証拠。 最初に、検索方法と範囲。次に、証拠ごとにカード：タイプ（測定、パイロット、ガイド、研究…）、何を言っているか（数値付き）、影響を受けるシナリオ、およびプロジェクトへの示唆：何を裏付けるかと、裏付けないか。
-
実証すべきこと。 文書からパイロットへの移行。優先順位付けされたフェーズ。各フェーズに、サーキット、理由、および進行条件。必要な検証（技術、運用、経済）。進行の決定（ゲート）。提案された決定とその測定方法。
-
出典と参考文献。 すべての出典。タイプごとのコード（例：E：証拠、F：技術データシート、P：価格、D：経済、C：臨床、M：プロジェクト自身の文書）、出典、リンク、およびレビュー日。
オプション
- 目的と価値観（ミッション、ビジョン、価値観）。冒頭に、独自のセクションとして、または最初のセクション内のカードとして。チームや協力者を調整するプロジェクト向け。
- 問題のコスト。経済的な側面がある場合。文書化されたケース（数値と「影響と範囲」付き）。回避できることと経済モデル（計算式）。開発する理由の後。
- 市場または地域の規模測定。出典が何を主張できるか、何をできないか。必要なデータ（分母、露出、経済）。透明性のあるシナリオ（専用の計算機を伴う場合あり）。防御可能な見積もりに変換する方法。「実証すべきこと」の前。
- 既存の参照との比較の付録。次元ごとのカード。2列（「参照・公開済み」と「プロジェクト・設計」）。各アプローチの貢献。最後に、比較が保持すべき価値と、付加価値を確認する方法。
- 要素ごとのデータシートの付録（医薬品、材料、コンポーネント、顧客タイプ…）。要素ごとのデータシート（データとシナリオ付き）。ジェネレーターは、検索機能とシナリオフィルターを追加します。
- 影響。製品が機能した場合に何が変わるか。常にパイロットが実証することに条件付き。次元ごとのカード（経済、人々、地域または環境への影響）。「何が変わる可能性があるか」と、指標（測定可能、前後比較）。最初の散文は、既存のベースラインと測定が必要なものを示します。このコントラストなしに、プロジェクトに節約額を帰属させることはできません。SDGs（持続可能な開発目標）を引用する場合は、正式名称と出典を明記します。問題のコストまたはニーズの後。
- リスク。何が失敗する可能性があり、どのように軽減するか。リスクごとのカード。クラスをラベルとして（技術、運用、経済、規制）。「軽減策」と「チェック場所」（「実証すべきこと」のフェーズまたはゲートを参照）。最初の散文は、主要なリスクと、計画がそれを早期にどのように検出するかを示します。まだ分析されていないもの（例：規制上の適合性）は、オープンリスクとして宣言し、可能な場合は出典を添えます。「実証すべきこと」の直前。
- 協力への招待。求めるプロフィール、提供するもの、期待するもの。共有される文書向け。
レイヤー読み。 最初に最も重要なことを伝え、後続の各レイヤーで詳細を深めます。最初のセクションだけを読んだ人は本質を得られ、さらに知りたい人は読み進めます。順序は重要度順であり、結論に至ったプロセス順ではありません。これは文書全体と各セクションに適用され、各セクションは結論で始まり（「編集ルール」参照）、詳細はカード、折りたたまれた #### セクション、および付録に委ねられます。
プロジェクトにここにないセクションが必要な場合は、作成前に作成者に提案します。他のプロジェクトにも役立つ場合は、このスキル（SF所属）の改善となります。プロジェクトには記録せず、1行で伝えます。SF自体では、それはプロジェクトのものです。
編集ルール
- 最新の決定のみ。 文書は現在の状態を説明し、履歴は含めません。
- 3つのタイプの主張は常に分離する： 公開された事実（参照付き）、プロジェクトの設計目標（実現したいこと）、および計算上の仮定（例示としてマーク）。冒頭のスコープボックスでこれを説明し、「公開済み」と「設計」のラベルで比較箇所に注意を促します。
- ドメインに関するすべての数字や主張は、書く前に必ず出典と照合し、記憶に頼らず、同じ文の中で参照を付けます。ウェブ検索が必要な場合は、作成者に許可を求めます（まだ許可を得ていない場合）。
- 各証拠は、実証しないことも示す。 「プロジェクトへの示唆」、「議論の限界」、「影響と範囲」：文書は、自身の限界をマークすることで信頼性を高めます。
- コンパクトに。 2〜3文の段落、約20語以下の文。略語は最初の使用時に説明します。核は一気に読め、詳細な内容は付録に委ねます。
- 無駄を省く。 文書自体に関する記述（「この文書を更新する必要がある…」「この文書には含まれていない…」）や自明なことは避けます。各文はプロジェクトに関する何かを提供します。
- 各セクションは議論する散文で始める、最初のセクションと同様に。カードの前に、約2〜3段落、サブタイトルなしで。セクションの結論、それを支える事実（数字と参照付き）、およびまだわかっていないこと。紹介文（「6つの経験により…」）だけでは不十分です。テーゼまたは全体的な読み取りは、その散文に含め、ボックスにはしません。カードは後続し、議論を繰り返さずに参照される詳細を提供します。
- 完全な文、カタログではありません。 各小見出し（
###）内では、動詞を含む文で記述し、何がどのように機能するか、なぜかを説明します。動詞のない列挙（「識別、在庫、トレーサビリティ…」）は避けます。小見出しは、回答する質問でタイトルを付けます（「どのように冷気を維持するか」）、パターン「トピック：サブトピック」は避け、####で段落を分割しません。####は折りたたむ詳細のために残します。 - 可視的な構造、読みやすさを損なわない： いつカード、散文、小見出し、ボックス、テーブル、リスト、太字、繰り返しフィールド、およびタイポグラフィを使用するかは
crear_documentos（「各リソースの使用時期」）を参照。基本文書では、典型的なカードは、経験、シナリオ、証拠、フェーズ、ゲート、比較の次元、データシート、および製品の主要な数値です。バランスシートでは、うまくいったことは散文で説明し、欠点は（問題とそのステータスを含む）テーブルにまとめます。 - 読者がまだ知らないコードを使用しない。 内部コード（S1、S2…）は、それを定義するセクションの後、および相互参照に役立つ場合にのみ使用します。それ以前、および議論する散文では、言葉で説明します（「自宅への配送と家庭での保存」）。
- すべての重要な主張は、同じ場所で正当化する。 テーゼや重要な結論は、その根拠（文書内の事実、数字と参照付き）と、まだ実証されていないことを示します。
- 提案であり、強制ではない。 「提案する」、「検討する」、「担当者が決定する」。
- ドメインの感受性を尊重する。 プロジェクトのドメインに関するルールは、そのアイデンティティの
reglasにあります（documento_visionも読み取るものです）。
作業方法
- 提案の前に読む： プロジェクトのビジョン、そのアイデンティティとルール、仕様（存在する場合）、コードまたは双子（数値を提供する場合）、および作成者が持ってくる資料。 プロジェクトのすべての議論を棚卸しする。 製品の基本文書は、プロジェクトが持つすべての議論を収集します。特に他の製品と比較する場合、他の基本文書、ビジョン、仕様、およびすでに構築されたもの（デジタルツイン、プロトタイプ、テスト）からの議論も含みます。作成またはレビューの前に、欠けているもの（出典とタイプ：公開された事実、設計目標、仮定、またはシミュレーションでのみ検証された進捗）と、文書間の矛盾の棚卸しを行います。矛盾は、影響を受ける数値を渡す前に作成者に確認します。構築されたものは、宣言された限界とともに説明します。
- 目次とツールを提案する： 文書がプロジェクトのための成果物かユーザーのためのものか、どのツールを含めるか（検索、メモ、「読書」、折りたたみ、凡例、編集…）を、その目的に最適な推奨とともに、単一の質問（選択肢付き）で尋ねます。回答をヘッダーに記録します。目次を提案します。核、該当するオプションセクションとその理由、候補シナリオ（コード付き）、および表紙の数値。作成者が書く前に調整できるようにします。
- 不足している証拠を調査する（検索許可を得て）、正確な出典を添えて。
.mdを書く（以下のリソースを使用）、.htmlを生成する。バージョンを置き換える前に、_respaldo/にバックアップします（crear_documentos、「バックアップ」）。- 検証する（「チェック」参照）、要約とともに納品します。内容、例示的なもの、不足している証拠、および専門家による検証が推奨されるもの。
- 作成者と調整する。 一般的な修正は、
crear_documentosのルールの改善として追加されます（`crear_documentos
... [翻訳のために切り捨てられました]