title: KUDO-Vault Stage 1-B2 判定報告（cloud-sync symlink パイロット） date: 2026-05-19 executor: Claude Code (MacBook Pro M3 Pro, Opus 4.7 1M context) handoff: HANDOFF — KUDO-Vault Stage 1-B2 status: 判定C（判定不能）— 観察データ不足。観察延長または能動 trigger テストを推奨 observation_start: 2026-05-19T07:20:04+0900 observation_judgment: 2026-05-19T07:33:51+0900 elapsed_real: 約13分（24時間ではない）
Stage 1-B2 パイロット判定報告¶
結論¶
判定：C（判定不能）
24 時間観察を完了できていない。実経過時間は約 13 分。観察データは 3 点（うち 2 点は初期 30 秒以内、1 点は私が今しがた手動取得）。これでは「symlink が cloud-sync 環境で 24h 持続可能か」の判定にデータが不足する。
ただし 早期signal は有望（後述）。symlink を実 dir に戻すような cloud-sync の能動的修復は観察されておらず、即ロールバックを要する事象は確認されていない。
ロールバックは実施しない（HANDOFF §4 判定C 規定通り、パイロットは現状維持）。
観察データ不足の原因（2 点）¶
1. 実経過時間 ≪ 24 時間¶
| 時刻（JST） | イベント |
|---|---|
| 2026-05-19 07:20:04 | Pilot setup（mv + ln -s 実行） |
| 2026-05-19 07:21:03 | Code が T+0 baseline 記録 |
| 2026-05-19 07:21:30 | LaunchAgent RunAtLoad 発火（初回かつ唯一） |
| 2026-05-19 07:29:53 | Code が手動再観察（pilot 後の最初の有意な点） |
| 2026-05-19 07:33:51 | 判定実施（now） |
経過時間：約 13 分。24 時間後（2026-05-20 07:20）には到達していない。
2. Observer LaunchAgent の hourly 発火が未到来¶
launchctl print 確認：
これは「失敗」ではなく正常な待機状態。設計は StartInterval = 3600（1時間ごと）＋RunAtLoad = true（登録時に1回）。初回発火は 07:21:30 で正常完了済み。次回発火予定は 08:21:30（まだ来ていない）。
→ Observer に不具合はない。単に時間が経っていない。
観察された 3 点のスナップショット比較¶
| 観察時刻 (JST) | 経過 | PLUGIN_PATH_TYPE | SKILL_MD hash 一致 | PLUGIN_BAK | manifest lastUpdated |
|---|---|---|---|---|---|
| 07:21:03 (T+0) | 0s | symlink → Vault | ✅ 3経路一致 | still present | 1779138387720 (06:26) |
| 07:21:30 (LaunchAgent RunAtLoad) | +27s | symlink → Vault | ✅ 3経路一致 | still present | 1779138387720 (06:26) |
| 07:29:53 (手動) | +9min | symlink → Vault | ✅ 3経路一致 | MISSING ★ | 1779143216590 (07:26) |
早期 signal（13 分時点）¶
✅ Signal 1：symlink は 1 回の cloud-sync 周期を生き残った¶
07:21:30 と 07:29:53 の間に、cloud-sync が manifest を更新（06:26 → 07:26）。しかし PLUGIN_PATH_TYPE は依然 symlink → Vault のまま。cloud-sync は manifest 登録名と一致する symlink を破壊しないことが示された（少なくとも 1 周期分）。
✅ Signal 2：manifest 内の skill entry は安定¶
MANIFEST_SKILL_UPDATEDAT: 2026-05-13T23:17:23.008393Z が変化していない。enabled: True、desc_len: 517 変化なし。cloud-sync は kudo-mac-health-check を「再ダウンロード／修復対象」とは認識していない。
⚠️ Signal 3：cloud-sync は skills/ を能動的に reconcile している（重要な新発見）¶
PLUGIN_BAK: still present → MISSING への変化は 私が削除していない。find ~ -name 'kudo-mac-health-check.bak.2026-05-19*' で全 home 配下 0 件 hit。
タイムライン：
- 07:21:30：kudo-mac-health-check.bak.2026-05-19/ 存在
- 07:26:56：manifest.json が cloud-sync で更新（lastUpdated 変化）
- 07:29:53：kudo-mac-health-check.bak.2026-05-19/ 消失
→ cloud-sync は manifest 未登録の top-level dir を能動的に削除している。
これは判定とは独立した重要発見：
- symlink 自身は manifest 名と一致するため保持される（Signal 1）
- 一方で .bak.YYYY-MM-DD 形式の rogue dir は cloud-sync が掃除する
- ロールバック戦略は「skills-plugin 配下の .bak」に依存できない
なぜ判定 A ではないか¶
「symlink は 1 周期生存」は良い signal だが、判定 A（成功）には不足：
- 観察周期が 1 回のみ：複数回の cloud-sync イベントを跨いで安定するかが不明
- daily 03:30 auto-snapshot cron が未発火：pilot 後の最初の cron は 2026-05-20 03:30 JST。auto-snapshot.sh が symlink をどう Drive へ転送するかは未観察
- claude.ai web 側の確認なし：HANDOFF §2-4 で「web のスキル機能で正常に見えるか」確認を要求しているが、これは工藤さん側の操作要件
- 観察データ点が事実上 1 点（T+0）と 1 点（T+9min）のみ：時系列の傾向を語るには少なすぎる
判定 A を後で発令するには、最低限： - 24 時間継続観察（少なくとも 5-10 個の hourly snapshot） - 翌日 03:30 cron 後の auto-snapshot.sh の symlink ハンドリング確認 - claude.ai web からの動作確認
を満たす必要がある。
なぜ判定 B ではないか¶
判定 B（失敗）の trigger 条件： - symlink が実 dir に戻された：該当なし（依然 symlink） - スキル破損／半壊：該当なし（hash 一致継続） - web 側でスキルが消えた／壊れた：未確認
13 分時点で symlink は健全。即ロールバックを発動する根拠なし。
PLUGIN_BAK MISSING は startle するが、これは pilot symlink 自体の破損ではなく「同居していた rogue dir の掃除」。ロールバック可能性自体は別経路（Vault・Drive・local snapshots）で温存されている。
ロールバック可能性の現状再評価¶
.bak.2026-05-19 が消えた以上、HANDOFF §2-5 記載のロールバック手順は使えない。ただし以下 4 経路から復元可能（影響ゼロ）：
| 復元元 | 状態 | バイト数 |
|---|---|---|
Vault ~/KUDO-Vault/.claude/skills/kudo/kudo-mac-health-check/SKILL.md |
✅ 健全 | 9294 |
Drive ~/.../kudo-skill-sync/skills/kudo-mac-health-check/ |
✅ 実 dir として健全 ＋ Stage 1-A2 の .bak.2026-05-18 同居 |
9294 |
| Local snapshot 2026-05-19 | ✅ 実 dir として健全 ＋ Stage 1-A2 の .bak.2026-05-18 同居 |
9294 |
~/.claude/skills/kudo-mac-health-check（Stage 1-B Phase 2 symlink 経由で Vault） |
✅ Vault と同期 | 9294 |
更新版ロールバック手順：
PLUGIN="$HOME/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/3d48e787-cadf-495d-ad7f-bc26535863ce/29545076-9f99-4406-b410-8c4409db721c/skills"
# Step 1: symlink を除去
rm "$PLUGIN/kudo-mac-health-check"
# Step 2: Drive から実 dir を復元
DRIVE="$HOME/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/マイドライブ/working/claude/kudo-skill-sync/skills/kudo-mac-health-check"
cp -pR "$DRIVE" "$PLUGIN/kudo-mac-health-check"
# Step 3: 検証
shasum "$PLUGIN/kudo-mac-health-check/SKILL.md"
# → 521ad1f1d1a6958affe30876916c91f33dde2b84 が出れば成功
所要時間：約 10 秒。
推奨される次アクション（HANDOFF §4 判定C 規定）¶
Plan-1（推奨）：観察延長 24 時間 ＋ daily cron 通過確認¶
- 現状 symlink を維持
- 2026-05-20 07:20 JST まで観察継続
- 観察期間中に 2026-05-20 03:30 JST の daily auto-snapshot cron が発火
- cron で auto-snapshot.sh が symlink をどう Drive へ転送するか観察できる（symlink を symlink として転送する／実 dir に展開する／エラー）
- Observer は今のままで OK（hourly に発火する）
Plan-2：能動 cloud-sync trigger テスト¶
工藤さんに依頼可能： - claude.ai web で kudo-mac-health-check 以外の任意のスキルを微小編集（例：description 末尾にスペース追加→削除など） - これで cloud-sync が確実に発火する - 1〜5 分後に Code が再観察し、symlink が依然 symlink のままかを確認
この場合、判定までの時間を Plan-1 の 24h から数分〜数時間に短縮可能。ただし pilot 対象自体は触らない（変数増やさない）。
Plan-3：Plan-1 と Plan-2 の併用（最堅実）¶
- Plan-1 で時系列観察を継続（24h 観察を完遂）
- 並行で Plan-2 を 1 回だけ実施し、即時 sync trigger 後の挙動も記録
- 判定材料が大きく増える
Observer LaunchAgent の動作確認（再述）¶
判定 C を出すにあたって observer が機能していないと続けられないため、最終確認：
runs = 1 # RunAtLoad で 1 回発火（正常）
last exit code = 0 # 成功
state = not running # 次の StartInterval 待ち（正常）
StartInterval = 3600 # 1 時間ごと
next fire ≈ 08:21:30 # まだ来ていない
→ observer は機能している。08:21:30 JST 以降、hourly に発火する。
Mac uptime: 21:02（21 時間稼働）。observation 期間中 Mac がスリープに入ると StartInterval は deferred されるが、起きていれば毎時動く。長時間スリープが予想されるなら StartCalendarInterval の毎時複数エントリへの切替を検討（現状では不要）。
検証チェックリスト¶
- observation log を精査
- pilot setup からの実経過時間を厳密測定（≒13分）
- symlink 状態の現在確認（symlink → Vault のまま）
- 3 経路 hash 一致確認（Vault・Drive・symlink 経由）
- manifest.json 内 kudo-mac-health-check entry の安定性確認
- cloud-sync 活動の証拠確認（manifest lastUpdated 更新、.bak 削除）
- observer LaunchAgent の動作確認（runs=1 正常待機）
- ロールバック可能性の代替経路確認
- 判定 A/B/C のうち、どれが妥当かを根拠付きで結論
- 24 時間後の本判定（Plan-1 完了時に別ファイル
stage1b2-pilot-result-2026-05-20.mdで）
工藤さん・Chat への申し送り¶
1. 判定 C の確定理由¶
24 時間観察が完了していない（実 13 分のみ）。HANDOFF タスクD の「判定不能」基準「24時間で結論が出ない／cloud-sync が動いた形跡がない」のうち前者に該当。後者は逆に「cloud-sync は動いている」が確認されたため、観察延長で判定 A/B が出る見込みは十分。
2. ロールバック実施せず（HANDOFF §4 判定C 規定通り）¶
symlink は健全。即ロールバックを発動する材料なし。現状維持で観察延長。
3. 工藤さんへの選択肢¶
Chat 側で次のいずれかを起票してほしい： - (A) Plan-1：受動 24h 延長（明朝 2026-05-20 07:20 JST に再判定。observer hourly + daily cron 通過で十分なデータが集まる） - (B) Plan-2：能動 trigger テスト（工藤さんが web で他スキルを微小編集して cloud-sync を発火、Code が即時再観察） - (C) Plan-3：両方併用
4. 新発見：cloud-sync の reconciliation 挙動¶
.bak.2026-05-19 が cloud-sync によって削除されたことから、cloud-sync が skills/ 直下を能動的に reconcile していることが判明。Stage 1-B2-full（46件 bulk symlink 化）時の運用にも影響する：
- 一括 symlink 化時は、各 dir の .bak も同じく削除される
- ロールバック手段として skills-plugin 配下の .bak に依存しない設計が必須（Vault・Drive・snapshot を頼る）
これは判定 A/B のどちらが出ても、Stage 1-B2-full HANDOFF を起票する際に組み込むべき設計知見。
5. observer の継続稼働¶
判定確定までの間、observer LaunchAgent は稼働継続。次回判定時に hourly snapshot がいくつ蓄積されているかが判定の質を決める。
ファイル一覧¶
新規作成¶
~/working/_claude_workspace_global/reports/stage1b2-pilot-result-2026-05-19.md（本ファイル・判定C）
変更なし¶
- skills-plugin path の
kudo-mac-health-check（依然 symlink → Vault） - Vault
kudo-mac-health-check（無変更） - Drive
kudo-mac-health-check（無変更・実 dir のまま） - observer LaunchAgent（稼働継続）
cloud-sync が変更（観察された）¶
- skills-plugin path の
kudo-mac-health-check.bak.2026-05-19：消失（cloud-sync 由来） manifest.jsonlastUpdated：1779138387720 → 1779143216590（60 分後の自動更新）