著作者ヘッダー — ファイルごとの SPDX ライセンス行

下流のコントリビューター向けの、正規かつ規範的なリファレンス。 本ドキュメントは、プロジェクト仕様の著作者とファイルヘッダーのセクション（仕様 §0.5 + §4.6）を反映したものであり、公開リポジトリに同梱される単独のリファレンスです。アーキテクチャ上の根拠は ADR-0002 に記録されています。

1. 正規のヘッダー行Copy Anchor Link

エコシステム内の適用対象となるすべてのファイルは、そのファイルタイプ族のコメント構文で書かれた、単一の正規の SPDX ライセンス識別子行から始まらなければなりません（MUST）。この行より前に置いてよいのは、shebang、および Markdown ファイルでは YAML フロントマターだけです（§5）。この行はファイルの機械可読なライセンスマーカーです。免除されないファイルでは、その存在に交渉の余地はなく、その内容はファイルごとに即興で決めるのではなく、単一の信頼できる情報源によって定められます。著作権に関する完全な法的文書は、リポジトリルートの LICENSE ファイルに 1 か所だけ存在し、各ソースファイルには複製されません。

1.1 情報内容（不変）Copy Anchor Link

正規の内容は、ちょうど 1 行です:

1. SPDX-License-Identifier: MIT — FSFE が維持する REUSE 仕様に基づく機械可読なライセンスマーカー。SPDX ツールチェーン（reuse lint、scancode）、Linux カーネルのツール、下流のライセンススキャナーが、曖昧さなく解析します。視覚的な枠線はなく、ファイルごとの著作権、ウェブサイト、メール、GitHub の行もありません — ファイルごとの来歴は、設計上、単一の SPDX 行だけです（§4 を参照）。

1.2 参照形式（# コメント族）Copy Anchor Link

正規のテキスト — ここでは # コメント構文の形式で記載 — の信頼できる情報源は、src/apothem/schemas/authorship-header.txt です:

# SPDX-License-Identifier: MIT

このテキストが唯一の権威ある情報源です。file-header バリデーター（§8）は、このバイト単位で正確なフィクスチャに対してファイルを検査します。ファイルのヘッダー行とこのフィクスチャとの間のずれ（§2 に従った構文置換を前提とする）は、指摘事項として報告されます。このバリデーターはブロッキングです。CI と pre-commit フックが実行する --strict 付きの実行では、指摘事項があると実行が失敗します（§8）。

2. ファイルタイプごとのバリアント（バイト単位で正確）Copy Anchor Link

行の情報内容は不変であり、ファイルタイプごとに変わるのはコメント構文だけです。ファイルタイプごとのバリアントの完全な表は次のとおりです:

Markdown バリアント（正規のレンダリング）:

<!-- SPDX-License-Identifier: MIT -->

HTML コメント（または MDX の {/* */}）のラッパーは目に見えない形でレンダリングされるため、レンダリング後の表面はすっきりしたまま保たれ、ソース内のライセンスマーカーは、どのファイルタイプでも機械可読のままです。

3. 例外リスト（クラス単位で免除）Copy Anchor Link

次のクラスは、SPDX ヘッダー行が免除されます。file-header バリデーターは、これらのファイルを検査せずに通します。以下のクラスは、header-exceptions.txt のグロブ一覧と一致します：

• 法的文書とバージョンのファイル — LICENSE、LICENSE.md、LICENSE.txt、NOTICE、VERSION。LICENSE は権威ある著作権行を含み、license-author-consistency バリデーターがその存在を確認します。
• 正規のフィクスチャ — schemas/authorship-header.txt。フィクスチャにヘッダーを注入すると、ヘッダーのためのヘッダーが生じてしまいます。
• *.svg アセット — XML コメントは行コメントのマーカーとしては壊れやすいため、SVG の来歴はアセットの README と、生成されたラスター出力によって担われます。
• JSON ファイル（.json） — JSON にはコメント構文がありません。JSON 設定に帰属表示が必要な場合は、兄弟ファイルとして <file>.NOTICE.md を置きます。
• ロックファイル — すべての *.lock ファイル、package-lock.json、yarn.lock、pnpm-lock.yaml、go.sum。これらのファイルは機械が管理します。
• 生成ファイルと圧縮ファイル — generated/ ディレクトリ配下のすべてのファイル、および圧縮されたバンドル（*.min.js、*.min.css）。
• ベンダリングされたサードパーティのコンテンツ — _vendor/、vendor/、third_party/、node_modules/ 配下のファイル。これらは上流自身のライセンスまたは通知を保持しています。上流の帰属表示の上から自前のマーカーを注入することは、ライセンス違反です。
• 監査、計画、ハーネスの状態 — .audit/ および .apothem/ 配下のすべて（プラン、メモリ、学習データ、コンテキストを保持）。作業ツリーのルートにある projects/ と memory/ も、ハーネスが所有しています。これらのツリーは git で無視されるか、オペレーターが所有しており、公開ツリーの対象外です。プランファイルは、フロントマターによって来歴を追跡されます（plans-discipline.md §3 を参照）。
• テストデータのフィクスチャ — tests/fixtures/ 配下の .yaml、.yml、.txt、.json ファイル。そのツリー内のテストのソースファイルには、引き続きヘッダーが付きます。
• インジェクターのスモークテスト入力 — tests/conformity-scenarios/fixtures/F-13-injector-smoke/ 配下のファイル。インジェクターのテストは、インジェクターがこれらのファイルにヘッダーを追加することを確認するため、これらはヘッダーなしのまま保たれます。
• パッケージングと空のマーカー — パッケージングのパーサーが厳密に読み取る .SRCINFO、およびゼロバイトのマーカーである .keep、.gitkeep、py.typed。
• バイナリファイル — フィクスチャに列挙された画像、フォント、アーカイブ、メディア、コンパイル済みオブジェクトの接尾辞。バリデーターのバリアント表に対応付けられていない接尾辞は、既定で免除されます。

