claude-code-conductor 2.72.0__tar.gz → 2.73.0__tar.gz

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/.claude/docs/config-policy.md

@@ -280,6 +280,9 @@ C3 の wheel 配布除外パターンは **3 つのファイルに分散して
 `hatch_build.py` の重複が必要な理由: hatch build hook はパッケージ import 前に走るため、
 `_excludes.py` を import できない。2 ファイルの完全一致が必須。
 
+**KEEP 対象が sdist exclude 配下にある場合は `pyproject.toml` の force-include も同期対象**:
+公開ビルドは sdist を経由するため、sdist から落ちたファイルは wheel にも届かない。
+
 ### 同期確認の方法
 
 `.dev/hooks/_sync_check.py`（PostToolUse hook）が、3 ファイルのいずれかを変更した時に
@@ -289,8 +292,8 @@ C3 の wheel 配布除外パターンは **3 つのファイルに分散して
 
 1. `.gitignore` / `_excludes.py` / `hatch_build.py` のいずれかを変更
 2. `_sync_check.py` の警告を確認
-3. 残り 2 ファイルに同じパターンを追加（または削除）
-4. `python -m build --wheel` で wheel を再生成して実体検証
+3. 残り 2 ファイルに同じパターンを追加（または削除）。3 ファイルが既に同じ意図を持っている場合は、出遅れた 1 ファイルを合わせるだけでよい（配布元の root `.gitignore` を `KEEP_PATTERNS` の意図へ合わせた 2026-08-14 の是正が実例）
+4. 配布元では `python scripts/verify_wheel.py` で wheel 実体を機械検証する（`scripts/` は配布物に含まれないため、利用先には存在しないコマンド）
 
 ### 過去の同期漏れ defect
 

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/.gitignore

@@ -3,8 +3,12 @@
 !.claude/reports/.gitkeep
 
 # Session memory (personal)
