アーティファクトレジストリ

アーティファクトコホートの正規レジストリ。 本ドキュメントは、コマンド、ルール、委任ワーカー、フック、スキル、出力スタイル、アーティファクト進化の規律、および空のアーティファクトクラスの宣言の完全な一覧を載せています。実質的なテーブルはここに置かれます。プロジェクトのソースレイアウトが、凝縮された常時ロードのビューを提供します。

1. コマンド

src/apothem/commands/*.md（非再帰）から 30 個のコマンドが登録されます。各コマンドは第一級の登録済みファイルです。/plan オーケストレーターは、すでに第一級であるプランステージを連鎖させるだけで、それ自体のステージロジックを持たないため、依然としてモノリシックなディスパッチャーもサブコマンドのグルーピングも存在しません。非プラン・非ワークフローのコマンド：

プランパイプラインのコマンド

プランパイプラインは 8 つの第一級コマンドとして出荷されます——ステージごとに 1 つで、それぞれ src/apothem/commands/plan-<stage>.md の独自の登録済みファイルから /plan-<stage> として直接呼び出せます。

オペレーターワークフロー＆オーケストレーターのコマンド

3 つのコマンドは、それ自体のステージロジックを持つのではなく深いプロシージャに入ります：2 つのオペレーターワークフローのエントリポイント（それぞれ同名の兄弟スキルに支えられる）に加えて、薄いプランパイプラインオーケストレーター。

2. ルール

振る舞いのルールは src/apothem/rules/ 配下に存在します——小さな常時ロードのコアに加えて、より大きなパスフィルタ済みのセット（一致するアーティファクトに触れたときにオンデマンドでロードされる）。ルールごとの完全な一覧——Scope（常時ロード／パスフィルタ済み）と Implements の各列つき——は、リファレンスインベントリジェネレーターによって src/apothem/rules/*.md から更新されるソース生成の reference/rules.mdx です。権威ある現行リストはそれを参照してください。

CM-21 のファセット区分（3 つのルールが、異なる重複しないファセットで CM-21 を共同実装します）：創造的フィルタ＆認知的アイデンティティ → cognitive-identity.md；生成方法論（執筆＆再執筆プロトコル） → clean-room-generation.md；計画／レビュー技法 → planning-techniques.md。各ルールは自身のファセットを所有し、他は外部を参照します。

Interactive-questions スキーマのポインタ。 構造化インクワイアリの規約上の呼び出しスキーマ——必須フィールド、フィールド要約テーブル、2 つの実行可能な作業例（§2.1 のシングルセレクトと §2.2 のマルチセレクト）——は src/apothem/rules/interactive-questions.md §2「Structured-Inquiry Shape」に存在します。下流のアーティファクトは §2.1 または §2.2 を呼び出しテンプレートとしてコピーできます。各オプションの description 本体が担う 3 セグメントのオプションアノテーションスキーマは、同ファイルの §3 で規定されています。

3. 委任ワーカー

12 個の永続的なワーカー定義がエコシステムに同梱されています。オーケストレーションルールのチームパターンがそれらにディスパッチします。各定義は下記のファイルパスに存在します。

Worker              File                                       Pattern         Model Policy
------------------- ------------------------------------------ --------------- -------------
Codebase Explorer   src/apothem/agents/codebase-explorer.md   Research        host-selected
Convention Auditor  src/apothem/agents/convention-auditor.md  Audit           host-selected
Dependency Auditor  src/apothem/agents/dependency-auditor.md  Audit           host-selected
Fact Checker        src/apothem/agents/fact-checker.md        Audit           host-selected
MCP Builder         src/apothem/agents/mcp-builder.md         Generation      host-selected
Memory Auditor      src/apothem/agents/memory-auditor.md      Audit           host-selected
Prompt Evaluator    src/apothem/agents/prompt-evaluator.md    Quality         host-selected
Quality Gate        src/apothem/agents/quality-gate.md        Quality         host-selected
Refactor Surgeon    src/apothem/agents/refactor-surgeon.md    Implementation  host-selected
Research Scout      src/apothem/agents/research-scout.md      Research        host-selected
Security Scanner    src/apothem/agents/security-scanner.md    Audit           host-selected
Test Runner         src/apothem/agents/test-runner.md         Quality         host-selected

4. フック

登録されたすべてのフックコマンドは、Claude Code の exec 形式のコマンド形態 （command: "python" に args 配列を加えたもの）を使用し、 -m apothem.hooks.dispatch または -m apothem.conformity.gate のいずれかを呼び出します。ディスパッチャーは エコシステムルートの解決のために src/apothem/hooks/lib/resolve_root.py をインポートし、 それと並んで src/apothem/hooks/ 自体の配下にある 2 つのヘルパーに委任します： src/apothem/hooks/emit_hook_context.py はアシスタント向けにイベントペイロードを整形し、 src/apothem/hooks/session_start_bootstrap.py は、ディスパッチャーがそのイベントをルーティングする際に 引き渡す SessionStart の準備作業を担います。サポートされるイベントが発火したときにアシスタントに 表示されるフックメッセージは、src/apothem/hooks/messages/ 配下に Markdown コンテキストファイルとして 存在します——イベントバリアントごとに 1 つ：postcompact.md、precompact.md、 pretooluse-bash.md、pretooluse-bash-plan-guard.md、pretooluse-conformity.md、 pretooluse-dependency-guard.md、pretooluse-edit.md、pretooluse-edit-header-guard.md、 pretooluse-eval-guard.md、pretooluse-notebookedit.md、pretooluse-write.md、 pretooluse-write-header-guard.md、pretooluse-write-plan-guard.md、sessionstart.md、 stop.md。各ルーティング済みコンテキストファイルは、そのイベントが発火し、かつそのコンテキスト引数が settings.json に登録されているときにディスパッチャーによってロードされます。3 つのコンテキストファイル （pretooluse-conformity.md、pretooluse-dependency-guard.md、pretooluse-eval-guard.md）は、 現在の settings.json ルーティングエントリを持たない利用可能なバリアントとして出荷されています。

Event             Automates                Timeout  Purpose
----------------- ------------------------ -------- --------------------------------------------------
SessionStart      CM-14                    30s      Read memory, check plan state, report readiness
PreCompact        CM-24 §2.3               30s      Verify state externalized before compaction
PostCompact       CM-24 §6.2               30s      Restore working state after compaction
Stop              CM-14/CM-22/CM-24/CM-26  60s      Session-end externalization
PreToolUse        CM-7/CM-22               10s      Write/Edit/NotebookEdit validation — codebase-isolation, frontmatter, license-header, and plans-locality checks plus the conformity gate. Bash validation — git artifact isolation and plans-locality
PostToolUse       —                        10s      Accepted by src/apothem/hooks/dispatch.py whitelist for forward compatibility; no settings.json entry currently routes this event
UserPromptSubmit  —                        10s      Accepted by src/apothem/hooks/dispatch.py whitelist for forward compatibility; no settings.json entry currently routes this event
Notification      —                        10s      Accepted by src/apothem/hooks/dispatch.py whitelist for forward compatibility; no settings.json entry currently routes this event

規約。 Automates が — の行は dispatch.py によって受理されますが、settings.json には配線されていません。Timeout 列は、そのイベントが後で配線された場合に適用されるディスパッチレベルの既定値を示します。

Timeout 値の規約上のブロック。 このテーブルの Timeout 列は、エコシステム全体にわたるフックの Timeout 値の唯一の信頼できる情報源です。settings.json のフックごとの timeout フィールド、site/content/docs/reference/settings-reference.mdx § Hook Events と site/content/docs/reference/artifact-schema.mdx § Hooks Pipeline のミラーテーブル、および src/apothem/rules/persistent-conventions-vigilance.md § Convention Awareness のルールガイダンスは、すべてこの列から導出されます。今後の Timeout の改訂はここに着地し、消費者は次回の参照時に再導出します。

設定テンプレートのレビュー周期

settings.json は唯一の Claude Code テンプレートです。各フックコマンドは シェル固有のラッパーではなく exec 形式を使用するため、クロス OS の振る舞いは ペアになったテンプレートを diff するのではなく、1 つのファイル内でレビューされます。新しいパーミッションエントリ、 フックイベント、Timeout、ステータスメッセージは、そのファイルにアトミックに着地します。

5. スキル

再利用可能なスキルは src/apothem/skills/ 配下に、スキルごとに 1 フォルダで存在します。

規約。 各行の パス はフォルダです。エントリポイントはその中の SKILL.md ファイル——例：src/apothem/skills/plan-suite/SKILL.md——で、プロジェクトのソースレイアウトで宣言されたフォルダ-with-SKILL.md スキル規約に従います。

6. 出力スタイル

4 つの出力スタイルが src/apothem/output-styles/ 配下に存在します。

7. アーティファクト進化

必須。 再利用可能なパターン、修正、または技法が再発したとき（セッション内で 2 回以上、または記憶に再発として記録されたとき）、エコシステムは進化しなければなりません。サイクルには 4 つのステップがあります：あらゆるインタラクション中にパターンを Detect；既存のスキル、ルール、コマンド、フック、記憶を重複について Search；一致するアーティファクトをその場で進化させる（手順、アンチパターン、スコープを更新）か、関心が真に直交している場合は新しいものを作成することで Act；相互参照が依然として解決し、依存するアーティファクトが一貫したままであることを Validate。作成より洗練を優先する——新しいアーティファクトは保守面を複利的に増やす。あらゆるアーティファクトクラスにわたるギャップ検出トリガーの閉じたカタログを含む完全なプロトコルは、src/apothem/rules/persistent-conventions-vigilance.md §2+§4 を参照してください。

8. 空のアーティファクトクラス

エコシステムレジストリで宣言されているが、アクティベーショントリガーが発火するまで意図的に空であるサーフェス。各行は、予約されたサーフェス、そのクラスを足場立てするファイルまたはディレクトリ、そしてその行を空-アテステーションから埋め済みへと昇格させるトリガーを記録します。

空-アテステーションはギャップではなく、肯定的な宣言です。クラスの足場（存在する場合）は、アクティベーションの瞬間を追跡する規約上の no-op アーティファクトです。空-アテステーションから埋め済みへの昇格は、足場の最初の非空の値とともに、該当するレジストリセクションにアトミックに着地します。