付録 B — 動作確認の再現手順
本レポートの チャプター 7 は、このリポジトリのルートにある環境で再現できる。
B.1 必要なもの
docker のみ。 Python も dbt もコンテナ内にある。
B.2 手順
git clone https://github.com/dobachi/ossie-playground.git
cd ossie-playground
make spec # 仕様リポジトリを固定コミットで取得（ここだけネットワークを使う）
make verify # トラックA・Bを実行個別に実行する場合:
make verify-a # トラックA (0.1.1) のみ
make verify-b # トラックB (0.2.0.dev0) のみ。先に verify-a が必要
make shell # コンテナ内でシェルを開く検証結果は docs/results/*.json に出力される。
B.3 再現性の担保
固定の粒度は要素ごとに異なる。強い順に挙げる。
- 仕様リポジトリはコミットを固定している（
MakefileのOSSIE_COMMIT=07be0176）。 上流が変われば結果も変わりうるため、固定を外す場合は結果も取り直すこと - 消費側の主要パッケージは厳密固定。
docker/requirements.txtでdbt-core==1.12.0/dbt-duckdb==1.10.1を==で指定している。 本レポートの結論に直結する版はここで固定される - 検証コンテナは外部ネットワークから切り離してある（
network_mode: none）。 実行中に何かを取りに行かせないことで、結果を左右する要素を 固定コミットとビルド済みイメージだけに限定する。 外部を使うのはmake specの一度だけ
B.3.1 固定していない部分（既知の限界）
再現性は完全ではない。以下は固定していないため、再ビルドの時期によって動きうる。
- ベースイメージをダイジェスト固定していない。
docker/DockerfileはFROM python:3.12-slimとタグ指定のみで、@sha256:...を付けていない - 一部の依存はバージョン下限指定（
>=）。jsonschema/sqlglot/PyYAML/hatchling/jinja2、およびdbt-core経由で入るmetricflowなどは、 ロックファイルで固定していないため、解決される版がビルド時期に依存する
厳密な追試が必要な場合は、上記をダイジェスト固定・ロックファイル化したうえで 再取得することを勧める。本レポートの中核的な観測（バージョン文字列による排除、 ルート dialects の不整合、集約関数の脱落）は、 == 固定した dbt-core 1.12.0 と固定コミットの仕様に依存しており、 下位依存の版差では変わりにくい部分である。
B.4 構成
docker/ コンテナ定義と依存
compose.yaml network_mode: none で実行
Makefile 入口
scripts/
lib_ossie.py 共通処理（バリデータの展開など）
verify_track_a.py トラックA
verify_track_b.py トラックB
track-a/
dbt-project/ 検証用の最小 dbt プロジェクト（DuckDB）
osi/ 手書きの 0.1.1 準拠文書
track-b/
generated/ 公式コンバータの生成物（実行時に作られる）
spec/ 仕様リポジトリ（make spec で取得。git 管理外）
report/ 本レポート（Quarto）B.5 実装上の注意
バリデータの挙動がバージョンで違う。 osi-0.1.1-rc1 タグの validate.py には --schema オプションがなく、 __file__.parent.parent / "core-spec" を決め打ちで読む。 scripts/lib_ossie.py はその構造を再現している。
コンバータは PyPI にない。 spec/python（apache-ossie）と spec/converters/dbt（ossie_dbt）は 公開されていないため、リポジトリからソース導入している。 オフラインで導入できるよう、ビルドバックエンド（hatchling）を イメージに含めてある。
B.6 本レポートのビルド
cd report
quarto preview # ローカルで閲覧
quarto render # _site/ へ出力図版は report/diagrams/*.mmd（Mermaid ソース）から mmdc で PNG 化している。