自己完結型ランタイム

Apothem のエンジンは自己完結型ランタイムです。レジストリを必要とせず、任意の チェックアウトや配置されたソースツリーから直接動きます。なぜなら、そのサードパーティ 依存関係がエンジンとともに移動するからです。これを成り立たせるのは 2 つの部品です—— 内蔵された依存関係ツリーと、インストール済みのコンソールスクリプトを必要としない python -m 呼び出しモデルです。

内蔵された依存関係ツリー

検証とシリアライズのスタックは、純粋な Python ソースとして src/apothem/_vendor/ 配下に内蔵されており、各パッケージはその上流のライセンス ファイルと並んでいます。

• yaml（純粋 Python のパーサー/エミッター。オプションの libyaml C 拡張は 携行されません）
• jsonschema。その依存チェーン attrs（およびその attr エイリアス）、 referencing、jsonschema_specifications を伴います
• rpds——jsonschema と referencing が使用する HashTrieMap、 HashTrieSet、List の面を再実装した純粋 Python のシムで、組み込み型を バックエンドとするため、このスタックはコンパイル拡張ゼロで動きます
• typing_extensions

内蔵されたコピーは、システムにインストールされたいかなるバージョンよりも優先されます。 ブートストラップは vendor ディレクトリを site-packages より前に sys.path の 先頭へ前置します。選択ポリシー——何が内蔵され、何が内蔵されず、内蔵パッケージが どのようにリフレッシュされるか——は 依存関係内蔵戦略に記載されています。

2 つの依存関係はツリーの外に留まります。click と rich、すなわち CLI がインポートする端末向けのライブラリです。これらはエンジンを動かす インタープリターの下でインポート可能でなければなりません。インストーラーは両方を チェックし、欠けているものがあれば名前を挙げ、あなたの確認のもとで——または --yes / APOTHEM_AUTO_INSTALL_DEPS=1 で自動的に——インストールを申し出ます。

python -m 呼び出しモデル

Apothem は pyproject.toml で意図的にコンソールスクリプトを一切宣言しません—— コンソールスクリプトはパッケージマネージャーがそれらを PATH 上に置いたときにのみ 存在するものであり、自己完結型ランタイムは決してそれを前提としません。エンジンには 代わりに 2 つの呼び出し面があります。

• python -m apothem は src/apothem/__main__.py を動かし、それが apothem.cli:main——Click のコマンドグループ——を呼び出します。
• 物化された settings.json / hooks.json のフックエントリは、ディスパッチャー （および Claude Code の場合は <harness-root>/apothem/conformity/gate.py の一致性ゲート）を絶対スクリプト パスで呼び出します。どちらも自前の sys.path をブートストラップする独立した 標準ライブラリスクリプトであり、ゲートのスキーマフィクスチャは <harness-root>/apothem/schemas/ でそれと並んで携行されるため、フックは ホスト上にインポート可能な apothem パッケージがない状態で動きます。 テンプレートは ${HARNESS_ROOT} トークンを携行し、apothem install が それをスラッシュ形式の本物のハーネスルートパスへとレンダリングします。
• ソースチェックアウトからは、モジュール形式 python -m apothem.hooks.dispatch と python -m apothem.conformity.gate が開発のために同じコードを動かします。

チェックアウトの src/ ディレクトリを PYTHONPATH に前置することで、 パッケージディレクトリはインポート可能になります。

PYTHONPATH="$HOME/.apothem/src" python -m apothem <command>

これはまさに、ワンショットインストーラーが完了時に表示する呼び出しです。

プラグインツリーのブートストラップ

Claude Code プラグインは、PYTHONPATH に依存するのではなく、エンジンを <plugin_root>/lib/apothem 配下にバンドルします。ブートストラップモジュール apothem.lib.plugin_bootstrap は bootstrap_syspath を公開し、これは冪等に <plugin_root>/lib と vendor ディレクトリを sys.path に前置することで、 import apothem とすべての内蔵依存関係がプラグインツリーから解決されるように します。畸形のツリー（lib/ の欠落）は、陳腐化したシステムコピーを静かに インポートする代わりに PluginBootstrapError を送出します。

インストーラーがディスクに置くもの

スクリプトインストーラーはソースツリーの git クローンを ~/.apothem （APOTHEM_HOME で上書き可能）に置き、そこからエンジンを動かします——オプションの click / rich 前提条件の申し出を超えて、site-packages に Python パッケージが インストールされることはありません。このクローンは完全なリポジトリであり、 ランタイムが決してインポートしないテストスイートとドキュメントサイトを含みます。 それには 2 つの意図的な理由があります。エンジンはその cohort——ルール、スキル、 コマンド、テンプレート——をツリーから直接、各ハーネスへと 物化 するため、 ツリーは単なるランタイムではなく生きた信頼できる情報源であること。そして .git ディレクトリがその場に残るため、apothem update は再ダウンロードする代わりに 既存のクローンをファストフォワードできること、です。

このソースから実行するレイアウトは、nvm、pyenv、oh-my-zsh といった ツールが用いるのと同じパターンです——数メガバイトのソースに履歴を加えたもので、 アンインストーラーで一手間で除去できます（巻き戻すべきシステム状態はありません）。 より軽量なフットプリント——tests/ と site/ を省く浅いまたはスパースな チェックアウト——も可能ですが、それはその場で行われる、署名検証された git ベースの更新パスを引き換えにしてしまいます。現在のレイアウトは、最小ディスクよりも 単純で検証可能な更新を優先します。

ランタイムが Python をどのように見つけるか

ワンショットインストーラーと npx シムは、同じやり方でインタープリターを 特定します。python3、python、バージョン付きの名前（python3.14 から python3.10 まで）、そして Windows 上の py -3 を探り、Microsoft Store ランチャーのシムを拒否し、バージョン 3.10 以降を報告する最初の候補を受け入れます。 ソースツリーから動かす場合、インストーラーはバンドルされた hooks/lib/find-python ロケーターを再利用し、それは同じ下限を適用します。

推奨される次のステップ

python -m apothem --help を実行 し、チェックアウトの src/ ディレクトリを PYTHONPATH に載せて、自己完結型 CLI のパスがあなたのホストで 解決することを確認してください。