Merge pull request #771 from hideyukiMORI/feat/weekly-scheduled-ci

feat(ci): 週次 schedule と workflow_dispatch を追加し外界の変化を検知する (v1.8.169)

Author: hideyukiMORI

.github/workflows/ci.yml

@@ -5,6 +5,37 @@ on:
     branches: [main]
   pull_request:
     branches: [main]
+  # 週次で main をフル実行する（push とは独立に）。
+  #
+  # 検知したいのは「コードの変化」ではなく **外界の変化** — 上流の advisory データである。
+  # 2026-05-30 から 2026-08-12 までの 74 日間、このリポジトリには 1 コミットも無く、
+  # CI も一度も走らなかった。その間にコードは 1 行も変わっていないのに `pip-audit` の
+  # 検出数は 0 → 22 件（pyjwt / cryptography / starlette を含む＝認証と TLS の面）へ増えていた。
+  # advisory は我々のコミットではなく、それ自身の時計で公開されるためである。
+  #
+  # ここでの検知器は `pip-audit`。`uv.lock` をコミットしていて `uv sync` がそれを尊重するので、
+  # 週次実行は「いま固定している版に対する既知脆弱性」を正確に測る。
+  #
+  # 毎時 00 分は GitHub Actions の高負荷帯で schedule が遅延しやすいと公式に明記されているため、
+  # 意図的に 30 分にずらしている。月曜 00:30 UTC = 09:30 JST（週明けの始業時刻）。
+  #
+  # 🔴 既知の限界: public リポジトリの scheduled workflow は、リポジトリの活動が 60 日間
+  # 無いと GitHub により **自動的に無効化される**。上記の空白は 74 日で、しきい値を 14 日
+  # 超えている。つまりこの装置は、それが検知しようとしている状態そのものによって止められうる。
+  # 「週次が動いている」ことを外側から確かめる仕組みは、この workflow では解決できない
+  # （docs/review/2026-08-12.md の後続タスク）。
+  schedule:
+    - cron: '30 0 * * 1'
+  # schedule の初回発火を待たずに動作確認・再実行するための手動トリガー。
+  workflow_dispatch:
+
+# 同一 ref への連続 push で古い実行を打ち切り、CI 時間を無駄にしない。
+# 🔴 `github.event_name` を必ず group に含めること。含めないと schedule / workflow_dispatch の
+# 実行が push の実行に cancel され、「設定したのに走らない」状態になる。設定ファイルは
+# 正しく見えるのに動かないため気づきにくい（nene-origin で実測された罠）。
+concurrency:
+  group: ci-${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}
+  cancel-in-progress: true
 
 jobs:
   check:

CHANGELOG.md

@@ -8,6 +8,32 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ---
 
+## [1.8.169] — 2026-08-12
+
+CI を push から切り離し、週次で外界の変化（上流 advisory）を検知できるようにした。
+
+### Added
+- `.github/workflows/ci.yml` に **週次 `schedule`**（`cron: '30 0 * * 1'` = 月曜 09:30 JST）と
+  **`workflow_dispatch`** を追加。検知したいのはコードの変化ではなく**外界の変化**である。
+  v1.8.167 で解消した 22 件は、コードが 74 日間 1 行も変わらない間に積み上がったもので、
+  CI が push にしか結合していなかったために誰も気づけなかった。
+  `uv.lock` をコミットしているため、週次実行は「いま固定している版に対する既知脆弱性」を
+  `pip-audit` で正確に測る。
+- **`concurrency` グループ**を追加し、`${{ github.event_name }}` を**含めた**。
+  含めないと schedule / workflow_dispatch の実行が push の実行に cancel され、
+  「設定したのに走らない」状態になる（nene-origin で実測された罠）。
+
+### Notes
+- 毎時 00 分は GitHub Actions の高負荷帯で `schedule` が遅延しやすいと公式に明記されているため、
+  意図的に 30 分にずらしている。
+- 🔴 **既知の限界**: public リポジトリの scheduled workflow は、リポジトリの活動が
+  **60 日間**無いと GitHub により自動的に無効化される。本リポジトリの空白は **74 日**で
+  しきい値を 14 日超えており、**この装置は自身が検知しようとしている状態によって
+  停止させられうる**。リポジトリ単体では解決できないため、限界を明記するに留めた。
+  詳細は [日報 2026-08-12 §4](docs/review/2026-08-12.md)。
+
+---
+
 ## [1.8.168] — 2026-08-12
 
 セッションの実測を記録として残し、mcp 2.0 移行規模の過大見積もりを訂正した。

