Commerce モジュール（会員・アクセス制御）

会員・購入ドメインは core_src/Commerce/ に集約し、公開画面（View / PostType）は PaidArticleAccessServiceInterface のみを経由して閲覧可否を判定する。

有料記事の販売は 自サイト HTML ＋ codoc ペイウォール。サイト内 Stripe Checkout / Webhook は 削除済み。note 販売導線は採用しない。将来の国内決済代行（第一候補 KOMOJU）に備え、購入・サブスク用テーブルと AccessService は維持する（codoc 購入との自動同期は当面しない）。

境界

層	パス	役割
Commerce	core_src/Commerce/	Installer / Entity / Repository（購入・プラン）
公開 API	PaidArticleAccessServiceInterface	閲覧可否の窓口（編集者・将来の自前決済用に維持）
コンテンツ	core_src/PostType/PaidArticle/ 等	編集 UI・テンプレ・訪問者表示の安定 codoc-tag・保存時の同期用 post_content

Deptrac の Commerce / CommerceRepositoryInterface レイヤーで、PostType・View・ShortCode から Commerce への直接依存を CI で拒否する。

現状の販売導線

• 基本情報メタ: 販売価格。既定値 1000（新規初期化・編集画面オープン時・空欄保存）
• 訪問者経路では intro + 安定マーカー（data-id="codoc-tag"）のみを出し、有料セクション HTML はレスポンスに載せない
• 保存時に intro + Gutenberg 互換ブロック + 有料 HTML を post_content へ書き、codoc プラグインの sync_entry で販売記事を作成・更新。entry code 手入力はしない
• 価格 meta が空のときは販売未開始（ペイウォール境界なし）。旧 note CTA / NOTE_URL へは落とさない

日別記事末尾の投げゼニ（CodocSupportWidgetService）は本導線の対象外。

維持するデータ基盤

• db_paid_article_purchase / subscription 系テーブルと Repository（AccessService・将来の自前決済用。codoc とは自動同期しない）
• db_member_plan_master 等のプランマスタ
• 会員認証・メール確認・規約同意

国内代行導入時は config/di/commerce.php に決済ゲートウェイを再配線する。

将来: Composer 私有パッケージ化

複数サイトで同一決済基盤を使う、または決済モジュールだけ独立バージョンでリリースする必要が出た場合:

• 推奨: slot-kouryaku/commerce を Composer 私有パッケージとして切り出し、テーマ側 core_src/composer.json で semver 固定（例: ^1.0.0）
• 非推奨: Git サブモジュール（worktree 運用・CI・デプロイとの相性が悪い）

パッケージ化時は App\Commerce\ PSR-4 をそのまま維持し、テーマ側は DI 登録と PaidArticleAccessService のみ残す構成が移行コストが低い。