例外リスト自体は、src/apothem/schemas/header-exceptions.txt に正規表現 / glob のリストとして記述されており、バリデーターの適用可否チェックへの入力となります。変更には、構造化照会と新しい ADR が必要です。

4. ライセンスとの関係Copy Anchor Link

SPDX 行はプロジェクトのライセンスを機械可読な形で宣言し、LICENSE ファイルはそれを権威ある形で宣言します:

• SPDX-License-Identifier: MIT — REUSE 仕様と SPDX 標準に基づく機械可読なライセンスマーカー。自動のライセンススキャナーはこの行を直接解析します。SPDX 式の構文は、reuse lint、scancode-toolkit、FOSSology、Linux カーネルのライセンスツールと相互に互換性があります。

• リポジトリルートの LICENSE — 完全な MIT の条項と著作権者を記載した、権威ある法的文書。著作権表示の唯一の置き場所です。ファイルごとのヘッダーは、すべてのファイルで著作権を繰り返し記載するのではなく、共有の SPDX 識別子を通じて暗黙のうちにこれを参照します。

単一行の形式。 ファイルごとの来歴は単一の SPDX 行であり、著作権に関する法的文書はルートの LICENSE に 1 か所だけ存在します。枠線付きの複数行バナーボックス（罫線の枠で囲んだ、著作権、ウェブサイト、メール、連絡先の行）は、バリデーターによって拒否されます。これらは、連絡先と著作権のメタデータをすべてのファイルに重複して持たせるだけで、機械可読なライセンスマーカーがすでに REUSE/SPDX/SBOM のツールに提供している以上のものを何も加えないからです。src/apothem/schemas/authorship-header.txt にあるバイト単位で正確なフィクスチャが単一行の形式を保持しており、バリデーターはこのフィクスチャに対して実行されます。

相互参照。 LICENSE ファイル（MIT）— 食い違いがある場合は、法的文書が優先されます。ADR-0006 は、バナーの範囲を縮小する決定を正式に承認した際の根拠を記録しています。

5. 挿入位置Copy Anchor Link

• SPDX 行はファイルの最初のコンテンツであり、例外は 2 つあります。shebang 行（#!/usr/bin/env bash、#!/usr/bin/env python3 など）は常に 1 行目に残り、その場合 SPDX 行は 2 行目から始まります。YAML フロントマターを持つ Markdown / MDX ファイルでは、フロントマターが先頭に来ます（次の箇条書き）。
• YAML フロントマターを持つ Markdown / MDX ファイルでは、ツールが解析できるようにフロントマターはバイト 0 に置かれたままとし、SPDX コメントは閉じる --- の後に続き、その後に本文が来ます。H1 を持つファイルでは、本文は H1 で始まります。scripts/inject-header.py は、コメントをこの位置に置きます。
• 1 行の空行が、SPDX 行と次のコンテンツ（H1、本文など）を区切ります。

6. ヘッダー可視性ポリシーCopy Anchor Link

Markdown と MDX のファイルでは、SPDX 行は常にそのコメントラッパー（<!-- ... --> または {/* */}）の内側に書かれます。ソース上でのみ見えるもので、レンダリングされたページには表示されません。インジェクターには可視のレンダリングもファイルごとのオーバーライドもありません。リポジトリ内のどのツールも、フィクスチャ src/apothem/schemas/header-visibility.yaml を読み込みません。

7. インジェクター — scripts/inject-header.{sh,py}Copy Anchor Link

次のことを行う、決定的な CLI です:

• 1 つ以上のファイルパス（または glob）を受け取ります。
• 例外リスト（§3）によって適用可否を判定します。
• 既存のヘッダーの状態（正規 / 不正な形式 / 不在）を検出し、見つかった正規でないバナーブロックを取り除いて、再実行しても結果が変わらないようにします。
• ファイルタイプごとに正しい SPDX バリアントをレンダリングします（§2）。
• shebang とフロントマターを尊重しつつ、正しい位置（§5）に挿入します。
• 挿入位置にあって空行を伴わない SPDX 行には、不足している空行を追加します。その上に 2 つ目のコピーを挿入することはしません。
• 3 つのモードで動作します：fix-in-place（書き込む）、emit-patch（unified diff を出力する）、check（ずれがあれば非ゼロで終了する。追跡対象のツリーに対してこれを実行する CI ジョブはない）。
• 冪等です：2 回実行しても変化は生じません。