-.claude/memory/sessions/
-.claude/memory/archive/
+# ディレクトリ形除外（`dir/`）の中へ git は降りないため否定行が効かない。
+# KEEP_PATTERNS（_excludes.py / hatch_build.py）は各ディレクトリの .gitkeep を
+# 配布対象としているため、`dir/*` 形＋否定行で .gitkeep だけを tracked にする。
+.claude/memory/sessions/*
+!.claude/memory/sessions/.gitkeep
+.claude/memory/archive/*
 !.claude/memory/archive/.gitkeep
 .claude/memory/patterns.json
 .claude/memory/agent-audit.log
@@ -15,7 +19,8 @@
 .claude/agent-memory/
 
 # Temporary files
-.claude/tmp/
+.claude/tmp/*
+!.claude/tmp/.gitkeep
 
 # PO task execution logs
 .claude/logs/

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/CHANGELOG.md

@@ -1,5 +1,33 @@
 # Changelog
 
+## [2.73.0] - 2026-08-15
+
+### 追加
+
+- **リリース前 wheel 実体検証を CI 機械化した**: `scripts/verify_wheel.py`（配布元専用 dev ツール・
+  wheel/sdist 非収録）を追加し、`.github/workflows/test.yml` に `wheel-check` job を新設した。
+  公開経路と同じビルド（sdist 経由）で作った wheel の中身が `src/c3/_excludes.py` の意図
+  （EXCLUDE 不混入・KEEP 全件存在・`breaking-changes.txt` 在／`state/c3_version.txt` 不在）と
+  一致するかを毎 push 検証する。exit code は 0 = PASS / 1 = 違反 / 3 = 検証不能。
+  「除外フィルタが実際には何も落としていないのに緑」になるのを防ぐため、
+  `.claude/state/setup_done.flag` を sdist にだけ注入する正の対照を組み込んでいる。
+- sdist（第二の公開成果物）側の EXCLUDE 混入検査と対照サイズ検査を追加
+  （違反種別 `SDIST_EXCLUDE_VIOLATION` / `CONTROL_NOT_EMPTY`）。違反 detail のサニタイズは
+  正本 `.claude/hooks/_hook_utils.py` の `_TERMINAL_SANITIZE_RE` と同一の全クラス
+  （C0/DEL/C1・ゼロ幅・行区切り・双方向制御・BOM）へ被覆拡張し、sdist member は
+  種別（file/link/dir）で検査対象を振り分ける（EXCLUDE 名前検査は file+link・
+  候補件数の母数と対照系検査は file のみ・dir は全検査の対象外）。
+
+### 修正
+
+- **KEEP 対象の `.gitkeep` が公開 wheel に届いていなかった問題を是正した**: `KEEP_PATTERNS` が
+  配布対象と定めている `.claude/memory/sessions/.gitkeep` と `.claude/tmp/.gitkeep` を新規作成し、
+  root `.gitignore` のディレクトリ形除外（否定行が効かない形）を `dir/*` 形＋否定行へ直した。
+  この是正により、既存の `.claude/memory/archive/.gitkeep` も新たに git 追跡対象になった。
+  あわせて `pyproject.toml` の sdist force-include で `reports/.gitkeep` /
+  `memory/sessions/.gitkeep` / `tmp/.gitkeep` を救済し、sdist 経由の公開 wheel に KEEP 8 件が
+  すべて入るようにした（これまでの公開 wheel は `reports/.gitkeep` 等を欠いていた）。
+
 ## [2.72.0] - 2026-08-14
 
 ### 破壊的変更

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: claude-code-conductor
-Version: 2.72.0
+Version: 2.73.0
 Summary: Multi-agent orchestration framework for Claude Code with Codex/Cursor adapters (C3)
 Project-URL: Homepage, https://github.com/satoh-y-0323/claude-code-conductor
 Project-URL: Repository, https://github.com/satoh-y-0323/claude-code-conductor

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/pyproject.toml

@@ -72,6 +72,24 @@ exclude = [
     ".claude/docs/taxonomy.md",
 ]
 
+# 公開ビルドは `python -m build`（引数なし）＝ sdist を作り、その sdist から wheel を作る。
+# 上の exclude / VCS ignore で落ちるが sdist に入れなければならないファイルをここで救済する。
+# **役割が逆向きの 2 群**が同居しているので取り違えないこと。
+#
+# 群 1: KEEP 救済（wheel に **残る** べき側）
+#   `_excludes.py` / `hatch_build.py` の KEEP_PATTERNS が配布対象と定めている .gitkeep。
+#   sdist exclude に該当して落ちると、sdist 経由の wheel から KEEP が欠落する。
+# 群 2: 注入対照（wheel で **落ちる** べき側）
+#   `state/setup_done.flag` は VCS ignore（root `.gitignore` の `.claude/state/*`）で
+#   sdist から落ちるが、これが無いと除外フィルタが実際に通過する候補が 0 件になり
+#   「空の緑」（何も落とさずに緑）になる。sdist にだけ入れ、wheel ビルド時に
+#   hatch_build の should_skip が `state/*` で落とすことを scripts/verify_wheel.py が検証する。
+[tool.hatch.build.targets.sdist.force-include]
+".claude/reports/.gitkeep" = ".claude/reports/.gitkeep"
+".claude/memory/sessions/.gitkeep" = ".claude/memory/sessions/.gitkeep"
+".claude/tmp/.gitkeep" = ".claude/tmp/.gitkeep"
+".claude/state/setup_done.flag" = ".claude/state/setup_done.flag"
+
 [tool.pytest.ini_options]
 testpaths = ["tests"]
 markers = ["slow: marks tests as slow"]

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/src/c3/__init__.py

@@ -1,3 +1,3 @@
 """Claude Code Conductor (C3) - multi-agent orchestration framework for Claude Code."""
 
-__version__ = "2.72.0"
+__version__ = "2.73.0"

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/tests/test_ci_workflows.py

@@ -1,8 +1,18 @@
 """
 tests/test_ci_workflows.py
 
-.github/workflows/test.yml が `scripts/check_deletions.py --check` を実行する CI job を
-持ち続けること、かつその job の checkout が `fetch-depth: 0` を持ち続けることを守るテスト。
+.github/workflows/test.yml が dev script を実行する CI job を持ち続けることを守るテスト。
+
+対象は 2 系統:
+
+1. `scripts/check_deletions.py --check` を実行する job（＋ checkout の `fetch-depth: 0`）
+2. `scripts/verify_wheel.py` を実行する job（`wheel-check`。P6・**Red フェーズでは不在**）
+
+2 の凍結項目は 4 つ（architecture 改訂 3 ADR-5 改訂 2）:
+(1) job の存在 (2) run に `--wheel` を含まない（公開等価＝実ビルド経路の凍結）
+(3) `build`（PyPA build）のインストールステップ (4) `permissions == {contents: read}`。
+「空の緑」対策（注入対照の実働実証）は script 内蔵のため YAML では測らない
+（tests/test_verify_wheel.py の P8 が凍結する）。
 
 ## なぜ fetch-depth: 0 が本質か
 
@@ -54,6 +64,7 @@ YAML 1.1 のブール解決により、PyYAML の `yaml.safe_load()` は `on:`
 from __future__ import annotations
 
 import os
+import re
 from pathlib import Path
 
 import yaml
@@ -203,3 +214,114 @@ def test_test_yml_check_deletions_job_declares_permissions():
         " 本 job は checkout して読み取り専用の削除検出を行うだけなので、"
         " permissions: {contents: read} を想定している。"
     )
+
+
+# ---------------------------------------------------------------------------
+# P6: wheel-check job（scripts/verify_wheel.py）の静的検査
+#
+# Red フェーズでは job 自体が test.yml に無いため、4 本とも「job が無い」で失敗する。
+# ---------------------------------------------------------------------------
+
+_VERIFY_WHEEL_MARKER = "verify_wheel.py"
+_WHEEL_FLAG_MARKER = "--wheel"
+# PyPA build の導入ステップ（`python -m pip install build` 等）。
+# `pip install -e .` と同一 job 内の別ステップでも良いよう、run 文字列単位で探す。
+_BUILD_INSTALL_RE = re.compile(r"pip\s+install\b[^\n]*\bbuild\b")
+
+
+def _iter_step_runs(job_def: dict) -> list[str]:
+    """job の各ステップの `run:` 文字列を列挙する。"""
+    runs: list[str] = []
+    steps = job_def.get("steps", [])
+    if not isinstance(steps, list):
+        return runs
+    for step in steps:
+        if not isinstance(step, dict):
+            continue
+        run = step.get("run", "")
+        if isinstance(run, str) and run:
+            runs.append(run)
+    return runs
+
+
+def _find_job_running_marker(workflow: dict, marker: str) -> tuple[str | None, dict | None]:
+    """`run:` 文字列に `marker` を含むステップを持つ job を探す（job 名に依存しない）。"""
+    jobs = workflow.get("jobs", {})
+    if not isinstance(jobs, dict):
+        return None, None
+
+    for job_name, job_def in jobs.items():
+        if not isinstance(job_def, dict):
+            continue
+        if any(marker in run for run in _iter_step_runs(job_def)):
+            return job_name, job_def
+
+    return None, None
+
+
+def _require_wheel_check_job() -> tuple[str, dict]:
+    """wheel-check job を取得する。無ければ失敗させる（4 本共通の前提）。"""
+    workflow = _load_workflow("test.yml")
+    job_name, job_def = _find_job_running_marker(workflow, _VERIFY_WHEEL_MARKER)
+    assert job_name is not None and job_def is not None, (
+        "test.yml に 'python scripts/verify_wheel.py' を実行する job が見つからない。"
+        " リリース前の wheel 実体検証（/CLAUDE.md §3・§6 手順 5）を CI で機械強制するには、"
+        " 専用 job（wheel-check）のステップに verify_wheel.py の実行を追加する必要がある。"
+    )
+    return job_name, job_def
+
+
+def test_test_yml_has_wheel_check_job():
+    """P6-(1) test.yml に scripts/verify_wheel.py を実行する job が存在すること。"""
+    _require_wheel_check_job()
+
+
+def test_wheel_check_job_runs_the_build_route_not_an_existing_wheel():
+    """P6-(2) verify_wheel.py の run に `--wheel` を含まないこと。
+
+    `--wheel <path>` は「手元にある既存 wheel を検証する」モードであり、公開経路と
+    同一のビルド（sdist 経由）を回さない。CI がこちらに倒れると、検証対象が
+    「公開される wheel」ではなくなり、実ビルド経路の退行を検出できなくなる。
+    """
+    job_name, job_def = _require_wheel_check_job()
+
+    offending = [
+        run
+        for run in _iter_step_runs(job_def)
+        if _VERIFY_WHEEL_MARKER in run and _WHEEL_FLAG_MARKER in run
+    ]
+    assert not offending, (
+        f"job '{job_name}' の verify_wheel.py 実行に --wheel が含まれている: {offending!r}。"
+        " CI は既定（フラグなし＝ sdist 経由の実ビルド）で実行すること。"
+    )
+
+
+def test_wheel_check_job_installs_pypa_build():
+    """P6-(3) PyPA `build` を導入するステップがあること。
+
+    既定モードは `python -m build` を呼ぶため、build が未導入だと job は
+    BUILD_TOOL_MISSING（exit 3）で常に赤くなる。
+    """
+    job_name, job_def = _require_wheel_check_job()
+
+    runs = _iter_step_runs(job_def)
+    assert any(_BUILD_INSTALL_RE.search(run) for run in runs), (
+        f"job '{job_name}' に PyPA build を導入するステップ（例: "
+        f"`python -m pip install build`）が見つからない: {runs!r}"
+    )
+
+
+def test_wheel_check_job_declares_read_only_permissions():
+    """P6-(4) permissions が `{contents: read}` に完全一致すること。
+
+    job レベルで permissions を明示しないと、GITHUB_TOKEN はリポジトリ設定依存の
+    既定権限で動作する。本 job は checkout してビルドと読み取り検証を行うだけなので
+    最小権限に絞る（deletions-check job と同じ方針）。
+    """
+    job_name, job_def = _require_wheel_check_job()
+
+    permissions = job_def.get("permissions")
+    assert permissions == {"contents": "read"}, (
+        f"job '{job_name}' の permissions が {{contents: read}} と一致しない"
+        f"（実際の値: {permissions!r}）。"
+    )

{claude_code_conductor-2.72.0 → claude_code_conductor-2.73.0}/tests/test_scripts_src_bootstrap.py

@@ -24,13 +24,13 @@ architecture-report-20260804-235224.md ADR-10
 ## 検査内容
 
 1. `scripts/*.py` のうち `c3` を import しているファイルを動的に列挙する
-   （ハードコードしない。3本目が増えても黙って検査を免れない）
+   （ハードコードしない。対象ファイルが増えても黙って検査を免れない）
 2. 各ファイルについて、`PYTHONPATH` を明示的に除いた subprocess で
    `runpy.run_path(<file>, run_name=<"__main__" 以外>)` によりモジュールレベルの
    コード（bootstrap 行を含む）を実行し、`sys.modules["c3"].__file__` を取得する
    （`run_name` を `"__main__"` 以外にすることで `if __name__ == "__main__":` 配下の
    処理は実行されない。ADR-10 改訂3-b の前提: 対象スクリプトは import 時に
-   副作用を持たない = 現行2本は実測済み）
+   副作用を持たない = 現行の対象ファイルは全て実測済み）
 3. その `__file__` が repo の `src/c3/` 配下であることを確認する。
    site-packages 等それ以外を指していたら違反とする
 
@@ -71,7 +71,7 @@ Windows は非 editable のため全緑に見えて検出できなかった）
 
 `-S`（site を読まない）で起動する案も検討したが不採用。`site-packages` 全体が
 落ちるため、`scripts/*.py` が将来 stdlib と `c3` 以外へ依存した時点で**正の対照が
-壊れる**（現行 2 本は stdlib のみと実測済みだが、その前提に検査の正しさを
+壊れる**（現行の対象ファイルは stdlib のみと実測済みだが、その前提に検査の正しさを
 括り付けたくない）。また `sitecustomize` 等 `-S` で消えない注入経路もあり、
 「除去」方式の方が射程が広い。
 
@@ -245,7 +245,7 @@ def _iter_scripts_importing_c3() -> list[Path]:
     """`scripts/*.py` のうち `c3` を import しているファイルを動的に列挙する。
 
     ハードコードされたファイル名リストに依存すると、将来 `scripts/` 配下に
-    第3のファイルが追加され `c3` を import しても、リストへの追記漏れで
+    新たなファイルが追加され `c3` を import しても、リストへの追記漏れで
     この検査を黙ってすり抜ける（CR-NEW Medium 実測・E周回2）。走査結果を毎回
     AST で判定することでこれを防ぐ。
     """
@@ -408,7 +408,7 @@ class TestScriptsResolveC3FromRepoSrc:
 
 class TestResolveC3FileViaSubprocessDetectsViolations:
     """`resolve_c3_file_via_subprocess()` 自体が振る舞いレベルで違反を検出できる
-    ことの合成スクリプトでの裏取り。実運用ファイル（現状2件とも正しい）だけでは
+    ことの合成スクリプトでの裏取り。実運用ファイル（現状は全て正しい）だけでは
     この関数の検出力そのものは裏取りできないため、合成スクリプトで直接検証する。
 
     - 「見逃さない」: ブートストラップが無い/壊れている/誤った場所を指す