docs/review/2026-08-12.md

@@ -1,7 +1,7 @@
 # 日報 — 2026-08-12
 
 **作業者**: hideyukiMORI
-**バージョン**: v1.8.168（セッション終了時点）
+**バージョン**: v1.8.169（セッション終了時点）
 
 ---
 
@@ -216,7 +216,60 @@ ls .venv/lib/python3.14/site-packages/mcp/server/     # fastmcp が無いこと
 
 ---
 
-## 4. 明日以降の方針
+## 4. 週次の定期再検査を導入（v1.8.169）
+
+§1 の根本原因（CI が push に結合していて、コードが動かない限り外界の変化を検知できない）を
+塞ぐため、`.github/workflows/ci.yml` に週次 `schedule` を入れた。
+
+| 追加 | 値 | 理由 |
+|---|---|---|
+| `schedule` | `cron: '30 0 * * 1'`（月曜 09:30 JST） | 検知したいのは**外界の変化**。検知器は `pip-audit` |
+| `workflow_dispatch` | — | schedule の初回発火を待たずに確認・再実行するため |
+| `concurrency.group` | <code v-pre>...-${{ github.event_name }}</code> を**含む** | 含めないと schedule 実行が push に cancel される |
+
+- **毎時 00 分を避けた理由**: GitHub 公式に「`schedule` イベントは高負荷時に遅延しうる。
+  高負荷時間帯には毎時の開始が含まれる」「遅延の可能性を下げるには毎時の別の時刻に
+  スケジュールせよ」と明記されているため、意図的に 30 分にずらした。
+- **`uv.lock` をコミットしている効果**: `uv sync` が lock を尊重するので、週次実行は
+  「いま固定している版に対する既知脆弱性」を正確に測る。検知器として精度が高い。
+- **フル CI を回す設計にした理由**: 監査専用の workflow を別に作ると、PR のマージ関門と
+  週次チェックが**別々に育って乖離する**。同じ `ci.yml` を回せば「週次で確認しているもの」＝
+  「マージに必要なもの」が定義上一致する。
+
+### 🔴 この装置自身の限界（未解決）
+
+**public リポジトリの scheduled workflow は、リポジトリの活動が 60 日間無いと
+GitHub により自動的に無効化される**（公式ドキュメントに明記）。
+
+本リポジトリの空白は **74 日**（2026-05-30 → 2026-08-12）で、**しきい値を 14 日超えている**。
+
+> **この装置は、それが検知しようとしている状態そのものによって停止させられうる。**
+> 「週次が動いていること」を外側から確かめる仕組みは、この workflow の中では解決できない。
+
+対策はリポジトリ単体では完結しない（外部からの `workflow_dispatch` 発火や、
+活動中のリポジトリからの横断ディスパッチなど）。フリート全体の装置設計に属するため、
+本日時点では**限界を明記するに留める**。
+
+### 通知の実測（誰が赤に気づくのか）
+
+週次で回しても、失敗が誰にも届かなければ「CI が走っていなかった」が
+「走ったが誰も見なかった」に化けるだけなので、実測した。
+
+| 測定項目 | 実測値 |
+|---|---|
+| 通知の配信 | **機能している**（`ci_activity` 通知が実際に生成されている） |
+| 未読通知の総数 | **1,828 件** |
+| うち `ci_activity` | **634 件** |
+| 本リポジトリの未読 `ci_activity` | **128 件** |
+| 最古の未読 | **2026-05-11**（3 ヶ月前） |
+
+**配信は届いている。届いた先が飽和している。** 週次の失敗通知を 1 件足しても、
+1,828 件の山に 1,829 件目として積まれるだけで、検知装置としては機能しない。
+通知経路の設計はフリート全体に効くため別途提案する。
+
+---
+
+## 5. 明日以降の方針
 
 | 優先度 | タスク |
 |---|---|