インジェクターは make headers-fix ターゲットから呼び出され、このターゲットは scripts/inject-header.py --mode fix-in-place を実行します。

8. バリデーター — file-headerCopy Anchor Link

このバリデーターは src/apothem/conformity/file_header_grep.py にあります。作業ツリー内のすべてのファイルについて、バリデーターは（§3 に従って）適用可否を調べ、適用対象であれば、正規の SPDX 行が挿入位置に存在することを確認します。ほとんどのファミリーでは、挿入位置は、任意の shebang の後にあるファイルの先頭です。Markdown と MDX のファイルでは、YAML フロントマターのブロックを先に読み飛ばすため、§5 が求めるとおり、正規の行は閉じフェンスの後に置かれることがあります。MDX ファイルは {/* */} の形式（§2）に解決され、その形式に対して検査されます。バリデーターとインジェクターは、同じインデックスに正規のブロックを置きます。

src/apothem/schemas/authorship-header.txt にあるバイト単位で正確なフィクスチャに裏付けられています。コーパスの実行は、このマッチャーについて、指摘事項の件数とフラグされたファイルのサンプルを報告します。ファイルごとの差分もカバレッジの割合も出力しません。このマッチャーはブロッキングです。CI と pre-commit フックが使用する --strict 付きの実行では、指摘事項があると実行が失敗します。--strict を付けない場合、ゲートは指摘事項を報告し、0 で終了します。

9. 自己強制の仕組みCopy Anchor Link

この規律は、今後のあらゆるセッションと、今後のあらゆるコントリビューターを超えて存続しなければなりません。必須の強制面は次のとおりです:

1. src/apothem/schemas/authorship-header.txt — バイト単位で正確な正規のフィクスチャです。信頼できる情報源は 1 つだけです。
2. scripts/inject-header.{sh,py} — 機械的なインジェクター（§7）です。
3. file-header バリデーター（§8）— ずれを、ブロッキングの指摘事項として報告します。--strict 付きの実行を失敗させます。
4. pre-commit フック — conformity-corpus-perwrite フックが、--strict を付けて追跡対象のツリー全体に対して、Write ごとのマッチャーすべてを実行します。その中には file-header バリデーター（§8）も含まれます。file-header マッチャーはブロッキングなので、指摘事項があるとコミットはブロックされます。このフックはチェックのみを行います。修正モードはなく、インジェクター（§7）を実行することもありません。インジェクターは make headers-fix を通じて実行されます。
5. CLAUDE.md の必須動作ブロック — 適用対象のファイルを作成するときは常に、正規の SPDX 行を注入するようアシスタントに指示します。
6. GitHub Copilot の指示ファイル（.github/copilot-instructions.md）— ファイル生成時に同じことを行うよう Copilot に指示します。
7. PreToolUse フック（src/apothem/hooks/messages/pretooluse-{write,edit}-header-guard.md）— 適用対象のパスに対する Write/Edit ツールの呼び出しを横取りし、SPDX 行が後からバリデーターの指摘事項として見つかるのではなく、ファイルの作成時に注入されるようにします。ガードのチェッカーである src/apothem/hooks/lib/header_check.py は標準ライブラリのみを使用し、フィクスチャと除外リストを hooks/ の隣にある schemas/ ディレクトリから読み取るため、apothem パッケージをインポートできない Claude Code プラグインのもとでも動作します。チェッカーは、プロジェクト内のファイルに対して、インジェクターのバリアント表と挿入位置のルールを適用します。ただし、ヘッダーのフィクスチャ（src/apothem/schemas/authorship-header.txt）を持つ git プロジェクトでのみ適用します。SPDX 行はこのリポジトリの規約であり、プラグインが開くすべてのプロジェクトの既定ではないためです。
8. プルリクエストテンプレートのチェックボックス — すべての新しいファイルが正規の SPDX 行を持つことを、コントリビューターが表明するためのものです。
9. 本ドキュメント（site/content/docs/reference/authorship-header.mdx）— 正規かつ規範的な解説です。

関連項目Copy Anchor Link

• ADR-0002 — アーキテクチャ上の根拠と、検討した代替案。
• ADR-0006 — バナーの範囲縮小の承認。
• src/apothem/schemas/authorship-header.txt — バイト単位で正確な正規のフィクスチャ。
• src/apothem/schemas/header-exceptions.txt — 例外リスト（正規表現 / glob 形式）。
• scripts/inject-header.py と scripts/inject-header.sh — インジェクター。
• src/apothem/conformity/file_header_grep.py — バリデーター。
• プロジェクト仕様 §0.5 + §4.6 — ここに反映している正規のテキスト。