[debt] doeff / core-effects / doeff-hy の配布依存を一方向へ直す

[proboscis]

結論

配布単位としての doeff、doeff-core-effects、doeff-hy が循環依存しています。workspace 内では同時に解決できても、どの配布物が下位層かが決まらず、単独リリース、import 境界、互換性判断を難しくしています。

確認済みの事実

2026-07-16 の main (b69f77b7) で確認しました。

doeff
  -> doeff-core-effects

doeff-core-effects
  -> doeff
  -> doeff-hy

doeff-hy
  -> doeff
  -> doeff-core-effects

根拠:

• root pyproject.toml:23-26
• packages/doeff-core-effects/pyproject.toml:5-9
• packages/doeff-hy/pyproject.toml:11-15
• root import は循環を避ける順番に依存しており、doeff/__init__.py:7 にその事情が明記されています。
• release runbook も依存グラフの整理を後続作業として記録しています。
  • docs/release-publish-runbook.md:88-90

影響

• 下位の効果定義が上位 facade を import し、上位 facade が効果 package を再公開するため、層の責任が逆流します。
• package を一つだけ build / publish / install したときの成立条件が分かりにくくなります。
• import 順序が意味を持ち、初期化時の部分構築や循環 import を避ける知識が利用者側へ漏れます。
• doeff-hy の macro 層と doeff-core-effects の効果層を独立に進化させにくくなります。

設計上の目標

最低層に、Program / Effect / handler / VM bridge の依存中立な核を置きます。その上に標準効果、Hy macro、利用者向け facade を一方向で積みます。

例:

kernel
  <- core-effects
  <- doeff-hy
  <- batteries-included facade / CLI

正確な package 名は実装時に決めますが、循環を optional dependency や import 順序で隠すだけの修正にはしません。

完了条件

• 配布 metadata の依存グラフが有向非巡回になる。
• doeff-core-effects が batteries-included な root facade に依存しない。
• doeff-hy と doeff-core-effects の相互依存を解消する。
• 各 package の wheel を個別に build し、隔離環境で import smoke test を行う。
• publish 順序と互換性方針を release runbook に明記する。
• workspace source override がなくても、公開された依存だけで install が解決するテストを追加する。
• 循環 import を理由にした import-order 抑制を削除するか、循環と無関係な理由へ限定する。

対象外

• scheduler や VM の挙動変更。
• すべての root re-export の同時削除。公開 API の階層化は別 issue で追跡する。