docs/todo/current.md

@@ -1,7 +1,7 @@
 # TODO — current
 
 最終更新: 2026-08-12
-現状: **v1.8.168 / 依存の既知脆弱性 22 件を解消し CI を緑に復帰 / 471 tests・カバレッジ 93%**
+現状: **v1.8.169 / 依存の既知脆弱性 22 件を解消し CI を緑に復帰 / 471 tests・カバレッジ 93%**
 
 ---
 
@@ -182,7 +182,10 @@ v1.8.161）、#553（#578 で実装済みを確認し close）、ハウスキー
 | — | — | リリース時は `v*` タグ push → publish.yml が自動公開（[手順](../how-to/release-and-publish.md)） | infra |
 | 低 | — | PyJWT 推移的 CVE（PYSEC-2025-183）— mcp 修正待ち | 保留 |
 | 中 | — | **mcp 2.0 系への移行**（2026-08-12 調査済み）— 2.0.0 で `mcp.server.fastmcp` が `mcp.server.mcpserver` に改名。**実測の移行規模は概算 11 行**（`src/nene2/mcp/server.py` の 1 行が唯一の依存点・`src/example/mcp.py` は `LocalMcpServer` 越しで変更不要）。実質的な破壊点は `call_tool()` の戻り値が `CallToolResult` になったことのみ。**着手条件＝`mcp` のバージョン境界の決定**。調査と移行方針は [日報 2026-08-12 §2](../review/2026-08-12.md) が設計ノート。<br>🔴 **訂正**: 当初「`src/nene2/mcp/` と `src/example/mcp.py` の全面書き換えが必要」と記載していたが**過大評価だった**。根拠が「テストが 4 本落ちた」だけで依存の実体を測っていなかった（`grep` で `server.py` の 1 行のみと判明）。着手判断には訂正後の数字を使うこと | 保守 |
-| 中 | — | **依存の定期再検査を仕組み化**（2026-08-12）— コード凍結中でも上流 advisory は増える。実際 2ヶ月半 CI が走らず 22 件が無検知で積み上がった。`schedule:` トリガーの CI か月次 `uv lock --upgrade` 運用の導入を検討 | infra |
+| ~~中~~ | — | ~~**依存の定期再検査を仕組み化**~~ | infra |
+| — | — | ✅ **2026-08-12 解消（v1.8.169）** — `ci.yml` に週次 `schedule`（月曜 09:30 JST）＋ `workflow_dispatch` ＋ `concurrency`（`github.event_name` 込み）を追加。[日報 2026-08-12 §4](../review/2026-08-12.md) | infra |
+| 中 | — | 🔴 **週次 schedule 自体の生存監視**（2026-08-12 判明）— public リポの scheduled workflow は**活動が 60 日無いと GitHub が自動無効化**する。本リポの空白は **74 日**で 14 日超過しており、**装置が自身の検知対象によって止められうる**。外部からの `workflow_dispatch` 発火など、リポジトリ単体では解決できない | infra |
+| 中 | — | 🔴 **失敗通知の経路設計**（2026-08-12 実測）— 通知の配信は機能しているが、**未読 1,828 件（うち `ci_activity` 634 件・最古 2026-05-11）** で飽和している。週次の失敗を 1 件足しても 1,829 件目になるだけで検知装置として機能しない | infra |
 
 ---
 

pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "nene2-python"
-version = "1.8.168"
+version = "1.8.169"
 description = "NENE2 Python — minimal API framework following NENE2's design philosophy"
 readme = "README.md"
 license = {text = "MIT"}