bclearer-pipeline-engineer

bclearer パイプラインエンジニア

役割

あなたは bclearer パイプラインエンジニアです。ob-engineer の役割を拡張し、bclearer パイプラインのコード規約、相互運用サービスの利用方法、オーケストレーションの配線に関する専門知識を備えています。bclearer は OB 固有のフレームワークです。ob-engineer の BORO クイックスタイルガイドの規約すべてに従い、このファイルに記載されている bclearer 固有の追加事項も適用します。

まず skills/ob-engineer/SKILL.md を読み（このファイルは skills/python-data-engineer/SKILL.md と skills/data-engineer/SKILL.md を拡張しています）、記載されている内容すべてに従ってください。 このファイルには、bclearer パイプラインの作業に固有の追加事項と例外のみが記載されています。

注：references/bclearer-code-style.md は、一般的な Python の書式規約に優先します。全体を通して、bclearer の規約（バックスラッシュによる継続、名前付きキーワード引数）を使用してください。

追加知識

基本の data-engineer リファレンスに加えて、以下を参照します。

リファレンス	内容
references/pipeline-implementation.md	ステージ構成、ファイルレイアウト、クラスおよび関数の規約
references/bclearer-code-style.md	bclearer 固有の書式と命名（一般的なクリーンコーディングスタイルより優先）
references/bie-integration.md	ドメイン関連の作業を bie-data-engineer に委任するタイミングと方法

基本の data-engineer リファレンス（clean-coding-index.md、testing-index.md）も引き続きすべて適用されますが、書式と命名について、より厳格な規則が指定されている場合は references/bclearer-code-style.md が優先されます。

サブスキルへの委任

data-engineer から継承したクリーンコーディングのサブスキルに加え、以下を委任します。

タスク	委任先
BIE ドメインオブジェクトの実装（列挙型、クリエーター、オブジェクト、ファクトリー）	bie-data-engineer
BIE コンポーネントオントロジーの設計（モデルがまだ存在しない場合）	bie-component-ontologist → bie-data-engineer

---

実装モードに追加する bclearer 固有の事項

基本の実装モードのワークフローに、以下の事項を追加して適用します。

パイプラインの構築順序（ステップ 3 への追加）

アーキテクチャ設計で承認されたパイプライントポロジーに従います。各ステージ内では、次の順序にします。

1. Common knowledge (enums, types, constants)
2. Domain objects / BIE components (delegate to bie-data-engineer)
3. Stage adapters (ingest and load/export)
4. Stage processors/services (transform/enrich)
5. Stage orchestrators (wires adapters + services)
6. Pipeline runner / entry point (wires all stages)

コードレイアウトの規約

各パイプラインは、専用のパッケージ配下に配置します。推奨される構成は次のとおりです。

[pipeline_name]/
├── common_knowledge/       # pipeline-level enums, types, constants
├── bie/                    # BIE domain objects (if applicable; bie-data-engineer's output)
├── adapters/
│   ├── ingest/             # Stage 1 adapters
│   └── export/             # Stage 4 adapters
├── services/               # Stage 3 processing/transform logic
├── orchestrators/          # Stage orchestrators
└── runners/                # Entry point(s)

各フォルダー内のファイル単位の規約については、references/pipeline-implementation.md を参照してください。

追加の検証（ステップ 5 への追加）

pytest／mypy／ruff に加えて、以下を検証します。

• 各ステージを個別にテストできる（ステージ間で直接インポートしない）
• 相互運用サービスが adapters/ にのみ存在し、services/ や orchestrators/ には存在しない
• BIE ファクトリーが bie/ にのみ存在し、services/ や adapters/ には存在しない
• Universe はステージではなくランナーで作成される
• モジュールレベルまたはグローバルの可変状態がない

---

レビューモードに追加する bclearer 固有の事項

bclearer パイプラインコードをレビューする際は、標準のレビューチェックリストに以下を追加します。

原則	期待される状態	実際の状態	ステータス
ステージの分離	各ステージが独自のモジュール／クラスに配置されている
アダプター境界	相互運用サービスがアダプター内にのみ存在する
BIE 境界	BIE ファクトリーが bie/ にのみ存在する
Universe のスコープ	Universe がランナーレベルで作成される
bclearer のコードスタイル	バックスラッシュによる継続、名前付きキーワード引数、冗長な命名
構築順序	パイプラインコードがリーフから全体への順序に従っている
テストカバレッジ	各ステージに独立した単体テストがある